Skip to content
Leadership Advanced 4 min

Fitting Engineering Investment Into a Product Roadmap

Treating engineering health as leftover capacity defers it forever, until the deferral compounds into a cleanup you can't schedule. Make it a planned, argued line item.

By Victor Robin •

The problem

Treat engineering health as leftover capacity — the work that happens if a sprint comes in light — and it never happens, because sprints don’t come in light. Each individual deferral is defensible: a week of platform work versus a feature a customer is waiting on isn’t a hard call in the moment. The feature wins, because it has a name, a date, and someone asking, while the platform risk just hums quietly. Defer enough times and you stop choosing when to pay the cost.

We had a queue worker we called the “courier,” held together with retries and hope. Twice that year an engineer asked for a week to rebuild it; twice I said “not this quarter, the launch comes first.” Then it failed three times in a bad fortnight — a delayed batch, a manual replay, and finally dropped messages we couldn’t reconstruct. The cleanup was no longer a week; it was most of a month with two engineers off the roadmap. I hadn’t avoided the cost, only my ability to choose when to pay it.

The model

Technical quality is a continuous investment, not a project you finish once. You’re always either paying it down or letting it accrue, and “do nothing” is a position with a price. Once you hold it that way, the question stops being platform work or features and becomes what’s the right-sized, planned line for investment this quarter, and how do I argue for it. And the argument has to be in the language the roadmap already speaks — speed, reliability, cost — not virtue or craftsmanship. “This cuts incident recovery time roughly in half” survives a prioritisation meeting; “the team will be happier” does not.

What to do

  • Reserve a standing share of each cycle — around 15–20% — for engineering investment, and defend it like any other commitment instead of spending it first when a deadline slips.
  • Make every investment item carry a product outcome: faster delivery here, fewer pages there, lower cost over time. If you can’t phrase it that way, it isn’t ready to argue for.
  • Put the work on the same roadmap as features, sequenced and visible, not in a shadow backlog only engineers ever see.
  • Split large items to deliver incrementally, route by route, rather than as an all-at-once rewrite. The courier got migrated piece by piece behind its existing interface.
  • Name the loan out loud. When you choose to defer, say so and write down what you’re borrowing against, so the deferral is a decision instead of a default.

The results

Over the following two or three quarters, the courier-class incidents that had eaten whole weeks became rare, and the ones that remained were small enough to handle inside a normal day; recovery time on the failures we did have dropped by roughly half, mostly because the systems were no longer mysteries. Velocity is the part I’d describe carefully — we didn’t get dramatically faster, and I’d distrust a clean before-and-after number here. What changed is that velocity got steadier: fewer quarters torched by an unplanned emergency. Predictability mattered more to stakeholders than raw speed ever did.

The caveat: I over-corrected for about a quarter, letting the investment line creep toward a third of capacity and funding refactors that were aesthetic, not load-bearing. A reserved budget is a tool, not a virtue, and it can be misspent like any other. The discipline isn’t protecting the line; it’s making each item earn its place on the same terms as a feature. Next time I’d put numbers on the risk earlier — I had the incident data the whole time.

Further reading