Encouraging Your Team to Make Decisions Autonomously

Problem

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.

Actions taken

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.

Lessons learned

• 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.