Encouraging Your Team to Make Decisions Autonomously
22 April, 2021
We started out as a small team where people felt empowered to make local decisions. Most people were on the team from its inception and had enough context to decide on team matters. However, as we started to grow more rapidly, it became increasingly difficult for people to make decisions because they either lacked context or confidence. Immersed in their day-to-day work, most didn’t have time to stay on top of the thing and became reliant on other senior engineers and me. Asking for permission soon became a prevalent modus operandi that resulted in senior engineers becoming bottlenecks.
I needed to change how the team was operating. Though larger in size, I wanted them to exercise the same autonomy as they did before without senior engineers or me having to grant them permission for every single thing.
We have a process of completing design documents for all complex features, but many people find this process to be quite intimidating. Documents are lengthy, and their perplexing structure discouraged people from filling them in. Also, some senior people, who would rather write code than documentation, created a bias around those documents and, by doing so, had set an example for everyone else to follow.
I tried to encourage people to complete a brief document I templated for any workstream longer than a week. I used its brevity as the most convenient argument against those who would come up with a list of excuses. The new document should include several short paragraphs. It would begin with a problem description supported by some background information that should help someone unfamiliar with the problem to grasp the context. A paragraph where alternatives and recommendations should showcase why someone decided to go with a specific solution. My teammates would have to come up with two plans at least because in most cases, only, by comparison, people could understand the shortcomings and advantages of particular solutions. Recommendations should reflect their critical view on things as opposed to merely listing alternative solutions.
As people on the team started to practice documentation, they became more cognizant of its importance. Their involvement in the process and careful thinking about different solutions enabled a few more senior engineers and me to step away and have them make decisions. I could see how the team was becoming more autonomous and confident in their decision-making.
Besides, by introducing reviews to documents, a person submitting a document would always have a team’s approval as a safety net. That also added to their confidence and their willingness to take a more proactive approach to work.
- Autonomy, unlike permission, comes from within. As much as it was initiated by my efforts to introduce simplified documentation, it also required a mindset shift. Any mindset shift takes time and thrives on the clarity of expectations.
- I wish I had introduced the process earlier, as soon as I had spotted that senior engineers and I were becoming bottlenecks. Now, in hindsight, I understand how the process not only removed bottlenecks in decision-making and made the team more autonomous, but helped improve our documentation, introduced more critical thinking, etc.
- Different people will need more or less time to become comfortable with any new process. Some will come up with one-pagers full flashed out, some would do longer pieces still missing key information. You should ensure that people are supported through the process and allowed to absorb the new learnings at their own pace.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.
Senior EPM/TPM at Apple Inc.
Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.
Head of Software Quality Assurance at FICO
Henning Muszynski, Head of Frontend at Doist, promotes his ideas on how documentation ensures consistency, efficiency, and standardization.
Head of Frontend at Doist
Henning Muszynski, Head of Frontend at Doist, talks about the cost of slow and arduous processes that add up over time and how to bring the changes systematically.
Head of Frontend at Doist
Christophe Broult, Director of Test Engineering at diconium, focuses on how he scaled his team while building organization and management teams in place.
Director Test Engineering at diconium
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.