Bimodal IT: The Wrong Answer to the Right Question
Bimodal offered a diagram instead of that discipline, and a diagram is a far easier thing to buy.
Executive Summary
By the middle of this decade, most large organisations wrestling with the same problem had reached for the same answer. The problem was genuine: how do you move at the speed digital markets now demand while keeping systems that cannot fail from failing? The answer, endorsed by the major research houses and adopted almost as reflex, was to run technology at two speeds. One mode for the systems of record — deliberate, governed, careful. Another for the systems of engagement — agile, exploratory, quick. The model was elegant, it carried analyst authority, and it mapped almost perfectly onto the organisation chart that already existed. That last fact is precisely why we should distrust it.
This essay argues that bimodal IT is the wrong answer to a right question. The question deserves respect; the answer does not survive contact with how digital value is actually created. Two-speed IT solves the tension by institutionalising it rather than resolving it. It draws its central boundary at exactly the point where value is made — the seam between the fast new surface and the slow old core — and then staffs that seam with no one. It recasts the core’s slowness as a settled fact of nature rather than a debt to be repaid. And it quietly excuses the hardest, most valuable work of transformation: making the core itself capable of change.
The better answer is less flattering and more demanding. One engineering culture, held to one standard of discipline, releasing each system at whatever cadence its risk genuinely warrants — a spectrum tuned system by system, not a line drawn once through the middle of the organisation and left there.
The Programme That Was Green and Going Nowhere
Picture a transformation review of the kind that fills calendars across every regulated sector. The digital team presents first. Their board glows. Velocity is up and to the right, cycle time is falling, the mobile account-opening journey they have been building looks genuinely good, and it was assembled in six weeks by a small team that deploys several times a week. Everyone in the room relaxes a little. This is what the transformation was supposed to look like.
Then someone from the outside — a non-executive, usually, or a new finance director without the tribal loyalties yet — asks the only question that matters. When can a customer actually open an account this way? And the room cools, because the honest answer is not six weeks. It is closer to five months. The new journey has to write to the core policy system, and the core releases quarterly, through a change board, behind a queue of other demands. The slick front end has been ready for eleven weeks, waiting for an interface that the other side of the house has not been resourced to build. The velocity chart was true. It was also irrelevant, because the constraint was never the fast team.
I have watched that exact silence settle in more than one boardroom, and the lesson is always the same: the two-speed model had optimised the part of the system that was never the bottleneck, and reported the result as progress. The organisation had two speeds, and the one that governed the customer’s experience was the slow one all along.
That is the quiet failure mode of bimodal IT, and it is worth understanding properly, because the idea did not spread by being stupid. It spread because it answered a real question, and answered it in a way that asked almost nothing of the people adopting it.
The Right Question
Give the model its due. The problem it names is real, and the people who reached for it were not fools.
An experimental customer-facing service and a core ledger genuinely do not want the same treatment. The first lives or dies by learning speed; you want it in front of real users quickly, changed often, and killed without ceremony if it fails. The second lives or dies by not being wrong; a defect there is not a lost experiment but a regulatory breach, a mispriced book, a payment that does not reconcile. To subject an exploratory API to the full change-advisory apparatus of a core banking platform is to strangle it. To run the core with the abandon of a two-week experiment is negligence. Anyone who has stood between those two worlds has felt the pull to formalise the difference, to say plainly: these are not the same kind of work, and pretending they are helps no one.
So the instinct is sound. Different contexts warrant different cadence and different appetite for risk. That much is not in dispute, and any answer that denies it — that insists every system can and should ship on Friday afternoon — deserves the contempt it will receive from anyone who has carried a pager for a payments platform.
The question, then, is right and important. How does an enterprise hold exploration and reliability in the same hand? Where bimodal IT goes wrong is not in noticing the tension. It goes wrong in what it does about it.
Why the Answer Is Wrong
The error is to take a difference that is real at the level of individual systems and freeze it into a permanent division of the organisation into two tribes. A calibration becomes a caste line. Once that line is drawn, four things follow, none of them good.
- The value lives at the seam, and the seam belongs to no one. Almost nothing of worth in a modern estate happens purely inside the fast lane or purely inside the slow one. The customer value is in the new journey reaching into the system of record — the mobile flow that must read a balance, write a policy, move actual money. Bimodal draws its boundary precisely there and then makes integration everyone’s edge and no one’s centre. The fast team treats the core as a fixed external dependency; the slow team treats the digital layer as someone else’s weather. The defects breed in the gap between them, and the gap has no owner.
- It confuses speed with a property of teams rather than of systems. Bimodal talks as though some teams are simply fast and others simply slow, as if pace were a personality trait. But release speed is not a virtue of people; it is a property of architecture and engineering practice — small batches, automated deployment, decoupled components, tests you can trust. Label a team “Mode 1” and you have explained nothing about why it is slow, and quietly excused yourself from fixing it.
- It lets the core off the hook — permanently. This is the deepest fault. The reason the core releases quarterly is rarely some immovable law of physics. It is manual regression testing, big-batch releases, brittle integrations, and an accumulated fear of touching it. Those are debts, and debts can be paid down. Bimodal relabels them as the settled nature of Mode 1. The very technical debt that transformation exists to reduce is granted a permanent home and a respectable name.
- It creates a two-caste workforce, and the castes are not equal. Everyone can see which mode is the exciting one. The strongest engineers migrate toward the fast lane; the core becomes the place careers go to plateau. Within a couple of years the system you most need to be maintainable is staffed by the people with the least room to grow it, and it decays faster, not slower. The model that promised to protect the core hollows it out from the inside.
Bimodal IT does not close the gap between the organisation’s ambition and its core; it draws an organisational chart around the gap and calls it a strategy.
Put those four together and the pattern is clear. The two-speed model does not resolve the tension between exploration and reliability. It picks the tension up, sets it into the structure of the organisation, and walks away — leaving the hardest work undone and now harder to reach, because it has been renamed as the natural order of things.
The Value at the Seam, in Numbers
Return to the composite from the boardroom, because it repays a closer look. The fast team’s lead time was six weeks. The end-to-end lead time — idea to a customer actually opening an account — was closer to twenty. The difference, fourteen weeks, was almost entirely the wait for the core to expose a single interface and pass its quarterly gate. If you had doubled the velocity of the fast team, the customer would have waited twenty weeks minus a few days. If you had halved the release interval of the core, you would have taken a month or more out of every such journey, permanently, for every product that touched it.
This is not a subtle point, yet the two-speed frame hides it in plain sight, because it trains attention on the mode that moves and away from the mode that constrains. The measures that get reported — deployments per week, story points, cycle time — all belong to the fast lane. The measure that governs the customer belongs to the seam, and the seam is not on anyone’s dashboard. You optimise what you look at, and bimodal points the organisation’s eyes at the wrong half of its own system.
The transferable observation is this: in almost every two-speed estate, the binding constraint on delivery is not the speed of the fast team but the release cadence of the slow core and the friction of the integration between them. An operating model that structurally protects that cadence from scrutiny is not managing the constraint. It is hiding it.
The Case for Two Speeds, Taken Seriously
The strongest objection to everything above deserves to be stated at full strength, not as a straw man. It goes like this. You are romanticising uniformity. In the real world, a thirty-year-old core carrying millions of accounts genuinely cannot be released weekly, and no amount of pipeline automation changes the fact that a defect there is catastrophic in a way a defect in a marketing microsite is not. Bimodal is simply honest about that asymmetry. It stops organisations from applying start-up practices to systems where start-up practices get people’s mortgages lost. Two speeds is not a failure of nerve; it is a mature acceptance that risk profiles differ. Insisting on “one IT” is the naive position, not the sophisticated one.
There is real force in this, and it must be conceded where it is right. Risk profiles do differ. Cadence should differ. A core carrying regulated financial records should not, and need not, ship on the rhythm of an experiment.
But notice what the objection actually defends: different cadence per system, matched to risk. That is not what bimodal builds. Bimodal builds two organisations, two cultures, two standards of engineering discipline, two career paths — and then assigns systems to one side or the other and leaves them there. The distinction that saves the argument is the distinction the model erases.
“”This system releases quarterly because we have not yet automated its pipeline” and “this system is Mode 1, so quarterly is its nature” are separated by the entire width of the argument.”
The first sentence describes a debt with a repayment plan. The second describes a caste with a life sentence. A serious answer keeps the differentiated cadence — quarterly for the core if that is what its risk honestly requires today — while refusing to accept that quarterly is permanent, refusing to let the core’s engineering culture diverge downward, and refusing to draw a line through the organisation that puts the integration work on neither side. You can have many speeds without having two tribes. The moment two speeds becomes two peoples, the model has stopped calibrating risk and started entrenching decay.
Why It Persists Anyway
If the flaws are this visible — and by now, in engineering circles, they are much discussed — why has the two-speed model held on so tenaciously? The answer is not that leaders are foolish. It is that bimodal is structurally convenient in ways that have nothing to do with whether it works.
- It fits the organisation chart you already have. Most large technology functions already contain a projects-and-change world and a run-and-operate world. Bimodal does not require you to rebuild anything; it simply dignifies the existing divide with strategic language. A model that asks for no reorganisation will always be easier to adopt than one that asks for a hard one.
- It gives executives a transformation narrative that spares the core. Confronting the core — decoupling it, automating its delivery, paying down its debt — is expensive, slow, and unglamorous, and it is where most of the money and most of the risk sit. Bimodal offers a way to be seen to transform by bolting a fast lane onto the side, while the hardest ninety per cent of the estate is left untouched and, worse, declared fine.
- It matches how the work is bought. The procurement and vendor arrangements of most large organisations already split cleanly along the same line: a large integrator for the core, a boutique digital agency for the shiny front end. Bimodal is the operating-model shape of the contracts that were already signed. The model did not create that division; it ratified it.
- It carries external authority. When a strategy has the endorsement of the analysts a board pays to listen to, adopting it is defensible in a way that a more demanding, home-grown answer is not. “We are following the recognised model” is a safe sentence in a boardroom. It is also, too often, how organisations outsource the one act of judgement that mattered.
| Bimodal as structure | Capability as spectrum |
|---|---|
| Two modes, fixed by team | Many cadences, tuned by system |
| Speed is who you are | Speed is how you are built |
| Core slowness is its nature | Core slowness is a debt to repay |
| Integration owned by no one | The seam is the first-class concern |
| One culture drifts below the other | One standard of discipline throughout |
Every one of these forces is real, and every one of them pushes toward adoption for reasons entirely disconnected from delivery. That is the signature of a bad idea that spreads well: it is not chosen because it is right but because it is easy — easy to adopt, easy to defend, easy to reconcile with everything you were already doing. The market for management ideas rewards convenience at least as richly as it rewards truth, and bimodal is among the most convenient ideas the field has produced.
Toward One IT, Many Cadences
What, then, is the answer to the right question? Not a slogan, and not a single reorganisation, but a direction — and one that runs against the grain of the two-speed instinct at every point.
Begin with the insight the whole two-speed frame denies: for most systems, reliability and speed are not opposites to be traded against each other but companions that rise together. The practices that let you release safely and often — small changes, automated tests you trust, fast feedback, the ability to recover quickly when something breaks — are the same practices that keep a system stable. Teams that deploy frequently, done properly, are not reckless; they are the ones who have made change routine enough to be safe. The organisations getting this right in these years are not choosing between fast and reliable. They are discovering that, past a certain level of engineering discipline, the two arrive together. Bimodal assumes a trade-off that the best practice of the moment is busy dissolving.
From there, the moves follow.
- Hold one standard of discipline, apply it at many cadences. Every system, core or edge, deserves automated testing, version control, a repeatable deployment, and observability. What varies by risk is how often you release and how many gates you pass through — quarterly and heavily reviewed for the regulated core, daily for the experiment — not whether you engineer well. One culture, many speeds.
- Make the seam a first-class citizen. The integration between the new surface and the core is where value is realised, so it should be owned deliberately: clear interfaces, a team accountable for the contract between the two worlds, and investment in decoupling the core so the fast side is not forever waiting on the quarterly gate. Treat the boundary as the product, not the leftover.
- Invest in the core’s ability to change, rather than declaring it unchangeable. Every quarter the core stays undeployable is a quarter the whole enterprise moves at the core’s speed. Automating its delivery and breaking its hardest couplings is unglamorous and it is precisely the work that compounds. The point is not to make the ledger reckless; it is to make its cadence a choice you revisit, not a wall you accept.
- Organise around enduring products and value streams, not around modes. Standing teams that own a slice of customer value end to end — surface and the core capability beneath it — internalise the seam that bimodal externalises. When the same team owns both sides of the interface, the integration defect has nowhere to hide.
The goal is not one speed. It is one standard of engineering, deliberately run at whatever range of speeds each system’s risk requires — with the fast and the slow held to the same discipline and stitched together by a seam that someone actually owns.
None of this is easy, and that is the point. It asks the organisation to do the very thing bimodal was quietly designed to avoid: to reach into the core and change how it is built. But that is where the value and the risk both live, and no operating model that leaves it alone can do more than decorate the edges of the problem.
Coda
The most revealing thing about bimodal IT is not its mechanics but its appeal. It spread because it let organisations feel they were transforming while asking nothing of the hardest part of the estate — because it fit the chart, the contracts, and the narrative they already had. That is worth remembering well beyond this one idea, because the next elegant, analyst-blessed, low-friction answer to a hard question is already forming, and it will recommend itself in exactly the same way.
The right question — how to be quick where quickness pays and careful where care is non-negotiable — does not have a structural answer you can adopt and file. It has only a discipline you have to keep: one standard, many cadences, the seam owned, the core kept genuinely changeable. Bimodal offered a diagram instead of that discipline, and a diagram is a far easier thing to buy. The organisations that will still be moving well when this fashion has passed are the ones that declined the diagram and did the work.