Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

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

Building a New Team in a Foreign Country

23 November

Adam Hawkins, Site Reliability Engineer at Skillshare, went all the way across the world to build a brand new team who worked very differently than he was used to.

Team Processes
Adam Hawkins

Adam Hawkins

Site Reliability Engineer at Skillshare

What It Takes to Understand Other’s Perspective

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how to really understand someone else’s point of view.

Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

How to Handle Team Collaboration After a Merger?

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how he helped the acquired company’s team members understand the business mission and give them focus.

Acquisition / Integration
Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

Surefire Ways to Boost Team Morale

11 November

Rajesh Agarwal, VP & Head of Engineering at Syncro, talks about effective ways to boost team morale when stepping in as a new manager in the team.

Motivation
Team Processes
Rajesh Agarwal

Rajesh Agarwal

VP and Head of Engineering at Syncro

How an Empathetic Approach Can Solve Problems

10 November

Han Wang, Director of Engineering at Sonder Inc., shares how he changed a manager’s viewpoint for achieving better results and improved team coordination.

Goal Setting
Personal Growth
Leadership
Coaching / Training / Mentorship
Team Processes
Han Wang

Han Wang

Director of Engineering at Sonder Inc

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.