This article draws on findings from the 2018 State of DevOps Report, co-authored by Puppet and Splunk, based on a survey of more than 3,000 technology professionals.
Why a Structured DevOps Evolution Matters
Software teams face relentless pressure to ship faster without sacrificing stability or security. DevOps has emerged as a widely adopted approach for closing the gap between development speed and operational reliability. But knowing that DevOps works is only half the battle — teams also need a practical roadmap for getting there.
The 2018 State of DevOps Report defines DevOps adoption as a five-stage evolution. Each stage builds on the previous one, and the report’s data shows that progressing through these stages correlates strongly with measurable DevOps success, as evaluated through the CAMS model (Culture, Automation, Measurement, and Sharing).
The Five Stages of a DevOps Evolution
- Normalize the technology stack
- Standardize and reduce variability
- Expand DevOps practices
- Automate infrastructure delivery
- Provide self-service capabilities
This article focuses on stages 1 through 3 — the foundational work that makes automation and self-service possible in later stages.
Stage 1: Normalize the Technology Stack
Automation is often cited as the starting point for DevOps, and it is certainly central to any successful initiative. But automation is only as effective as the environment it operates in. The more complex and inconsistent your tools and systems are, the harder they are to automate reliably. Stage 1 is about doing the groundwork: simplifying the technology landscape before you try to automate it.
Normalization means adopting a standard set of tools and eliminating redundant or one-off technologies. Two practices are central to this stage:
Prioritizing Version Control
Version control is the foundation of continuous integration. When development teams commit both application code and configuration files to a version control system, they gain the ability to produce deployable artifacts more frequently and consistently. This increased velocity creates healthy pressure on operations teams to deploy quickly while maintaining stability — a tension that is, in fact, one of the key drivers of DevOps adoption.
As teams mature, configuration data is separated from application code to protect sensitive information. This separation builds the foundation for automated deployment pipelines and enables clear audit trails: you can see who changed what, when, and roll back if something goes wrong.
Standardizing Operating Systems
In a pre-DevOps environment, it is common to find applications scattered across a variety of operating systems, each with its own configuration quirks. Every one-off installation adds cognitive overhead for IT teams and increases both the risk and impact of maintenance — particularly emergency maintenance.
Reducing OS sprawl simplifies the automation surface and builds a shared pool of institutional knowledge around a common stack. A practical approach is to start within a single team, prove out the value of standardization there, and then expand to teams that require broader organizational buy-in. Establish clear guidelines for how and when new technologies can be added to production environments.
Stage 2: Standardize and Reduce Variability
By the time an organization reaches Stage 2, it should have achieved several foundational milestones:
- Begun standardizing on a consistent set of technologies
- Separated application configurations from sensitive data and placed them in version control
- Adopted a consistent process for infrastructure testing and source code sharing
Stage 2 deepens the standardization work begun in Stage 1, shifting the focus toward reuse of technologies and patterns. Repeatable outcomes with less variance become the goal.
Build on a Standard Set of Technology
As organizations scale, complexity compounds. Teams must simultaneously manage new microservices and applications alongside legacy systems, often leaving little bandwidth for strategic improvement work. Standardizing on common patterns and components means teams no longer need to re-learn how different technologies scale, fail, recover, and upgrade with each new project.
A useful starting point is to normalize foundational elements such as testing workflows and build-and-ship pipelines, with a focus on optimizations that have broad impact across multiple applications.
Reduce Operating System Variability
Reducing OS diversity saves time on patching, tuning, upgrading, and troubleshooting — time that can be redirected toward higher-value work. That said, OS standardization is not always straightforward. Long-lived applications may not be compatible with newer operating systems, or specific patches may conflict with particular workloads.
The guiding principle here is: less is more. Even if a single OS is not feasible across the board, running two is significantly better than running five. Within the operating systems you do maintain, normalize compute resources to reduce the surface area for troubleshooting and maintenance.
Stage 3: Expand DevOps Practices
Stages 1 and 2 create the conditions for genuine collaboration between development and operations. When both teams share tools, patterns, and knowledge, they can work together effectively. Stage 3 is about scaling these early successes from isolated pockets of adoption to organization-wide practice.
Two defining practices characterize this stage:
- Individuals can perform work without requiring manual approval from outside their immediate team.
- Deployment patterns for building applications and services are actively reused across teams.
Reduce Bureaucracy
When decision-making authority is removed from the people who have the most relevant context — those doing the actual work — productivity and efficiency decline. The authors of Accelerate: The Science of Lean Software and DevOps found that teams required to obtain approval from an external body consistently achieved lower performance. The 2018 State of DevOps Report echoes this finding.
This does not mean eliminating change oversight entirely — that would be irresponsible. But a DevOps transformation is a good opportunity to audit existing approval processes critically. Ask which delays and wait times are genuinely justified and which are artifacts of legacy bureaucratic workflows. Identify unnecessary bottlenecks and experiment with removing them.
One practical example: give operations teams the authority to approve specific categories of lower-risk changes without escalation. This accelerates delivery, builds trust between teams, and gives team members a tangible sense of ownership — both of which are essential to a healthy DevOps culture.
Reuse Deployment Patterns
When every team in an organization creates its own deployment patterns from scratch, agility is constrained and knowledge silos form. Engineers moving between teams face steep learning curves, and documentation debt accumulates. Developing and promoting reusable deployment patterns — regardless of their complexity — reduces silos and makes it easier for engineers to contribute across team boundaries.
Some patterns apply universally; others are specific to families of applications, such as n-tier web applications or cloud-native services. The broader a pattern can be applied, the greater its leverage. An optimization made to a shared deployment pipeline is immediately inherited by every application that uses it.
Looking Ahead: Automation and Self-Service
Stages 1 through 3 are not always completed in strict sequence. The 2018 State of DevOps Report notes that some organizations tackle Stage 3 before fully completing Stage 2, or pursue them in parallel. What the research does show is that both stages are prerequisites for success in Stage 4: automating infrastructure delivery.
Stages 4 and 5 — infrastructure automation and self-service capabilities — build directly on the normalized, standardized, and culturally aligned foundation established in the first three stages. Without that foundation, automation efforts tend to automate existing chaos rather than improve on it.
For teams beginning this journey, the core takeaway is straightforward: start with simplification before you pursue automation, standardize before you scale, and reduce bureaucracy as you expand DevOps practices across the organization.