Is it speed versus quality, or speed and quality? That question sits at the heart of the debate between Gartner’s Bimodal IT framework and DevOps. The two are frequently cast as opposites, but the tension between them is largely unnecessary — and resolving it starts with understanding what each approach actually proposes.
Why DevOps Looks Like a Farce (at First)
Consider for a moment the core practices DevOps advocates for, and then imagine arguing against each of them in turn:
- Developers collaborating directly with users — Sounds risky. Surely customers should only interact with a formal interface?
- Developers and operations staff working together — Why not keep all communication through a ticketing system?
- Operations included in release planning — Won’t they just slow things down?
- Customer service briefed on new features before release — What value does that add?
- Test-first development practices — Seems like overkill for most teams.
Every one of those objections reflects how many organizations actually operated before the agile movement — and how some still operate today. The irony is that IT staff often have the clearest view of what keeps systems stable, and customer service representatives frequently surface the most actionable product feedback, simply because they interact with both the software and its users every day. Locking those people out of the development process is a real organizational cost, not a risk mitigation strategy.
Bimodal IT in a Nutshell
Gartner’s Bimodal IT model proposes that organizations run two distinct modes of IT delivery in parallel:
- Mode 1 — Predictable, stable, and deliberate. Suited to legacy systems and core business applications where reliability is paramount. Change is gradual and well-understood.
- Mode 2 — Exploratory and fast-moving. Suited to new product development, emerging technology adoption, and innovation initiatives where speed and experimentation matter more than certainty.
The underlying assumptions of Bimodal are worth naming explicitly:
- Agile and DevOps are best suited to new projects and nimble organizations.
- Applying DevOps to legacy systems introduces unacceptable risk.
- Organizations must choose between speed (DevOps) and quality (traditional approaches).
- Different applications require fundamentally different operating modes.
The Upsides of Bimodal IT
Bimodal IT is not without merit. Its strongest contribution is the explicit encouragement of pilot projects around emerging technology areas. Organizations have historically benefited from treating early-stage technology exploration — whether cloud adoption, NoSQL databases, mobile application development, or earlier waves like the move to the web — as a distinct track that operates under different rules and risk tolerances than core systems. For many enterprises, the instinct to ring-fence experimentation is pragmatic and organizationally sensible.
The Downsides of Bimodal IT
The problems with Bimodal IT become apparent when you try to apply it consistently across a real organization:
Who Decides Which Mode an Application Belongs To?
Categorizing applications as Mode 1 or Mode 2 forces difficult and often arbitrary value judgments. Which applications — and therefore which users — deserve faster delivery? More innovation? Higher quality? Better support? Bimodal does not provide a clean answer to those questions, and in practice, the answers tend to reflect organizational politics rather than user needs.
It Recreates the Silos DevOps Was Designed to Eliminate
Running two separate development processes, toolchains, and team cultures creates exactly the kind of organizational fragmentation that DevOps addresses. Mode 1 teams risk becoming a professional dead-end. Mode 2 teams risk becoming disconnected from the operational realities that keep production systems stable.
Most Applications Cannot Be Cleanly Categorized
Modern systems are rarely self-contained. Consider airline reservation and ticketing applications: the mobile-facing booking interface may follow a fast agile release cycle, but it is almost certainly tightly coupled to legacy transactional back-end systems. A change on either side typically requires coordination with the other. Labeling one component Mode 1 and the other Mode 2 does not eliminate that interdependency — it just obscures it.
The Speed-Quality Tradeoff Is a False Choice
Research from Puppet Labs and others (including the annual State of DevOps reports) has consistently found that high-performing technology organizations deliver both faster deployment frequency and higher reliability than low-performing organizations — not one at the expense of the other. The tradeoff Bimodal assumes is empirically weak. Additionally, practitioners including Gene Kim have cited data suggesting that a significant proportion of successful DevOps transformations — reportedly around 60% — involve legacy rather than greenfield applications, which challenges the assumption that DevOps is unsuitable for established systems.
How to Reconcile Bimodal IT with DevOps
The underlying intent of Bimodal IT — recognizing that different systems carry different risk profiles, and that organizational change requires structure — is reasonable. The implementation, however, tends to produce the wrong outcomes. The following approaches preserve that intent while avoiding the pitfalls.
Focus on People, Not Applications
Every organization has individuals who are more receptive to new methods, regardless of which system they support. Instead of assigning an application to Mode 1 or Mode 2 and locking its team into that mode, identify the people most likely to succeed with a DevOps approach and build early wins around them. Let demonstrated success drive broader adoption rather than top-down categorization.
Invest in Collaboration and Feedback Loops
Most organizations — regardless of application type — have room to improve communication between development, operations, and end users. Shortening feedback loops is beneficial across the board. It is not a Mode 2-only concern.
Break Down Silos Rather Than Formalizing Them
Bimodal can inadvertently legitimize the organizational silos that DevOps is designed to dismantle. People generally do not want to be confined to a narrow, unchanging role. Offering expanded responsibilities and cross-functional opportunities tends to be more motivating and more productive than enforcing strict operational boundaries.
Treat Shadow IT as a Signal, Not a Problem
Unsanctioned technology adoption — shadow IT — has a long history of producing genuine innovation, from early PC adoption to the emergence of cloud services. Rather than suppressing it, investigate why teams are working around official channels and address the underlying friction. The goal is to make the official path less painful, not to eliminate the pressure that drives people to find workarounds.
Reframe Speed as Speed to Value
The concern that DevOps moves too fast for legacy applications usually conflates release velocity with release risk. A more productive framing is speed to value: getting the most important changes to users sooner, in smaller increments, with fewer changes per release. Smaller releases are inherently lower risk than large batch deployments, regardless of the age of the underlying system.
Expand the DevOps Definition Beyond Dev and Ops
DevOps is a useful shorthand, but the label can create artificial boundaries. The principles apply equally to quality assurance, customer service, product management, and executive leadership. A broader definition of who participates in DevOps practices — and who benefits from them — will produce better outcomes than one confined to engineering teams.
Conclusion
Bimodal IT and DevOps are not inherently incompatible. The stability and risk-awareness that Bimodal advocates for are legitimate organizational concerns. The rapid delivery, continuous feedback, and cross-functional collaboration that DevOps advocates for are not threats to stability — they are, when properly implemented, mechanisms for achieving it.
The key shift is to stop treating application age as a proxy for the appropriate development approach, and to stop treating speed and quality as a zero-sum tradeoff. Innovation can and should happen across your entire portfolio — in legacy systems as much as in new ones. A DevOps practice that is inclusive of the whole organization, measured honestly, and built on genuine cross-functional collaboration will reduce risk, increase agility, and create competitive advantage from systems that might otherwise be treated as liabilities.