How to Empower Teams to Be More Autonomous

Problem

I inherited a team that was accustomed to a traditional operational style that was essentially a command-and-control style. Whenever the team encountered a problem, they would rush to the manager asking what to do next. The fact that the leaders of the team were unable to go on vacation illustrated the severity of the situation. I wanted to change it not only because I believe people can reach their real potential as autonomous and accountable individuals, but because it was creating problems on a structural level.

After I addressed this issue, a year later we had conducted a survey which indicated an increase in autonomy and self-sufficiency of the team. My mind is at rest knowing that the team knows how to run its stuff.

Actions taken

First of all, I had to clearly outline roles and responsibilities on the team. The lack of clarity was slowing them down and they were unable to ramp up as expected. I worked with newly hired employees whose responsibilities were unclear. I compiled a document clearly explaining the expectations for new hires.

For the first month or so, I was merely observing how the team was operating. During retros, I would pay particular attention to recurring problems and focus on them first.

Most of the problems we encountered were process-based rather than people-related. Examples of this were multiple dependencies we had on Design, and how we learned that those dependencies should've been ready before the engineering sprint even started. The lack of transparency was inherent. We knew what the team needed to do, but the breakdown of how we were going to do it was not very transparent. I decided to be open with the team and encourage participation. I would tell the team what we should accomplish by the end of a quarter and then ask them to contribute to breaking the tasks down sprint by sprint for six sprints. The team would identify dependencies, and we were able to notify them much earlier than before. We would know exactly what dependency is needed, and Design or some other team would be made aware of the upcoming work.

I created collective accountability among employees. Previously, people would ask what to do and perform it, and then they would do it without any notion of collective accountability. I made them commit together as a team to accomplish a certain goal.

They self-identified tasks, found the best subject matter experts, and worked with them to complete each task. Knowing their goals, they became aware of risks and more systematically brainstormed about solutions and strategies to mitigate risks. That empowered them to take ownership of their work and claim accountability.

Sometimes it wasn’t obvious to find matching subject matter experts or the right team. As an EM, I had greater visibility into the different teams and was able to connect the right people. Also, I have identified recurring dependencies and have resolved them efficiently, by facilitating the knowledge transfer between the teams and making the team self-sufficient.

I would decrease workstreams to increase availability, especially in Product and Design that have been chronically behind. It meant setting the right priorities and matching them with availability. The team became increasingly involved in determining high/low priority and picking high priority work. The team was able to solve 80 percent of problems with 20 percent of the effort following the Pareto principle and our approach to prioritization. This gave them confidence and also sent a clear signal to stakeholders of the great work they had done.

Lessons learned

• As a new manager of a team, don't presume anything and try to figure out why things are the way they are. Instead of assigning tasks, explain the problem and let the team figure out their own solution (even if you already know what it is). Deliver problems, not solutions.
• We formally established the feature lead role that had already been practiced in some parts of the company. We had multiple iterations of the concept, but a feature lead paved the way for making the team autonomous. Feature leads would have a broader view into what was happening, and as we started to rotate them, we had to start onboarding new people. I coached two people to become feature leads and be able to solve some of the recurring problems.
• Make engineers accountable. If something needs to be delivered on the x date, communicate as early as possible, and have them have precise expectations, including picking the right solution for that timeframe. If there is no timeframe, make an estimate on the timeframe and make them accountable for it.
• You have to tailor your coaching. Some people want to stretch their assignments, and other people are comfortable at where they are. You should understand where they all want to get to and adjust your approach. I made someone a feature lead when they were not ready; I thought it was a great growth opportunity for them, but it turned out that they were not comfortable with that.