DevOps Maturity Assessment: Where Does Your Organisation Stand
DevOps is simultaneously one of the most transformative and most misunderstood movements in enterprise technology. A decade after Patrick Debois coined the term, organisations continue to conflate DevOps with tooling, equate it with CI/CD pipelines, or treat it as a team name rather than an operating philosophy. The result is that many enterprises believe they are “doing DevOps” while their engineering organisations continue to struggle with the same delivery challenges that DevOps was intended to address.
The Accelerate State of DevOps Report, published annually by the DORA team, provides compelling evidence that high-performing DevOps organisations deliver software faster, more reliably, and with lower change failure rates than their peers. These are not marginal differences — elite performers deploy on demand with lead times of less than one hour, while low performers deploy between once per month and once every six months with lead times of between one and six months. The gap is enormous, and it translates directly into competitive advantage.
For the CTO seeking to understand where their organisation stands and what investments will yield the greatest improvement, a structured maturity assessment is essential. Not as a one-time exercise, but as a recurring practice that drives continuous improvement with clear, measurable progression.
The Five Levels of DevOps Maturity
A useful maturity model must be specific enough to be actionable while avoiding the trap of reducing a multidimensional capability to a single score. The model I use with enterprise clients assesses maturity across five levels and four dimensions: culture, process, technology, and measurement.
Level one — Initial — is characterised by manual processes, siloed teams, and infrequent releases. Development and operations function as separate organisations with handoff-based interaction. Deployments are manual, error-prone, and typically performed outside business hours to minimise impact. Testing is predominantly manual and occurs late in the development cycle. Monitoring, if it exists, is reactive — the team learns about problems when users report them.
Level two — Managed — introduces basic automation and cross-functional awareness. CI pipelines automate build and unit testing. Version control is used consistently. Development and operations teams have regular communication, even if they remain organisationally separate. Deployments follow documented procedures, though they may still require manual steps. Basic monitoring covers infrastructure availability, but application-level observability is limited.
Level three — Defined — represents the transition to systematic practices. CD pipelines automate deployment to at least some environments. Infrastructure is managed as code, even if not all environments are fully automated. Cross-functional teams begin to form, with developers taking on-call responsibility for their services. Automated testing covers unit, integration, and basic end-to-end scenarios. Monitoring includes application-level metrics and alerting with defined escalation procedures.
Level four — Measured — is distinguished by data-driven optimisation. The four key metrics identified by the DORA research — deployment frequency, lead time for changes, mean time to restore, and change failure rate — are tracked and used to drive improvement. Feature flags enable progressive delivery and rapid rollback. Infrastructure is fully automated and reproducible. Security is integrated into the delivery pipeline (DevSecOps). Incident response follows structured processes with blameless post-mortems that drive systemic improvements.
Level five — Optimised — represents continuous improvement driven by experimentation. The organisation experiments with delivery practices, measures the outcomes, and adopts what works. Chaos engineering proactively tests system resilience. The deployment pipeline supports canary releases, blue-green deployments, and automated rollback. The organisation contributes to the broader community through open-source contributions, conference presentations, and published research.
Assessing Each Dimension
Culture is the most difficult dimension to assess and the most impactful. DevOps culture is characterised by shared responsibility between development and operations, psychological safety that enables learning from failure, and a systems-thinking approach that optimises for global outcomes rather than local efficiency.
The assessment questions for culture include: Do development teams take on-call responsibility for their services? Are post-mortems conducted without blame, focusing on systemic improvements? Do teams have autonomy to select their tools and practices within defined guardrails? Is collaboration between development, operations, and security the norm or the exception? Do leaders model the behaviours they expect — transparency, learning from failure, and continuous improvement?
Process maturity is assessed through the lens of the delivery pipeline. How frequently does the organisation deploy to production? What is the elapsed time from code commit to production deployment? What percentage of deployments require manual intervention? What is the change failure rate, and how quickly are failures detected and resolved? Is there a defined process for managing technical debt and prioritising it against feature development?
Technology maturity encompasses the toolchain and practices that enable the process. Is source code managed in a modern version control system with branch management practices? Are builds automated and reproducible? Are tests automated at unit, integration, and end-to-end levels? Is infrastructure defined as code? Are environments provisioned and configured automatically? Is the deployment process automated with support for rollback? Is monitoring and alerting comprehensive, covering infrastructure, application, and business metrics?
Measurement maturity asks whether the organisation uses data to drive improvement. Are the four key DORA metrics tracked? Are they used to identify improvement opportunities and measure the impact of changes? Are experiments conducted to test hypotheses about what will improve delivery performance? Is there a feedback loop from production incidents to development practices?
Common Anti-Patterns and Progression Blockers
Several patterns consistently prevent organisations from progressing through the maturity levels.
The “DevOps team” anti-pattern creates a new silo rather than eliminating existing ones. When an organisation creates a team called “DevOps” and assigns them responsibility for the CI/CD pipeline, they have merely renamed the operations team and perpetuated the handoff model. DevOps is a set of practices and cultural norms adopted by all teams, not a team name.
The “tools before culture” anti-pattern invests heavily in tooling while neglecting the cultural and process changes that make those tools effective. The most sophisticated CI/CD pipeline in the world does not help if developers do not write automated tests, if deployments still require manual approval gates with week-long lead times, or if operations does not trust the deployment process enough to allow daytime releases.
The “big bang transformation” anti-pattern attempts to change everything at once. DevOps maturity is built incrementally. Organisations that try to jump from level one to level four in a single initiative typically achieve neither, burning out their teams and creating cynicism about transformation efforts.
The “metrics without action” anti-pattern tracks the DORA metrics without using them to drive improvement. Measurement is only valuable if it leads to action. When the data shows that lead time is increasing, the response should be investigation and targeted improvement, not a dashboard that no one reviews.
Building a Progression Strategy
The most effective approach to DevOps maturity improvement is to assess current state honestly, identify the highest-impact improvement opportunities, and execute focused improvement initiatives with measurable outcomes.
For organisations at level one or two, the highest-impact investments are typically in CI/CD automation and cultural change. Automating the build and test process reduces the friction of delivering software and creates the foundation for further improvement. Establishing cross-functional incident response and blameless post-mortem practices begins the cultural shift toward shared responsibility.
For organisations at level three, the focus shifts to measurement and optimisation. Implementing the DORA metrics and using them to identify bottlenecks provides the data-driven foundation for targeted improvement. Introducing infrastructure as code and automated environment provisioning eliminates a common source of deployment delays and inconsistencies.
For organisations at level four, the opportunity is in advanced practices — progressive delivery, chaos engineering, and continuous experimentation. These practices further reduce risk and improve resilience while maintaining or increasing delivery velocity.
At every level, investment in people is as important as investment in technology. Training, mentoring, communities of practice, and external engagement (conferences, meetups, reading groups) build the capability and cultural norms that sustain DevOps practices.
The CTO’s role in this progression is to set the strategic direction, provide the investment, remove organisational blockers, and model the cultural behaviours that DevOps requires. The transformation will not happen because of a tool purchase or a reorganisation. It will happen because the leadership team commits to a sustained programme of improvement that values learning, measurement, and continuous adaptation.
Honest self-assessment is the starting point. Where does your organisation stand today — not where you wish it stood, but where it actually is? That honest answer is the foundation on which meaningful improvement is built.