There is a particular kind of exhaustion that comes from changing systems that still appear, from a distance, to be working just fine.
Not healthy systems. Not well-understood systems. Not systems anyone would design this way today. Just systems that continue, stubbornly and profitably, to do their job just that well enough — at least until you touch them — that the deeper cost of keeping them alive remains acceptable and the need to change them easy to ignore.
The important distinction, and it is one that gets lost in most conversations about legacy, is this: the problem is not that the system has stopped running. It is that the system has become nearly impossible to change safely. And in a market that does not wait, the ability to change is not a luxury feature. It is the ballgame.
Inside engineering, that cost is paid in very concrete currencies: delays, continuous rework, context switching, failed “quick wins,” and the quiet demoralization of discovering, for the fifth time that same week, that a small change is not small at all.
Outside engineering, the business still moves, customers still knock at the door, and no public catastrophe has happened yet — so the call for modernization can sound faintly theoretical. Until those same 2–3 sprints turn into 2 months, and the question becomes: “why is this taking so long?”
The truth is that modernization is rarely just a technical problem. It is an organizational one, and it needs more than engineers.
The cost asymmetry of legacy
What makes legacy difficult is not simply age. Age alone is often innocent. I have seen — and also built, let’s be honest — old systems that were perfectly understandable after ten years. Not elegant, but legible. One can work with that.
The more dangerous situation is different. It is what engineers mean when they speak of technical debt: not simply old code, but the accumulated interest on decisions made under pressure that were never cleaned up afterward. Unlike financial debt, it does not charge in currency. It charges in time, in friction, in the cognitive load of reasoning through a system that was never designed to be reasoned through whole. It compounds quietly, invisibly, until the day a routine change suddenly takes three weeks and nobody can quite explain why.
The cost appears first as friction: every change takes longer than it should, every estimate carries hidden uncertainty, every small improvement risks waking a sleeping dependency. These are not spectacular failures. They are quieter than outages, and they do not produce the kind of chart that makes executives sit upright in a meeting. But they accumulate: in developer days, in rework, in postponed decisions, and in the slow erosion of confidence that the system will behave proportionally to the change requested. And eventually the first high-performers start to leave, the team starts to feel like a maintenance crew, each refinement session an agonistic sport of trying to find the one change that will not trigger a cascade of unintended consequences, instead of a creative process of improving the product and innovating and very quickly engineering work becomes a cost center instead of a competitive advantage.
That is why I came to think of legacy and “technical debt” less as an old stack and more as a cost asymmetry: it allows one part of the organization to experience continuity while another part absorbs the hidden price of maintaining it. And because the price is hidden, it is easy to underestimate.
When scale arrives
There is a second problem, and it compounds the first.
When a legacy system belongs to a single team, its friction is felt by one team — annoying, but contained. The team learns the system’s personality. They know which corners bite.
Then the organization grows. More products, more markets, more cross-functional teams organized deliberately for autonomy. You split into squads, assign clear ownership, promise independent delivery cycles, hire for initiative. “You build you own it” you say, “be proactive” you say, “communicate across teams” you say.
And then you discover that the architecture underneath does not support the organization on top of it.
Three teams working on the same legacy system do not move three times faster. They move through the same bottleneck three times as often if not more. Every shared release becomes a coordination event. Every legacy dependency becomes a risk shared across team boundaries, at different paces, with different priorities. The system couples what the org chart tries to decouple.
You hired talented people, organized them for parallel delivery, and then parked them all on the same runway. At best, they take turns. At worst, they collide. This is not a failure of the teams, it is the symptom of a structural mismatch between organizational model and technical foundation, and it does not get better by asking people to communicate more.
The undocumented company
When you try to redesign infrastructure or decompose a system, you are not only moving software. In many companies, what we call “the system” is not just code — it is code plus process, plus exceptions, plus manual habits, plus historical decisions, plus “I have an extra script for this” or “an extra excel import for that”.
Some of the most important business logic is nowhere a newcomer would think to look. It lives in the institutional memory of the one person who says, “ah, yes, this breaks if the customer was created through the old flow.”
This is not a criticism of individuals. It is what most organizations do under time pressure: we routinize uncertainty, stabilize around habits. But modernization eventually exposes the bill: everything the organization forgot to write down, everything it postponed clarifying, everything strategically tolerated because the old setup still functioned well enough.
This is why so many modernization efforts feel psychologically heavier than expected. They are not just technical transformations. They are encounters with ambiguity. And this kind of ambiguity does not belong to engineering alone.
Pressure is not a strategy
One of the recurring mistakes in transformation efforts is the belief that more pressure will compensate for structural uncertainty.
When teams are forced to move too quickly through poorly understood terrain, they do not become more effective — they become usually more tactical. Workarounds are preferred over cleanup. Fragile solutions proliferate because they are locally cheaper. The near-term plan feels protected, but the overall capacity of the system to absorb change gets worse.
This is one of the crueller paradoxes of modernization:
under enough pressure, organizations choose the path that feels fastest and thereby extend the duration of the problem.
Speed is not neutral. In a well-understood system, it can be a multiplier. In a poorly understood one, it becomes a mechanism for distributing confusion faster.
Pressure can help a team execute a clear plan. It cannot replace the work of arriving at one.
A quieter appeal
The real request, underneath all the frustration and the failing estimates and the missed deadlines, is simpler:
Help us keep the business capable of change.
That means accepting that engineering cannot be the only department expected to carry the cognitive burden of untangling years of accumulated complexity. It means making room for product, operations, and business stakeholders to help reconstruct how the system actually works. And it means admitting trade-offs honestly: modernization may require slower feature throughput for a while, or pausing parallel initiatives to protect critical paths, or letting teams finish cleanup that is not externally marketable but strategically essential. None of this is free. That is precisely the point. Modernization becomes dangerous when everyone agrees with it in principle but no one is willing to absorb the local cost it imposes on their own roadmap.
The organization has to decide that the ability to change is itself a business capability worth protecting.
Because in the end, it is about whether the company can still shape its product intentionally, or whether the accumulated weight of its own history has started making those decisions on its behalf.
That is a strategic question, not a technical one. And it needs more than engineers.