I Hired Two CFOs Before Realising the Problem Wasn't the CFO

There's an admission I owe my team in writing here. Before we built the internal layer that became Saldo, I hired a CFO twice in the space of eighteen months. The first stayed four months. The second stayed nine. Both, on paper and in person, were strong hires: one had run finance at a 200-person agency before us, the other had come from professional services consolidation work at a Big Four firm. Neither was the problem.

I told myself, after each of them left, that finance hiring was just hard at our size. We were a 50-person agency growing to 80 in a market that wasn't paying senior finance rates. I was wrong about that. I was hiring the wrong job.

The first CFO: she did everything right, monthly

She started in February of 2023. By April she had stood up a clean monthly close: every project tagged, every worklog reconciled, every overhead line allocated. The closing pack was a single PDF with a margin number per project, a roll-up by client, and a one-page narrative of what had happened that month.

The first month I read it, three projects we'd been celebrating internally were red. One was negative. The narrative explained why: scope creep on two of them, a senior covering junior work on the third, and a retainer that had quietly grown 40% without a price review. The work was excellent. The math was right.

The problem was that I was reading this at the end of April. The negative project had finished in early March. The scope-creep projects had been wrapping in mid-March. By the time I had the data, the levers I could pull on those projects had already been pulled — or, more accurately, hadn't been pulled, because nobody had known there was anything to pull.

I asked her if we could close weekly instead of monthly. She told me, politely, that we couldn't. Closing the books weekly with our setup would mean reconstructing the entire spreadsheet stack four times a month instead of once, and the reconstruction was already a five-day exercise. Closing weekly would consume her entire week, every week, with no time left for analysis or any of the other things a finance lead is supposed to do.

She was right. I asked the wrong question.

The pattern that made me let her go

By August it was clear we had a structural mismatch. Every closing pack I read showed me what had already happened. Every conversation with the team about it ended with the same phrase: yes, we know now. Knowing now wasn't the point of having a CFO.

The thing that broke me was the September pack. We had landed a high-profile retainer in late June at what looked like good margin. By September the retainer had absorbed two senior engineers for support work that should have been at junior rate, the client had requested three small expansions that nobody had repriced, and the actual margin had fallen from 38% (the estimate) to 14% (the closing number). All three months — July, August, September — had been quietly bleeding. The closing pack told me about July only at the end of August, August at the end of September, and September I'd find out about on the 24th of October.

We were, at any moment, three months blind.

I let her go in October. She was relieved, I think. The job was unworkable from her side too: she had built a clean process for an agency that needed something different, and was being asked weekly for numbers she could only produce monthly.

The second CFO: same problem, different intelligence

I hired more carefully the second time. The new CFO came from a Big Four background, had run financial integration on three agency acquisitions, and understood project-level economics deeply. He proposed a fortnightly close. We agreed to try it.

He delivered the fortnightly close cleanly for six months. He shaved the cycle down from five days to two and a half by automating most of the worklog reconciliation. The reports got sharper: he started flagging projects mid-flight when the burn was visibly above the estimate's pace. The CTO and I started actually using the fortnightly pack the same week it was produced.

But by month seven the same pattern came back, slightly compressed. The fortnightly close still meant that any project that started bleeding on day one was about ten working days into the bleed before we saw it on a report. For a three-month build, ten days is a chunk of the project's lifetime. For a year-long retainer, ten days a fortnight is most of the retainer.

He came to me at month nine and said, more or less: I can keep tightening the cycle, but every pound of further compression is going to cost us another half-day of close time, and we're already at the limit of what one person can sustain. The question, he said, isn't who runs the close. The question is whether you should be running a close at all.

That sentence is the reason this article exists.

What changed when the P&L became continuous

Within a month of him saying that, we had the first internal version of what is now Saldo running against our Jira instance. The brief was simple: read the worklogs as they appear, multiply by each person's real hourly cost, allocate overhead pro-rata against the rolling 30-day revenue, and never again present a margin number that's older than the last sync.

We turned off the fortnightly close on the first of the next month. Not because it was bad — it wasn't. We turned it off because it had become redundant. The dashboard had the same numbers, but yesterday's, not last fortnight's. The CFO didn't write the closing pack any more. He came into the Monday review with an interpretation of what the live numbers were doing, why, and what to do about it.

Two changes happened almost immediately and they're the ones I would have paid the entire build cost for, several times over.

The first was that mid-flight intervention became possible. Two of the four projects we materially intervened on in the first three months had been within an estimate-pace tolerance you couldn't have caught at the fortnightly close. One was an account where an account manager had quietly absorbed a chunk of weekly support that hadn't been priced; we caught it in week two of the new month and added a line to the next invoice. The other was a build where the senior architect had stayed on the project past the point his rate could justify; we caught it on day twelve and rotated him out. Neither of those would have shown up on the closing pack until weeks later, by which point both were unfixable.

The second was that the cancellation conversation got crisper. We let two retainers go in our first quarter on the new system, both at the client's quiet expense and quietly without breakage. Both had been earning money on the invoice and losing it on the saldo for months. The decision to walk away from a paying client is a hard conversation; it's a much easier conversation when you can show the numbers in real time, on screen, against the client's signed estimate.

What the CFO does now

The third hire (and current finance lead) joined eight months after we put the first CFO version of the layer in. The brief was different from the first two. The phrase I used in the offer letter was "interpretation, not reconstruction".

What she actually does, week to week:

• Monday morning live margin review. Forty-five minutes with leadership and the operations director. The margin numbers are already on screen by the time we sit down. Her job is to read them, not produce them. She spends most of the time on which projects need a conversation that week, which clients need a re-pricing, and which people are landing in roles that don't match what they're being costed at.
• Pricing reviews on every new estimate over £40k. Not approval; a sanity check that the role mix is buildable, the role rates carry their margin, and the overhead allocation has been thought about. Two pricing review notes in the average week.
• Salary and rate reviews quarterly. Real hourly cost numbers for every person; the review changes the numbers in the system, which automatically shifts the historical reports forward (with a snapshot of the old number kept for audit).
• The CFO conversation that matters most: with the people who do the work. Most weeks, two or three engineers come into her office to talk about why a worklog is showing in red on the dashboard. The answer is usually fine — they're solving a hard problem in a way that's worth the senior cost. Occasionally it isn't, and that's a conversation that wouldn't have happened in either of the previous two regimes.

What she doesn't do: produce the closing pack. There isn't one. The data is the report. The interpretation is the meeting.

How to think about it if you're 50–100 people

If you're at 50–100 people on Jira and considering a finance hire, the question I'd ask before posting the role is: what cadence will the new hire run on, and is that cadence fast enough for the decisions you actually want to make?

A monthly cadence will give you good books and a closing pack. It will not let you intervene on projects before they're over.

A fortnightly cadence will give you mid-flight reads on long-cycle work. It will leave short-cycle projects to surprise you.

A continuous P&L (which is what we built ourselves and is what Saldo is) will give you the live margin number. It changes the CFO role from reconstruction to interpretation. It also changes who you should hire: the right person is no longer the one with the cleanest closing process, but the one with the strongest opinion about what to do with the live number.

I learned all of this the expensive way. Two CFOs left thinking they had failed. Neither did. The system they were embedded in failed. They were running a job, perfectly, that the available tooling made impossible to do properly.

If you're reading this with a CFO who has just told you politely that the close is taking five days a month and you'd like it weekly — that conversation is a tool problem, not a person problem. They're telling you the truth.

The number you actually want isn't last month's. It's today's. Once you have today's, you don't need the closing pack at all, and the CFO you hire next will be a different (and frankly more interesting) job.

If this sounds familiar, Saldo is the layer we built around our own Jira to make today's number possible. The 15-minute demo is on your real Jira data; we don't ask for card details up front, and we don't follow up if it doesn't land.