Autonomy is often introduced with good intent. Teams move faster when they own delivery, can make local decisions, and do not wait for approval on every step. The failure mode is predictable. Autonomy expands, but decision rights stay implicit. Over time, leadership direction starts to feel optional. Teams make trade-offs quietly. Leaders experience resistance and excuses. Teams experience competing priorities and unclear constraints.

‍

Jeff Bezos captured the core issue in a sentence that travels well because it is practical. "Good intentions don’t work, mechanisms do" (Clifford, 2022). In high-autonomy environments, leadership gets "heard" when the organisation has mechanisms that make direction actionable and enforceable.

‍

What it looks like when decision rights are unclear

‍

You will often see the same patterns across engineering, product, and operations.

1. Decisions stall, then re-open. The same topic reappears every few weeks with no durable conclusion.
2. SLAs and reliability targets drift. Commitments exist on paper, but teams prioritise feature throughput over service health.
3. Architecture and tooling choices fragment. Teams optimise locally, creating cross-team friction later.
4. Accountability diffuses. Many people contribute; nobody owns the outcome end to end.
5. Escalation disappears. Misalignment gets resolved by delay, fatigue, or "we will revisit later."

‍

Rogers and Blenko describe this in decision-making terms. Decisions get stuck when there is ambiguity over who decides what, especially across global versus local, function versus function, and centre versus business unit boundaries (Rogers & Blenko, 2006).

‍

Why it happens

‍

This is rarely a discipline problem. It is usually a system design problem.

1. The "D" is missing: When nobody clearly holds the decision, teams default to consensus or quiet vetoes. RAPID was created for this exact bottleneck. It forces one Decider while keeping room for input and execution roles (Rogers & Blenko, 2006).
2. Ownership exists without decision authority: Teams are accountable for delivery outcomes, but they lack clarity on which decisions they can make versus which require leadership alignment. In addition, in consultancies, Teams are accountable for delivery outcomes, while the client retains final decision rights; this creates a gap between responsibility and the power to choose, especially when the rationale and risks are not explicitly surfaced.
3. Incentives favour visible throughput: If promotion, recognition, and planning  rituals reward feature output, teams will treat platform work, reliability work, and control improvements as optional.
4. Psychological safety gaps create passive resistance at every level, including among leaders. When leaders do not feel safe to challenge peers, escalate misalignment, or admit uncertainty, they may soften direction, avoid conflict, or accept ambiguous commitments; teams then fill the vacuum with local optimisation. Psychological safety is strongly linked to learning behaviours that surface problems early (Edmondson, 1999).
5. Autonomy is under-supported. Team Topologies frames autonomy as something enabled by reducing cognitive load, often through platform capabilities and enabling support. Without that support, autonomy turns into improvisation (Atlassian, n.d.).

‍

How to fix with out killing autonomy

‍

These moves are deliberately lightweight. The goal is clarity and speed, not bureaucracy.

1. Publish your non-negotiablesWrite down the small set of policies that are not optional. Examples include production change controls, minimum security controls, incident response expectations, and service-level objectives. Keep it short and versioned. If teams want an exception, they must document the risk and seek explicit approval.
2. Define decision rights for repeat decisionsPick the recurring decisions that create the most drift. Examples are prioritisation trade-offs, SLA changes, major vendor choices, and architecture patterns that impact multiple teams. Define roles using RAPID (Rogers & Blenko, 2006). You can do this on one page. The outcome should answer a single question per decision. Who has the "D".
3. Assign a single Directly Responsible Individual for every meaningful outcomeApple operationalised this through the "Directly Responsible Individual" concept. A meeting action list has a named owner for each item. The question "Who’s the Directly Responsible Individual?" becomes normal language (Lashinsky, 2011). GitLab codifies a similar approach, treating a Directly Responsible Individual as the single accountable person for a decision or initiative, while still expecting consultation and collaboration (GitLab, n.d.).
4. Use written proposals for irreversible decisionsDo not require memos for everything. Require them for decisions that are hard to reverse, high risk, or cross-team. Bezos distinguishes reversible "two-way door" decisions from irreversible "one-way door" decisions; he recommends lighter process for reversible choices and clearer escalation for true misalignment (Bezos, 2016). A written proposal makes trade-offs legible. It also makes it easier to disagree early and commit after the decision.
5. Add an escalation mechanism that people will actually useIn practice, escalation fails when it feels political or punitive. Make escalation a normal path for misalignment. Bezos explicitly warns that without escalation, disputes get resolved by exhaustion, which is slow and de-energising (Bezos, 2016).

‍

A real-world example you can use

‍

Scenario. A CTO asks a team to review a risky production change and align on an SLA. The team chooses a faster shortcut that violates the intent, then defends it with time pressure and dependency constraints.

‍

Mechanism-based response.

1. Classify the decision. Is this reversible. If not, treat it as a one-way door decision and require a written proposal (Bezos, 2016).
2. Name the Directly Responsible Individual. One person owns the recommendation and the final call within agreed guardrails (Lashinsky, 2011; GitLab, n.d.).
3. Make trade-offs explicit. The proposal must include impact to the SLA, risk level, rollback plan, and what work is being displaced.
4. Apply the non-negotiables. If the plan violates a stated control, the team either changes the plan or requests a documented exception with an approver.
5. Close the loop. After execution, review outcomes against the measures below. If reality differs from the proposal, update the mechanism so the error is less likely to repeat (Clifford, 2022).

‍

Measurable Outcomes

‍

If decision rights are improving, you should see movement in measurable indicators within a quarter.

1. Decision cycle time: Time from "proposal created" to "decision made."
2. Delivery stability: Use DORA’s stability measures, such as change fail rate and recovery time after failed deployments (DORA, 2026).
3. Delivery throughput: Use DORA’s throughput measures, such as change lead time and deployment frequency (DORA, 2026).
4. Unplanned work ratio: Percentage of time spent on incidents, rework, and urgent fixes versus planned delivery.
5. SLA adherence: Breach rate and time-to-detect and time-to-restore trends.

‍

If you want a simple leadership test, try this. Ask three people in different roles the same question: "Who decides on X, and how do we escalate if we disagree?" If you get three different answers, you do not have autonomy. You have ambiguity.

‍

References

• Atlassian. (n.d.). Team Topologies. Retrieved February 24, 2026, from https://www.atlassian.com/devops/frameworks/team-topologies
• Bezos, J. (2016). 2016 letter to shareholders. About Amazon. Retrieved February 24, 2026, from https://www.aboutamazon.com/news/company-news/2016-letter-to-shareholders/
• Clifford, C. (2022, October 6). How this popular Jeff Bezos quote drives Amazon's climate goals. CNBC. https://www.cnbc.com/2022/10/06/how-this-popular-jeff-bezos-quote-drives-amazons-climate-goals.html
• DORA. (2026). A history of DORA’s software delivery metrics. Retrieved February 24, 2026, from https://dora.dev/guides/dora-metrics/history
• Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly, 44(2), 350–383. https://doi.org/10.2307/2666999
• GitLab. (n.d.). Directly responsible individuals (DRI). GitLab Handbook. Retrieved February 24, 2026, from https://handbook.gitlab.com/handbook/people-group/directly-responsible-individuals/
• Lashinsky, A. (2011, May 24). How Apple works. Fortune. https://fortune.com/article/inside-apple/
• Rogers, P., & Blenko, M. (2006). Who has the D? How clear decision roles enhance organizational performance. Harvard Business Review, 84(1), 52–61. https://pubmed.ncbi.nlm.nih.gov/16447369/

‍