Features and Foundations, Together
Don't pause to do foundations; grow them as you go.
A very common question from product managers when engineers pitch an architectural change is “does this need to happen now, or can it be deferred?”
It’s the wrong question. The right question is: why aren’t you already doing this? Because solid foundations should be an expectation of strong engineers.
You need to deliver, and you need to grow foundations - at the same time, continuously. There is (almost) no version of reality where the business says “sure, let’s stop shipping for a quarter and sort out the infrastructure”. And every plan that depends on that happening is a plan to fail.
If you are an engineer who thinks they “never get time to work on foundations or tech debt”, listen up. This one’s for you.
The Deferral Trap
Engineering says: the architecture won’t scale, we need to invest in it. Product says: we have launches to hit, can it wait? Engineering says: fine, but it’ll hurt. Everyone agrees to revisit it next quarter.
Next quarter, the launches are bigger, the pain is worse, and the ask has grown from “a few weeks of refactoring” to “a proper migration”. Product says: we definitely can’t stop now. Engineering says: we told you so. Nobody wins, and the relationship between the two sides is a little worse than it was.
Repeat for three years and you’ve got a platform team that resents its product team, a product team that thinks engineering never ships, and a codebase that’s genuinely in trouble.
The Stop-Everything Trap
The other failure is the opposite: engineering wins the argument and gets its quarter. Or its year. Or two.
The rebuild is sold on the promise that it’ll reduce maintenance and free up capacity for features. When it finally ships, the business discovers it has paid a fortune for the ability to keep doing what it was already doing. That’s not nothing - but it’s very close to nothing, and it’s infuriating to the people paying for it.
Long technical projects that deliver nothing visible are how engineering loses the trust it needs to do architecture at all. It’s why asking for “tech debt weeks” is a warning sign, not a plan.
Both, Always
So the answer is both. Not “both eventually”. Both, in the same sprint, in the same plan, in the same conversation.
In practice:
Sequence the uplift alongside the launches. You’ve got a run of features to ship. Each one touches the system you want to fix. So each one fixes a bit of it - the bit it touches - and ships the feature on the new foundation. Output continues. The architecture improves underneath it.
Make the architecture prepare for the next wave, not just survive this one. The pitch isn’t “we’ll be able to keep working”. It’s “the next twenty launches will each take a third of the time”. That’s a business outcome, and it’s one you can only deliver if the uplift is happening while the launches are.
Ship the crappy version first. The “proper” system often doesn’t need to exist yet - ship something that works this sprint, and let real usage drive the real system that grows behind it. Software is grown, not built.
Structure it so everyone wins. Product gets its launches. Engineering gets its foundations. The business gets a measurably faster delivery machine. If your plan means one side loses, then sorry Frank and Sally, but it’s a shit plan.
The Signal This Sends
For engineers thinking about seniority: doing both at once is one of the clearest signals that you’re ready for the next level. Anyone can argue for a rewrite. Many can grind out features on a bad foundation. The person who can do both - deliver this quarter’s output and leave the system better than they found it, visibly, measurably - has uplifted the whole team’s ability to deliver.
That’s not just a technical achievement, it’s technical leadership.
Show the decider a plan where the next three launches land on time, and the fourth comes in twice as fast because it’s on a stronger foundation.
That’s a plan that’s impossible to say no to.
Link copied!