DevOps Maturity: A Practical Diagnostic

"DevOps isn't a job title, a tool, or a separate team. It's a culture of collaboration between the people who build software and the people who run it."

Having Docker and a CI pipeline doesn't tell you whether a team ships safely. You have to look at the entire path between a code change and its outcome in production.

The five stages below are my own diagnostic roadmap, not an official DORA classification. Use them to spot your next bottleneck without turning the labels into a competition between teams.

The 5 Levels of DevOps Maturity

---

Level 1: Initial (Controlled Chaos)

Situation: Manual deployments, inconsistent environments, "it works on my machine."

Characteristics:

• Deploying is a traumatic event
• Rollback means praying and restoring from backup
• No clear versioning of configuration
• Ops team is purely reactive (constantly firefighting)

What to observe: Delivery frequency, lead time to production, failure rates, and recovery time. Record your current baseline before setting targets.

Action Plan:

1. Put all code under version control (Git) if it isn't already
2. Document the current deployment steps
3. Create your first staging environment
4. Automate at least the build step

---

Level 2: Repeatable (Defined Processes)

Situation: Processes exist, but they are still manual. Checklists exist, but humans execute every step.

Characteristics:

• Deployment follows a script or runbook
• Staging exists, though it doesn't always mirror production
• Automated tests exist, but they don't block deployment
• Reactive monitoring (alerts fire only after things break)

What to observe: Where the process still relies on manual execution and how long a change sits waiting at each stage.

Action Plan:

1. Implement basic CI (automated build + test suite)
2. Create a semi-automated deployment pipeline
3. Improve parity between staging and production
4. Set up basic infrastructure alerts

---

Level 3: Defined (Consistent Automation)

Situation: Working CI/CD, Infrastructure as Code (IaC) in use, standardized practices.

Characteristics:

• One-click (or merge-triggered) deployments
• Versioned infrastructure (Terraform, Pulumi)
• Automated tests gate deployments
• Foundational observability (logs, metrics, traces)

What to observe: Whether automation actually reduced delivery time without increasing failed changes. Compare metrics for the same service over time.

Action Plan:

1. Full CD pipeline (automated deploy to staging, one-click promotion to production)
2. Feature flags for gradual rollouts
3. Observability dashboards
4. Runbooks for common incidents

---

Level 4: Managed (Metrics Guide Decisions)

Situation: DORA metrics tracked, SLOs defined, culture of continuous improvement.

Characteristics:

• Multiple deployments per day when needed
• Automated rollback on failure
• SLOs backed by error budgets
• Blameless post-mortems

What to observe: Delivery throughput and reliability indicators together, always within the context of the specific service.

Action Plan:

1. Canary or blue-green deployments
2. Formalized SLOs with error budgets
3. Structured post-mortem process
4. Self-service workflows for developers

---

Level 5: Optimized (Elite)

Situation: End-to-end continuous deployment, constant experimentation, chaos engineering.

Characteristics:

• A commit reaches production in minutes
• Feature flags are used wherever they help decouple deployment from release
• Chaos engineering practiced regularly
• Dedicated platform team enabling product developers

What to observe: The ability to ship small changes, recover quickly from failures, and learn from incidents. Deploying multiple times a day is a capability, not a universal target for every system.

---

DORA Metrics Today

The DORA documentation describes five metrics for evaluating software delivery performance over time:

1. Deployment frequency: How often changes reach production.
2. Change lead time: Time from commit to production.
3. Failed deployment recovery time: How long it takes to restore service after a failed deployment.
4. Change fail rate: Percentage of deployments that require immediate remediation.
5. Deployment rework rate: Percentage of unplanned deployments aimed at fixing production incidents.

The older MTTR label still appears in many resources, but the current DORA framing specifically distinguishes recovery time from a failed deployment. Compare each application against its own history and investigate bottlenecks alongside the team. Isolated numbers never explain product quality on their own.

---

Where Platform Engineering Helps

An internal platform can eliminate repetitive work when multiple teams hit the same friction points:

• Platform team builds self-service capabilities
• Developers consume clean abstractions instead of raw infrastructure tools
• Standardization balanced with flexibility
• Developer Experience (DevEx) treated as a first-class metric

Read more in: The End of DevOps As We Know It

---

The Next Step

1. Diagnostic: Which level describes your current workflow?
2. Prioritization: What is the single highest-impact next step?
3. Execution: Small, consistent improvements

Want help mapping delivery bottlenecks in your environment? Talk to me.

Reference

• DORA: software delivery performance metrics