Two teams, one codebase, four lost weeks.
A delivery team and a research team worked in the same codebase without agreeing what could change during modernization.
This pattern comes from a real project. Identifying details have been changed, but the mechanics and four-week delay are preserved.
Two valid missions
Two teams needed to work in the same part of a system. One was a Fishing Vessel: deliver new functionality quickly on the technology where the product already lived. The other was a Research Vessel: test a new technology and, if it proved suitable, modernize that same area.
For the delivery team, success meant value in users' hands. For the research team, it meant hypotheses validated or invalidated and a clear path forward. Both teams were doing exactly what their work required.
What happened
Nobody had written down who owned the shared area, whether it stayed open to new features during modernization, who could change what, or when those boundaries would end.
Research began. The delivery team kept shipping on the old technology, in precisely the area that was being modernized. Weeks passed before anyone noticed that two teams were building similar things in the same place, heading toward different versions of the future.
Why the technical cost kept growing
Modernization starts with a snapshot of existing behavior. The aim is to carry that behavior to the new technology without breaking what users rely on. When the legacy code keeps changing, that snapshot expires and the target moves.
Every feature added to the old technology created more work for the research team:
- More behavior to reproduce on the new technology.
- Missing context to reconstruct from code, tickets and conversations.
- More parity checks to prove the new implementation still behaved as expected.
- Rework when old patterns could not be ported and had to be redesigned.
The cost of an unanswered decision
The two lines of work drifted further apart. Bringing them back together took the research team four extra weeks. They were not slow; the thing they were modernizing kept growing while they worked on it.
Replacing either team would not have solved it. The collision came from context that had never been aligned, not from poor execution.
Where the Navigation Debt came from
Five questions would have made the missing decisions visible before the teams started:
- Position: where will the teams work in the same part of the system?
- Direction: is this area moving to the new technology this season?
- Priority: which work wins when delivery and research collide?
- Limit: what changes are paused, and until when?
- Success: what does a good period look like for each team, side by side?
The options that were available
There was no universal right answer. The team could have frozen the area except for critical fixes, built new functionality on the new technology through an adapter, migrated incrementally, or kept both lines running in parallel with an explicit cutoff date and accepted cost.
What mattered was choosing deliberately. Discovering the collision by accident cost four weeks.
A 15-minute check before the next season
Ask which parts of the system each team will touch, where those areas overlap, who owns every overlap and what must stay frozen. Then write each team's definition of a good period next to the other.
An unanswered question may not be a disagreement yet. It is still a debt that will come due when the work meets.