Autonomy Is Binary
Thanks to Daniel Pink’s popular TED talk, everyone in software now knows that autonomy is important for keeping the motivation high for engineers. And it’s not surprising that every software company nowadays declares “autonomy is an important part of our company culture”.
At least that’s what they tell the public.
What’s really happening behind those glass doors? I’m pretty sure the following conversation is familiar to most of you.
Engineer: This is how I want to design and implement the task. I have asked other engineers. Some of them came up with different designs but I am not sure I’m convinced their designs are better options.
Manager: Sure. You have the autonomy to design and implement this task. Please put your design in an ERD (Engineering Design Document) to share with the team. Please make sure engineers A and B sign off the ERD since they are the domain experts. Oh don’t forget to get buy-in from C because she is in charge of infrastructure, and architect D. When you submit your PR (Pull Request), please get it accepted by E and F since they will be impacted by your work.
I know a lot of people would ask “What’s wrong with the manager’s response? Isn’t it the manager’s responsibility to make sure an engineer won’t end up implementing the wrong design?”
To this question I always respond: “There is nothing wrong with this conversation if you don’t want to give your engineers autonomy at all, which won’t be the end of the world since this is actually what most companies do. But if you do believe your engineers should have autonomy, they should be given 100%, unconditional permission to make the final call. Autonomy is binary.”
Why is this important?
It is important because autonomy is the most important source of your engineer’s motivation. When given autonomy, the same engineer can be 10x more motivated, 10x more productive, and 10x more impactful than otherwise. And because autonomy is binary, you can’t just get 5x of the motivation level out of them by giving them 50% of the autonomy.
You either let go your fear of loss of control and give your engineers real, unconditional autonomy, or you are settled with a team at much lower motivation level, a team that cares very little more than “just getting by”.
My faith on autonomy was put under serious test a few years ago when I had a disagreement with a young engineer who we just hired out of a coding bootcamp. At that time I was the team lead. I had 15 years of experience under my belt. And I was very sure that his design had several serious flaws based on my experience. It took a leap of faith for me to say “I don’t think how you plan to do it is the most optimal way. However, since you are the person who will implement it, you are the one who get to make the final call. You should go with your own design if you are convinced that it is the right one”.
Sure enough, that engineer went ahead with his own design. And sure enough, he ran into many problems along the way. What amazed me was that all these problems only seemed to motivate him to work harder, to learn more. And he would approach me for suggestions and be very open to them. Within just a few months, he had grown to be one of the most productive engineers in the team, capable of solving the problems that even very senior engineers found challenging.
That’s why autonomy is binary. I was presented with a red pill and a blue pill. If I had taken the red pill and told him to do what I say, I would have saved him a few days chasing a sub-optimal design. By taking the blue pill to give him real, unconditional autonomy, the team ended up with yet another super motivated and productive engineer in a very short period of time.
Other articles in The Soft Side of Software Engineering Series:
