Note: This is the first post in a multi-part series about a major replatforming effort that I led. Additional posts will be released every two weeks.
“You know you’re writing the first line of your professional obituary, right?”
Our chairman said it the day the board approved the replatforming of our core product. He wasn’t being cruel (he was, if anything, being kind, giving me one last exit). He was doing the math out loud that everyone in the room was doing silently. Rebuild the platform your entire company runs on, the platform your customers depend on every day, and if it goes sideways that sentence writes itself. The alternative was obvious and available: keep the old platform running, patch what hurt, ship features around the edges, and let the thing limp forward for a few more years. Nobody gets fired for keeping the lights on.
That instinct — keep the lights on, don’t touch the load-bearing wall — has a name, and it turns out to be one of the most studied biases in decision science. William Samuelson and Richard Zeckhauser called it status quo bias in their 1988 paper in the Journal of Risk and Uncertainty, and once you see it you cannot stop seeing it in every roadmap review you’ve ever sat through.
Samuelson and Zeckhauser ran a series of experiments where they handed people the same decision with one thing changed: whether an option was framed as the thing they already had. When an option was the incumbent, people chose it far more often than when the identical option was just one choice among several. The pull wasn’t analysis. It was the plain fact of already being there.
They didn’t stop at the lab. They looked at real decisions with real money (faculty members choosing health plans and retirement programs) and found the same thing at scale: people stuck with what they’d picked before, long after better options existed, in choices that mattered enormously for their futures. One of my favorite details in the paper is a small one, a colleague of theirs who ordered the same lunch, at the same place, for 26 years. Standing still isn’t a decision you make once. It’s a decision you quietly re-make every single day you don’t move.
That’s the part that should worry any CTO. Keeping the old platform alive felt like the neutral choice, the no-decision decision. But there is no neutral. Choosing not to replatform was a choice, with compounding costs: technical debt, a widening gap between what customers wanted and what the architecture could bear, good engineers spending their best hours fighting the past. The status quo just doesn’t send you an invoice. It bills you quietly, and you don’t notice until the platform can’t do the one thing the market has started demanding.
Here’s the part I’m less proud of. We didn’t go straight to the big bet. We tried the gradual version first: strangle the old system piece by piece, stand up new services alongside it, migrate quietly in the background, never make anyone nervous. On paper it’s the responsible path (lower risk, reversible, no obituary line required).
It failed. Not dramatically, just slowly. The systems had to talk to each other constantly, the seams multiplied, and every new piece we built had to stay compatible with the old world we were trying to escape. We were spending real money to make the legacy platform more entrenched while telling ourselves we were replacing it. That’s when the honest question showed up: was incrementalism the wise choice here, or was it status quo bias wearing a nicer outfit?
Because incrementalism can be either one. Sometimes gradual really is right, when the risk is lower and the reversibility is worth paying for. And sometimes “let’s do it in phases” is the socially acceptable way to never do it at all. Barry Staw’s research on escalation of commitment describes the close cousin of this problem, the way we keep pouring resources into a course of action precisely because we’ve already poured resources into it. Our incremental attempt had quietly become a thing we were protecting rather than a path to somewhere new.
Thanks for reading Digital Evolutionary! This post is public so feel free to share it.
So how do you separate the two in the moment, when both look identical from the inside? The test I landed on is uncomfortable but useful: ask whether the incremental plan has a credible endpoint where the old thing is actually gone. Not smaller. Gone. If you can draw a straight, believable line from “phase one” to “the legacy system is decommissioned,” gradual is probably right. If every phase instead makes the old system a little more necessary, a little more load-bearing, you aren’t migrating. You’re renovating a house you swore you were going to leave.
The second test is about who the plan comforts. If the phased approach exists mostly because it lets everyone (you very much included) avoid a hard conversation, that isn’t risk management. That’s the bias doing what it does best, making the expensive choice feel like the prudent one.
We killed the incremental attempt and committed to the full replatform, the one with the obituary line attached to it. It was the higher-variance decision on paper. But the real career risk was never the bet. The real risk was the slow version, the one where nothing ever visibly fails, the platform falls a little further behind every quarter, and one day you look up and the market has moved somewhere your architecture can’t follow. Nobody gets fired for keeping the lights on. They just get passed by.
The chairman was right that I was writing the first line of something. He was just wrong about which decision was the dangerous one. If you want the organizational version of this same gravity, why companies keep deferring the projects they most need, I wrote about that a while back in The Rise of Change Fatigue.
No posts

Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.