Failures in a new system get blamed on technical debt inherited from the previous leadership, so a steering committee that has invested heavily keeps its patience and stops asking about the new build.
An example
Eight months after a regional airline replaced its crew-scheduling system, the new platform had caused three days of mass cancellations. Each incident report, written by the transformation team, traced the root cause to legacy integration debt: the old payroll interface, an aging crew database, undocumented rules in the previous vendor's code. None named a defect in the new build. The vice president of flight operations asked which inherited component had failed in the December outage. The program director answered that the inherited architecture was too entangled to isolate a single cause, and that questioning the team undermined morale during the hardest phase. The steering committee, which had approved $42 million for the program, voted to extend the team's contract another year.
Why it works
Patience becomes the easy path for a committee that has already sunk capital: staying the course looks like cleaning up a mess that was always coming. Holding the current team accountable loses its diagnostic value, since failures are reclassified as evidence about the predecessor, and pressing for accountability looks unsophisticated or unfair to the team doing the dirty work. It works when the inherited system is opaque to non-technical deciders, the team writes its own post-mortems, the predecessor is gone, and the committee wants a face-saving story. An independent reviewer who can separate inherited faults from new-build defects breaks it.
The thinking behind it
George A. Akerlof George Akerlof's The Market for "Lemons": Quality Uncertainty and the Market Mechanism (1970) showed what happens when one side knows what the other cannot check. An inherited system is opaque to a non-technical steering committee, so the team that writes the post-mortems sets the terms of the explanation. An independent technical review closes the gap, which is why it ends the alibi.
Barry M. Staw Barry Staw's Knee-Deep in the Big Muddy: A Study of Escalating Commitment to a Chosen Course of Action (1976) found that people committed the most additional money to a course of action when they were personally responsible for its negative results, which he read as self-justification. A steering committee that approved $42 million wants a story in which its decision was sound. Blaming the predecessor's system supplies one.
Warning signs
Every incident report traces root cause to inherited systems and none to new code. The team writing the post-mortems is the team being judged by them. Explanations invoke technical debt globally and never name a specific inherited component. The previous team is gone. Questions about the new build are answered as attacks on morale.
How to defend yourself
Force the inheritance claim down to specifics.
- For each incident, ask which inherited component failed, what evidence shows it, and why the new build did not account for it.
- Commission an independent technical review that separates inherited defects from new-build ones and reports to the committee.
- Find the dated baseline: the handover documents, the old system's known-issues list, the requirements the new team signed up to.
- Talk to the previous team's people if any remain; documentation that survives intact undercuts the frame.
Keep the tone forward-looking. You want the system fixed, which needs an accurate diagnosis, and a committee member who frames it that way is hard to cast as hostile to the team.
How a leader shuts it down
Fix a dated baseline of the inherited system at every handover: known issues, documentation, interfaces. Have post-mortems written or reviewed by someone outside the team being judged. Require every technical-debt claim to name a component and show evidence. Sunk capital is a reason for more scrutiny, so resist the patience it invites.