Deep-dive guide
Technical Debt Velocity Loss Simulator: What Rework Costs Your Engineering Team
Executive industry analysis
Technical debt is the accumulated cost of shortcuts: code that works but is hard to change, missing tests, tangled dependencies and old systems nobody understands. It rarely appears in a budget. Instead it appears as a feeling that everything takes longer than it used to. Estimates slip, small changes break unrelated things and the team spends sprints on work that creates nothing new. The invoice for this arrives not as a charge but as a smaller number of features shipped each month for the same payroll.
The structure of the problem is a tax on capacity. If a fifth of every sprint goes to workarounds and rework, the team behaves as if it were a fifth smaller, while the salaries are unchanged. Debt also compounds. Each new feature built on a shaky base adds more complexity, so the share lost grows unless some effort is spent on repayment. Paying down debt costs output now, which is why it is always tempting to postpone, and why the decision deserves numbers.
The domino model follows the loss. The share of sprint lost to debt reduces the capacity available for new work, which reduces features shipped. Fewer features reduce the value delivered per dollar of payroll, and the burden of rework, firefighting and turnover grows with debt. The last box compares value shipped with the true cost of the team. A modest rise in debt can turn a healthy return into a loss, because payroll is fixed while value is not.
The iceberg shows what the payroll line hides. Visible is the payroll itself. Below the waterline sit the part of payroll spent on rework, the firefighting that debt causes in production, the turnover of engineers who leave tired codebases and the value of features that were never built. The last item is an opportunity cost that never appears in accounts, yet it is usually the largest. Use the simulator to find the debt level where the team stops paying for itself, and to test whether a payoff plan is worth it.
Formula and methodology blueprint
The model is a monthly view of a product team. Payroll is engineers times loaded cost. A share of the sprint goes to debt and a share to deliberate payoff, and the rest builds new features. Features shipped are engineers times features per engineer times that remaining share, valued at the value per feature. Debt also causes incidents, as a share of the rework cost, and raises turnover, priced at four months of loaded salary per replacement. In the projection, debt drifts up each month unless payoff is funded.
- Building share
- b = 1 − debt − payoff
- The portion of the sprint that goes into new features.
- Features shipped
- F = engineers × features per engineer × b
- New features delivered in a month.
- Rework cost
- W = payroll × debt
- The payroll that bought no new value.
- Turnover cost
- A = engineers × (1% + 0.06% × debt points) × 4 months × cost
- Expected monthly cost of replacing engineers, rising with debt.
- Net result
- Net = F × value − payroll − 0.15 × W − A
- Value delivered minus the true cost of the team. The breaking point is where it reaches zero.
Cascading elasticity
Debt share is the most elastic input, because it reduces output and increases incident and turnover costs at the same time. Value per feature and features per engineer scale the whole return. Payroll cost matters because it is the fixed base that value must exceed.
Three real-world case studies
Bootstrapped starter
A small team with a clean codebase
A team of three keeps debt low, ships fast and values each feature highly relative to payroll. Rework is small. Loading it shows the early advantage of a clean base, and how little debt is needed to start eroding it.
Scaling mid-market
A large team that invests in payoff
A forty-five person team carries moderate debt but reserves a tenth of each sprint for cleanup. Features ship at a good rate and incidents stay low. Loading it shows why disciplined payoff scales.
Black-swan crisis
A fast-growth codebase nobody can change
A twenty-five person team inherited years of shortcuts. More than half of every sprint goes to rework and incidents, turnover is high and payoff time is zero. Loading it shows a large payroll producing little, and which lever restores the month.
Industry benchmark matrix
| Metric | Danger zone | Industry average | Top 10% elite |
|---|---|---|---|
| Share of sprint lost to rework | Above 40% | 15–25% | Below 10% |
| Time reserved for debt payoff | Zero | 5–10% | 15–20% where needed |
| Value shipped per dollar of payroll | Below 1.0 | 1.2–1.6 | Above 2.0 |
| Monthly engineer turnover | Above 2.5% | 1–1.5% | Below 1% |
| Incident work as share of rework cost | Above 25% | 10–15% | Below 8% |
Variables and levers
Engineers on the team
Developers working on the product, counted as full-time equivalents.
Lever: Do not add engineers to a team with heavy debt first, since each new person inherits the same drag and slows onboarding.
Loaded cost per engineer per month
Salary plus taxes, benefits, equipment and overhead for one engineer in a month.
Lever: Hold salaries to the market but cut hidden overhead, because every hour lost to debt is paid at the full loaded rate.
Sprint lost to debt and rework
Share of engineering time spent on workarounds, bug fixing, slow builds and fighting old code instead of new features.
Lever: Make debt visible: list the worst modules, estimate rework hours and fix the ones that touch the most features first.
Features per engineer per month (no debt)
How many meaningful features one engineer would ship in a month if no time were lost to debt.
Lever: Remove build, test and review friction, because developer experience decides how many features a person can ship.
Monthly value of a shipped feature
Revenue, savings or retention a typical feature adds per month once shipped, in your own estimate.
Lever: Ship features that move revenue or retention; if shipped value is low, no amount of velocity makes the team profitable.
Sprint invested in paying debt down
Share of the sprint deliberately spent reducing debt. It costs output now and reduces debt later.
Lever: Reserve a steady slice of each sprint, often ten to twenty percent, for debt that blocks upcoming work.
How to use this simulator
- 1Start from the realistic preset or enter your team size, loaded cost and estimated rework share.
- 2Read the five domino boxes to see whether velocity or the debt burden turns red first.
- 3Press Find my breaking point to see the debt share that makes the team unprofitable.
- 4Compare the current plan with the payoff plan on the 24-month chart.
- 5Measure rework for a few sprints and revisit the model each quarter.
Mistakes to avoid
- Treating the time lost to debt as free because salaries are fixed, when every hour carries the full loaded cost.
- Adding engineers to a slow codebase and expecting velocity to rise in proportion.
- Planning a big rewrite instead of paying debt down steadily where it blocks upcoming work.
- Ignoring turnover, which is a real and recurring cost of unpleasant code.
Frequently asked questions
How do I estimate the share of sprint lost to debt?
Tag tickets and pull requests that are rework, bug fixes or workarounds for a few sprints, then divide that time by total engineering time. Ask the team for a rough number as a cross-check.
Is all technical debt bad?
No. Taking a shortcut to learn faster or meet a deadline can be a good trade, if you track it and repay it. Debt becomes a problem when it is unmanaged and compounds.
How much time should we spend on payoff?
It depends on the debt level and upcoming work. A steady ten to twenty percent is common, but spend it on debt that blocks planned features rather than on cleanup for its own sake.
How do I value a feature?
Estimate the monthly revenue, retention or cost savings it adds, even roughly. If you cannot, use the average revenue growth divided by features shipped as a starting point.
How do I find the debt level where the team loses money?
Press Find my breaking point. The tool moves each input towards its worse end and reports the value where monthly profit reaches zero.
How accurate is this?
It is an educational model with stated assumptions, not management advice. Real engineering outcomes depend on many factors. Replace the inputs with your own data.
This is an educational planning model with stated assumptions. It is not financial, tax or legal advice. Replace the inputs with your own figures and verify important decisions with a qualified professional.