The problem DevOps solves
Summary: before DevOps, development and operations were two separate departments, evaluated on contradictory objectives. It was not a problem of bad faith: the organizational structure mechanically produced the conflict. This lesson explains the wall of confusion, its root causes, and the price it makes you pay.
1. The wall of confusion
This is the point to understand before anything else. The conflict between development and operations is not a problem of character, generation or skill. It is a mechanical consequence of how the two teams are evaluated.
If you reward one team for the speed of change and the other for the absence of change, you will get a conflict — regardless of the people you hire. Replace everyone and the conflict will reappear.
The practical consequence: you do not solve this problem with a team-building seminar. You solve it by changing the objectives.
2. The classic scene
The vicious circle in step 6 is the heart of the problem. Because releases are scary, they are spaced out. Because they are spaced out, they contain more changes. Because they contain more changes, they fail more often. Which increases the fear.
DevOps breaks this circle from the counter-intuitive side: deploy more often in order to deploy more safely. A deployment containing three changes is infinitely easier to diagnose than one containing two hundred.
3. The six structural problems
Problem 4 has the greatest impact on software quality. A developer who is never woken up at night by their own code has no concrete reason to make it observable, robust or easy to restart. It is not a lack of professionalism: it is the absence of a feedback loop.
This is where the principle "you build it, you run it" comes from, formulated at Amazon, and we will come back to it in lesson 7.
Problem 5 is the one that leadership underestimates the most. If you map the real time between the idea and its availability to the user, you will find that waiting time — approvals, deployment windows, availability of a test environment — far exceeds actual working time. Optimizing developers' work when 80% of the delay is waiting achieves nothing.
4. The real cost of silos
Cost 5 is the most important in the long run, and the most invisible. An organization where shipping costs three weeks stops experimenting. It does not test ideas, does not measure its users' reactions, does not correct itself. It keeps building what it decided a year earlier, without knowing whether it was right.
The link with cost 4 is direct: a team that is afraid to deploy avoids touching existing code. Technical debt accumulates, which makes deployments even riskier. Again, a vicious circle.
5. Why this changed now
Point 5 is the most important, and it deserves to be well understood because it contradicts a very solid intuition.
For decades, it was considered obvious that you had to choose between going fast and being reliable. The data collected from thousands of organizations shows the opposite: the teams that deploy most often also have the lowest failure rates and the shortest recovery times.
The explanation is logical: small frequent changes are easier to test, understand and revert than big rare ones. Speed produces reliability, it does not oppose it. This finding is the empirical foundation of the entire DevOps movement.
6. What DevOps changes concretely
Point 5 produces a remarkable change in behavior. A developer who knows they will be on call for their own code spontaneously writes better logs, better error messages and cleaner restart mechanisms. No directive is needed: the feedback loop is enough.
7. What DevOps does not solve
Point 4 is the most common failure in enterprise transformations. Renaming the operations team to "DevOps team" while keeping the same organization, the same objectives and the same wall produces exactly the same results — plus a lasting loss of credibility with the teams.
Remember in 30 seconds
- The wall of confusion comes from contradictory objectives: development is evaluated on change, operations on its absence.
- It is not a people problem. Replace everyone, the conflict will reappear. Change the objectives, it will disappear.
- The vicious circle: deploying is scary → releases are spaced out → batches grow → they fail more → fear increases.
- DevOps breaks this circle from the opposite side: deploy more often in order to deploy more safely.
- Six structural problems: opposing objectives, divergent environments, costly handoffs, no end-to-end responsibility, dominant waiting times, no learning.
- Waiting time far exceeds working time in most organizations.
- The speed / reliability trade-off is a myth: the fastest teams are also the most reliable. This is the founding empirical result of DevOps.
- "You build it, you run it" — the feedback loop changes behavior better than any directive.
- DevOps does not fix a bad product strategy, a skills gap or an unsuitable architecture.
- Renaming operations to "DevOps team" changes nothing — it is the most common transformation failure.