If you want to unlock your team’s potential, it has to be able to work at maximal speed, with minimum to no failure work. On our quest to triple impact-per-engineer, let’s talk about one part of that core: creating autonomy. When there’s no autonomy, leaders tend to act as “routers.” Everything goes through them. Progress stalls without their explicit direction. You can accelerate progress rapidly.
If you’ve learned computer science, you probably spent some time drawing automatons. Some leaders instinctively think of something like this when they first attempt to increase autonomy. If they just lay down enough processes and guidelines, everything will be smoother. That’s not good enough.
While this is a good practice in general and especially helps hybrid teams, aspiring to have really fast automatons is just not going to cut it. Automatons only work when you are able to describe all possible scenarios preemptively. That’s impossible and wasteful. Genuine autonomy is manifest when your people can bridge gaps by themselves.
Admittedly, it is not always easy to know where to start. When I work with leaders, we can pinpoint together the areas where autonomy is mostly lacking in their teams. To do so yourself, you can start by becoming more aware of radio silences. I mean, what happens whenever you are not available? Perhaps you had a sick day or were at a leadership offsite. Even when you are just busy with some back-to-back meetings.
Whenever that happens, consider a few things. First, were there any interruptions during this time? Things that could not be handled by the team and were escalated to you? For each, evaluate whether that is the correct behavior or if they should’ve handled it. Second, look at the things that have been blocking waiting for you. I sometimes call this the “hall count”: how many people tackle you the second you come out of a conference room. Are these issues the kinds you’d expect to block waiting for your input? Lastly, consider the decisions that were made without you. Were they the right calls?
Taking stock of all these instances for a few days should help find the first areas in your teams that need an autonomy boost. It might be about a certain aspect of the product, legal concerns, process questions, cross-team communication, etc. Whatever it is, each area that should not be waiting for you or where the wrong decisions are made regularly should be adjusted.
Taking the Initiative
Equipped with your list, you should start coaching your people to take the lead and go on the right path. This is twofold.
One part is about coaching. Except for those already making decisions on their own (even if the wrong ones), the managers in your organization should be paying attention to the autonomy of their team members. For example, reverse engineering cases where people waited for something to see why they thought they had to wait for permission. Create the safety in the organization that reduces stress and risk associated with making minor mistakes. That sort of stuff. Without this, no matter how much context people have, they’ll never venture forth on their own. They’ll always want to hold mommy’s hand.
The other part is about ensuring the right decisions are made. As I explained earlier, this isn’t a matter of laying out more and more procedures and plans. Try to help people see things from a higher altitude. What are your guiding principles when considering the different options? Are there any company values that connect to this that could have helped weigh possibilities?
Again, this is not about preemptively trying to think of each and every possible problem. It is about distilling things down to the company’s core and realizing its strategy, values, and advantages to make the best decisions. Those can manifest in major product decisions and minute details like how a rare error is handled. Work on these, and you’ll see your team improve impact-per-engineer rapidly.