What makes an effective product engineering strategy? In the debut episode of the Velocity’s Edge podcast, host Nicko Goncharoff speaks with Sarah Wells about the importance of strategy to engineering effectiveness.

Can you really have separate business and product-engineering strategies? Why is creating a clear strategy so difficult? Do engineers in your organization know what the strategy is? How are you communicating this?

It’s a densely-packed, 20-minute listen.

Sarah is a recognized leader in software engineering, with a focus on microservices, DevOps, and engineering enablement. She played a pivotal role at the Financial Times, where she helped scale deployments from 12 to 20,000 releases per year. Sarah is a frequent speaker and the author of Enabling Microservices Success.

As in all our episodes, we speak in plain, executive-summary business terms, framing complex business and technology strategic challenges in context, using language that makes them more accessible and actionable.

Listen here, download it from Apple Podcasts, Spotify, or find it wherever you get your podcasts.

Episode Information

Season 1, Episode 1
Length: 18 minutes, 41 seconds
Host: Nicko Goncharoff
Guest: Sarah Wells
Recorded: VOXPOD Podcast Studios, Parsons Green, London
Engineer: Dayna Ruka
Editor: Dayna Ruka, Jeet Vasani

Episode Transcript

Nicko Goncharoff (HOST): Hi, this is Velocity’s Edge podcast. I’m Nicko Goncharoff and with me is Sarah Wells. She is the lead consultant for Engineering Effectiveness at EPSD. Today we are going to talk about the importance of strategy to engineering effectiveness.

Sarah Wells: Yes. Let me start by saying that I have worked in a lot of places where it’s been very hard to understand what the strategy is. And I think if you were to ask the average engineer, even in places where there is a technical strategy, I don’t think it’s something that’s normally shared often enough for people to know exactly what it is.

And I think it’s important because if you want to have autonomous teams being able to make their own decisions, you want that autonomy to be what people at Spotify call “aligned autonomy,” so we are all at least going in the same direction.

What you don’t want is that every team is autonomous, and they’re all pulling in completely different directions, and you’re not moving with purpose in the direction that the company needs you to move. So I think strategy is super important.

NG Yes, very.

SW I think it’s very hard to have a technical strategy without a product strategy and a business strategy. But still you can start in an engineering team with a technical strategy, even if some of those other things aren’t there. And generally speaking, I think there are two challenges.

The first challenge is to come up with the strategy that actually is strategic. So almost everyone that I know that talks about tech strategy refers to a book by Richard Rumelt called Good Strategy, Bad Strategy, and I love it. It’s a really great book because it basically says, well, you know, if you’re going to have a strategy, it has to be something that you can imagine doing the opposite. So there has to be a decision where you’re deciding to do this thing, but not that thing, because otherwise it’s just hopes and prayers. You know, it’s basically, oh, we’re going to be really great at this and at this, but you’re not making any choices there.

SW: The strategy is about having to make choices with the resources that you have. What thing are you going to do? So Rumelt says there are three aspects to a strategy. The first is the diagnosis. What is the challenge? What’s the most important challenge that we’re facing right now?

The next thing is guiding policies. How are we approaching that challenge? And finally a set of actions that you identify that will start to move you in the right direction according to the guiding policies. So I think that can be really helpful.

An example perhaps from my time at the Financial Times is we basically said one of the things we wanted to do is be out of our data centers. We want to be entirely in the cloud. One of our actions was, we’re going to be out of the data center by 2020. And actually, if you asked any engineer at the FT, they’d have known cloud only 2020 was a thing for several years. Having that identified, what’s the most important challenge, saying, how are we going to approach solving it and having some identified action so that you go back and you revisit is really important.

But the next thing about that is actually communicating it in a way that lands with your team. My experience of creating strategies is the people who are creating a strategy get sent off to do it, and they spend several months having meetings and talking about it, and they come up with the strategy and they send out an email and they mention it in a showcase, and then no one ever talks about it again.

NG: Right? It goes to PowerPoint death.

SW: Well, yeah, I think the problem is people have in their head that you have achieved the goal when you finish writing the strategy, but you haven’t because you haven’t effectively communicated.

NG: You haven’t implemented it.

SW: No, you haven’t implemented it, but also you haven’t got it to the point where it’s second nature and it’s guiding everyone’s decisions. If it’s not something that people can make decisions based on, well, I know this is the direction we should be going. You haven’t really got a strategy. You’ve got a document. You have a PowerPoint.

NG: Yeah. And I think this actually applies to not just technical strategy but business strategy as well. Product strategy and I see what you mean about you can have a technical strategy absent a clear business strategy. But because one of the things that- so I’m coming from the perspective of working on the business side of multiple, you know, machine learning focused startups and working in informatics companies. And a clear strategy can often be quite elusive.

And the further you get away from the senior team, the less clear it is. I think that communication of strategy is really absolutely crucial. And then consistency of strategy seems quite important as well. I think you have to get people to buy in and then believe.

SW: Yes. Well and so when I say you can develop a technical strategy without the other two, it’s not that it’s not ideal, it’s just sometimes you have to do it because you’re not in control of making sure that there is a well communicated business strategy or product strategy, and you can’t wait until that gets done, because it can take time. You have to make some decisions so that you’re providing direction to your group.

And I think also within engineering, for example, some of what you do and I worked as an engineering director, some of what you do is you translate that overall engineering strategy into something that applies for the people that are in your part of the organization. So maybe not all of that strategy is relevant. So how do you make it so that people understand what does that mean for you. There’s like a translation layer involved in any of this.

And I actually think that it’s important to think about, well, what’s our strategy within our part of the group that feeds into that wider engineering strategy. So that people … the aim is that anybody making decisions can make a decision knowing whether or not it’s complying with the direction of travel. Because as soon as you make it harder, like people don’t know whether I should adopt this technology or this technology, I don’t really understand which of these would align us with the strategy. You’re just slowing everything down.

NG: Right. So from the C-suite vantage point, not having I mean, we’ll leave the business in product strategy to the side for the moment because presumably they’ll maybe they’ll have a handle on that, maybe they won’t. But not having or not effectively communicating a technical strategy looks like slowed velocity. It looks like maybe some morale issues.

SW: Yeah. And it might look like several teams doing work in the same area that overlaps. It might mean that you’re basically wasting some of your efforts because several people are trying to solve the same problem in different ways, because there’s no common idea of which of these is the right path.

NG: Right. And that can lead to people trying to solve the same problem using different tools.

SW: Yeah. Yeah, absolutely. And that might be, to be honest, your strategy might be that that’s okay. Your strategy might be we are willing to set different teams off using different technologies. And then at some point we’ll make a decision on which of these work the best. But that should be a deliberate thing rather than an accidental thing, right?

NG: Because deliberate, you’ll be able to measure the outcome, whereas if it’s accidental, you’re not measuring anything. Probably.

SW: Yeah. And deliberate you’re saying to people, we’re taking a couple of bets and we’re going to do an assessment at the end. And that’s a lot easier to deal with than turning around to someone when they’ve invested six months into something and saying, actually, this is a duplicate of other work, and we’re going to stop the work on it because that’s really hard on morale. So you want to be very conscious of what you’re doing.

So I think having that strategy is so important and the communication side of things, I saw this really great model about communication that said, it’s not enough to transmit the information. You have to make sure it’s been received and understood and that people have agreed with it, and then finally that they’ve converted it into actions they’re going to take. And I think that’s a really good model for when you’re trying to talk to people about anything not just strategy, but anything is to basically go. Did they get the message? Did they understand it applied to them, and have they worked out what that means?

And this applies for things like security migrations. There’s all kinds of activities that you do in an engineering department where you want to make sure everyone has understood that there are things they need to patch, there are things they need to migrate to, that this work needs to happen by a certain time. So I think that model of communication is really, really useful.

NG: And that does tie back to the strategy too, because if you understand that so security is a good example right. Security is often seen as just a compliance box ticking exercise. But it’s actually really really fundamental to your revenue, to the integrity of customer data, to your competitive advantage or lack thereof. But that has to be communicated. And people need to know how they can contribute to that.

SW: Yeah. So I think that it is really great when I’ve worked as a principal engineer. It’s great to understand what do I need to do? Because often with things like security, things that you’re not an expert in yourself and your team, you just want to be able to work out, what do I need to do? Do I need to put these scanning tools into my build pipelines? Do I need to what do I need to fix? How long do I have to fix it?

Clarity about what those expectations are makes your life much easier. And one of the things that we had at the Financial Times was this idea of an engineering checklist that said, here’s what we expect when you’re building a system. Here are the things that you must do. There must be security embedded. Here are the things you need to put in place to make that work.

We want to understand every change that we’re making in the production. So every change should be logging that change into this API that allows us to know what’s changed and where and when and who by. We want to have observability for all of our systems. We want all of the logs to go to the single log aggregation system using a common structured format so that we can see across all of our different services what’s happening.

So I think that clarity of expectations also really helps. I just think that every time that you’ve got engineering teams basically saying, I don’t understand what I need to do for this thing. You’ve lost the opportunity to speed them up.

NG: Right? And that goes to something you touched on earlier with me about engineering satisfaction.

SW: Yes.

NG: Right. Because I think, as you said, engineers want to solve problems and because maybe senior management don’t understand they don’t have maybe they don’t have a technical background or they just don’t understand the challenges that engineers face there. There can be this perception that, oh, they’re just going off and working on whatever they want. But I have rarely met an engineer that actually has that mindset.

SW: No, I mean, I think there’s always an element of being enthusiastic about new technologies that you need to balance with other stuff. But generally people are trying to they’re looking at them because they want to use them to solve problems that they can see. Business problems generally, the more that you can explain what the business problem is to your engineers, the better.

I think back to when I was first a developer and everything came through multiple layers. I never spoke to my stakeholders because they spoke to the product owner who spoke to the BA, who created a story, and it came to me, and anything that was missing had to go back through several people. It’s much more efficient when I’m talking directly to the people who have a problem, and I can really understand what it is that they need from me.

And I think anything that allows your engineers to really understand what they’re trying to solve more easily, with fewer layers in between is good.

NG: Yes. That was a hard lesson learned for me. My first startup, where we were actually based in California. The development team was in New Zealand, but we would visit New Zealand and we would get together with the developers and we would meet with them about technology. But when it came to sales, the engineers said, oh well, we need to be a part of this meeting.

And my big mistake, this is my first startup was no, no. And what I inadvertently was doing was cutting them off from information about the goals of the business. And we recognized that. And we actually started bringing some of the engineers on sales calls with us. I mean, that’s not a scalable model, but we were ten people. And so we could do it from time to time.

And then after that first six months of letting them talk to customers and having a few representatives, either in our meetings or receiving communications about business goals and the strategy, we got a lot better. We really did. Our velocity increased. We still had I mean, it was our first startup. We still made mistakes. But putting in an artificial barrier between business and engineering is never a good idea.

SW: No, but going back to the original topic of this podcast, the strategy helps with this. The business strategy, the product strategy, the engineering strategy, they should all be things that provide you with that. What is it we’re trying to do as a group and that you should be able to go back to it?

And I think that having it well communicated and being able to look at whether it’s still the right strategy periodically, because I think sometimes you get to the point where you go, I don’t know that this is the decision I want to make right now. Well, that might indicate that you need to re-look at the strategy.

NG: It’s important for it to be bidirectional as well, because of course, if your business goal or strategy is not achievable technically, then you have to reconsider it. And I’ve been in situations like that as well. I mean, we had early AI startups before the resources of today were available. And we thought we could solve some problems that in the end, it turned out we couldn’t at the time.

SW: Yeah. And there should be the opportunity for technical changes to feed upwards. So you should be able to have an engineering team say, hey, you know, there’s this really interesting new thing. And we think it might offer us new ways to solve problems. I think so. Marty Cagan is someone who talks a lot about product.

And one of the things he said is if you’re not using your engineering team to input into your product decisions, you’re wasting a resource. You’re not taking most advantage of it. And I think that’s really for me, it’s I really enjoyed that as an idea because he’s someone who comes from that product side and he’s saying like, make sure you are including engineers in your ideas.

NG: If we were to try and summarize a few key takeaways, I’m probably going to leave most of this to you. But one is that effective communication between senior management and engineering is crucial, and it needs to be the information needs to flow both ways. Ideally, a consistent strategy, a business strategy is critical and we didn’t really delve into that. But you also need- if you continually pivot, you can lose- people can lose faith, right? Because they’ve spent- they may have spent six months, nine months working toward a release, and all of a sudden they’re told that all the work that they did was never going to be used.

And that’s you don’t want to tell someone who’s dedicated and motivated and driven to solving problems. That’s a very deflating moment when they’re told that. But also it’s recognizing that the implementation of strategy, the communication of strategy and you’re, what you mentioned about you’re communicating, then you see that they receive it. You see that they understand it. I might interject getting feedback and whether you need to adjust it, and then also how they implement the strategy. Only then do you actually have a strategy. Is that a fair summary?

SW: Yes. I think if I was back in a permanent leadership role somewhere, I would be saying, okay, let’s ask the question. Let’s ask everyone in our engineering department what is our strategy? What are the three points of our strategy? And I would be surprised in most places whether you get that much back that’s consistent. So I think you could easily check. Do people really understand what is our direction of travel, what we’re trying to achieve. And I think that time invested in communicating that would be worth it. Definitely.

NG: I’d be very shocked if anybody was very clear on it. Just based on my past experience.

SW: Well, I think that’s a miss. I honestly think it’s a miss. And I think that when I was a senior engineer principal, I really liked to understand what I was trying to achieve. And I think that having an idea of “this is the direction of travel” helps with that. And that’s what your strategy gives you.

NG: And the great thing about that is it can be implemented for free. You don’t need to hire any additional people. You don’t need to license any more technology. You just need to sit back, look at how your communication channels are structured. Look at how people are motivated. And you can probably figure it out.

SW: Definitely.

NG: I’m not saying it’s easy. I’m just saying it can be done. Communication is- communication is challenging.

SW: Yes. So I think there’s a couple of things that makes me think about. One is it’s really interesting when you first start working with a company to ask people their understanding of the strategy. And quite often, people are like, well, I’m not really sure. I think we’re trying to do this. So I think that’s a really, really useful thing.

But I also think that strategy is a bit like brand. So someone said to me once, you know, people don’t like the idea of having a personal brand, but you have a personal brand whether you actively work on it or not. There’s something people think of when they think of you, so you should probably consider how do you want to be perceived? I think strategy is the same. You know, people will make assumptions about what the strategy is. If there’s nothing there to document it, it’s just their assumptions won’t be the same. They’ll all be working towards a different mental model of what that strategy is. And that is just inefficient.

NG: Interesting. The relationship to the personal brand, I realized yes, I don’t like the idea of having a personal brand, but you’re absolutely right.

SW: Honestly, it hit me so hard when this was from some training I did years and years ago, and I just went, oh, that’s a really great point.

NG: Yeah. And tying it back to strategy because you’re right. If you look at strategy in terms of how it’s perceived internally, then you can start looking at where the gaps in communication or understanding are. Well, this has been fascinating. Thanks very much, Sarah.

SW: You’re welcome. It’s been fun.

NG: This is Velocity’s Edge podcast, I’m Nicko Goncharoff.