The math that ruined a Tuesday standup
You closed the round, and the first thing you did was hire. Six engineers in ten weeks. Burn went up roughly $1.2M annualized. Then you sat in the Q3 planning meeting and watched the roadmap slip to Q4 anyway. More people, less output. If you've felt that, you're not imagining it, and you don't have a talent problem.
What you have is an allocation problem. At Series B/C, between $10M and $50M ARR, the codebase you shipped to get here was built for a smaller, simpler company that no longer exists. Every shortcut that helped you hit the last milestone is now a line item your engineers pay down every sprint, whether or not anyone names it. I call it the Innovation Tax, because that's what it functions as: a recurring levy on your payroll that produces nothing new.
Here's the part founders miss. When your VP of Engineering says "we need to refactor before we can ship the integration," that is not an engineering opinion. It's a capacity disclosure. A chunk of the team you're funding isn't available for the roadmap, and the only question worth asking is exactly how big that chunk is.
You measure it from tickets, not from code
You don't need to read a single line of the codebase to calculate this. You need your last two sprints of Jira data. Tag every engineer-hour into one of two buckets: building something a customer asked for, or keeping the existing thing alive. The second bucket is bug fixes, emergency patches, unplanned incident response, and rewrites of code that already "works."
Technical Debt Load % = (FTEs on bug fixes + FTEs on refactoring + FTEs on unplanned outages) / total engineering FTEs
Run it honestly. Say you have 20 engineers and, across the last sprint, 8 of them spent the majority of their time patching the billing service, chasing a flaky deploy, and rewriting the integration someone hacked together in 2023. That's a 40% load. Translated to the only language your board cares about: for every dollar of engineering salary, sixty cents reaches the roadmap. The other forty is interest on speed you borrowed when the company was a third its current size.
Where 40% stops being normal and starts being terminal
Some debt is healthy. A 0% load means you over-engineered your way to here and probably moved too slowly to deserve a Series B. The danger isn't having debt; it's not knowing which side of the line you're on. And the line is closer than founders assume.
Stripe's Developer Coefficient report pegs the average developer at 42% of their time spent on maintenance and bad code. Sit with that. The average is not the goal; the average is the company you don't want to be. If your load lands near 42%, you are not running a 20-person team. You are running the equivalent of an 11-person team and paying for 20.
- 10–20% — healthy. You ship, you break small things, you fix them inside the same sprint. Velocity holds week over week. This is the load you defend.
- 20–30% — drifting. Estimates start coming in at 2x. Engineers begin sentences with "well, the legacy part…" The slip is small enough to explain away each time, which is exactly why it compounds.
- Above 30% — the spiral. New features break old ones on contact. Your strongest engineers, the ones with options, leave first because they did not join to do janitorial work. Board targets get missed two quarters running, and the explanation gets vaguer each time.
Put it in dollars before anyone says "refactor"
The 42% figure is abstract until you multiply it by your payroll. On a $5M engineering budget, a 42% load is $2.1M a year spent purely keeping the lights on. Not building the feature your competitor announced last month. Keeping the lights on. McKinsey, in its tech debt research, frames this as a tax on the entire technology balance sheet, eroding equity quarter after quarter while nobody books the loss. That framing is the whole game. A board will debate "refactoring" forever and fund a $2.1M leak immediately. Walk in with the number: quantify the debt in dollars first, and the budget conversation gets dramatically shorter.
What you do Monday morning
You can't fire your way out of this, and you can't hire your way out either. Adding engineers to a tangled codebase just multiplies the surface area of the tangle. You have to change how capacity gets allocated, and that's a decision only the founder can make stick.
Cap the tax at 20%, every sprint, no exceptions
The discipline that actually works is boring: 20% of every sprint goes to debt paydown, permanently. Not "when the roadmap calms down," because it never calms down. Twenty percent, protected, the same way you protect customer-facing commitments. This is what keeps the load from creeping toward 42%. If you're already above 40%, a steady 20% won't dig you out fast enough; you run one focused quarter at 50% remediation to reset the baseline, then drop back to the standing 20%. Gartner's research found that teams that actively manage debt this way move materially faster than those that don't, which is the point: the 20% is not charity, it's the cheapest velocity you can buy.
Refuse the grand rewrite
At some point an engineering leader will propose stopping feature work for six months to rewrite the platform. Say no. A full rewrite at $30M ARR is a bet-the-company event with no customer-facing upside until the very end, and most don't land on schedule. Prioritize by blast radius instead: refactor only the code you touch constantly or the code whose failure hits customers. The ugly, stable module nobody has opened in a year costs you nothing while it sits there. Leave it. Burning a sprint on it is just vanity remediation.
The one chart that exposes the leadership question
Ask your engineering leader for a chart: maintenance versus net-new capacity over the last six months. If they can produce it in a day, you have someone who already manages the tax. If they can't, that's the finding. Sustained drift usually means your roadmap is quietly working against your exit because no one is measuring the drag, and the fix is a leader who reads a P&L as fluently as they read Python. If you're staring at a gap at the top of engineering, start with the 48-hour stabilization plan so a transition doesn't spike the load before you've capped it.
