The Invisible Cap Table: Why Your Engineers Are Slowing Down
You just hired six new engineers. Your burn rate jumped by $1.2M annualized. Yet, your roadmap velocity didn't budge. In fact, it might have slowed down.
This is the paradox of the Series B stall. You aren't suffering from a talent shortage; you are suffering from an Innovation Tax. When you ask your VP of Engineering why the Q3 launch is slipping to Q4, they talk about "refactoring" and "scalability." What they really mean is that a significant portion of your payroll is being diverted to pay interest on past decisions.
Technical debt is not abstract. It is a quantifiable drag on your P&L. To fix it, you must stop treating it as a philosophical debate and start measuring it as a capacity allocation problem. We use the Maintenance Load Formula to diagnose exactly how much of your engineering capacity is stolen by debt.
The Formula: Innovation vs. Maintenance
To calculate your Technical Debt Load, you don't need to read code. You need to read timesheets (or Jira tickets). The formula is simple but brutal:
Technical Debt Load % = (FTEs on Bug Fixes + FTEs on Refactoring + FTEs on Unplanned Outages) / Total Engineering FTEs
If you have 20 engineers, and 8 of them spent this sprint fixing bugs, patching servers, or rewriting a hasty integration from 2023, your Tech Debt Load is 40%. That means for every $1 you spend on engineering salaries, only $0.60 goes toward the features that drive new revenue. The rest is the tax you pay for speed you borrowed years ago.
The Benchmarks: What is 'Healthy' vs. 'Toxic'?
Every company has technical debt. If your debt is 0%, you moved too slowly. But at the Series B/C stage ($10M-$50M ARR), there is a fine line between leverage and bankruptcy.
The Danger Zone: >30%
According to Stripe's Developer Coefficient report, the average developer spends 42% of their time on maintenance and bad code. This is the industry average, but it is not the winner's average. If your team is spending 40%+ on maintenance, you are effectively running a part-time engineering organization.
- Healthy (10-20%): You are moving fast, breaking small things, and fixing them quickly. This is sustainable.
- At Risk (20-30%): Velocity feels sluggish. Features take 2x longer than estimated. Developers are grumbling about "legacy code."
- Toxic (>30%): You are in the "death spiral." New features break old ones. Your best engineers quit because they hate janitorial work. You miss board targets repeatedly.
The Financial Impact
Let's translate that 42% into dollars. If your engineering payroll is $5M, a 42% maintenance load means you are spending $2.1M annually just to keep the lights on. That is $2.1M that isn't building the AI feature your competitor just launched. This is why we tell founders: Quantify technical debt in dollars before you walk into the board meeting. When you frame it as a $2M loss, you finally get the budget to fix it.
The Cure: The '20% Tax' Rule
You cannot fire your way out of technical debt, and you usually can't hire your way out of it either (adding more people to a messy codebase just creates more mess). You must engineer your way out.
1. The Golden Ratio
The most successful PE-backed CTOs we work with enforce a strict capacity allocation rule: 20% of every sprint is dedicated to debt paydown. Not "when we have time." Mandatory. This prevents the debt from compounding. If your current load is >40%, you may need a "Debt Jubilee"—a focused quarter where 50% of capacity goes to remediation to reset the baseline.
2. Stop the 'Grand Rewrite'
Do not let your engineering leader convince you to stop feature development for six months to "rewrite the platform." This is a death sentence. Instead, prioritize debt based on Revenue Impact. Only refactor code that you touch frequently or that directly impacts customer stability. If the code is ugly but stable and rarely touched, leave it alone. That is "shelfware debt"—it costs you nothing until you touch it.
3. The Leadership Test
If your current engineering leader cannot produce a chart showing Maintenance vs. Innovation capacity over the last 6 months, you have a leadership problem. Your product roadmap is sabotaging your exit because no one is measuring the drag coefficient. You may need a leader who speaks fluent P&L, not just fluent Python. If you suspect you have the wrong person at the helm, read our guide on the 48-hour stabilization plan.
