Letting Go: Enabling Autonomy in Teams

My detailed project plan won the war.
— said no military commander, ever.

In the chaos of battle, it is accepted military doctrine that highly centralised decision-making fails. Information cannot be rapidly assimilated from the front line and turned into timely decisions. To address this, a commander’s intent is communicated, guiding each platoon in their own decision-making in lieu of direct supervision.

Modern business is similar. Business volatility and disruptive technologies cannot be met with rigid mechanisms and structures. Much has been written about the benefits of autonomous teams, including improved employee motivation and retention, richer innovation, faster returns on investments, and rapid responses to customer needs. What has traditionally been pitched as idealistic for organisational effectiveness is now a central tenet of digital transformation: moving from “doing digital” to “being digital.” Driving autonomy is essential for a modern enterprise’s success—and choosing to ignore or pay lip service to it leads to overtaxed leadership and a stagnant, underutilized workforce

Autonomy

Autonomy is about distributed leadership of outcomes, not an amped-up version of task delegation. It more broadly distributes power, which can be deeply uncomfortable for leaders worried about organisational stability and personal value. Here I will share some proven practices to overcome these concerns. Apologies to the Agilistas, but this isn’t a guide to Agile or Agile teams. It’s about how to “let go” with confidence to create strategic agility.

Why do I believe this to be critical in transformations? One reason is the virtuous cycle this enables. The more you can create the right culture to support autonomy, the more you can focus on strategic opportunities, the really difficult challenges, and reinforcing a customer-obsessed culture. To enable this, we need to look at changes to leadership behaviours, guardrails, and coordination mechanisms. Leadership behaviours enable autonomy, while guardrails and coordination mechanisms protect against organisational chaos. You will need to find the right balance between stability and flexibility for your organisation, one providing efficiency and scalability and the other increasing speed and ownership.

Leadership in an Agile Environment

Cultural aspirations can be quickly derailed if leadership behaviours do not also change. Don’t fall into the trap of believing you are creating autonomy when your people don’t. Research indicates that 50% of subordinates don’t agree with their CEO that they have autonomy. Broadly, the leadership changes required are those of servant leadership, including listening, empathy, self-awareness, growing others, and building community. Sounds wishy-washy, doesn’t it?

Autonomy is learned and earned. Individuals grow most by making and learning from judgement calls and yet our tendency as leaders is to give answers rather than ask questions, relishing the endorphin rush we get from solving problems. This disempowers teams, creating a culture of dependency on the “HiPPO” (highest paid person’s opinion). If we expect judgement to develop and teams to take sensible risk, we also need to be reasonably tolerant of mistakes. Use decision requests and mistakes as coaching opportunities. Reframe and clarify problems by asking questions. Autonomous organisations require leaders at every level, and hence you will need to coach people who don’t have leadership experience to be confident and competent. Ultimately, you need the team to own their decisions.

Help teams identify and mitigate bottlenecks and dependencies. Push for loosely coupled architectures so teams can develop and deploy features safely and independently. This will take time in most enterprises. In the meanwhile, relentlessly question what dependencies exist and why.

Guardrails

How do you stop a team from metaphorically driving at 100 mph over a cliff edge due to poor judgement? Create structure—both cultural and organisational—to guide their decisions. Let me illustrate with examples from Amazon Web Services.

Firstly, we use AWS’s fourteen leadership principles to hire, evaluate, and guide everyday thinking. All employees are familiar with them. Do not underestimate the work required to create and embed truly ubiquitous principles. The words are important, but living them every day is where the magic happens. For instance, when a decision is needed regarding the customer, the “customer obsession” principle directs everyone to think about what is truly in the best interests of the customer and how to best respond to those interests. A strong, widely communicated and lived culture that is organisationally ingrained and reinforced through peer support creates high-trust environments.

Secondly is the concept of one-way and two-way doors. Two-way doors are decisions that can be reversed without significant effort. One-way doors have a more profound impact and are harder to undo. Agile organisations recognise the difference between the two. They ask what the most appropriate level of the organisation is to make a decision rather than which decisions to explicitly delegate. Decision-making processes are evaluated for speed more than control. It’s not an excuse for poor decisions, but rather a reflection that the search for perfect information is normally fruitless and slow. Delegation of these decisions enables better rigor and time to be spent on fewer, more critical decisions.

Thirdly, in many organisations, escalations are seen as signs of weakness, friction, or failure. We encourage teams to escalate quickly and often. We view this as a measure of organisational health. It prevents issues from festering and encourages teams to look to leaders as allies in removing obstacles. If teams escalate two-way door decisions due to a perceived lack of empowerment, use the escalations as opportunities to coach the teams. A mistake is another coaching opportunity, not a time for punitive action—else issues will go underground once more.

Fourthly, autonomy requires you to be explicit about the standards teams must respect. A pragmatic enterprise architecture team, for instance, is critical, as are standards to promote positive, consistent customer experiences.

None of this removes the need for governance mechanisms, but right-sized, these guardrails will support the team rather than becoming multi-layered status meetings.

Coordination

Leadership sets the tone of an organisation and the framework in which teams operate. The coordination mechanisms enable the free flow of information between teams and leaders to propagate learnings, identify overlap and inefficiencies, and create high levels of trust.

Many organisations have somewhat ad-hoc processes to communicate and share knowledge. Just like the commander’s intent, a clear, widely espoused vision is the starting point. It is the single most important unifying force and forms the foundation of day-to-day decisions. Our previous blog posts on change management and the customer journey can help you here.

Having extensively used tools in place to share knowledge, and the encouragement to use them, is a foundational part of the coordination infrastructure. Make sure that you are visibly sponsoring the use of these types of tools, making sharing knowledge a norm rather than a “nice-to-have.” Tools alone are not the answer. Even the workspace, be it physical or virtual, can make a difference by engineering opportunities for employees to create “serendipitous encounters.” Leadership stand-ups, management by walk-around, communities of knowledge, and short-term co-location of people from different parts of the business all help break down siloes.

Some leaders worry that creativity will unintentionally create chaos, so many large enterprises have inadvertently institutionalised the “no,” causing employees to feel stifled. How do you find a balance? Ongoing communication and transparency are key. At AWS, there is a notion of “1 > 2 > 0.” In other words, it’s better to have two teams working on an idea than none, but over time, the two teams can be collapsed into a single initiative. I’ll write more on this concept and associated guardrails in a future blog post.

Getting Started

Does autonomy feel risky? I ask you to consider whether your current processes, imposing some degree of discipline on complex problems and needs, is really such a low-risk approach given the changing world.

The trend toward more autonomous organisations is by no means a simple one, just as Taylorism was disruptive a century ago. Start by asking yourself what’s really stopping you from letting go so you can address roadblocks now—but don’t beat yourself up if you have a ways to go. Research indicates only 4% of companies have implemented organisation-wide Agile transformations, with 37% in progress. As for start-ups, yes, they are often perceived as being more autonomous, but many struggle with the lack of robust coordination and guardrail mechanisms that large organisations often excel at.

It’s a lot to take in. My advice: start bottoms-up and top-down. Identify projects and forward-looking teams that you can experimentally grant autonomy and implement guardrails. Top-down, have an active conversation about your culture: what’s working, what isn’t, what was working but has become dated, and how to make explicit desired organisational behaviours. Companies that have done this well—AWS included—did so over many years with a relentless, continuing focus on getting incrementally better.

Oh, and if you’re a non-technologist reading this: yes, it applies to you too.