When you need 3 months to refactor legacy code and finance sees zero new features
This is a hypothetical, illustrative example for teaching purposes, not an actual case study.
Company:
B2B SaaS company with $10M ARR, 75 enterprise customers
Engineering Team:
15 engineers
The Codebase:
5-year-old monolithic application with mounting technical issues
The Request:
3 months (Q2) for a major refactoring project
The Impact:
Significant reduction in new feature delivery
The Meeting:
You need to convince the CFO and CEO to approve this investment
The Context: Your engineering team has been building features fast to keep up with customer demands, but the codebase has become increasingly fragile. Deployments take 2 hours and fail 30% of the time. Bug fixes that should take hours now take days. The team spends 40% of their time dealing with technical issues instead of building new features. You know this will only get worse, but finance sees a 3-month refactoring project as "spending money to build nothing new."
Here's how this conversation usually unfolds when the engineer uses technical language
"We need to take Q2 to pay down technical debt. The codebase has become very difficult to work with. We need to refactor the core modules, update our architecture, and modernize our tech stack."
"That's 3 months where we're not shipping new features. We have a roadmap commitment to customers. What's the business justification?"
"If we don't do this, things will get worse. Our deployment process is broken, we have high coupling in the code, and we're accumulating more technical debt every sprint. This is slowing us down."
"We just closed two major deals that require specific features by end of Q2. Can we do both?"
"Not really. We need focused time to do this properly. Otherwise we'll keep building on a shaky foundation."
"But those features represent $800K in new ARR. What's the ROI of this refactoring? Will customers pay more for a 'cleaner codebase'?"
"It's not about customers paying more. It's about making the team more productive and preventing future problems. This is an investment in our future velocity."
"I hear you, but I can't justify zero features for a quarter. Can you at least deliver the high-priority items?"
"We'll try, but we'll end up doing a half-hearted refactoring and the technical debt will keep growing. This has been the pattern for 2 years."
Result: Request gets denied or watered down to 20% time. Team continues to struggle. Technical debt grows. Engineering morale suffers. Feature delivery slows further.
Let's break down where the communication failed and what each party was really concerned about
The engineer never quantified what technical debt is currently costing the business in time, money, and opportunity cost
"High coupling," "shaky foundation," and "tech stack" are engineering concepts that don't translate to business impact
Didn't present a clear ROI or payback period for the refactoring investment
Failed to explain how technical debt impacts time-to-market, revenue velocity, and customer churn
Presented it as "3 months or nothing" instead of phased approach with incremental value
Now let's see how the same scenario plays out when the engineer can speak the language of finance
"I need to talk about a significant drag on our engineering efficiency that's costing us approximately $900K per year in opportunity cost and putting future revenue at risk. I have a proposal to address it with a 6-month payback period."
"I'm listening. What's the $900K based on?"
"I've tracked our team's time for the past 2 months. We're spending 40% of our engineering hours on things that are direct consequences of technical debt: fixing deployment failures, investigating production bugs caused by brittle code, and working around architectural limitations. That's roughly 6 engineers worth of capacity."
"At an average fully-loaded cost of $150K per engineer, that's $900K per year we're spending on technical debt 'interest payments.' More importantly, it means we're delivering 60% fewer features than we could be. Last quarter alone, we delayed 3 roadmap items that represent approximately $500K in pipeline deals."
"That gets my attention. What's your proposal?"
"A phased refactoring project over 3 months in Q2. The investment is approximately $300K in engineering time. In return, we'll reduce technical debt overhead from 40% to 15%, which frees up 3.75 engineers worth of capacity going forward—that's $560K per year in recovered productivity."
"More importantly, our time-to-market will improve by 35%. Features that currently take 6 weeks will take 4 weeks. That means we can deliver the Q3 and Q4 roadmap faster, which accelerates revenue. Based on our current pipeline, improving time-to-market by 35% could mean closing deals 2 months earlier, which has real cash flow impact."
"But you said 3 months. That's a quarter with reduced feature delivery. What about the $800K in deals we closed that need Q2 features?"
"Great question. I'm proposing a phased approach: 70% of the team on refactoring, 30% on critical features. We can still deliver those P0 features for the $800K deals, just at a slightly slower pace. The refactoring work happens in parallel and pays dividends immediately—by Month 2, the team working on features will already see productivity improvements."
"The alternative is continuing as we are. If we don't address this, I project we'll miss 40% of our H2 roadmap commitments, which puts approximately $2M in pipeline at risk. We're also seeing increased customer churn related to slow bug fixes—that's costing us roughly $180K in annual recurring revenue that we're losing."
"So if I understand correctly: $300K investment, 6-month payback, $560K annual benefit, and it reduces our risk of missing future roadmap commitments?"
"Exactly. And the ROI actually improves over time because we stop accumulating more debt. Think of it like paying off a credit card—once it's paid off, we stop paying interest. The $560K annual benefit compounds because we maintain the cleaner codebase going forward."
"This makes sense. Let's approve it with two conditions: monthly progress reports showing the productivity improvements, and a commitment to deliver those P0 features for the $800K deals by end of Q2."
Result: Project approved with clear ROI justification. Finance understands the business case. Engineering gets the time needed. Everyone is aligned on success metrics.
Here are the specific financial concepts the engineer used to transform the conversation
What it is: The gain from an investment relative to its cost
How it was used: "$300K investment yields $560K annual benefit = 87% ROI"
Why it mattered: Quantified the value in terms finance uses for all investment decisions
What it is: How long it takes for an investment to pay for itself
How it was used: "6-month payback period"
Why it mattered: Showed this is a quick-return investment, not a long-term bet
What it is: The cost of not taking an alternative action
How it was used: "We're spending $900K/year on technical debt maintenance instead of features"
Why it mattered: Framed the current state as expensive, making the refactoring look like a cost reduction
What it is: Lost recurring revenue from customers canceling
How it was used: "Slow bug fixes are costing us $180K in annual recurring revenue"
Why it mattered: Connected technical debt to customer retention and revenue loss
What it is: How long it takes to deliver features to customers
How it was used: "35% improvement in delivery speed = closing deals 2 months earlier"
Why it mattered: Connected engineering efficiency to revenue velocity and cash flow
What it is: Total cost of employment including salary, benefits, overhead
How it was used: "40% of engineering time = 6 engineers = $900K/year"
Why it mattered: Quantified technical debt in actual dollar terms finance understands
Started by calculating what technical debt is currently costing: 40% of engineering time = $900K/year. This made the "do nothing" option look expensive.
$300K investment, 6-month payback, $560K annual benefit. These are the metrics leadership uses for every investment decision.
Showed how technical debt puts $2M in pipeline at risk and causes $180K in churn. This elevated it from an engineering problem to a business problem.
70/30 split allowed critical features to continue while making progress on technical debt. This showed flexibility and business awareness.
Connected faster delivery to earlier deal closures and better cash flow. This resonates with both sales and finance teams.
Never said "high coupling" or "tech stack." Instead talked about time, money, risk, and opportunity cost—universal business language.
Think about technical debt in your own codebase and calculate its business impact:
What percentage of your team's time is spent dealing with consequences of technical debt (bug fixes, deployment issues, working around limitations)? Track it for 2 weeks.
Calculate the annual cost: (Team size × Fully-loaded cost per engineer × % time on technical debt). This is your "interest payment."
List 3 features or improvements you couldn't deliver in the last quarter due to technical constraints. Estimate their business value.
If you could refactor one piece of the system, how much would it cost (in engineering time), and how much would it reduce the technical debt overhead percentage?
Calculate the payback period: Cost of refactoring ÷ Annual productivity savings. If it's under 12 months, you have a compelling business case.
Bonus Challenge: Draft a one-page proposal for a technical debt reduction project using the financial framework from this example. Include: current cost, investment required, ROI, payback period, and revenue/churn impact. Practice presenting it to a non-technical colleague.
Continue your learning journey