Investment framing

“We need to refactor the payments service.”

That sentence has ended more engineering careers than any technical failure. Not because the refactoring wasn’t needed — it almost certainly was. But because nobody outside engineering has any idea what it means, why it matters, or what happens if you don’t do it.

Now try this: “We’re investing £400K over two quarters to reduce payment processing failures by 80%, which protects £2.1M in annual transaction revenue and eliminates the need for three support engineers handling payment escalations.”

Same project. Completely different conversation.

The job

Investment framing is the discipline of translating engineering work into business terms. Every piece of engineering work consumes capital — salaries, infrastructure, opportunity cost. The question isn’t whether engineering is spending money. It’s whether leadership understands what they’re getting for it.

Most engineering work is invisible to the business. Not because it doesn’t matter, but because engineers describe it in engineering terms. Migrations, refactors, service decomposition, test coverage, observability — these are meaningful to us and utterly opaque to a CFO.

Your CFO doesn’t fund technology. They fund business outcomes. Investment framing is how you connect the two.

This isn’t about spin or politics, though plenty of people treat it that way. It’s about genuine translation — expressing the business value of technical work honestly and precisely. When done well, it changes the entire dynamic between engineering and the rest of the business. When done badly or not at all, engineering becomes a cost centre that leadership tolerates rather than a strategic function they invest in.

Why it matters

Engineering typically represents 15-30% of total operating expenditure in technology companies. At a 200-person company with a 60-person engineering team, you’re looking at £8-12M per year in fully loaded engineering cost. That’s a massive investment by any measure.

Now ask the average CFO: “What is engineering producing for that £10M?” Most of the time, you’ll get a pause, followed by something vague about “the product” or “the platform.”

That vagueness is lethal. When budgets tighten — and they always tighten — vague line items get cut first. The CFO knows exactly what the sales team produces for their budget (pipeline, closed revenue) and exactly what marketing produces (leads, brand awareness, conversion rates). Engineering? “They build stuff.”

I’ve seen this play out painfully. A mid-market SaaS company I worked with had a £400K tech debt reduction programme that was genuinely critical — their deployment pipeline was so fragile that they could only ship once a fortnight, and every release carried significant rollback risk. Engineering knew this was an existential issue. But they pitched it as “tech debt reduction” and the CFO killed it in favour of a marketing programme with a clear ROI model.

Six months later, a botched deployment took the platform down for 14 hours, cost them two enterprise contracts worth £600K ARR, and the tech debt programme got emergency-funded at twice the original budget.

The engineering team was right about the work. They were wrong about how they communicated it.

What good looks like

Struggling: Engineering work is described in technical terms. Budget conversations are adversarial — engineering asks for money, finance pushes back. Tech debt and infrastructure work gets perpetually deferred because nobody can articulate why it matters. Leadership views engineering as a cost centre.

Mature: Every significant engineering initiative has a business case expressed in business terms. Engineering is categorised as a portfolio of investments with expected returns. The CFO can explain engineering’s investment thesis to the board. Engineering is viewed as a strategic function that generates returns.

Markers of excellence:

• Every initiative above a threshold (say, £50K in cost or one engineer-quarter of effort) has a one-page investment case
• Engineering work is categorised into a portfolio framework that leadership understands
• The engineering leader can present a “return on engineering investment” narrative at board level
• Finance proactively involves engineering in budget planning, not as an afterthought
• Technical work like debt reduction and infrastructure improvement has the same rigour of business justification as feature work

The approach

1. Categorise your portfolio

Not all engineering work is the same type of investment. Lumping “build new checkout flow” and “upgrade database cluster” into the same category is like a fund manager treating growth stocks and treasury bonds as interchangeable.

Use a three-category framework that any business leader can understand:

Grow: Work that directly enables new revenue or market expansion. New features, new product lines, new integrations, new market capabilities. This is the easiest category to justify because the revenue connection is direct.

Protect: Work that prevents revenue loss or reduces risk. Reliability improvements, security hardening, compliance work, tech debt that threatens stability. This is the category most engineering leaders under-invest in because it’s hard to show ROI on something not breaking.

Sustain: Work that keeps the lights on. Infrastructure maintenance, dependency upgrades, on-call, routine operations. This is the cost of doing business. You can’t eliminate it, but you can manage it.

A healthy engineering portfolio typically looks something like 40% Grow, 30% Protect, 30% Sustain. The exact ratio depends on your company stage and market position, but if Sustain is over 40%, you’ve got a structural problem. If Protect is under 20%, you’re accumulating risk. If Grow is under 30%, you’re not investing in the future.

Present this portfolio view to leadership every quarter. “Here’s how we’re allocating our £10M engineering investment: £4M on growth initiatives, £3M on protecting existing revenue, £3M on sustaining operations.” Suddenly engineering isn’t a black box. It’s a portfolio with a thesis.

2. Build investment cases

Every significant initiative needs a one-page investment case. Not a business case document that takes three weeks to write — a concise framing that answers four questions:

1. What are we investing? Total cost in pounds (or dollars, euros — whatever your company counts in). Include salary cost, infrastructure cost, opportunity cost. Be specific: “£180K over one quarter (two senior engineers full-time, £20K in infrastructure).”

2. What do we expect in return? Revenue enabled, revenue protected, cost reduced, risk mitigated. Quantify it. “Reduces payment failures from 5% to 1%, protecting approximately £2.1M in annual transaction revenue.”

3. What’s the time horizon? When does the investment start paying off? “Initial improvements within 6 weeks, full impact by end of Q3.”

4. What happens if we don’t? This is the one most people skip, and it’s often the most compelling. “Payment failure rate is trending upward at 0.5% per quarter. Without intervention, we’ll reach 7% by Q4, which based on current transaction volume puts £3.2M at risk and will likely trigger an audit from our payment processor.”

That’s it. One page. Maybe half a page. If you can’t articulate these four points concisely, you either don’t understand the work well enough or the work genuinely doesn’t have a business case — in which case, maybe don’t do it.

3. Quantify the intangible (honestly)

Some engineering work has obvious financial returns. “Build integration with Salesforce” clearly enables revenue. Easy to frame.

Other work is genuinely harder to quantify. How do you put a number on “improve developer experience” or “reduce technical debt in the authentication service”?

Here’s how: follow the chain of consequences until you hit something with a number on it.

“Improve developer experience” → faster development cycles → ship features 20% faster → based on last year’s feature velocity and revenue attribution, that’s approximately £500K in revenue acceleration.

“Reduce tech debt in authentication service” → fewer auth-related incidents → currently averaging 3 incidents per quarter at 4 hours each, costing £15K per incident in engineering time and roughly £8K in customer impact → fixing it saves approximately £90K per year and reduces customer churn risk.

Are these numbers precise? No. Are they better than “we need to do this because the code is bad”? Enormously. The CFO knows your estimate is an estimate. They’re not expecting engineering ROI calculations to be as precise as a DCF model. They’re expecting you to think about business impact at all.

Don’t bullshit the numbers, though. If you inflate returns to get a project funded and it doesn’t deliver, you’ve spent your credibility. Better to present an honest, conservative estimate and over-deliver than to oversell and under-deliver.

4. Frame tech debt as accumulated risk

Tech debt is the hardest category to get funded because the consequences are probabilistic. The payments service might fall over. The authentication system might have a security breach. The deployment pipeline might cause a bad release.

“Might” doesn’t get funded. Here’s the reframe: tech debt is unhedged risk on the balance sheet.

Every piece of significant tech debt has a probability of causing an incident, a severity if it does, and a cost of remediation after the fact versus prevention before it. Frame it like insurance:

“The authentication service has accumulated significant technical debt. Based on our incident history, we’re averaging one auth-related outage per quarter. Each outage costs approximately £45K in direct engineering time and customer impact. We can invest £120K now to modernise the service and reduce incident probability by 80%, or we can continue paying £180K per year in reactive costs with the risk of a major breach that could cost significantly more.”

That’s not a tech pitch. That’s a risk management pitch. CFOs understand risk management.

5. Present portfolio-level narratives

Individual investment cases matter, but the real power is in the portfolio view. Once a quarter, present engineering’s investment portfolio to leadership the way a fund manager would present to investors:

• Portfolio allocation: How investment is distributed across Grow, Protect, and Sustain
• Returns on previous investments: What did last quarter’s investments deliver? Were the business cases accurate?
• Proposed changes: Where do you want to shift allocation and why?
• Risk assessment: What risks are you carrying and what would it cost to address them?

This is the artefact that transforms engineering from “the people who build stuff” to “a strategic investment portfolio managed by someone who thinks like a business leader.”

The first time you present this, expect surprise. Most leadership teams have never seen engineering framed this way. By the third quarter, they’ll expect it — and they’ll use it to make better investment decisions.

The conversations

With your team

Trust-building: “I need your help quantifying the business impact of the database migration. Here’s how I’m framing it for leadership — does this accurately represent what we’d achieve?”

Trust-eroding: “We need to make a business case for the migration or it won’t get funded. Can you write something up?”

Involve your engineers in the framing, not just the execution. They often understand the technical risks better than you do, and they’ll feel ownership over the investment case if they helped build it. What kills morale is the engineering leader who asks them to produce justification documents for work everyone knows is necessary.

With Finance

Trust-building: “Here’s our engineering investment portfolio for Q3. I’ve categorised everything into Grow, Protect, and Sustain, with cost and expected return for each initiative. I’d love your input on whether the return assumptions look reasonable.”

Trust-eroding: “Here’s our budget request. We need £2.3M for Q3.”

Finance partners become allies when you speak their language and invite their scrutiny. The engineering leader who presents a portfolio with return expectations is asking for a partnership. The one who presents a budget request is asking for permission. These are fundamentally different relationships.

With leadership

Trust-building: “Last quarter we invested £2.8M in engineering. Here’s where it went and what it produced. The reliability programme has reduced customer-facing incidents by 60%, which our customer success team attributes to a 15% improvement in enterprise renewal rates. The new integration drove £430K in new pipeline. For next quarter, I’d recommend shifting 10% from Sustain to Grow because the infrastructure stabilisation work has reduced our maintenance burden.”

Trust-eroding: “Engineering had a productive quarter. We shipped the new integration and made good progress on reliability.”

The first version gives leadership a return on their investment. The second gives them a vague feeling that things are fine. One builds strategic trust. The other maintains the status quo.

Common failure modes

Over-quantifying. Not everything needs a precise ROI. Some work is clearly necessary — security patches, compliance requirements, keeping the lights on. Trying to calculate the ROI of a mandatory security update wastes everyone’s time. Frame it as a compliance cost and move on.

Treating investment framing as a one-off exercise. Building a great investment case and then never reporting on outcomes is worse than not building one at all. You’ve made promises. Follow up on them. “We said this would reduce failures by 80%. Here’s what actually happened.” Even if results fell short, the follow-up builds credibility.

Letting the framework become bureaucracy. If every three-day task needs a one-page investment case, you’ve gone too far. Set a threshold — typically one engineer-month or £30-50K — and only require formal framing above that threshold.

Conflating investment framing with project justification. Investment framing isn’t about justifying your existence. If it feels defensive, you’re doing it wrong. It should feel like you’re helping leadership make better decisions about where to allocate capital. If the answer is “invest less in engineering,” a good investment frame will show that honestly.

Using engineering jargon in business frames. If your investment case includes the words “refactor,” “microservices,” “technical debt,” or “code quality,” you’ve failed at translation. These words mean nothing to your CFO. Translate them into outcomes: reliability, speed, risk, cost.

Getting started

If you’re not doing investment framing today, here’s a lightweight start.

This week: Pick your three largest engineering initiatives. For each one, write a four-sentence investment case: what you’re investing, what you expect back, the time horizon, and what happens if you don’t do it. Don’t overthink it. Four sentences.

This month: Categorise all your current engineering work into Grow, Protect, and Sustain. Calculate the approximate percentage split. Just seeing the ratio will be illuminating — most leaders are shocked by how much goes to Sustain.

This quarter: Build your first portfolio narrative. Share it with your finance partner before you share it with leadership. Get their input. Refine it. Then present it at a leadership meeting as “a new way I’m thinking about engineering investment.” Watch how the conversation changes.

Next quarter: Report on outcomes. “Last quarter I said initiative X would deliver Y. Here’s what actually happened.” This is where the real trust gets built. Not in the promise, but in the follow-through.

The engineering leaders who get this right — who can fluently translate between technical work and business outcomes — are the ones who get promoted, get funded, and get to build the teams they want. The ones who don’t are forever asking permission and justifying their existence.

Stop asking for budget. Start presenting investment opportunities. It’s the same work. It’s an entirely different conversation.

Downloads

The Investment Case Template includes a one-page investment case format, a portfolio categorisation worksheet (Grow/Protect/Sustain), and a quarterly portfolio summary view. Use the investment case template for any initiative above your threshold, the categorisation worksheet to classify all current work, and the summary view to present your portfolio narrative to leadership.

Related plays

• Capacity Planning — You need to know what your team can deliver before you can frame it as an investment. Capacity planning gives you the denominator.
• Scenario Planning — Investment framing works hand-in-hand with scenarios. Each scenario implies a different investment portfolio.
• The CapEx/OpEx Discipline — How engineering investment gets classified for accounting purposes, and why it matters for your CFO relationship.