There are teams that seem to achieve near mythical levels of performance. To outsiders, it can almost seem like black magic but you don’t have to look too deeply to spot the secret. The thing they all share is autonomy.
“…empower people to make choices.”
Let’s say you want to hire a building company to come and do some work on your house. There are a number of problems to fix quickly but you know it’s important to find a team that is reliable and will do a good job. You spend a month speaking to various companies and eventually, you find one that you love for a price that is fair. A few weeks fly by and as promised, the builders arrive at your home ready to begin solving the problems you need fixing. You decide the team needs some space to get set up and get settled in. In no time at all the builders are ready to begin working. “I would like you to start by taking the doors off and re-hang them because some of them stick when they open” you tell the builder in charge. “I’ve had experience doing this before so I’ll be checking in frequently in case you need my help.” “Urrrm OK. I’m not sure starting with the doors is a good idea” the builder replies. “I’m pretty sure this is the biggest problem I’ve got and it’s the one I want you to solve” you tell the builder. Reluctantly they agree and work begins.
This example may seem trivial but it serves a point. Could you imagine asking a builder to come to your house to tell them how to do their job? If you answered yes then I guarantee you won’t have a functioning team for long, and you certainly won’t get the build quality you were after in the first place. If your answer was no, then good. It’s important that we establish a common understanding of why this is a problem before we can understand why autonomy is so important. Indulge me whilst I present a different version of the same situation but, this time I’ll demonstrate what happens when you empower people to make choices.
…In no time at all the builders are ready to begin working on solving the first problem you outlined. Whilst the builders were setting up you took the builder in charge through the issues one by one. “Some of the doors are hard to open” you say as you move through the house. “No problem, they might need re-hanging. We’ll take a look”. Satisfied, you continue on through the house. “I want this wall knocked down to open up this space a bit more” you tell the builder. “Ah OK, that’s important to know. We will need to take the doors off their hinges anyway so we can get the wheelbarrows in to move the debris. We can sort any doors that stick at the end.” the builder replies.
Enabling Through Ownership
Let’s stop that riveting tale right there for a moment as we’ve reached the first critical thing — enabling people by giving them ownership over the problems we want them to solve. By connecting the builder with the problem we want them to solve cogs started turning about how they’d solve it. We didn’t need to know how they’d solve it, just that they would. As we continued to move through the house we started to give the builder the bigger picture of where we want to end up. Immediately their experience came to the rescue as the builder connected the two problems together and realised that it would be foolish for us to solve the door issue before knocking the wall down as we’d surely need to remove the doors from their hinges in order to get the debris outside. The secret to autonomy is no secret at all, it’s just common sense. When you hire highly skilled people and you align them around the problems you want to solve the only thing you need to do is to get out of their way and let them do their job.
I‘m surprised at the way many developers react when I tell them that this is the most important thing to me when I’m managing a team. Find good people and align them around the problems the business needs them to solve and encourage them to find the best solution. “That’s really great to hear. I’ve not worked anywhere like that before” is a fairly common reply. Your job as a team leader and even as a business is simply to make sure those important problems are as clear as possible. The more you can shine a light on the end goal the better the results will be. At the end of the day, the results are what count. It’s critical to drive this point home because without the right amount of alignment and heaps of autonomy you’ll have bedlam.
Henrik Kniberg from the Spotify team hit the nail on the head in his 2 part Spotify engineering culture in 2014. It’s about finding the right balance between autonomy and alignment. Too much autonomy and not enough alignment and you’ll have people all trying to solve the same thing in different ways. Too much alignment without enough autonomy becomes a culture of micro-management. I speak from experience having fallen into the “over alignment” trap before. It’s easy to think you’re being helpful by providing a solution for team members when you think you’ve already got a good handle on the problem you’re trying to solve. When the pressure turns up and you need to deliver that trap is more easily sprung.
So the next time you find yourself presented with a situation and you’re about to tell the builder how to do their job STOP! Instead, invest all your energy in making sure the builder is connected with your problems, articulate the end state as clearly as you can. Put all the trust in them that you had when you hired them in the first place.