Across three companies, I've seen DevOps evolve from a job title to a culture to something that AI agents are starting to automate entirely.
DevOps is the most misunderstood term in engineering. People call it "using Kubernetes." People call it "having a DevOps team." People call it "infrastructure automation." All of these are false.
DevOps is a culture. It's a set of practices that align incentives between the people who build software and the people who operate software.
The Origin: Misaligned Incentives
Thirty years ago, Development and Operations were separate functions with opposite goals.
Dev wanted to ship fast. Push code to production. Move quickly. The faster you shipped, the better.
Ops wanted stability. Don't change production. Minimize incidents. Each change is a risk.
These goals are opposed. Dev says "release every day." Ops says "releases are dangerous, we release twice a year." This conflict creates delays, frustration, and bad outcomes. Features take months to reach customers. Small bugs take weeks to roll out because release scheduling is constrained. Ops is blamed for delays. Dev is blamed for instability.
The solution is alignment: both Dev and Ops care about shipping value reliably. Fast and stable, not fast or stable.
What DevOps Actually Means
DevOps is not a tool or a team. It's a set of practices that break down the wall between Dev and Ops.
Shared responsibility for the full software lifecycle. Dev is responsible for code quality and testing. Ops is responsible for production reliability and observability. DevOps means they're responsible for both. Developers care about production stability. Operations engineers care about shipping velocity.
This doesn't mean everyone does everything. It means incentives are aligned. When a developer ships code that causes an outage, that's on them (or the team). When an outage takes three hours to debug, that's on the team too (they need better observability).
CI/CD as the standard path: Code goes from your editor to production through an automated pipeline. Test, build, deploy. No manual steps (or very few). No approval gates (or few). This makes shipping fast and low-risk. Fast because there's no waiting for approvals. Low-risk because there are no human manual steps where things go wrong.
Infrastructure as code: Your infrastructure is defined in code, version-controlled, reviewed, and deployed like application code. This creates consistency, auditability, and the ability to reproduce your infrastructure exactly.
Monitoring and observability as first-class concerns: You're not observing production after it's built. You're building observability into the code. Logs, metrics, traces are as important as the application logic. This lets you answer questions about production behavior fast.
Blameless post-mortems: When something breaks, you investigate the root cause without assigning blame. "John made a mistake" is not the answer. "The system allowed this mistake to reach production" is. You fix the system (automation, testing, tooling) so the same mistake doesn't happen again.
This requires a specific culture: mistakes happen, we learn from them, we improve the system.
On-call rotations that include developers: Developers respond to production incidents. Not as a special case. As part of their job. This creates powerful incentives: you write code that's easy to debug and operate because you're on-call for it.
When developers are on-call, code quality improves. When Ops is responsible for reliability and Dev doesn't care, code quality is bad and Ops is constantly putting out fires.
DevOps Theater
DevOps theater is having all the tools and none of the culture.
You have Kubernetes. You have Terraform. You have CI/CD. But:
- Developers write code with no thought for production.
- Operations has a separate on-call rotation and owns all production.
- Post-mortems assign blame.
- Deployments require multiple approvals and take hours.
This is theater. You look like DevOps from the outside. You're not actually DevOps.
The tell: are developers in the on-call rotation? Do they care about production incidents? If the answer is no, you're theater.
DevOps Maturity
DevOps maturity looks like this:
Level 1 (Ad hoc): No automation. Deployments are manual. Operations is a mess. Incidents are chaos. This is unsustainable.
Level 2 (Foundational): You have some CI. You have monitoring. Deployments are mostly automated. Incidents are managed. You're stable but slow.
Level 3 (Practices in place): You have full CI/CD. You have observability. Infrastructure is code. On-call includes developers. Deployments are frequent. You're fast and mostly stable.
Level 4 (Optimized): You're improving continuously. Blameless post-mortems drive improvements. Team autonomy is high. You're shipping fast with high reliability.
Most companies are Level 1-2. Some get to Level 3. Very few get to Level 4.
The progression isn't quick. Each level requires investment. Level 3 requires 6-12 months of serious effort for a growing company. Don't expect it overnight.
How DevOps Maturity Connects to Business Outcomes
This is the part that matters to PMs and business leaders.
Deployment frequency: How often can you deploy? Level 1: weeks. Level 3: daily. This is how fast you can ship features and respond to bugs. If a competitor ships a bug fix in hours and you need three weeks, you lose.
Lead time for changes: How long from "I want to build this" to "it's in production"? Level 1: months. Level 3: days. This is how fast you can respond to market changes.
Mean time to recovery: When something breaks, how long until you fix it? Level 1: hours (you're waiting for Ops to investigate). Level 3: 15 minutes (Dev is on-call, they know the code, they fix it fast). This is your reliability.
Change failure rate: What percentage of deployments cause an incident? Level 1: 40%. Level 3: 5%. This is your quality.
These aren't independent. They're connected:
- High deployment frequency + low change failure rate is possible (Level 3 achieves this).
- High deployment frequency + high change failure rate is reckless.
- Low deployment frequency + low change failure rate is safe but slow.
DevOps maturity gets you both fast and safe.
For PM Audience: What This Means for Planning
When you're planning a roadmap and the CTO says "we can ship 20 features per quarter," that's constrained by DevOps maturity.
Level 1 team: 5 features per quarter (months of stabilization per feature). Level 2 team: 10-15 features per quarter. Level 3 team: 20-30 features per quarter.
If you want to promise more features than your team can deliver, you have two choices:
- Hire more people (slow, expensive).
- Improve DevOps maturity (fast, free in the long run).
Plan roadmaps with DevOps maturity in mind. If you're Level 2 and want Level 3 productivity, budget time for DevOps improvements.
Conversely: if your team is Level 3 but you're not seeing the productivity gains, the problem is not DevOps. It's something else (vague requirements, unrealistic scope, bad prioritization).
Connecting to Codebase Intelligence
Here's where Glue helps. DevOps maturity requires understanding your codebase.
Glue lets you ask: "Which services lack observability? Those are the ones where on-call will be painful." Focus observability improvements there.
Or: "Which services have the most manual deployment logic in their Makefiles or scripts? Can we standardize that in our CI/CD pipeline?" You identify automation candidates.
Or: "Which services have the lowest test coverage? Those are candidates for incidents." You know where to invest in testing.
Or: "Show me the deployment patterns. Are we really deploying continuously or is it monthly with big batches?" This is reality vs. stated maturity.
Codebase intelligence helps you improve DevOps maturity by showing you where the problems actually are, not where you assume they are.
What Is DevOps in 60 Seconds TL;DR
DevOps aligns Dev and Ops incentives. It's culture (shared responsibility, blameless post-mortems, on-call includes developers) plus practices (CI/CD, infrastructure as code, observability). DevOps theater has tools but not culture. Maturity levels: ad hoc (months to deploy), foundational (weeks), practices (days), optimized (hours). High maturity means: deploy frequently, low failure rate, fast recovery, high quality. Plan roadmaps with DevOps maturity in mind.
Frequently Asked Questions
Q: We don't have a separate Ops team. Are we DevOps?
A: Maybe. If developers are responsible for operating their services (monitoring, on-call, incident response), you're close. If developers write code and throw it over the wall to production without caring what happens, you're not. Team structure doesn't matter - incentive alignment does.
Q: How long does it take to go from Level 1 to Level 3?
A: 6-12 months for a 20-50 person team. Longer for larger teams. This is not a small investment. But the payoff (2-3x productivity and faster incident response) is worth it.
Q: Can we do DevOps with legacy systems?
A: Yes. It's harder. You can't rip and replace. But you can gradually improve: start with monitoring, add CI/CD, move to infrastructure as code. It's slower than greenfield, but possible.
Related Reading
- DORA Metrics: The Complete Guide for Engineering Leaders
- Deployment Frequency: The DORA Metric That Reveals Your True Engineering Velocity
- Cycle Time: Definition, Formula, and Why It Matters
- Change Failure Rate: The DORA Metric That Reveals Your Software Quality
- Code Refactoring: The Complete Guide to Improving Your Codebase
- Software Productivity: What It Really Means and How to Measure It