"Let's just do something quickly to get this moving." I have heard that many times over fifty years. I have said it myself. And sometimes it is exactly the right call — a pragmatic response to real delivery pressure that produces genuine momentum at a moment when momentum matters.
But not always. And the cases where it is not the right call tend to have a remarkably consistent pattern — one that only becomes fully visible years later, when the "quick" solution has become structural and the original intent to replace it has long since been forgotten.
The Appeal — and the Reality
In large programmes, quick wins are genuinely attractive. They demonstrate progress, build confidence in the team and with stakeholders, create momentum at moments when the programme needs it, and in environments under significant delivery pressure, they can feel not just useful but essential.
None of this is wrong. The problem is not the quick win itself. It is the assumptions that accompany it — that it is truly temporary, that someone will replace it with the proper solution when time allows, that its scope will not expand. These assumptions are almost never tested at the time of the decision, and they are almost always wrong.
In one programme, we needed to integrate two systems quickly to meet a hard business deadline. The architecturally correct solution would have taken months we did not have. So we implemented a lightweight interface — minimal development, quick turnaround, delivered on time. It worked. The deadline was met. Everyone moved on to the next priority.
What happened next followed a pattern I have seen many times since. Additional requirements were added to the interface. It became more complex. Dependencies increased. Other processes began to rely on it. Two years later, it was still there — not because no one had tried to replace it, but because it had become so embedded in the surrounding landscape that replacement had become a programme in its own right.
The Lifecycle of a Quick Win
The progression is consistent enough that it can be described as a pattern. Each stage is individually predictable; the cumulative result is consistently underestimated.
The "temporary" solution that becomes structural is one of the most consistent sources of technical debt in large organisations. It is not created by negligence. It is created by rational, pragmatic decision-making — each step of which seemed entirely reasonable at the time.
The Trade-Off That Should Be Named
Quick wins are not inherently bad decisions. They involve a trade-off that is often genuinely worth making. The mistake is not making the trade-off. It is making it without recognising it — which means the future cost is not planned for, not funded, and not owned.
The cost is not removed by the quick win. It is deferred — and deferred costs in complex systems have a way of increasing during the deferral period, as the quick solution becomes more embedded and the replacement becomes more disruptive.
The Questions I Ask Before Making the Trade-Off
I still make the pragmatic call to implement quick solutions when the circumstances warrant it. The discipline I have developed is to make that decision consciously — with the trade-off named, the exit strategy considered, and the future cost acknowledged before the decision is made rather than after.
- “Is this truly temporary — or are we calling it temporary to make the decision easier?”
- “What is the realistic exit strategy, and who owns it?”
- “If we are still running this solution in two years, what will that cost us?”
- “Will this make the future easier, or harder?”
The last question is the one that matters most. A quick win that makes the future easier — that buys time, builds capability, or removes a constraint — is a genuinely good decision. One that simply defers difficulty while adding complexity is a debt, not a win.
Quick wins are powerful tools. In the right circumstances, they are exactly the right decision — and the programme leaders who refuse to make pragmatic calls in the name of architectural purity create their own category of problems.
But if you are not careful, quick wins do not just solve problems. They become them. The discipline is not to avoid them, but to make them with open eyes: naming the trade-off, planning the exit, and ensuring the future cost is owned by someone rather than quietly deferred into a landscape that becomes progressively harder to change.