Back to resources

How to Empower Teams to Be More Autonomous

Team Processes

23 January, 2021

Velu Alagianambi
Velu Alagianambi

Engineering Manager at Atlassian

Velu Alagianambi, Engineering Manager at Atlassian, tells of his efforts to empower a team he inherited to be more autonomous, self-sufficient, and productive.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

The Optimization and Organization of Large Scale Demand

4 May

Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.

Managing Expectations
Delegate
Team Processes
Prioritization
Kamal Qadri

Kamal Qadri

Head of Software Quality Assurance at FICO

Why Documentation Is the Key to Success

6 April

Henning Muszynski, Head of Frontend at Doist, promotes his ideas on how documentation ensures consistency, efficiency, and standardization.

Alignment
Collaboration
Productivity
Hiring
Team Processes
Henning Muszynski

Henning Muszynski

Head of Frontend at Doist

It's Time to Say 'No' to Manual Business Processes

6 April

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.

Changing A Company
Conflict Solving
Internal Communication
Feedback
Team Processes
Henning Muszynski

Henning Muszynski

Head of Frontend at Doist

Typical Challenge of Scaling Teams: What to Do When Your Process Doesn’t Scale

30 March

Christophe Broult, Director of Test Engineering at diconium, focuses on how he scaled his team while building organization and management teams in place.

Scaling Team
Building A Team
Reorganization
Team Processes
Christophe Broult

Christophe Broult

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.