How do you explain the £20M engineering spend?

I understand the pain of trying to justify software engineering costs. Whether it's explaining project overruns to finance executives at enterprise companies or projecting burn rate to investors at startups, the conversation is always the same.

The CFO or investor asks: "We're spending £15 million on engineering. What are we getting for it?"

You open your spreadsheet. You've got headcount numbers. You've got salary bands. You've got a list of ongoing projects. But when they ask "How much did the checkout rebuild actually cost?" or "What's the ROI on that six-month platform migration?" you're guessing.

I've led engineering teams across startups and larger organisations, managing at most 30 engineers at a time. The scale might be different, but the problem is identical everywhere: Nobody can tell you what anything actually costs.

Not the features. Not the projects. Not the "strategic initiatives" that consume whole quarters. The money disappears into a black hole labelled "Engineering" and everyone just hopes it comes out the other side as revenue.

My experience spans both worlds. In startups, I've had to project costs to investors who want to understand unit economics before Series A. In enterprise environments, I've had to explain to finance executives why a six-month project is now projected at twelve months. The excuses change but the underlying problem doesn't: we lack the fundamental infrastructure to measure what engineering work actually costs.

The problem isn't new, but it's getting worse

Here's what I hear from almost every technology leader I talk to:

"We end up centrally bucketing costs because we can't close the loop in-month."

Translation: We don't know what we're spending on what, so we just dump it all into a general bucket and call it "Platform Team Q3". Finance hates it. The board questions it. But what else are you supposed to do?

"If we cut 20% of headcount or move teams, I want to see the impact instantly."

But you can't. Because your "planning tool" is a spreadsheet with 47 tabs that breaks if you delete a row. By the time you've modelled the scenario, the board has already made the decision based on gut feel.

"We spend £20 million on people—I need to show we're spending it wisely."

This one keeps CTOs up at night. You know you're spending wisely. You know your teams are talented. But you can't prove it with data because the data doesn't exist.

"We have to replan every few months when priorities or people shift."

And every replan costs you three days of meetings, another round of spreadsheets, and the same painful process you went through last quarter.

Why planning dies the moment you ship it

Most engineering organisations do quarterly planning. You spend 4-6 weeks building a plan for the next quarter. By week seven, someone leaves. By week nine, a "strategic priority" appears from nowhere. By week twelve, your original plan is historical fiction.

Here's how engineering leadership time actually breaks down:

• Meetings (planning, allocation, reviews): 17.9 hours/week — 7 hours more than individual contributors
• Fragmented time: 7.1 hours/week — causes 40% productivity penalty
• Focus time: 10.4 hours/week — only 2.6 hours uninterrupted

That 17.9 hours of weekly meetings? A significant portion is planning-related: quarterly planning kickoffs that stretch across 4-6 weeks, mid-quarter reviews, resource allocation discussions, budget justifications. When you do the maths, engineering leaders spend roughly one-third of every quarter planning the next one. You're perpetually six weeks behind reality because by the time you finish planning, the world has changed.

And what are you planning? According to McKinsey research, engineering teams spend 40-60% of their time on maintenance and operations rather than new capabilities². But can you tell me which 40-60%? Can you show me which engineers are working on which projects and whether those projects are CapEx or OpEx?

Of course not. Because tracking that requires updating a spreadsheet every week, and we all know that never happens.

CapEx vs OpEx blindspot

Here's where it gets painful. Your CFO needs to know if engineering work is building new capabilities (CapEx) or maintaining existing ones (OpEx). This isn't accounting pedantry—it fundamentally changes how work gets funded and measured.

McKinsey found that in some organisations, developers spend more than 50 percent of their time just dealing with technical debt ³. That's the difference between a strategic engineering organisation and a team perpetually fighting fires.

In contrast, top-quartile companies (as defined by the Developer Velocity Index) spend 33 percent less time on undifferentiated, manual work, freeing them to innovate ⁴.

But here's the kicker: The problem is nearly universal. A 2023 survey found that 91% of IT leaders identify technical debt as their biggest challenge to innovation ⁵. Yet many companies only "carve out 15 to 20 percent of IT's budget to address tech debt," an allocation McKinsey notes is often insufficient ³.

Can you show your board which bucket each engineer falls into? Can you demonstrate you're moving from 50% tech debt drag to 30%? Or are you just hoping nobody asks?

Private Equity pressure cooker

Here's why this matters more than ever: private equity buyout dealmaking rebounded to $602 billion in 2024, a 37% year-over-year increase ⁶. The technology sector was the primary driver, capturing 33% of all buyout deals by value globally ⁶.

But the game has changed. Look at how PE firms create value over time:

Operational excellence moved from 18% to 47% of value creation. Financial engineering—leverage and multiple expansion—dropped from 51% to 25%.

What does that mean for you? If you're running engineering at a PE-backed company, you've got 90 days to show how you're spending money and 12-24 months to show meaningful efficiency improvements.

"We're hiring more engineers" is not a plan. "We're allocating 8.5 FTE to these three projects with these expected returns" is a plan.

And guess what PE operating partners are asking for?

• True cost per project (not estimates, not guesses)
• OpEx vs CapEx allocation across the engineering org
• Resource utilisation rates
• Feature development costs with actual numbers
• Margin expansion roadmap with engineering efficiency drivers

Most technology leaders can't answer any of it.

Spreadsheet Error Tax

Here's something that should terrify you: Academic reviews, including a recent 35-year analysis, consistently find that 88-94% of spreadsheets used in critical business decisions contain errors ⁸. That's not a typo. Nearly every spreadsheet driving your workforce planning has mistakes.

And yet, PwC reports that 80% of organisations still rely on spreadsheets for their financial planning and analysis (FP&A) ⁹.

This isn't a technical problem. It's an organisational crisis. When your CFO doesn't trust your numbers because they're built in Excel, you lose credibility. When they ask for scenario analysis and you need three days to copy tabs around, you lose influence.

This misalignment is endemic. Workday found that only 30% of CFOs say they are closely aligned with their CIOs on their companies' digital and tech road map ¹⁰. How can you align when you're speaking different languages? Finance speaks cost centres and quarterly forecasts. Engineering speaks story points and sprint velocity.

What we're missing: A minimum viable unit

The problem isn't that we need better Gantt charts. It's that we don't have a minimum viable unit for measuring engineering work.

Finance has a clear hierarchy:

• Line items → Cost centres → Departments → Total spend

Manufacturing has:

• Components → Products → Production lines → Output

Software?

• Story points (meaningless outside your team)
• Features (too granular)
• Products (too broad)
• "Platform investment" (could mean anything)

Startups are especially blind. Ask any founder what their new checkout flow cost to build—not in story points, but in cash spent on salaries, overhead, and opportunity cost—and you'll get a shrug.

This is what we're fixing at Flowstate.

---

The Flowstate Method: Treating engineering like the investment it is

We're not building another project management tool. We're building a framework for how engineering organisations should plan, track, and measure work.

Think of it like:

• Agile was for software development methodology
• The Linear Method for issue tracking and product workflow
• The Flowstate Method for workforce planning and cost visibility

The core principle: workforce planning should be structured around bets, not backlogs.

Projects as Minimum Viable Bets

Here's where we're opinionated. In the Flowstate Method, a project is:

• Minimum 1.0 FTE of a team's monthly capacity
• Maximum 4 concurrent projects per team per quarter
• Single-team owned where possible
• Cost centre aligned so finance can track it
• Skills-matched to ensure teams have the right capabilities

Why 1.0 FTE minimum? Because anything smaller isn't a bet—it's a task masquerading as strategy. If you're not willing to dedicate at least one person-month to something, you're not serious about it.

Why maximum 4 per quarter? Because focus is a scarce resource. A team trying to do more than four meaningful things simultaneously is doing none of them well.

This structure gives you:

1. True cost visibility: You know what "rebuild the checkout" cost because you see the constituent projects and their FTE allocation
2. Scenario planning that works: Move a team? See instantly which projects lose capacity
3. Real ROI tracking: You can measure whether the bet paid off because you know what you bet
4. Skills balancing: Match project requirements to team capabilities—not just headcount, but actual skills

People are more than FTEs

Here's where most workforce planning tools fall down: they treat everyone as interchangeable resources. Flowstate doesn't.

We track:

• Role (Frontend Engineer, Backend Engineer, DevOps, etc.)
• Level (Junior, Mid, Senior, Staff, Principal)
• Skills (React, Python, AWS, PostgreSQL, etc.)

This means when you're planning a new project, you can ask: "Do we have the right skills available?" Not just "Do we have capacity?"

You can see that your team has 4.0 FTE available, but only 1.5 FTE with the React skills needed for the frontend work. That changes your planning. Maybe you need to hire differently. Maybe you need to adjust the project scope. Maybe you need to upskill someone.

But at least you know. And that's better than discovering the skills gap six weeks into the project.

Initiatives break down, not up

Large strategic work—initiatives—don't exist as monolithic things in Flowstate. They break down into constituent projects, each owned by a single team with clear FTE allocation.

This means when the CFO asks "How much did the checkout rebuild cost?" you can answer:

"Three projects totalling 12.5 FTE across Q2 and Q3. Approximately £340k in fully loaded costs. Delivered on schedule. We're seeing 15% conversion improvement, which translates to £2.1M additional annual revenue."

That's not a guess. That's data.

The Bet Framework

Every project in Flowstate maps to:

• Business value: Revenue impact, cost savings, or strategic positioning
• Cost centre: Where the expense gets booked
• Value stream: Which part of the business benefits
• FTE allocation: Exact resource commitment over time
• Required skills: What capabilities the project needs

When you structure work this way, the CapEx/OpEx conversation becomes straightforward:

Project Type	Typical Allocation	Business Impact	Accounting Treatment
New capabilities	20-30% of capacity	Revenue growth	CapEx
Platform modernisation	15-20%	Efficiency & scale	Mixed
Technical debt reduction	15-20%	Long-term velocity	OpEx
Maintenance & support	20-30%	KTLO	OpEx
Innovation experiments	10-15%	Option value	CapEx

Flowstate Method recommended allocation for balanced engineering organisation

You're not just tracking time. You're tracking investment and return.

What this looks like in practice

We're working with companies like RAC on their workforce planning. Here's how it changes the conversation:

Before Flowstate:

"We need five more engineers for the platform team."

After Flowstate:

"We're allocating 8.5 FTE to three projects this quarter:

• API v3 migration (4.0 FTE, £110k, expected to unlock £2M in operational savings)
• Observability infrastructure (3.0 FTE, £82k, reduces incident MTTR by 40%)
• Security hardening (1.5 FTE, £41k, table stakes for enterprise tier)

Total cost this quarter: £233k. Current capacity: fully allocated.

If we add five engineers (£150k/quarter fully loaded), we can take on the payments modernisation project in Q4. That's projected £5M annual revenue impact from reduced cart abandonment and new payment methods.

However, we need 2.0 FTE with payment processing experience and 1.5 FTE with PCI compliance knowledge. Our current hiring pipeline doesn't have those skills covered yet."

See the difference? You're not arguing about headcount. You're discussing investment, return, and capability gaps.

The planning interface you'd actually want to use

Traditional planning tools were built for project managers in 2005. You need a degree in MS Project to understand them.

Flowstate is different:

• Drag and drop team members between projects
• Instant cost calculations as you allocate people
• Real-time capacity views showing what's actually possible
• Skills matching to see if you have the right capabilities
• Scenario planning that doesn't require copying spreadsheets
• Automatic audit trail of every change and why

You can model "what if we hired three senior engineers next quarter?" in about 30 seconds. Compare scenarios side by side. See the impact on delivery dates, costs, and capacity.

Six months from now when someone asks "Why did we move those engineers off the payments team?" you can show them:

• The original allocation and project plan
• Who changed it and when
• The comment explaining the business reason
• What impact it had on downstream projects
• Whether the bet paid off

Collaborative planning that actually works

Here's where it gets interesting. Scenario planning in Flowstate is collaborative and live.

Think of it like Git for your workforce plan.

You can:

• Create as many scenario drafts as you like
• Share scenarios with stakeholders for review
• Get feedback and iterate
• Approve a scenario and it becomes the new plan
• Everyone's drafts automatically update with the approved changes

It's collaborative. It live-updates for everyone viewing. You can throw away as many drafts as you like. But there's one up-to-date source of truth, and it magically updates everybody's own drafts with the approved changes so you're always working off the latest version.

No more "which version of the plan are we looking at?" No more emailing spreadsheets around. No more discovering that finance was working from last week's numbers.

Commit. Merge. Rebase. But more magical.

Dynamic replanning without the pain

The software market changes fast. Strategic pivots happen. Key people leave. Priorities shift.

In the Flowstate Method, replanning doesn't mean starting over. It means:

1. Drag projects to adjust timeline
2. See instant impact on costs and delivery
3. Compare scenarios before committing
4. Document the why for future reference
5. Publish the new plan to stakeholders automatically

What used to take three days now takes thirty minutes.

And because everything's tracked properly, you can answer "Why did this project overrun?" with actual data:

• "We reallocated 2.0 FTE to the security incident in week 3"
• "The API migration took 6 weeks longer due to data quality issues we discovered"
• "We added scope in week 7 based on customer feedback—here's the approved change"

Not guesses. Facts.

The Method Drives the Product (Not the other way around)

We're not just building software. We're codifying best practices from technology leaders across industries.

The Flowstate Method is our answer to:

• How should engineering work be structured for visibility?
• What's the minimum viable unit of planning that balances granularity and overhead?
• How do you balance focus (few projects) with flexibility (changing priorities)?
• How do engineering bets map to financial outcomes finance actually cares about?
• How do you make scenario planning fast enough to be useful?
• How do you track skills and capabilities, not just headcount?

We're talking to:

• CTOs at PE-backed companies under operational scrutiny
• Scale-ups going through rapid growth and multiple planning cycles per year
• Mid-market firms trying to get control of engineering spend for the first time
• Engineering leaders tired of spreadsheet hell

The problems are consistent. The solutions shouldn't be bespoke.

---

Where we go from here

The scrutiny on engineering spending has never been higher. PE firms demanding operational excellence. Boards pushing for margin expansion. CFOs wanting real-time visibility into where money goes.

At the same time, the nature of engineering work is shifting. Productivity baselines are moving. Historical workforce planning models will be obsolete within months.

The organisations that figure this out—that can plan dynamically, measure accurately, and adapt quickly—will have an enormous advantage. The ones still copying spreadsheet tabs will get left behind.

We built Flowstate because I was tired of not having answers. Tired of spreadsheets that break. Tired of scenario planning that takes three days. Tired of explaining to boards why we can't tell them what things cost.

The Flowstate Method is our attempt to solve this properly. Not with another task tracker. Not with another spreadsheet replacement. But with a real framework for how engineering organisations should plan and measure work in 2025 and beyond.

Help us refine this

We're still early. The software works—RAC and others are using it today—but we're refining the method through conversations with technology leaders.

If you're dealing with any of these problems, I want to talk to you:

How do you currently do scenario planning?
When your CFO asks "what if we cut 20%?" what's your process? Spreadsheets? Gut feel? Three days of meetings?

How do you track the cost of features?
Can you tell me right now what your last three major features cost to build? Not estimates. Actual costs.

How do you justify headcount requests?
What's your narrative? "We need more people" or "We need 3.0 FTE for six months to build [thing] which will generate [value]"?

How do you handle frequent replanning?
When priorities shift monthly, how do you keep plans current without burning weeks on administration?

How do you match skills to projects?
Can you see at a glance whether your available capacity has the right skills for upcoming work?

The best frameworks emerge from collective wisdom, not individual experience. We're building Flowstate to solve problems I've lived, but I want to make sure we're solving problems you're living too.

If this resonates, get in touch: flowstate.inc

References