Essay · Frameworks
Modernization Starts with Incentives
Technical debt isn't a technology problem. It's an incentives problem wearing a technology costume.
Every modernization effort I've seen fail had excellent technical plans. The architects knew what to build. The engineers knew how to build it. And yet, six months later, the legacy system was still humming along while the new system gathered dust. The problem wasn't technology. The problem was that no one was incentivized to actually make the switch.
← Back to essaysThe incentives you think you have
When leadership announces a modernization initiative, they assume everyone shares the goal. The legacy system is slow, expensive, hard to hire for. Of course everyone wants to replace it.
But incentives are local, not global. The people who have to do the work face a different calculation:
- The team that owns the legacy system gets headcount because it's critical. Modernization threatens their empire.
- The engineers who know the old system have job security. The new system makes their expertise worthless.
- The product managers get credit for features, not migrations. Moving to a new platform ships zero features.
- The executives get bonuses for quarterly targets. Modernization is a multi-year bet.
Everyone agrees modernization is good. No one is paid to make it happen.
The incentives you actually have
Before you write the first line of migration code, map the incentive landscape:
| Stakeholder | Incentive to support | Incentive to resist |
|---|---|---|
| Legacy team lead | Resume builder, new skills | Loss of headcount, expertise devalued |
| Individual engineers | Work with modern tech | Uncertain role, learning curve |
| Product managers | Eventually faster delivery | Short-term feature freeze |
| Finance | Lower long-term TCO | Higher short-term spend |
| Executives | Strategic positioning | Quarterly target risk |
If the "resist" column outweighs the "support" column for most stakeholders, your modernization will fail. Not because it's technically wrong, but because it's incentive-misaligned.
Designing for adoption
The successful modernizations I've seen didn't fight incentives. They redirected them.
Make the old path painful
If the legacy system is too comfortable, no one will move. Introduce friction: deprecation warnings, reduced support, slower response times for legacy issues. Don't make it impossible - make it slightly worse every quarter.
Make the new path rewarding
Early adopters should get something: better tooling, faster deployments, recognition, first pick of new projects. The new system needs to feel like an upgrade, not a chore.
Protect careers
No one will help you retire their system if it means retiring themselves. Explicitly plan what happens to the legacy team. Retrain them. Give them ownership of the new system. Make modernization a career opportunity, not a career threat.
Align metrics
If product managers are measured on features shipped, give them credit for migration milestones. If engineers are reviewed on impact, count migration work as impact. What gets measured gets done.
The burning platform fallacy
Some leaders think the answer is urgency. "We have to modernize or we'll die." They manufacture a burning platform.
This works briefly and backfires spectacularly. People respond to urgency with short-term heroics, not sustainable change. When the crisis passes (or stops feeling urgent), the old habits return. Worse, you've spent your credibility. The next time you declare something urgent, no one believes you.
Real change requires aligned incentives, not manufactured panic.
The long game
Modernization is measured in years. Incentive alignment has to last that long. This means:
- Building modernization into promotion criteria, not just project plans
- Tying executive compensation to multi-year migration milestones
- Creating public dashboards that make progress (or lack thereof) visible
- Celebrating wins along the way, not just at the finish line
The organizations that modernize successfully treat incentive design as seriously as system design. They know that the best architecture in the world means nothing if no one is motivated to build it.
Questions to ask before you start
- Who wins if this modernization succeeds? Are they the people doing the work?
- Who loses? What are we doing to address their concerns?
- How are the people making decisions being measured? Does modernization help or hurt those metrics?
- What happens to the legacy team when the legacy system is gone?
- What does success look like in 6 months? In 2 years? Are we rewarding the same things at both horizons?
If you can't answer these questions, you're not ready to modernize. You have a technical plan but not an adoption plan. And in the long run, adoption is what matters.
The uncomfortable truth
Most legacy systems exist because they were rational choices given the incentives at the time. And most failed modernizations happen because the new system, however technically superior, doesn't change those underlying incentives.
If you want to kill a legacy system, don't just build something better. Make sure someone is rewarded for switching to it.