The Art of Building Autonomous Teams

If you are a large organisation trying to become "agile", autonomous teams seem to be the Holy Grail. Spotify-style squads are where we want to be. We all want our teams to be lean, mean, agile machines, delivering business value wherever they go.

But agile transformation is hard. It isn't something you can turn on with the flick of a switch. The other day Peter, an executive at a large investment bank, was telling me about his experience. "When I started here, I was very keen to get the teams doing Agile as fast as possible. We ran some Scrum courses and gave the teams a lot of freedom to do what they judged best. But things soon started going pear-shaped. The testers are still finding a lot of defects. The teams don't communicate well at all, and there is a lot of duplication. Management doesn't believe in Agile anymore. Even the team members are unhappy! They miss the old days where they were given detailed specifications and didn't have to make any decisions. To be honest, I'm really tempted to go back to Waterfall."

Indeed, a two-day course do not an Agile master make. A team does not become agile overnight, and even less so an organisation. And too much autonomy, too soon, can lead to organisational chaos and unsatisfied employees.

But why is autonomy so hard to get right?

The Journey to Autonomy

For many organisation, autonomous teams are "what good looks like". And for good reason. Studies show how autonomous teams are more engaged and more productive. Autonomy spurs creativity and innovation.

Daniel Pink resumes some of these studies in his book "Drive: The Surprising Truth About What Motivates Us". Pink lists three factors that lead to higher motivation and better performance:

• Autonomy - the desire to have control over what we do
• Mastery - the satisfaction that comes from becoming better at what we do
• Purpose - the feeling that we are doing something that matters

But in a large organisation, autonomy is a tricky balancing act. For example, suppose you have hired a junior developer fresh out of school. You are unlikely to give them free reign to start with. First, they will need training, direction and coaching. Then over time, they will become more skilled and experienced. And, with luck, they will gain an understanding of the company's business model. As this happens, you can trust them with larger pieces of work, and with less supervision.

Teams are similar. They aren't all ready for autonomy straight away. Autonomy should not mean anarchy. Organisations need to tread a fine line between:

• The autonomy a team exercises,
• The visibility and feedback the team provides, and
• The confidence that the team will deliver high quality outcomes,
• And the confidence that these outcomes will be in line with business goals.

In fact, autonomy relies on three essential factors to work its magic:

• Competence
• Shared Understanding
• Trust

These factors balance and support each other in the journey to high-performing autonomous teams.

Competence

David Marquet is a well known leadership guru and retired nuclear submarine commander. In his book "Turn the ship around", he tells the story of his experience abord the USS Will Rogers.

As engineering officer, David was keen to apply modern leadership techniques. He wanted to give more autonomy to the crew. But his efforts were a disaster. Unused to their new-found freedom, the crew members made mistake after mistake. "I overheard people wishing for the old engineer back, who would just tell them what to do". David ended up reverting to traditional command-and-control style management.

David had given the crew decision-making autonomy, but they made bad decisions. They did not have the competence for that level of autonomy.

To perform well, teams need to be competent. They need to know how to deliver the optimal solution using the most appropriate technical practices. In other words, team members need to be skilled at their craft.

Technical competence is too often overlooked or assumed. But effective organisations go out of their way to build up the skills of their teams. Competence is closely related to Pink's concept of Mastery. Motivated, engaged knowledge workers want to get better at their craft. Effective organisations give them the support and the means to do so.

Shared Understanding

But competency is of little use if it is not used to help advance the organisational goals. High performing teams have (and seek out) a deep understanding of business goals and objectives. This "Shared Understanding" gives competency it's focus. Shared understanding helps ensure that teams go in the same direction, towards the same goal.

Shared Understanding is a two-way street. High preforming teams take care to make their intentions, actions and outcomes very visible.

David Marquet calls this shared understanding "Clarity". He explains this concept in the context of his experience as a submarine commander in the US navy:

• In a traditional, command-and-control environment, the capitain says "Submerge the ship!" and the crew member says "Aye aye, sir!"
• In a competent crew with a shared understanding of the mission goals, the crew member says "Captain, I intend to submerge the ship. Water depth has been checked and is four hundred feet, all men are below, and the ship is rigged for dive." And the captain says "Go ahead".

In the second case, the crew member understands the mission goals. He gives enough feedback to the captain to show that he know what to do and why. The captain can be confident that the crew will get the job done.

At Spotify, they call this Aligned Autonomy:

"The stronger alignment we have, the more autonomy we can afford to grant."

Trust

In 2015 Google did a study of over 180 teams, to discover the secret mix that makes a high performing team. And the results surprised them. By far the number one ingredient was psychological safety. Team members must feel comfortable taking risks and making mistakes.

The main ingredient in Psychological Safety is Trust. Trust in other team members and trust between team members and management.

The last of our three elements, but probably the most important, trust is the key to autonomy. Without trust, any effort to give autonomy will be hollow. Autonomous teams need the trust of management to deliver outcomes, rather than specific solutions. Without trust, they will not have the flexibility they need to produce their best work.

When they work with autonomous teams, management need to ask for outcomes, rather than specific solutions. They need to trust the team to figure out the optimal way to deliver these outcomes. They count on the team's shared understanding and technical competence to achieve their goals.

Conclusion

In the real world trust is earned, not given. Leaders need to build up their trust by progressively giving teams more autonomy. And teams justify this trust by delivering valuable outcomes. And this doesn't happen overnight. But the goal, high performing autonomous teams working in alignment with business goals, is most definitely what good looks like.