Introduction #
The 'wall of confusion' is a fundamental concept for understanding the origins of the DevOps movement. Historically, the software development lifecycle followed a waterfall model where each phase was isolated. Although Agile methods sped up code writing, they often hit the boundary of operations. This 'wall' represents the cultural, organizational and technical barriers between those who build the software (Dev) and those who keep it running (Ops).
1. Conflicting goals and metrics (KPIs) #
The first pillar of this wall is structural: teams are rewarded for diametrically opposed outcomes.
The dogma of change (Dev) #
Agility pushes developers to ship as many features as possible as fast as possible. Their performance is often measured by throughput and meeting delivery deadlines (Lead Time).
The cult of stability (Ops) #
Conversely, Ops are responsible for availability (uptime). For them, every change is a potential risk of outage. They are measured on MTBF (Mean Time Between Failures) and SLA compliance.
Consequence #
This mismatch creates constant tension: Dev see Ops as a brake on innovation, while Ops see Dev as irresponsible sources of instability.
2. Silos and the 'throw it over the wall' syndrome #
Physical and hierarchical organization reinforces technical isolation.
One-way communication #
In a siloed structure, Dev finishes their task, 'throws' the code over the wall to Ops and considers the job done. Ops then receive a 'black box' they must deploy without understanding its internal logic.
Loss of technical empathy #
Without interaction, teams no longer understand each other's constraints. The developer ignores infrastructure limits (network, storage), and the administrator ignores the business value of the code.
3. The 'tyranny of the ticket' and bureaucracy #
Bureaucracy becomes a defense mechanism against uncertainty and risk.
Heavy CABs (Change Advisory Boards) #
To limit risk, companies impose manual approval boards. Every deployment requires time-consuming forms and approvals, which kills responsiveness and competitive advantage.
Dehumanization through ticketing #
Communication is reduced to JIRA or ServiceNow tickets. People no longer talk; they exchange cold requests, which slows incident resolution and creates frustration.
4. Environment inconsistencies and drift #
Lack of technical standardization is a major component of the wall.
Configuration drift #
Development, test and production environments inevitably diverge over time. An OS patch on one, a library version on another... and the code becomes unpredictable.
The local illusion #
The developer tests in a simplified local environment. When the application reaches production with real security, firewall and load constraints, it collapses.
5. Blame culture (blame game) vs post-mortems #
When an incident occurs, energy is often spent looking for a culprit rather than a systemic solution.
Shifting responsibility #
'It's a code bug,' says Ops. 'It's an infrastructure problem,' replies Dev. This sparring delays recovery and durably damages the company's working climate.
No constructive lessons learned #
Without a DevOps culture, incident analyses aim to point at a human error rather than fix a process or automation flaw.
6. Technology fragmentation and observability #
Each team has its own technical 'truth' through its own tools.
Toolchain sprawl #
Dev use local profiling and logging tools, Ops use industrial monitoring solutions. Neither has access to the other's data, preventing any quick correlation.
Siloed observability #
Dev see the code but not its impact on the infrastructure. Ops see the CPU saturating but don't know which line of code or SQL query is responsible.
Conclusion: how to tear down the wall? #
Tearing down the wall of confusion is not just a matter of tools (such as Docker or Kubernetes); it is a deep cultural transformation.
The CALMS framework #
The answer lies in CALMS: Culture (trust), Automation (CI/CD, IaC), Lean (small batches), Measurement (shared data) and Sharing (knowledge).Read our detailed article on the CALMS framework to dig deeper into these concepts.
Towards shared responsibility #
The ultimate goal is 'You build it, you run it'. By involving Dev in operations and Ops in architecture design, the wall fades away in favor of business value.
Not to be confused with: the mood board #
Another 'wall' of agile teams.
Mood board #
The mood board (or niko-niko calendar) has nothing to do with the wall of confusion: it is an agile team ritual where everyone records their mood every day (with an icon or a color). It makes fatigue or tension visible before they become problems.
- Wall of confusion: a barrier between Dev and Ops, to be torn down by DevOps culture.
- Mood board: an indicator of team morale, to be reviewed in retrospectives.
Good practice: The two complement each other: a mood board that deteriorates after every release often signals a wall of confusion that is still very much there.
