Giving Product Engineers Autonomy In Decision Making

How can you empower software engineers to make product decisions without expecting them to fully become product managers? And equally, how can you enable product managers to make technical decisions without expecting them to become engineers? Today we're talking about decision making authority and how you can share context from around your product and around your organisation so that people are empowered to make decisions they can be held accountable to while also having the context to be able to make those decisions. (Music) Hi, I'm James Charlesworth. Welcome back to the Product Engineering Podcast. And today we're talking about decision making autonomy on product engineering teams. Imagine you're building product and you are trying to drive a particular outcome inside that product, but every single idea you have and every single change you want to implement requires somebody else to come in and give you authority to make that change. That's going to slow you down. And it's also going to make it very, very difficult to hold you accountable for driving that outcome. So for an effective product engineering team to function, you need to give that team as much decision making authority and autonomy as possible, even when they don't always initially have the context required to make those decisions. So in that intro, I talked about the example of how do you get a software engineer to be able to make product decisions or how do you get a product manager to be able to make technical decisions? Well, the answer to that is to create a mechanism in which you can share context that doesn't automatically remove decision making authority. Let's say you want to get your house redecorated and you just hired like a designer, like an interior designer. There are two ways you can do it. You can either say to designer, this is what I want the house to vaguely look like. I quite like greens. I quite like this style. And then you set them off and go and ask them to achieve that. Or you can micromanage them and every single piece of paint that they buy or every single piece of furniture they try to put somewhere, you stand in the corner and you say, no, no, no, move that to the left by five centimeters or whatever it is. One of those two is going to give you a better house. It's the one where the designer that you've hired is actually allowed to decide what to put where and what to create. And your job in that situation is not to micromanage them. Your job is to provide them with enough context about the outcome you want them to achieve with your interior. That will allow them to use their own creativity and their own decision making authority to give you a better outcome. And I'm sure we've all experienced micromanaging like that. It's very demoralizing. And ultimately, not only does it slow people down, but it also reduces the quality of the final result. Because just because you know in your heart, like what exact color you want your room to be, by trying to over communicate or over control what that's going to be, the person doing the work is going to move a lot slower. We've seen this in software engineering all the time. Let's say you're an engineering team and every single piece of code or pull request you need needs to be signed off by somebody elsewhere inside your organization who isn't working on the thing that you're doing. In larger organizations that are working on larger code bases, there often are silos of knowledge around certain parts of the code base. And organizations usually have to put mechanisms in place to allow that information to flow from the experts in that domain to the people that actually need to make changes in that area without taking away decision making authority. So an example might be if you have a front end engineering team that's trying to work on a user interface, and then over here you have a back end team that's building an API. Now if that front end team is being asked to do something, maybe they're trying to build a feature or they're trying to put something inside that user interface, that's the thing that the front end team or maybe they have a couple of back end engineers. But a front end team is being asked to change that, but they don't understand the API. There's two ways they can go about it. They can either take their mission of driving this front end change, go to the API team and say, this is what we're trying to achieve. Can you go and build it for us? Or can you build this functionality and then allow the API team to make all the technical decisions? Or you can go to the API team and say, this is what we're trying to achieve. Can you show us how the back end works? Can you show us how the API works? Give us the context behind why these end points are structured like this, then we'll take that information away and we will make the decision. Now, a lot of organizations get stuck in that first model where they think that the people that know the code the best should always be the ones making the decisions around it. And that happens between products and engineering as well. People assume that product managers know everything about the customer and the user and the context and the history of the product. So they should be making all of the decisions, but that can actually be a failure state for a couple of reasons. The first reason is simply speed. Product managers are usually quite overworked. If every product's change that a team wants to make has to go through a particular product leader who maybe has all the context around that, you have to wait for them to learn about what you're trying to do to make that decision and document that decision and then you can carry on with your work. That's just going to slow everything down. The second thing it does is it removes accountability. Because if you are a product engineering team and you're trying to drive a particular outcome and you're doing an experiment or you're building something that might not be in the final product, if every single one of those decisions has to go to somebody who's not being held accountable to the same outcome that you are, then ultimately they're making a decision that they're not going to be held accountable to. They might be the expert in that domain, but if you ask somebody to make a decision that they're not going to be held accountable or if it goes wrong, then you're going to end up in a really weird failure state where the team that were actually building the thing that you were trying to hold accountable for that change are not being given the autonomy to make those decisions and the decisions are being made by people that don't really have skin in the game just because they're experts. This is a really, really important concept to be able to break down and you need to build a mechanism inside your organization where context can be communicated on a request for context type basis where people who are empowered to make decisions can go out and they can seek context and they can educate themselves, but then they still have the authority to make those decisions. Imagine a football manager on a team who tells every single player, "Oh, you have to pass here now. You have to pass here. You have to pass here." That's not their role. They might have all the context about how the other team is playing and all of that, but ultimately, football managers need their players to be able to take autonomous decisions. The role of a manager in a football team is to have that kind of high level picture and then educate the team on that high level picture without actually micromanaging every single thing that they do so that the players themselves are making decisions. You can hold those players accountable to making those decisions. Your defenders might come to you and they might say, "Is this team going to play a high press today?" or "How are they structured?" The manager's job there is to tell the team to educate them on what they know, what they need to know to be able to do their job, and then they go out and they decide how they're going to pass it, when they're going to pass along, all that kind of stuff. That's the way effective football teams work and it's a way effective product engineering teams work as well. When the deep context behind some piece of work is isolated to a few individuals, you need a mechanism that can get the information out of their heads or out of the data that they understand towards the people that you're trying to empower to make decisions, instead of creating a mechanism where those people have to sign off steps. Now, this doesn't go for all decisions, for example, like security. Security teams will often need to have the authority to make a decision based on security. So with a security model, like you will go to a security team and you'll describe what you're trying to do and they will say yes or no, you're not allowed to do that. That's slightly different, but with a lot of product decisions, there are some decisions that can be reduced down to local decisions that won't have a huge amount of impact if they're wrong, and therefore you need to allow the product engineering team to make those decisions. I'll give you an example that goes the other way around. On this podcast, I talk a lot about software engineers making product decisions, but it does go the other way around as well. In order to have an effective product engineering team, you need product managers to be able to make technical decisions. So for any engineers listening to this, this can be quite uncomfortable as it is uncomfortable for product managers to give up the decision making authority inside their product. But let's say, for example, you had a product manager and that product manager wanted to bring in some new functionality inside the product and they wanted to make a build or buy decision. So build or buy decision might be we want this functionality and there are third parties out there that provide that functionality or we could build it ourselves. So what they would do in that situation is go to an engineering team and they would say, this is the functionality we want. Here's a couple of third parties that provide it. Tell us how much work it would be to build this ourselves. Maybe you could assess those third parties and then come back to us with a decision. Now, whether you allow the engineering team to make that build or buy decision or you allow the products team to make it, it's actually very telling about the way the organization is structured. Because if you put the onus on the product, all the engineers, sorry, to make that build or buy decision, if those engineers are actually part of the team that's trying to implement that functionality, then again, you've taken away decision making authority from the people that are actually trying to make it. In this case, the product manager and you've given it to some people that might have a lot of knowledge because they've looked into it. But ultimately, they're not held accountable to whether that was the right decision or not. So what you really want to do is you want an engineering team that can educate the product manager on both of the tradeoffs on that decision. So a product manager says, I want this functionality. We could buy it from this third party or we could build it. They go to the team and the team assess how much effort will be in building and maintaining it. They assess the third party. They work it all out. They come out of some estimates and then they hand all that context over to the product manager. And they say, these are your options. These are the tradeoffs. This is what we know. This is what we're unsure about. Here's all the information. And then the product manager makes that decision. Now, that's uncomfortable for engineers because they like to be making the decisions on like how something's going to be written. But if you can give that information to a product manager, they can then be held accountable to whether that's the right decision or not. So providing they've got all of the information or as much information as you can possibly give them, then they can go off and make that decision. And if they decide to buy in a third party or they can decide to ask some engineers to build it, that's really their decision. So this isn't just product managers making technical decisions or software engineers making product decisions. It's a blend of both. Everyone, everybody on a product engineering team needs the autonomy and the authority to be able to make products decisions and technical decisions and other decisions that are going to allow them to quickly move. Experimentation, prototyping, gathering feedback from those experiments and then working out where to go next and when to change direction. All of that requires quite a lot of decision making autonomy. And so the more you can get context towards those people making those decisions, the quicker they can move. And the quicker they can move, the quicker they can learn. Because after all, products engineering is about removing ambiguity and trying to learn about the correct thing to build and what to double down on and what to abandon. So the quicker people can learn and the quicker they can iterate, the better you'll be able to drive successes inside your product. And so speed generally comes out of autonomy of decision making. If you ask someone to paint your house and you don't micromanage them, you just give them a few ideas of what you really, really want. They'll get a much, much quicker result and usually a much, much better result than if you sit there and stand in front of the paint aisle with them and tell them exactly what paint to buy at each point in the process. So what you need in your organization is a mechanism to hand context over from people that know about it to people that want to make those decisions. The best way to do this in practice is to be explicit about the outcome you're trying to drive and then be open about what evidence you've gathered so far so that you can take all of that information to the people that have the deep context and you can ask them for information on this. There's a bunch of mechanisms you can employ inside your organization, like a request for context where you say what outcome you're trying to drive and you decide like what we know so far and what we don't know. And you put that out into your organization and say, we think making this change based on this evidence will drive this outcome. Does anybody who knows more about this want to come along and educate us? And so that creates a model where you know what you're trying to do and you think you've got the right thing, but you can invite experts in from other parts of the organization and they will fill in that missing context. But crucially, they won't make the decisions for you. Nobody makes the decisions other than the people that are going to be held accountable to making that change. So by asking people for context, you can build up a much clearer picture. You can ask back-end software engineers about context about why the API performance falls down in a certain place. You can ask front-end engineers about the context behind why we've used a certain front-end library. You can ask product leaders the context behind the history about why a product was built a certain way. Bring all of that information together and put it in front of the product engineering team that are making the actual decision. Don't rely on anybody externally to make those decisions for you. The same goes for leadership. One of the failure states for this is to tell people they have the authority to make a decision, but then at the last minute, override them based on leadership. If you know that acronym, highest paid person's opinion, HIPPO, HIPPO basically is a failure state a lot of organizations will fall into, where somebody who's very, very senior in the organization will block a decision for whatever reason, and that can ultimately disempower the team that are trying to make that decision. Some decisions do need to be blocked at a high level, but it's important to, if you're going to do that, provide context about why this decision is being blocked at a high level. Not just do it randomly, because otherwise teams will drift back towards asking for approval from leadership for every single decision. So teams that work effectively generally have kind of flatter, more autonomous structures, where product engineering teams are being given guardrails around what kinds of decisions they have to make. So, for example, a sensible guardrail might be anything to do with user authentication and security. So, as long as you have guardrails around which kinds of decisions are autonomous to the team and which kind of decisions do need approval from elsewhere, then you can be really, really explicit about allowing people to actually get approval from somebody. So, if you're going to take one thing away from this episode is that your organization needs a mechanism to move context from the people that know about it to the people that need to make decisions about it. So, don't have local decision makers that aren't aligned to what you're actually trying to do. They're not working on the same thing and you're not holding them accountable, because if you do that, then you're not going to be able to truly hold those teams accountable for the outcomes that they're trying to drive. So, have a mechanism in which experts in a certain area can provide that context to other people in your organization so that they can run with it and they can make the decisions. So, I hope this has given you something to think about. This is another solo episode. The first few episodes of this podcast are just me talking at you, but I am booking guests for future episodes. So, after the 10th episode from 11 onwards, we're going to have guests come on and give other opinions and other perspectives on product engineering. So, stay tuned, stay subscribed. You can watch this on YouTube or it's on all of the standard podcasting platforms. My name is James Charlesworth and I'll see you next week.