Another team in my company runs DevOps. They own an important piece of infrastructure that my system depends on.
Every important release takes my system down.
Not sometimes. Every important release. The pipeline passes, the release goes out, and my system breaks. Then it stays unstable for a while — incidents coming one by one, each one triggered by a fresh attempt to fix the last.
So now the operations team plans for it. Releases happen at weekends, and we expect an incident every week. Not as an anomaly. As a schedule.
That’s what it looks like when delivery is mistaken for development. The pipeline did its job. The software wasn’t verified. And nobody could tell the difference until it broke.
What DevOps Models
DevOps models the path from commit to production. Version control, build, test execution, deployment, monitoring, rollback. Every step is about movement — how a change gets from a developer’s machine to users, safely and repeatably.
That’s a real model. It’s complete, coherent, and it works. Teams that adopt it deliver more reliably.
What It Doesn’t Model
It doesn’t model the software.
Nothing in the pipeline tells you:
- what the system’s structure is
- what depends on what
- which paths are covered by the tests
- what’s verified and what isn’t
Those are properties of the software, not of the delivery. DevOps doesn’t model them, because they’re not what DevOps is about.
The Mistake
Here’s where it goes wrong. A model that’s complete in itself doesn’t invite questions about what it’s missing. The pipeline has stages, inputs, outputs, metrics, failure modes. It looks like a full picture of the work.
So it gets used as one.
Pipeline health becomes software health. A green build feels like a sound system. Deploy frequency feels like progress. Automation feels like engineering.
Each substitution is reasonable on its own. Together, they move the team’s attention onto the thing being modeled — delivery — and away from the thing that determines quality.
The Result
Once the pipeline is the model, the questions change.
| With a software model | With the pipeline model |
|---|---|
| Is this path covered? | Did the pipeline pass? |
| What depends on this? | How long did the build take? |
| What’s unverified? | What’s the failure rate? |
| Is the structure sound? | How many deploys this week? |
Every question on the right is answerable. Every question on the left has nowhere to land.
But the deeper reason isn’t that the tool can’t hold both sets. It’s that the tooling consumes the attention that would have gone to the other questions.
Multiple tools. Versatile dashboards. Endless settings. Interacting subsystems. Each one demands configuration, maintenance, and understanding. Each one is a place to look, a thing to check, a knob to turn.
Attention is finite. When the tooling takes most of it, the questions that aren’t in the tooling stop being asked — not because anyone decided they don’t matter, but because there’s nothing left to ask them with.
So the focus shifts to the delivery process. Gradually, and without anyone noticing, the thing the tooling models becomes the thing the team thinks about. What mattered before — structure, coverage, readiness — stops being part of the conversation.
The team doesn’t decide to stop caring about structure. It just stops having the bandwidth. And after a while, the questions that used to seem essential stop occurring to anyone at all.
What Improves, and What Doesn’t
The delivery gets better. Builds get faster. Deploys get more frequent. Stages get added. Automation grows.
All of it is real improvement — of the delivery cycle.
The software doesn’t improve. It can’t, because the software was never the thing being modeled. The pipeline delivers whatever it’s given. It has no way to tell a well-verified system from a badly-verified one.
And because delivery improved, everyone believes the software did too.
What It Costs Over Time
A single broken release is an incident. What follows is worse.
Every dependent system inherits the constraint. Teams design around instability — retries, fallbacks, degraded modes, recovery procedures. None of that would be needed if the dependency were reliable. All of it is needed because it isn’t. And none of it shows up on the ledger of the team that caused it.
The cost becomes normal. When a downstream team builds its staffing around another team’s release failures, the failure has stopped being a defect. It’s a condition to plan for.
The questions stop being asked. Nobody asks what’s covered, because the pipeline says it passed. Nobody asks what’s unverified, because there’s no place to look. And after a while, the questions stop occurring to anyone at all.
That’s the bleed. Not one outage — a permanent tax on everything built on top of the mistake.
The Flaw Is in DevOps, Not in How It’s Run
It would be easy to read this as a complaint about teams doing DevOps badly. It isn’t.
The teams are following the practice correctly. They’ve built the pipeline, adopted the tooling, and automated what the practice says to automate. By every measure DevOps provides, they’re doing it well.
The flaw is in the practice itself. DevOps models delivery, and it presents that model as a complete picture of the work. Nothing inside DevOps tells you where its boundary is. A team can follow it perfectly and still never ask the questions it doesn’t cover.
That’s not a misuse. That’s the design.
What a Development Model Would Need
Something has to model the software itself:
- Structure — components with boundaries and owners
- Dependencies — what must be true before what
- Coverage — which paths are verified and which aren’t
- Readiness — what’s safe to start, and what isn’t
Those are properties of the system, not of the pipeline. And without them, a delivery model can only tell you that changes moved. Not what they were.
The Point
DevOps provides a delivery model. It’s mistaken for a development model.
The delivery model is accurate, complete, and useful. It just isn’t about the software — and it’s used as if it were.
That’s not a failure of execution. It’s what the practice is — and what it doesn’t say about itself.
Related: