Business acumen for FDEs: follow the money before you write the first line of code

Picture week six of a pilot. The agent runs smoothly, the accuracy numbers look good and the head of operations is nodding along. Then someone from finance asks a single question: “How much extra money does this make the company, or how much does it save?” The room goes quiet, and the FDE has nothing to offer but a latency chart.

That scenario is not rare. IBM cites an MIT report from summer 2025 finding that 95% of generative AI pilots are failing. IBM’s own CEO survey found that only about 25% of AI initiatives achieve the expected ROI, 16% are scaled across the enterprise, and only about 29% of executives are confident they can measure ROI.

IBM’s conclusion is that the main challenge is organisational, not technological. For a developer who wants to become an FDE, that is good news: the missing skill is not another framework but the ability to read the customer’s cash flow. It can be learned.

Is time saved actually money?

IBM divides ROI into two kinds. Hard ROI is tangible impact tied directly to profit. Soft ROI covers benefits that are not immediately tied to profit but still help the organisation, such as less tired employees or faster decisions.

The trap for engineers is that most of what we can measure (minutes saved, automation rate, accuracy) is only soft ROI. It becomes hard ROI only when it changes a specific line on the profit and loss statement (P&L): revenue goes up, costs go down, or an expense that would have been incurred is no longer needed.

Customers make money in three basic ways: selling more, keeping customers longer, and doing the same work at lower cost. Before writing code, you need to know which of these your project affects. If the answer is “none of them”, the project is simply waiting its turn to be cut.

A worked example: a 200-person call centre

Take a hypothetical case. A consumer finance company runs a call centre with 200 agents, each handling 60 calls a day. After each call, the agent spends 3 minutes writing notes into the CRM. You deploy an agent that summarises calls and brings that down to 1 minute.

The technical arithmetic looks great: 200 people × 60 calls × 2 minutes = 24,000 minutes, or 400 hours a day. But ask the finance question: where do those 400 hours go? If staff still work full shifts, still receive full pay and call volume does not rise, the P&L does not move by a cent. That is soft ROI.

There are three ways to turn it into hard ROI, and each needs a different person to agree. First, the call centre takes on more sales calls with the same team: the sales director must commit to supplying enough leads. Second, the company avoids hiring extra staff for the coming peak season: the head of HR must confirm the hiring plan.

Third, outsourcing costs fall: the manager of the outsourcing contract must agree to scale it down.

From there, the answer to finance is no longer “we save 400 hours”. It becomes: “400 hours a day is equivalent to the peak-season headcount HR was planning to hire, and HR has confirmed that figure.” That is a financial statement that can be verified.

Where is the money, and who signs?

Many engineers assume the CIO holds the money, because the CIO is the first person they meet. Futurum Group finds the opposite: AI spending increasingly sits in business-unit budgets, spreading budget authority beyond the CIO.

Its advice to vendors is to confirm who actually controls the budget before treating the CIO as the main economic buyer.

An opinion piece on DEV Community describes a common split: IT chooses the technology, business units adopt it, finance approves the budget. The problem, the author argues, is that nobody owns the financial outcome, meaning the gap between projected and actual figures.

This is one writer’s view rather than a survey, but it gives an FDE a usable map.

Party	What they care about	What the FDE needs to bring
IT	Security, integration, running costs	Architecture, data handling, maintenance plan
Business unit	Whether their department hits its targets	Before-and-after business metrics, the new workflow
Finance	Money spent versus money returned	Baseline, assumptions, how hard ROI will be measured

Finance deserves even more attention once costs start running over plan. Futurum reports that 46.9% of companies say AI spending has exceeded budget, while only 5.6% spent less than planned. According to Futurum, finance is also the function most likely to force that conversation into the open.

If you have not met anyone from finance yet, they will come looking for you, usually at the worst possible moment.

Four questions for discovery

You do not need to see the customer’s financial statements. You need four questions, asked naturally during customer discovery, ideally with the person who owns the business process.

“If this project succeeds, which number in your monthly report will change?” This finds the P&L line. “What is that number today, and who measures it?” This gives you the baseline. “Which department’s budget pays for this project?” This identifies the economic buyer.

“If we want to roll this out across the company, who would have to sign?” This tells you whom to meet next.

Write the answers on a short one-page document: the P&L line, the baseline, the budget holder, the person who signs off on scaling, and the person who will compare projections with actuals. Any blank box is a project risk, as important as an undocumented API.

Three common mistakes

The first mistake is reporting technical metrics to people who need financial ones. 92% accuracy means nothing to the person approving the budget unless you can say how much the remaining 8% costs to handle manually.

The second is failing to measure a baseline before deployment. Once the agent is running, you have no way to prove “it used to take 3 minutes”. Measure in the first week, even if that means timing 30 calls by hand with a stopwatch.

The third is mistaking the friendliest user for the decision-maker. A team lead who praises the project to the skies does not necessarily control the budget. If you have only one relationship on the customer side, whether the project lives or dies depends on whether that person stays in the room for the budget meeting.

Putting this skill on your CV

When reading an FDE job description, look for passages about customers’ business outcomes or working with multiple stakeholders. If they are there, that is where an example like the call centre above belongs, including in interviews. On your CV, do not write “built a call-summarisation pipeline”.

Write that you cut post-call handling time from one specific number to another, which department confirmed it, and what that changed in their plans.

A good FDE does more than deploy agents. They are the person who can stand in the middle of the meeting room and answer the finance question before anyone asks it.