Building team autonomy

Autonomous teams solve high-impact problems together with very little outside intervention. They know the goals of the business, understand the problems they’re trying to solve, and work together to find and build the best solution.

Empowering engineering teams to act with autonomy is incredibly difficult. It involves building an immense level of trust with the team and relinquishing a degree of control. It requires a careful, hands-off approach to leadership that can be quite scary.

Not only that, but it’s easy to fall into the trap of believing that a team of autonomous engineers will, by default, become an autonomous team. But this is not always the case.

So how can we create an environment where autonomy is possible?

Clear priorities

Autonomous teams understand the goals of the business. To make teams more autonomous, we must make our goals and priorities clear. Clear priorities provide a shared space in which an autonomous team can channel their creativity.

When goals are unclear, it is much harder to know which work is likely to move us forward and which work is likely to waste everyone’s time. Think about it — given all of the possible paths we can take, what are the chances that the path we choose is the one that will put us in the best position to achieve our goals if we don’t understand our priorities?

Having a strong understanding of our priorities empowers teams to make better decisions. We can reason about requirements and make decisions that push us toward our goals. We can also determine which solutions are worth pursuing.

A team that is aligned about priorities will broadly understand the answers to the following questions:

• “What kinds of problems are we trying to solve?”
• “What is our company investing in right now, and how do we fit into that investment?”
• “What can wait, and what can’t?”

If our team does not seem to be on the same page here, that may be a sign that it’s time to meet with the team and clarify our goals.

Accessible metrics and analytics

Autonomous teams understand the definition of success for a project. They use this understanding to measure their outcomes and react. As a result, autonomous teams need accessible metrics and analytics.

Our metrics must be both visible and simple to be considered accessible. Without simplicity, the friction of creating new metrics causes teams to compromise the quality of their metrics. Without visibility, it doesn’t matter how good our metrics may be — they’ll be lost to the void anyway.

As a rule of thumb, consider what I call the two-halves rule:

• Anyone can create the metrics they need in half of a day.

• Anyone can find the metrics that they care about in half of an hour.

The tools we use for this will vary from company to company (I’ve used Datadog, Mixpanel, and Pendo for various projects in the past). The important part is that our team understands the tools and can use them to measure success.

Collaborative decision-making

Autonomous teams solve problems together. When the team takes on a new initiative, they brainstorm solutions as a group, consider alternatives, and come to a broad consensus. This creates a sense of ownership among the team and ensures that everyone’s voice is heard.

When taking on a new initiative, there are two key anti-patterns to avoid:

Top-Down Decisions

The first anti-pattern is top-down decisions. Here, someone outside the team makes decisions and the team is only responsible for implementing the solution they’re given.

Depending on the company, top-down decisions may come from the team’s manager, a product manager, or even a member of the executive team. This anti-pattern typically happens when a team has been short-staffed or has been through a period of rapid change, and it’s generally pretty easy to spot.

Top-down decisions are harmful for engineering teams because:

• The team no longer feels a sense of ownership over their work.
• The team’s creativity is limited and, over the long term, new ideas are discouraged.
• Decisions are made by people who are less familiar with the code, which can create tension between expectations and the limitations of the code base.

Lone-Wolf Decisions

The second anti-pattern is lone-wolf decisions. Here, someone within the team makes decisions with little to no input from the rest of the team.

Unlike top-down decisions, these choices usually come from someone with a strong understanding of the code. However, there’s still a problem: decisions are made in isolation rather than through collaboration.

One common sign that we’re dealing with the lone-wolf pattern is that the team’s first exposure to a new initiative comes in the form of an ADR.

Lone-wolf decisions are harmful for engineering teams because:

• Decisions in isolation are more likely to have negative side effects because they’re subject to less input from others.

• Each decision the lone wolf makes robs the team of a chance to improve their own decision making skills. This stunts the growth of junior engineers while creating a boring work environment for other senior engineers.

• As the lone wolf makes more decisions, the team becomes more dependent on that person. Over time, the lone wolf becomes a bottleneck that slows down the team.

These two anti-patterns undermine team autonomy and limit creativity. Instead, we should aim for collaborative, bottom-up decisions.

Once we have done this, we’ve set the stage for autonomous teams to thrive. Now comes the hard part: trusting our teams and giving them room to grow.