Autonomy: The Art of Letting Go Without Losing Control

Part 2 of 4: The Four Pillars of Progressive Delivery

At GitHub, developers can deploy code to production over 100 times per day. Each deployment happens autonomously—no approval committees, no change management boards, no waiting for the “right” time to ship. Yet the platform serves millions of developers who depend on GitHub for mission-critical work.

How do you give teams that much autonomy without creating chaos?

The answer lies in understanding that autonomy isn’t about removing all constraints—it’s about moving constraints to the right places in your system.

What Autonomy Actually Means

In Progressive Delivery, autonomy is the ability of individuals and teams to act independently from others when they have access to all necessary resources to complete their desired tasks. This includes:

• Technical autonomy: Access to tools, infrastructure, and environments needed to build and deploy
• Decision autonomy: Authority to make choices about implementation details and timing
• Process autonomy: Freedom to adapt workflows to match team needs and project requirements
• User autonomy: Control over when and how to adopt new features and changes

The key insight is that autonomy without alignment leads to chaos, but alignment without autonomy leads to stagnation.

From Git to Radical Delegation

The evolution of software development illustrates how autonomy has expanded over time. Before distributed version control systems like Git, developers often worked in a serialized fashion—only one person could modify a particular piece of code at a time to avoid conflicts.

Git revolutionized this by enabling parallel development. Suddenly, teams could work autonomously on different features while maintaining the ability to integrate their work. This wasn’t just a technical improvement—it was a fundamental shift in how software development work could be organized.

Progressive Delivery extends this concept through what the authors call “radical delegation”—progressively moving control closer to the people most affected by the outcome. Instead of central teams deciding when users should adopt new features, you delegate that decision to the users themselves.

Autonomy in Action: The Adobe AI Strategy

Adobe’s approach to AI integration demonstrates sophisticated autonomy in practice. When they added AI capabilities to their Creative Cloud suite, they could have simply pushed the latest models to all users simultaneously. Instead, they implemented granular controls that respect different types of autonomy:

• Developer autonomy: Engineering teams can experiment with new AI models and features without waiting for company-wide approval processes.
• Business autonomy: Product teams can decide when and how to expose AI capabilities based on user feedback and market readiness.
• User autonomy: Individual users can choose which AI model version to use for different projects, maintaining consistency for ongoing work while experimenting with cutting-edge capabilities for new projects.

This layered approach allows innovation to happen at the speed of development while ensuring users never feel forced into disruptive changes.

The Three Types of Autonomy

Individual Autonomy

The ability for single contributors to make meaningful progress without waiting for others. This includes access to development environments, deployment tools, and decision-making authority within their domain of expertise. It also assumes a stable shared platform with APIs and similar interfaces that allow internal changes without changing external interactions.

GitHub exemplifies this with their approach to feature development. Any developer can create a feature branch, implement changes, and deploy the changes behind feature flags without requiring approval from other teams. The constraint isn’t on individual action—it’s on when changes become visible to users.

Team Autonomy

The ability for small groups to operate independently while maintaining alignment with broader organizational goals. This often manifests as microservices architectures, where teams own entire services end-to-end. This also relies on a shared platform and interaction standards.

Amazon’s famous “two-pizza team” rule reflects this thinking. Teams should be small enough that two pizzas can feed everyone, and they should have everything they need to build, deploy, and maintain their services independently.

User Autonomy

The ability for software consumers to control their own experience. This might mean choosing when to adopt new features, customizing interfaces to match their workflows, or integrating with other tools in their environment.

Microsoft’s Office suite demonstrates this well. Power users can customize ribbons, create macros, and integrate with other applications, while casual users can stick with default configurations. Both groups use the same underlying software but with very different levels of autonomy.

The Trust Equation

Autonomy requires trust, but trust must be earned through demonstrated competence and shared alignment. This creates what Progressive Delivery calls “the trust equation”:

Trust = (Competence + Reliability + Alignment) / Risk

As teams demonstrate competence (they know what they’re doing), reliability (they do what they say they’ll do), and alignment (they’re working toward shared goals), they earn more autonomy. But this only works when the potential risk of independent action is manageable.

This explains why GitHub can allow autonomous deployments—they’ve built systems that make individual deployments low-risk through feature flags, automated testing, and easy rollbacks. The trust isn’t blind—it’s backed by engineering practices that minimize the cost of mistakes.

Autonomy Without Chaos

The key to enabling autonomy without creating chaos is understanding the difference between delegation and abdication:

Delegation maintains accountability while transferring authority. You give teams the power to make decisions but retain responsibility for outcomes.

Abdication transfers both authority and accountability. You give teams power but also abandon responsibility for results.

Progressive Delivery advocates for radical delegation, not abdication. When GitHub gives developers deployment autonomy, the company still maintains responsibility for platform reliability. When Adobe lets users choose AI models, Adobe still ensures all available models meet quality standards.

Psychological Safety as Required Foundation

Autonomy only works in environments with high psychological safety—where people feel safe taking risks, making mistakes, and speaking up about problems. Without psychological safety, autonomy devolves into either paralysis (people afraid to act) or recklessness (people taking shortcuts to avoid scrutiny).

Organizations building Progressive Delivery capabilities must invest heavily in creating cultures where:

• Mistakes are treated as learning opportunities, not blame events
• People are encouraged to surface problems early rather than concealing them
• Success is measured by outcomes achieved, not processes followed
• Experimentation is rewarded even when experiments fail

Getting Started with Autonomy

Begin by identifying where lack of autonomy currently creates bottlenecks:

• Technical bottlenecks: Where do teams wait for infrastructure, environments, or tool access?
• Process bottlenecks: What decisions currently require approval that could be delegated?
• Information bottlenecks: What knowledge is trapped with individuals rather than shared across teams?
• Feedback bottlenecks: How long does it take to understand whether changes are working?

Start with low-risk areas where the cost of mistakes is manageable, then gradually expand autonomy as teams demonstrate competence and alignment.

The Autonomy Advantage

Organizations that successfully balance autonomy with alignment can move faster than their more centrally controlled competitors. They can experiment more rapidly, adapt to changing conditions more quickly, and attract talent that values independence and ownership.

But autonomy isn’t an end goal—it’s a means to delivering better software to users who can also exercise their own autonomy in adopting and using that software.

Next week: Part 3 explores Alignment—how autonomous teams and users can work together toward shared goals without sacrificing independence.

This series explores concepts from the book Progressive Delivery: Build The Right Thing For The Right People At The Right Time by James Governor, Kim Harrison, Heidi Waterhouse, and Adam Zimman (IT Revolution Press, November 2025).

- About The Authors

Leah Brown

Managing Editor at IT Revolution working on publishing books and guidance papers for the modern business leader. I also oversee the production of the IT Revolution blog, combining the best of responsible, human-centered content with the assistance of AI tools.

Follow Leah on Social Media

•