This article is based on analysis originally published on GigaOM in May 2018, authored by Jon Collins.
The Wall of Confusion, Revisited
DevOps practitioners are well acquainted with the “Wall of Confusion”—the organizational barrier that separates development teams, who want to ship fast, from operations teams, whose primary mandate is stability. DevOps emerged as a practical answer to that tension: align incentives, break down silos, and deliver software continuously and reliably.
In theory, the value proposition is compelling. In practice, scaling DevOps beyond a single initiative or enthusiastic team is where the real difficulty begins. Two illustrative failure patterns appear repeatedly:
- A large institution sees early DevOps wins, only for momentum to collapse when the initiative tries to expand to a wider developer community that responds with indifference.
- A consumer-facing organization winds down its DevOps-focused group because its ways of working are so misaligned with the rest of the business that it cannot deliver effectively.
Neither failure is a technology problem. Both are organizational ones. Understanding why scaling stalls requires looking at a set of interdependent factors—each necessary, none sufficient on its own.
The Five Cs of DevOps at Scale
The following five elements each contribute to whether DevOps can grow beyond an isolated group. Remove any one of them and you dilute the potential value of the entire practice. By a useful coincidence, all five start with the letter C.
1. Commodity
DevOps functions most smoothly when the underlying infrastructure is relatively uniform and opinionated. Cloud-native development models—where teams build on containers, managed runtimes, or platform-as-a-service abstractions—deliberately remove the need for developers to concern themselves with the operating system, VM configuration, or network topology beneath their applications.
This is not about naivety; it is about reducing complexity at scale. As Michael Coté of Pivotal has noted, cloud-native developers typically have neither the need nor the desire to tinker with the lower layers of the stack. Whether or not they are missing something is debatable. What is not debatable is that a commoditized, standardized platform dramatically lowers the cognitive and operational overhead that DevOps practices must absorb. Heterogeneous, snowflake infrastructure, by contrast, introduces fragility and inconsistency that scales badly.
2. Consistency
Frequent, reliable software delivery demands discipline—the kind of discipline that must be systemic, not personal. Continuous integration and continuous delivery pipelines only work when every member of a team follows agreed practices: committing code regularly, keeping the build green, writing tests, and not bypassing gates under pressure.
The human reality is that sustained, high-level discipline is the exception rather than the norm. Champions of DevOps who are naturally disciplined may find it genuinely difficult to understand why their colleagues struggle to maintain the same cadence. Scaling requires acknowledging this gap and designing processes, tooling, and feedback loops that make the right behavior easier than the wrong one—not simply hoping everyone will rise to the standard.
3. Collaboration
DevOps is, at its core, a collaborative practice. It assumes—and requires—that developers, operations engineers, security teams, and business stakeholders communicate regularly, share context, and make decisions together. In organizations where cross-functional interaction is already a cultural norm, this feels natural. In organizations where it is not, deploying collaboration tooling (chat platforms, shared dashboards, incident management systems) does not create collaboration; it merely makes the absence of collaboration more visible.
True collaboration cannot be mandated by a tool purchase. It requires psychological safety, shared goals, and leadership that models the behavior. Its absence introduces friction, slows delivery cycles, and increases project risk—exactly the outcomes DevOps is meant to prevent.
4. Continuity
DevOps depends on repeated, time-boxed delivery cycles—whether called sprints, iterations, or something else—typically lasting no longer than a few weeks. As one cycle ends, the next begins. This rhythm is both the engine of continuous improvement and one of the hardest cultural shifts for established organizations to sustain.
In environments where scheduling a cross-functional meeting requires three weeks of diary negotiation, the cadence simply cannot hold. Continuity is not just about technical pipelines running on schedule; it is about the entire organization being able to respond, decide, and act at the pace the delivery cycle demands. Misalignment here—where the business operates on quarterly approval cycles while engineering teams work in two-week sprints—is a common and serious source of DevOps stall.
5. Charisma
DevOps is as much a community as it is a methodology. Its most successful practitioners are often evangelists: people whose enthusiasm is infectious, whose clarity cuts through organizational fog, and whose example others want to follow. This is not a trivial factor. In the early stages of a DevOps initiative, a single compelling advocate can carry enormous weight.
The problem is what Jon Collins has called the guru’s dilemma: when the champion, mentor, or consultant moves on, the organization is left to sustain the practice on its own. Without the charismatic leader, teams often revert to familiar habits. This makes it critical to distribute DevOps knowledge and ownership broadly—rather than concentrating it in a single person or group—before that person leaves.
Why These Factors Matter Together
Each of the five Cs addresses a different dimension of organizational readiness. Commodity tackles infrastructure complexity. Consistency addresses human behavior under pressure. Collaboration targets cultural norms. Continuity aligns organizational rhythm with delivery cadence. Charisma ensures leadership and evangelism can be sustained.
Crucially, these factors are interdependent. A team with charismatic leadership but no consistency in its practices will see progress stall once the leader is stretched thin. A platform with commodity infrastructure but a culture that resists collaboration will find that its pipelines automate friction rather than eliminating it.
The underlying risk in all cases is the same: time to value. Every piece of software has a window of relevance. Decisions made today serve a need that exists today; delays in delivery mean the result may arrive after the need has shifted or the opportunity has passed. Any organizational friction—whether it comes from inconsistent practices, siloed teams, or a delivery cadence out of sync with the business—erodes that window.
Practical Takeaways for DevOps Leaders
- Audit your infrastructure standardization. Before scaling DevOps, assess whether your platform is opinionated enough to support consistent practices across teams. Snowflake environments compound every other challenge.
- Design for human consistency, not just technical automation. Invest in guardrails, feedback loops, and tooling that make disciplined behavior the path of least resistance.
- Treat collaboration as a cultural program, not a tooling decision. Identify and address the organizational barriers to cross-functional communication before deploying new platforms.
- Align business and delivery rhythms explicitly. Map your sprint cadence against actual organizational decision-making cycles and surface the gaps to leadership.
- Build a community, not a cult of personality. Distribute DevOps knowledge deliberately so that the practice can survive the departure of any single champion.
DevOps at scale is achievable, but it requires treating the organization—not just the toolchain—as the system to be engineered.