Everyone in the room agrees the system should be retired. The technical case took twenty minutes to make and nobody pushed back on it. Eighteen months later it's still running, still being patched, still showing up on someone's roadmap as 'in progress.' The gap between agreement and action is where the real reason lives, and it's rarely technical.
The system is also a job description
A system that's mapped cleanly onto a team's boundary — Conway's Law predicts this mapping happens by default, since design tends to follow communication structure — isn't just a piece of software. It's frequently the reason that team's headcount exists in its current form. Deprecating the system doesn't just remove a dependency; it removes the artifact that justified three or four engineers' continued presence in that shape, on that team, doing that work. The owning team's resistance to a technically sound deprecation plan is, more often than it looks, a rational response to a threat the deprecation proposal never explicitly names. The go-to-market half of engineering management is handled in more depth by the XenGrowth practice.
Stakeholder | Stated concern | Underlying incentive |
|---|---|---|
Owning team's engineers | "There are edge cases the migration plan doesn't cover" | Uncertainty about what their role looks like once the system is gone |
Owning team's manager | "We need more time to do this safely" | The system's existence currently justifies the team's headcount and scope |
Downstream consumers | "We're not ready to migrate yet" | Migration is real, uncompensated work competing with their own roadmap |
Leadership sponsoring the deprecation | "This should have been done a year ago" | The savings are attractive and abstract; the disruption is concrete and someone else's problem |
Why deprecation is genuinely riskier than it looks, separate from politics
Even setting the incentive problem aside, there's a real technical reason deprecation drags: Richard Cook's account of complex systems states that catastrophe requires multiple failures acting together, because well-defended systems resist any single point of failure. An old system, by definition, has had years to accumulate dependents nobody fully mapped — a report that reads from it quarterly, a script someone wrote once and forgot, an integration a different team built without telling anyone. Removing the system doesn't test one dependency at a time; it tests all of them simultaneously, and the actual risk isn't any single dependency breaking cleanly, it's an unmapped one combining badly with something else nobody remembered depended on either of them.
This is the deprecation version of Cook's point about post-accident attribution: when a retired system's removal causes an incident, the postmortem finds a single proximate cause, when the real story is a decade of undocumented entanglement that no single review was ever going to catch.
Why 'just mandate it' usually backfires
The obvious-seeming fix — leadership sets a hard deadline and holds the owning team accountable — addresses neither the incentive problem nor the technical entanglement problem, and often makes both worse. A team facing a mandated deprecation that also threatens their headcount has every reason to work slowly, surface every edge case at the last possible moment, and generally behave in ways that look like resistance because, functionally, they are: the mandate created urgency without removing the reason to resist it. And rushing the technical work under deadline pressure is precisely the condition under which Cook's multi-failure risk is most likely to materialize, because a rushed migration has less time to discover the undocumented dependents before removing the thing they depend on.
Before proposing a deprecation, identify what the owning team's engineers would move to next, and make that concrete before you make the deprecation case, not after — this removes the headcount threat that makes resistance rational
Treat 'what depends on this that we haven't mapped' as a real, separate risk from the migration plan itself, and budget time specifically for discovering unknown dependents rather than assuming the documented ones are the complete list
If a deadline is necessary, attach it to a genuine resourcing commitment for whoever executes the deprecation, not just a date — an unstaffed mandate produces the slow-motion resistance described above, staffed or not the incentive problem persists but at least the technical risk is being actively managed
Expect the last 10% of dependents to take disproportionately longer to find than the first 90%, because the easy ones are the documented ones and the hard ones are exactly the undocumented, entangled kind Cook's framework predicts
What this looks like from inside the owning team
If you're the engineer being asked to deprecate a system you also depend on for your team's continued existence, the honest position is worth naming directly rather than performing enthusiasm you don't feel or performing resistance you'd rather not be seen doing. Raising the incentive problem explicitly — 'we can execute this well, and we need clarity on what the team does next before we can commit to a timeline' — is a more useful contribution than either slow-walking the technical plan or agreeing to a schedule everyone privately expects to slip. It surfaces the real blocker in terms a decision-maker can actually act on, instead of leaving it to be inferred from a pattern of missed dates. The XenGrowth resource library approaches this from the the operations side of this side.
A worked example: the reporting system nobody wants to own, and nobody will let go
Take a legacy internal reporting system, built eight years ago, that every current engineer agrees is a liability: it's slow, poorly documented, and blocks a broader data-platform migration everyone wants. The team that owns it consists of three engineers whose entire remit, for the last two years, has been maintaining exactly this system. A clean technical proposal to retire it and move its few remaining legitimate use cases onto the new platform gets unanimous technical agreement in the room. Eight months later, the system is still running, now with a fourth 'final' migration deadline quietly passed.
The actual blocker becomes visible only when someone asks the three owning engineers, directly and without judgment, what they'd be doing the week after the system is gone. Nobody has an answer, because nobody has had that conversation with them. From their seat, executing the deprecation perfectly is indistinguishable from executing their own team's dissolution, and no technical elegance in the migration plan changes that calculus. The moment their manager commits, in writing, to specific new ownership for each of the three engineers — one moving to the data platform team building the replacement, two absorbed into a reliability team that has open headcount — the remaining migration work, which hadn't meaningfully changed in months, gets finished in six weeks.
Phase | Technical plan status | What actually changed |
|---|---|---|
Initial proposal | Complete, technically sound, broadly agreed | Nothing — no next role identified for the owning team |
Months 1-8 | Unchanged, repeatedly re-deadlined | Owning team quietly deprioritizes migration work relative to other tasks |
After next-role commitment | Same plan, no technical revision | Owning team actively drives the remaining work to completion |
Six weeks later | System retired | The blocker was never the plan — it was the absence of a next role |
Why this is easy for leadership to miss entirely
From a level or two above the owning team, this pattern is almost invisible, because every individual status update sounds like a reasonable technical explanation: an edge case, a dependency that needed more investigation, a testing window that slipped. None of those explanations are lies, and each one is individually plausible. What's missing from the aggregate view is the pattern across eight months of individually plausible delays, and the fact that nobody in a position to fix the actual blocker has asked the one question that would surface it. Leadership sponsoring a deprecation from several levels up is structurally the worst-positioned group to notice an incentive problem, because they experience the resistance only as a series of technical status updates, each one true, none of them mentioning the thing that's actually being protected. There is a longer treatment of AI agents and marketing automation in XenGrowth on AI agents and marketing automation.
The honest limit of this argument
Not every deprecation delay is about incentive misalignment, and it would be a mistake to read organizational politics into every slow migration. Some systems genuinely have more undocumented entanglement than anyone estimated, and some delays are honest technical caution rather than disguised resistance. The useful discipline is distinguishing the two before assuming either: if the owning team's roadmap after the deprecation is vague or unaddressed, incentive misalignment is very likely part of the story. If a clear next role exists and the delay persists anyway, the technical entanglement is probably real and worth taking at face value rather than reading as stalling.
The direct question worth asking, if you're sponsoring a deprecation and progress has stalled without an obvious technical reason, is small and specific: has anyone explicitly told the owning team what they're doing after this is done? If the honest answer is no, that's very likely the actual blocker, and it's a cheaper problem to fix than another quarter of status updates about edge cases that never quite resolve.
Where technical caution and incentive protection genuinely look identical
There's an honest reason this is hard to diagnose even for the owning team's own engineers: the two failure modes produce the same visible behavior. An engineer who is genuinely worried about an unmapped dependency and an engineer who is unconsciously protecting their own role both surface caveats, both ask for more time, both resist a hard deadline. The difference isn't visible from watching the behavior. It's visible only by asking directly, and separately, about the technical risk and about what comes next professionally — two questions that get very different answers when the resistance is genuinely technical, and the same evasive non-answer when it isn't. There is a longer treatment of AI search, GEO and discovery in XenGrowth on AI search, GEO and discovery.
None of this makes deprecation easy. It makes the actual difficulty legible, which is different and more useful than treating every stalled retirement as either a technical failure to be solved with a better plan, or a people problem to be solved with a firmer deadline, when it's usually a specific combination of both that requires being named correctly before it can be addressed at all.
The system was never really the obstacle. It just happened to be the thing everyone could point at while the actual question — what happens to the people who currently justify their team by keeping it alive — went unasked.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
For the marketing and revenue operations view of engineering management, see XenGrowth.
Five questions on the organizational mechanism behind why a technically obsolete system keeps surviving.
