Maximising engineering ROI: the CFO's guide

Engineering is usually the largest discretionary line a CFO cannot easily evaluate. The outputs are technical, the timelines are long, and the people explaining it have an interest in the answer.

This is a way to evaluate it that does not require becoming technical.

The CFO’s lens: three questions, not twenty

Most finance reviews of engineering get lost in detail. Three questions carry almost all the signal.

1. Is the spend structural or discretionary? Keeping existing systems running is structural — it is the cost of the revenue you already have. Building new capability is discretionary. Most organisations cannot split their engineering budget this way, and that inability is itself the finding: if you do not know what proportion goes to maintenance, you cannot tell whether you are investing or merely sustaining.

A healthy mid-market split is often quoted loosely; the useful version is to measure your own and watch the trend. A maintenance share that rises year on year is the clearest early signal of accumulating technical debt, and it shows up in finance data before it shows up anywhere else.

2. Is unit cost moving in the right direction? Total engineering spend should rise with a growing business. Cost per customer, per transaction or per delivered change should not. Total spend tells you almost nothing on its own.

3. Is capacity fixed or flexible? This is the structural question, and it is the one where finance has the most influence.

Benchmarking in the DACH market

Benchmarks travel badly. Applying a US or Indian cost benchmark to a Swiss organisation produces a number that is technically accurate and decision-useless.

What is worth comparing locally:

• Fully-loaded cost per engineer, including recruitment, employer contributions, workplace, tooling and management overhead — typically well above the salary figure people quote
• Time-to-hire, which in Switzerland is long enough for the delay itself to be a material cost
• Utilisation, the share of paid capacity actually applied to planned work
• Cost of idle capacity between projects, which fixed teams carry and flexible ones do not

The last two are where most of the recoverable money sits, and neither appears in a salary comparison.

Why hybrid capacity changes the arithmetic

A permanent Swiss hire is the right instrument for work that is permanent, requires deep knowledge of your business, and will still exist in three years.

It is an expensive instrument for work that is temporary, specialised, or uncertain — because you are buying a fixed, long-duration commitment to meet a variable need. The mismatch costs in two directions: idle capacity when demand falls, and an inability to respond when it rises.

The hybrid pattern that most Swiss mid-market companies land on separates the two:

• Permanent, internal — business knowledge, architecture ownership, anything where continuity is the point
• Flexible, external — specialised capability (cloud, data, MLOps), surge capacity, and work with a defined end

From a finance perspective the change is that a share of engineering cost becomes variable, and variable cost in an uncertain market is worth a premium per hour. That is the trade being made, and it should be made explicitly rather than by default.

The detailed comparison sits in Swiss engineering costs: in-house vs remote.

The levers a CFO can actually pull

Four, in order of how quickly they act.

Cost attribution. Until engineering spend is attributed to products or teams, no one can manage it. This is a finance capability, not a technical one, and it is usually the fastest available improvement.

Retirement. Every estate runs systems nobody uses. Each carries licences, hosting and maintenance attention. Asking “what did we switch off this year?” is a finance question with a direct answer in the ledger.

Capacity structure. Shifting part of the team from fixed to flexible changes the cost base rather than trimming it, which is more durable than a hiring freeze.

Sequencing by return. Engineering roadmaps are typically ordered by dependency and preference. Re-ordering by expected return is a finance contribution that costs nothing and frequently changes what gets built first.

What not to do

Do not cut maintenance to fund new build. It is the most common move and it converts a visible cost into an invisible liability. The bill arrives two years later as an outage or a migration.

Do not manage engineering by headcount. Headcount and output are only loosely related; managing the proxy rather than the outcome reliably produces worse outcomes.

Do not accept technical metrics as ROI. Deployment frequency and test coverage are operational health indicators. They are not financial returns, and treating them as such makes the next conversation harder.

Three questions for the next review

1. What share of engineering spend goes to maintaining what exists? And which way has that share moved in two years?
2. What is our cost per delivered change, and is it falling?
3. What proportion of capacity is fixed? Is that proportion a decision, or an accident of hiring history?

Related reading

• The engineering ROI playbook — the same question from the engineering seat
• The hidden costs of scaling
• Dedicated engineering teams

If you want an outside view on your fixed-versus-flexible split, book a call. No obligation.