☝🏻️ Hard to read? Find the same content below 👇🏻
Supporting two ways of doing things is costly and frustrating. And for those working on the “old way,” it can be demoralizing. In large companies, it’s hard to avoid, and the costs are more palatable — in early-stage and high-growth companies, it’s something you’ll want to fight to minimize.
Once you’ve got a “new way,” any features built for the old way are instant tech debt that moves your “done” further out of reach and increases the work required to get the new way to feature parity.
It’s a good risk mitigation strategy to maintain the old way in parallel and progressively switch over. The problem is when the transition period is perpetual, and you keep building on the old way.
The two trains metaphor – the old way and the new way are trains running on parallel tracks. The “transition” moves the cargo from one to the other while they’re both in motion along the tracks. The goal, get everything switched over and leave the old train behind.
The obvious trap is moving the cargo too slowly, and that’s an easy one to address. Once you’ve validated that the new way is fit for purpose, work diligently to migrate everything over.
Let’s take the metaphor a little further. We have to keep both trains moving (let’s think of them as steam trains we’re shoveling fuel into) at about the same pace while transitioning all the cargo.
The worst thing to do is shovel fuel into the old train faster than the new train.
What does this look like in practice? A small team on the new way and keeping a much bigger team on the old way.
While fine in the early stages, once you’ve validated fit-for-purpose, you have to invest heavily in the new way, or your old train will leave the new train behind!