When the data shows a client's process is broken: how an FDE should tell the process owner

Three weeks into a deployment, you run a query on the logs and get a result nobody wants to hear. Most of the exceptions the client asked you to automate trace back to an approval step designed by the head of operations. On Monday morning, that person will be sitting across from you at the progress meeting.

There are two ways to get this wrong. Say it clumsily and you lose your most important ally inside the client’s organisation. Stay silent and you automate a broken process, so the errors happen faster than before.

The skill between those two sounds “soft” next to writing code. But it often decides whether a deployment produces real change or leaves behind a dashboard nobody opens.

The client asks you to fix the symptom; you can see the cause

GSDC Council, describing situations FDEs commonly face, makes a familiar point: the solution a client asks for may not be the real problem. They ask you to automate one step, but what needs fixing is sometimes the step just before it.

Why do FDEs often spot this before the client does? Vinoo Ganesh, discussing how Kepler does forward deployed engineering, argues that watching people work produces a very different kind of evidence from asking them whether they like a feature.

According to an analysis of Palantir’s model, FDEs there spend most of their working week, 30–40 hours, sitting next to analysts and operators, often in a secure facility. Sit that close and you see where the process on paper and the real process diverge.

That means your finding is grounded in real work rather than hearsay, though it still needs checking. The difficulty is that the person who wrote the process on paper still believes in it.

Facts first, interpretation second

The STATE method from the book Crucial Conversations gives you a clear sequence. Every sensitive conversation should start with observable facts. Then you tell your interpretation, but as a story that could be wrong, not as an unarguable truth.

Next, humbly ask how the other person sees it, and make clear that you want to hear their view, even if it is completely different from yours.

The sequence works because facts are hard to argue with, while anyone can argue with a conclusion. But it only holds up if your facts are genuinely solid. Quirk’s, in a guide to delivering bad news, stresses that any bad news must be backed by sound data, and that the data must rest on a sound method.

The Quirk’s piece also makes an easily forgotten point: bad news is rarely all bad, and many clients only need to adjust their strategy to play to their strengths. So alongside the bad facts, always state what is working.

One meeting, sentence by sentence

Imagine a distribution company asks you to build an agent that reconciles invoices against purchase orders (POs). After four weeks, suppose the logs show 1,200 invoices, of which 310 have fallen into the manual processing queue.

You trace each invoice and find that 248 of those 310 had a PO raised after the goods had already arrived at the warehouse. So the agent had nothing to match them against.

The “receive goods first, raise the PO later” step was introduced by the head of operations to speed up deliveries. Here is a five-sentence script you can use.

State the facts: “Over the past four weeks, 310 invoices needed manual processing. For 248 of them, the PO was raised after the goods were received. I’ve brought ten specific invoices for you to look at.”

Say what is working: “But the other 890 invoices matched automatically, which means the reconciliation itself is working.”

Tell your hypothesis: “Raising POs late may be the main reason the number of manually processed invoices isn’t falling. But I don’t yet know the background to why this step was set up this way.”

Ask and invite pushback: “How do you read these numbers? If I’ve read something wrong, for example if there are urgent orders that have to be handled this way, I’d really like to know.”

Propose a small trial: “If it makes sense to you, let’s try two weeks with one group of suppliers: raise a provisional PO before the goods arrive. At the end of the two weeks, we compare that group’s manual invoice count with the past four weeks.”

Notice that nowhere in the script is there a sentence saying “your process is wrong”. The listener either reaches that conclusion themselves or shows you a legitimate exception the logs did not capture. Either outcome works in your favour.

Before the meeting: check your work as if it will certainly be challenged

Preparation starts with method, not wording. Recheck how you counted: the time window, the timestamp source, the records you excluded. The process owner will attack the weakest link.

Next, pick a few cases and go and see them for yourself, in the spirit Ganesh describes: observing work produces evidence a query cannot. Ten real invoices are more persuasive than a chart.

Then have an action ready. Natalie Meurer, discussing the “dirty secret” of forward deployed engineering, argues that a useful operational application must help people act on data, not just look at it.

In the example above, that is the last sentence of the script: a two-week trial, narrow in scope, with a number to compare at the end.

How the conversation goes wrong

The most common mistake is opening with the conclusion. If your first sentence is a verdict, the listener spends the rest of the meeting rebutting it instead of reading the numbers with you.

Another trap is speaking before you have their trust. Ganesh describes how FDEs use small, successful fixes to earn trust and access to deeper problems. If you point out a flaw in someone else’s process in your first week, you are spending capital you have not yet earned.

Nor should you spring the finding on them in front of their boss. Talk to the process owner privately first, so they have a chance to push back and present it upwards with you.

Finally, don’t bring only a dashboard with no proposal. The meeting will then tend to end in a nod, and nothing changes.

Turning the skill into evidence when job hunting

When preparing for FDE interviews, be ready for a question like: “Tell me about a time you had to tell a client something they didn’t want to hear.” A good answer has four parts: the data you found, how you verified it, who you persuaded, and the measurable change that followed.

When reading job descriptions, look for lines about working with client stakeholders or understanding their operational processes. That is where this story belongs on your CV, written in numbers rather than adjectives.

This week’s exercise: take the most worrying number in the project you are working on and write a five-sentence script following the template above. Read it to a colleague and ask them: which sentence sounds like an accusation?

The process owner does not need you to prove them wrong. They need to see that fixing the process with you is less risky than continuing to defend it.