Autonomy lets developers and teams make decisions within their responsibilities without waiting for another team to perform routine work. It does not mean removing controls or making developers build every pipeline alone. The aim is to reduce the friction of rigid approvals while preserving governance and compliance. section 4.1 section 4.0
Consider a team that needs an S3 bucket, database access, or a production deployment. If each request requires tickets and handoffs, the team cannot act independently even when it owns the service. A useful first step is to identify which requests interrupt daily work most often. Pipeline control is one starting point; infrastructure provisioning, access requests, secrets, and observability setup present similar opportunities. section 4.1.1
For pipelines, separate responsibility for compliance from verification:
- Let development teams control their pipelines within necessary guardrails, rather than assigning each step to a different team. section 4.1.1
- Distinguish doing the work needed for compliance from verifying that it was done. section 4.1.1
- Verify at the point of change: the first environment deployment and every deployment after it, especially production. section 4.1.1
Self-service deployment
A developer uses an internal developer platform to configure and deploy a new microservice without waiting for operations. Templates and policies provide standardization; CI/CD integration and automated provisioning handle repetitive work. The developer gains control over delivery without having to manage every infrastructure detail. section 10.6.1
Autonomy also needs clear team boundaries and ownership. Stream-aligned teams that own their services can reduce handoffs, while independent platform domain teams can evolve according to user demand and business value. To assess progress, map handoffs and bottlenecks, then track measures such as deployment frequency, lead time, and failure rate alongside the team's experience of the process. section 9.4 section 10.3.3 section 1.3.2
