Autonomous teams perform better.

Dave Leigh

• 4 min read

There is a plethora of material with sound advice on how to create high performing teams. However... our systems of work are unique meaning at times it can be difficult knowing how to act on this advice, moving from theory into reality.

We all know that theory - autonomous teams perform better. It’s a key principle in agile, DevOps, and modern software delivery.

TL;DR:

If we can grow as organisations to ease off bureaucracy to truly empower teams with autonomy, and if we put trust in those teams embedding this mindset into team culture then improvement becomes real. Experimentation becomes normal, inertia fades and teams get measurably better at shipping high quality software, fast.

Note- this requires strong leadership within the teams, motivated to make their teams the best they can possibly be.

Some examples of forces that reduce autonomy (and what to do about them)

Below I’ve recorded my experience across our teams, examples where lack of autonomy has slowed us down and practically what we did about it.

1. Bureaucracy: Code Freezes, Quality Gates and red tape.


Problem:

Overly cautious release policies (like code freezes and rigid approval gates) give a false sense of confidence. They delay releases, demotivate teams, and reduces flow.

Opportunity:

  • Aim to eliminate handoffs in the release process by giving teams accountability and ownership of the full delivery lifecycle.
  • Introduce instrumentation, real-time observability, feature flags, and automated testing to eliminate code freezes.
  • Ask teams what it would take to ship code regularly, quickly and safely and back them to get there by reserving dedicated time to continuous improvement.

2. Lengthy external testing


Problem:

It’s easy to fall into a trap where we draw confidence in our ability to release through a 1-2 week test cycle external from the team. In reality real confidence comes from continuous delivery and low change failure rates. Long external testing slows everything down and decouples teams from outcomes.

Opportunity:

  • Shift end-to-end testing into the team.
  • Embrace lightweight testing, contract testing, and risk-based testing for key flows.
  • Automate everything - ship continuously to pre-prod, and ideally to prod (behind feature flags).
  • Practice testing in production strategies.
  • Trust your automation - if the tests pass, then ship the code.

3. Inertia and cultural resistance to change


Problem:

It’s easy for teams to fall into “this is how it’s always been” mindset, where we become used to friction and improvement is optional. This slows innovation.

Opportunity:

  • Encourage experimentation, especially a culture where those experiments are emerging from the teams.
  • Help teams share new ideas, and improvement strategy,
  • As leaders encourage a ‘why not change it?’ mindset over ‘this is how its always worked’
  • Celebrate and share internal wins - even minor improvements.

4. Manual release process


Problem:

Manual steps like traffic switching, updating documentation, or waiting for sign off creates friction and risk

Opportunity:

  • Value stream map your release process to identify opportunities - Identify manual steps and automate them.
  • Separate the concepts of deployment and release to make release a non-event - just update a flag.
  • Use infrastructure as code (IaC) and CI/CD pipelines to replace human handoffs with reliable, repeatable steps.

5. Shared deployment pipelines and fear of change


Problem:

Shared pipelines can bring a sense of efficiency but they don’t always work out in practice. When multiple teams use shared pipelines or tooling, changes are slow and risky. Nobody wants to be the one to break it.

Opportunity:

  • Empower each team to own their own delivery pipelines.
  • Use platform teams to provide paved roads (sensible defaults) to enable teams to quickly build their own pipelines using reusable foundations.
  • Don’t be scared of duplication where it reduces friction. Centralisation is a cost - ensure it’s a worthwhile cost.
  • Avoid premature abstraction - don’t build shared services or tooling until there's a clear, shared need.

6. Shared codebases and apps owned by multiple teams


Problem:

Apps that span multiple teams require coordination, cause slowdowns, and introduce unclear ownership. With unclear ownership it is more difficult for a single team to improve a shared solution or process.

Opportunity:

  • For smaller applications a monolithic architecture is fine but when working at scale use techniques such as DDD and Bounded context to break up large apps and align them to a single team.
  • This promotes clarity of ownership, faster decision making, and reduced coordination costs.
  • Teams can move faster because they understand, control, and take responsibility for the full lifecycle.

7. Unclear or short lived team structures


Problem:

When we don’t design our teams to be long lived and product orientated they can lack context, continuity, and purpose.

This matters because:

  • Teams without domain alignment don’t build up deep understanding and expertise.
  • Short lived teams are less invested in the long-term quality of their systems.

Opportunity:

  • Design teams to be long lived and aligned to specific business domains.
  • These teams can build expertise, take accountability for outcomes, and own their systems end to end.

8. Shared APIs, Databases, CDNs.


Problem:

Changes to shared APIs, DBs, or CDN rules often require external approvals and coordination with other teams, impacting our ability to deliver quickly.

Opportunity:

  • Consider backward compatible APIs - versionless where possible.
  • Use contract tests to ensure consumer compatibility - it requires buy-in of both teams but becomes a shared benefit.
  • Automate database and content migrations as part of the deployment process.
  • Shift CDN and traffic routing closer to the product teams and ensure its built using Infrastructure as code.

9. Cloud Engineering as a dependency


Problem:

When teams throw IaC tickets over the fence to a cloud engineering team, they lose speed and control.

Opportunity:

  • Try a truer DevOps model where infrastructure and platform knowledge are moved into the team.
  • Utilise platform teams to enable engineers to provision and manage their own infrastructure.
  • Cloud SMEs can join teams for a period of time to act as enablers.

10. Centralised standards without flexibility


Problem:

Forcing rigid adherence to centralised standards, for example “this is how we build APIs” can stifle innovation and autonomy.

Opportunity:

  • Provide platform-led patterns and recommended/default approaches, but don’t enforce uniformity unless it's proven to add value.
  • Let teams deviate if there's a good reason. Crucially then encourage them to share their learnings back.
  • Use guardrails, not gates - promote consistency without creating constraints.

Conclusion

Autonomy is not about letting every team do whatever they want - ten teams with ten different ways to build and deploy an API might not be sensible. Instead it’s about empowering teams to own their outcomes, with clear boundaries, the right skills, and the trust from leadership.

When we are able to foster a culture of autonomy, and we see these behaviours bubbling up from within the teams then we:

  • Ship faster
  • Own quality end to end
  • Reduce dependencies and delay