How do you prioritize technical debt vs new features?

Long Answer

Startups win by learning faster than the market, but speed without long-term code quality buys short-term throughput at the cost of future agility. Treating technical debt as an explicit investment choice—not an afterthought—lets you move fast now and keep moving fast later. My strategy blends data, governance, and culture so the team can negotiate trade-offs openly and continuously.

1) Make debt visible and measurable

You cannot prioritize what you cannot see. I keep debt in the same backlog as features, never on a side list. Each debt item has a clear hypothesis and a metric link: slower lead time in a module, elevated MTTR, rising incident frequency, or high cognitive load indicated by change failure rate. Static analysis, test coverage, and hotspots from Git history reveal where to focus; production telemetry shows the real user impact (for example, tail latency in a hot path).

2) Use a lightweight value–risk–cost model

For both features and debt, we score three dimensions: Value (revenue, retention, unblock future features), Risk (security, reliability, compliance), and Cost (time to implement, opportunity cost). Debt often carries hidden future cost via compounding complexity, so we add a drag factor based on rework and onboarding friction. The outcome is a comparable priority score that prevents “features first, debt later” bias.

3) Reserve capacity and time-box

I institutionalize a debt budget: for example, 20–30% of each sprint or a rotating “stability week” every 6–8 weeks. This prevents starvation during growth spikes. For emergent, high-risk debt (security issues, flaky releases), we escalate immediately. Otherwise, we time-box refactors and split them into incremental slices that ship alongside features, avoiding big-bang rewrites.

4) Align refactors with roadmap outcomes

Technical work is easiest to fund when it unlocks roadmap value. I pair refactors with adjacent features: while building a new pricing flow, extract a clean domain module and add contract tests. While adding a search facet, replace an ad-hoc query layer with an indexed repository and caching. This “opportunistic coupling” reduces context switching and yields visible wins.

5) Install guardrails to stop the bleeding

We move fast, but not loose. CI enforces minimum tests, static checks, and security scans; a blocking quality gate protects main. Architecture Decision Records (ADRs) capture trade-offs so future engineers understand why choices were made. Coding standards and module boundaries reduce accidental complexity. Feature flags let us release in small slices, gather feedback, and roll back safely without patchy hotfix code.

6) Prefer surgical refactors over rewrites

Rewrites reset bugs and knowledge. I favor strangler-fig techniques: wrap, extract, and replace seams around hot spots. Introduce ports and adapters, add tests around the seam, then peel out legacy implementations. This de-risks the work, preserves flow, and keeps value shipping.

7) Govern with SLOs and “error budgets” for quality

Adopt SLOs for reliability and performance (for example, p95 latency, change failure rate). If the error budget burns fast, we throttle features and prioritize remediation and refactors until budgets recover. This converts gut feelings into shared rules, aligning product and engineering on when quality must take precedence.

8) Communicate like a product manager

Debt prioritization is a negotiation. I translate technical risks into business language: “This refactor cuts lead time on onboarding flows by 30% and halves incident blast radius.” I present before/after metrics and a small roadmap of enabling moves, so stakeholders see compounding payoffs, not abstract cleanliness.

9) Close the loop with metrics

Track cycle time, deployment frequency, MTTR, defects per KLOC, and incident counts in the refactored area. If a debt item does not change a metric, we revisit the hypothesis. Publish a quarterly “engineering capital” report: what debt we paid down, what agility we gained, and what quality risks remain.

By treating technical debt versus new features as a continuous, data-driven portfolio choice—budgeted, measured, and tied to outcomes—you keep code malleable without freezing product momentum. The result is sustainable speed: shipping today does not mortgage tomorrow.

‍

Table

‍

Common Mistake

• Hiding technical debt on a separate list, so it never competes fairly with features.
  
• Treating debt as cleanup without hypotheses or measurable outcomes, making it easy to cut.
  
• All-or-nothing rewrites that pause delivery and recreate old problems in new code.
  
• Starving debt until incidents force emergency refactors at peak business times.
  
• Skipping guardrails: no CI quality gates, inconsistent reviews, and no ADRs, so debt regrows.
  
• Refactoring in isolation from the roadmap, increasing context switches and stakeholder resistance.
  
• No SLOs or error budgets, so quality concerns become subjective debates.
  
• Failing to publish before/after metrics, making wins invisible and budgets fragile.
  
  

Sample Answers

Junior:
“I keep technical debt tickets in the same backlog as features and tag them with impact. We reserve time each sprint for small refactors, and I use feature flags to ship in slices. CI checks and code reviews help prevent new debt.”

Mid:
“I score items by value, risk, and cost, and I pair refactors with nearby features to reduce overhead. I measure effect on cycle time and defects. If reliability SLOs are at risk, I pause feature work to restore the error budget, then resume.”

Senior:
“I run a portfolio approach: fixed debt capacity, SLO-driven governance, and ADR-backed decisions. We use strangler patterns, contract tests, and quality gates to deliver incremental refactors. Quarterly, I publish metric deltas (lead time, MTTR) so product sees the compounding ROI of sustained technical debt reduction.”

‍

Evaluation Criteria

Strong answers treat prioritizing technical debt versus new features as a product decision with shared metrics, not just engineering taste. Look for: a unified backlog; a simple scoring model (value, risk, cost, drag); fixed capacity for debt; incremental patterns (strangler, seams, contract tests); guardrails (CI gates, standards, ADRs); and governance via SLOs and error budgets. Candidates should tie refactors to roadmap outcomes and commit to before/after metrics. Red flags: big-bang rewrites, “we will clean later,” no metrics, separate shadow backlogs, or skipping guardrails that let new debt accumulate.

‍

Preparation Tips

• Draft a one-page policy: backlog in one place, 20–30% debt capacity, scoring rubric, and SLO thresholds.
  
• Practice writing debt tickets with hypotheses and measurable outcomes (for example, “reduce checkout MTTR by 40%”).
  
• Learn strangler and seams patterns; rehearse splitting a refactor into safe, incremental steps.
  
• Configure CI quality gates (tests, linting, security scan) and adopt ADRs for key changes.
  
• Define 2–3 SLOs and an error budget policy; simulate a burn-down and the resulting feature throttle.
  
• Build a dashboard (cycle time, CFR, MTTR, incidents) and run a mini case study: pick one module, refactor for two sprints, report the deltas.
  
• Prepare a stakeholder narrative that links debt payoff to specific roadmap acceleration.
  
  

Real-world Context

A B2B SaaS team reserved 25% capacity for debt and used strangler seams to extract a payment module; feature lead time fell 32% and incident count halved in two quarters. A marketplace tied refactors to SLOs; after error-budget burns repeatedly paused launches, they replaced a brittle queue with idempotent handlers, cutting MTTR from hours to minutes. A consumer startup paired debt with features (search relevance work bundled with index refactors); search latency dropped 40% while shipping new filters on schedule. In each case, debt reduction succeeded because it was budgeted, measured, and explained in business terms.

‍

Key Takeaways

• Put technical debt and features in one backlog with shared metrics.
  
• Use a simple value–risk–cost score and reserve 20–30% capacity.
  
• Pair refactors with nearby features; prefer strangler over rewrites.
  
• Enforce guardrails (CI gates, ADRs) to prevent new debt.
  
• Govern with SLOs and error budgets and prove ROI with before/after metrics.
  
  

Practice Exercise

Scenario:
You are the first Startup Web Engineer at a fast-growing product. Incidents have increased, onboarding is slow, and roadmap pressure is high. Leadership asks you to improve delivery speed without sacrificing reliability.

Tasks:

1. Create a one-page policy that sets a 25% sprint capacity for debt, defines a value–risk–cost–drag score, and states SLOs with error-budget rules.
   
2. Audit the codebase to produce a top-10 debt list using static analysis, hotspot commits, incident history, and cycle-time data.
   
3. For the next two roadmap features, propose “opportunistic” refactors in the same modules (for example, extract a service boundary, add contract tests, standardize logging).
   
4. Design CI quality gates (unit thresholds, lint, security scan) and add ADR templates.
   
5. Choose one high-risk seam and plan a three-step strangler sequence; include rollback and feature-flag strategy.
   
6. Define success metrics (lead time, CFR, MTTR) and build a lightweight dashboard.
   
7. Present a two-sprint plan to stakeholders that shows feature timelines, the debt items bundled, predicted metric deltas, and the rule for pausing features if SLOs exceed budget.
   
   

Deliverable:
A concise plan and dashboard mock that leadership can approve today, demonstrating how you will ship features while reducing technical debt and protecting long-term code quality.