Refactor or build features? The CFO frame
The recurring sprint-planning argument, reframed as a capital-allocation question. Both sides are investments with payback periods; the comparison is a CFO question, not an engineering preference.
The 90-Second Answer
Treat refactoring and feature work as comparable investments. Both have implementation cost (engineer-weeks), payback period (months), confidence interval, and strategic alignment. The side with the better payback inside the relevant decision horizon wins. The 5-7 month McKinsey payback for targeted refactoring usually beats feature work with 12+ month payback; new-market feature work with a 3-month payback usually beats refactoring with an 18-month payback. Case-specific, not ideological.
The Standard Failure Modes
How teams get this wrong consistently
The argument as it usually happens in engineering organisations is qualitative: product managers want features, engineers want refactoring, the manager mediates. The qualitative framing produces consistent biases. Product managers have visible outcomes attached to features (revenue, customer acquisition, win rates); engineers have less visible outcomes attached to refactoring (eventual velocity gain, reduced incident rate, easier onboarding). The visibility asymmetry means features systematically win in qualitative arguments, regardless of the actual economics.
The consistent over-allocation to features in qualitative-argument organisations is the dominant mechanism producing the McKinsey 25-42% drag figure. The trajectory described on the technical insolvency page is the same trajectory, viewed over 5-7 years. The qualitative-argument organisation does not run out of headroom on debt servicing because they decided not to refactor; they run out because each individual quarter's decision favoured features in a defensible way and the aggregate was unsustainable.
The mirror failure mode is the engineering organisation where senior engineers have captured enough authority to consistently favour refactoring over features. This produces a different failure: missed revenue opportunities, slower-than-competitor product evolution, founder frustration with engineering velocity. Less common in venture-backed software companies but real in some engineering cultures, particularly in companies where the founding CTO retained strong individual contributor authority into later stages.
The Four-Number Discipline
How to compare options fairly
The discipline that produces fair comparisons is computing four numbers for each option, in the same format, presented to the same decision-maker. The numbers are not magic; the discipline of computing them consistently is the value.
The ranking is: pure economics (cost vs payback) first, weighted by confidence; then adjusted for strategic alignment. The adjustment is small but real; strategic alignment should never override a clearly inferior payback by more than 30% in either direction.
The Quarterly Allocation
How to set the broad ratio
The strategic allocation is best set quarterly, not per-sprint, because the underlying ratios are slow-moving. A typical mid-stage SaaS allocation might be 60% feature work, 25% platform / debt servicing, 15% experimentation and discovery. The exact numbers vary by company stage (more feature focus at pre-Series A, more platform focus at growth stage) and by current debt position (more remediation when the debt service ratio is concerning).
The allocation should be visible to the CEO and CFO every quarter, with the underlying rationale documented. Allocations that drift quarter-over-quarter without explicit decision are usually drifting toward more feature work because of the qualitative-argument bias described above. The CTO should look for quarter-over-quarter drift specifically and challenge it when it appears.
The sprint-level allocation flexes within the quarterly target based on emergent priorities. A production incident that requires a structural fix can absorb capacity that would otherwise have gone to feature work; a competitive release that requires a fast response can absorb capacity that would otherwise have gone to refactoring. The quarterly target absorbs the variance; the sprint planning becomes lower-stakes when the quarterly target is well-set.
The Decision-Maker Question
Who actually decides
The decision authority for the refactor-vs-features question varies by company structure. In most healthy mid-stage organisations, the CTO sets the quarterly allocation in consultation with the CPO (product) and the CFO (finance), with sprint-level execution delegated to engineering managers. The CEO becomes involved when the allocation has material strategic implications (a remediation programme that reduces feature shipping for two quarters; a feature commitment that requires deferring critical platform work).
The dysfunctional pattern is when the product organisation owns the allocation decision entirely. Product organisations have a structural bias toward feature work, for exactly the reasons described in the failure-modes section above. A company whose product team unilaterally sets the feature-vs-platform allocation will systematically under-invest in platform work, with the technical insolvency consequence that emerges 5-7 years later. The CTO who recognises this pattern early can re-establish joint decision authority through the CFO conversation, which is one of the higher-leverage moves available to a mid-stage CTO.
Where the founding CTO is also the CPO (a common pattern at pre-Series A), the conflict is internal and is resolved through the founder's judgement. The CFO conversation becomes the external check that keeps the allocation honest. This dynamic is one of several reasons why bringing in a senior engineering leader during the Series A-C window (see the Series A-C page) often improves the quality of the allocation decision: a separate CTO and CPO produce a better quarterly allocation than a combined founder-CTO-CPO role.
Cross-Reference
The decision in the broader stack
The refactor-vs-features decision is the daily expression of the broader tech-debt strategy. The strategic frames sit above it: CFO pitch (funding), CEO pitch (prioritisation), board pitch (risk). The operational metrics sit alongside it: debt service ratio (measurement), velocity impact (consequence). The strategic options sit below it: technical insolvency (the failure mode).
For the engineering-practitioner view of how to scope and execute specific refactor initiatives, see the sister site technicaldebtcost.com. The site covers per-pattern refactor strategies (strangler fig, parallel run, blue-green) with cost arithmetic for each.
Field Notes
Frequently asked questions
How should engineering teams resolve the refactor-vs-features tension?+
By treating it as a capital allocation decision, not an engineering preference. Each side has a payback period; the side with the better payback inside the relevant decision horizon should win. Refactoring with a 5-7 month payback usually beats feature work with a 12+ month payback. Feature work with a 3-month payback usually beats refactoring with an 18-month payback.
Is there a default answer?+
No. The default that engineering teams often apply (always prefer features) tends to produce technical insolvency over 5-7 years. The default some senior engineers prefer (always prefer refactoring) tends to produce missed revenue opportunities. The right answer is case-specific allocation with both options costed using comparable methodologies.
What is the CFO frame specifically?+
Both refactor and feature work are investments with payback periods. The CFO evaluates them on the same terms, with the same NPV math. Engineering teams that present both options in this format get the right answer; teams that present feature work as 'what we should do' and refactoring as 'what we want to do' get systematically wrong answers.
Should we run the calculation per sprint or per quarter?+
Per quarter for the strategic allocation, per sprint for the tactical adjustment. The quarterly allocation sets the broad ratio (e.g. 70% feature, 30% platform/debt); the sprint-level allocation flexes within that ratio based on emergent priorities.
What if leadership won't fund any debt work?+
The debt accumulates. The trajectory documented on the technical insolvency page applies. The CTO's job is to document the decision and the trajectory; leadership has the authority to make the trade-off, and the CTO has the responsibility to make the consequences legible.
How do we score the comparison fairly?+
Compute four numbers for each option: implementation cost (engineer-weeks), expected payback (months), confidence interval on the payback (high / medium / low), and strategic alignment with the next round narrative. Rank pure economics first, then weight by strategic alignment. The discipline of computing the four numbers consistently produces fair comparisons.
Adjacent Reading