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

Team Development Framework for new managers

26 June

Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.

Building A Team
Team Processes
New Manager
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

Promoting Interdepartmental Teamwork for More Efficient Problem-Solving

13 June

Roland Fiala, Senior Vice President of Engineering at Productsup, raises an interesting issue about autonomy in teams: does it hinder collaboration opportunities that lead to better problem-solving? He shares his system for promoting teamwork in engineering departments.

Internal Communication
Collaboration
Roadmap
Team Processes
Cross-Functional Collaboration
Roland Fiala

Roland Fiala

Senior Vice President of Engineering at Usergems

How to Motivate Your Engineers to Grow in Their Careers

13 June

Roland Fiala, Senior Vice President of Engineering at Productsup, highlights the importance of soft skills and shares how he motivates his engineers to further their careers by focusing on personal growth.

Goal Setting
Different Skillsets
Handling Promotion
Personal Growth
Coaching / Training / Mentorship
Motivation
Team Processes
Career Path
Performance
Roland Fiala

Roland Fiala

Senior Vice President of Engineering at Usergems

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

Technical Program Management 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