The FDE Playbook: Three Implementation Patterns That Consistently Improve Success Rates

About the Author:

Milos is a forward-deployed engineer. At any given moment, he has around ten client engagements running in parallel.

Before FDE, he spent several years in data and observability engineering — triple-certified by Elastic.

He writes FDE Hub — a newsletter on the craft of forward-deployed engineering, with essays drawn from live engagements as they unfold.

A practitioner's playbook from ten parallel client engagements, across every industry.

Forward-deployed engineering is my day job. The work is automating operational processes, the order handling, invoicing, and planning that keep a business running, for companies that make, move, and sell physical products. 

It comes with unusual access: a seat inside the client's operation, their systems and data, and the people who actually do the work, with a mandate to take an automation from the first conversation to running in production. 

Most forward-deployed engineers go deep on one or two clients at a time. They learn a single company's systems, its people, its particular mess, and they get very good at it. 

I work the other way. At any given moment, I have around ten engagements running in parallel, across logistics, finance, manufacturing, wholesale, and a handful of other industries.

That breadth comes at a cost. I don't get the months buried inside one company's systems that a dedicated engagement gives you, and there's real value in that kind of depth. 

What the parallel view offers instead is range, and range surfaces things that depth alone can't. When the same problem appears at four companies that have nothing in common, you stop treating it as each company's dysfunction and start seeing the underlying structure.

What that vantage point has taught me is that the factors that determine whether an implementation succeeds are almost never technical. 

The engineering still has to be right, and you can't do this job without it. But it's the part that gets easier every month, and it's rarely where projects actually fail. 

The parts that make or break a project repeat, and they're human. Three show up more often than all the others combined: you build with the wrong person, you automate a process before you've actually understood it, and you treat the first weeks of an engagement as a technical problem when they're an organizational one.

The Four-Person Rule: who actually matters, and when

Every project has someone who is thrilled you're there. They're senior enough to make decisions, responsive, and they want this to work more than anyone in the building. Every instinct tells you this is the person to build with.

It usually isn't.

On one engagement, accounts payable automation for a company operating across several countries, we had exactly that person. Sharp, available, completely bought in. We spent two months building with her. The system worked. Then we handed it to the people who process invoices every day, and it came apart in dozens of small ways rather than one big one.

They were editing records directly in the ERP in ways we'd never been told about, so the one-way sync we'd built was wrong. 

The approval logic ran on a spreadsheet that had been growing for a decade, full of paths and exceptions nobody had written down. The supplier base was in chaos. 

One invoice we kept flagging for a missing purchase order number came back revised, still missing it, because someone had typed the words "purchase order" onto the document instead of an actual number. We had built around how the process was supposed to work, not how it actually did.

The champion wasn't wrong about anything. She genuinely believed she understood the process. But there's a difference between overseeing work and doing it eight hours a day, handling the exceptions that never reach a summary. 

She knew what the team did. She didn't know why they did it the way they did, because that knowledge lives with the operators.

That cost us two to three months of redesign. The technology was fine. We'd built with the wrong person's version of reality.

I think of it as the Four-Person Rule. 

There are usually four people who matter on a project: the sponsor who funds it, the champion who advocates for it, the operator who actually does the work, and you. 

Each matters at a different moment. The champion is invaluable in pre-sales and for keeping everyone aligned. During the build, the operator is the one you need sitting beside you, and they're almost never the one raising their hand.

Before you schedule your first working session, ask: Do you know which of these four people actually runs the process day to day? If not, that's your first task. 

Not the scoping document, not the architecture diagram. Finding that person.

If you've run implementations for a while, this sounds obvious. 

Of course, the end user matters. 

But knowing that and resisting the pull of the eager stakeholder are two different things. 

The champion is available and easy to work with. The operator is busy, sometimes wary of why you're really there, occasionally worried you've come to automate them out of a job. 

The trap isn't that people forget operators matter. It's that everything about a project's momentum pushes you towards the person who is easiest to spend time with.

What works is almost embarrassingly simple to describe and surprisingly hard to do. 

On a later project, sales order processing, we pushed from the first call to get operators in the room, before scoping was finished and before the deal had even closed. 

We mapped the real process with the people who ran it, and we let nothing from the sales conversations carry over unchecked. It shipped in six weeks. 

We didn't build any faster than usual. We just knew who to sit with from the start, which meant we built the right thing once instead of the wrong thing twice.

The Brilliant Intern Test: Do you actually understand the process?

The second pattern is quieter, and it's the one that most often separates a four-week project from a four-month one.

When a client describes their process, they compress it into a sentence. 

"We process sales orders and enter them into the ERP." 

What that sentence hides is everything that matters. 

Which fields get populated? 

Where does each piece of data come from? 

What happens when a customer asks for a delivery date you can't meet? 

How do you decide which warehouse fulfills the order? 

The several different packaging methods and the rules for choosing each.

The person describing the work usually can't tell you any of that, because they don't do it. And the person who does do it often can't tell you either, for a strange reason. 

They've done it ten thousand times, and the decisions have gone invisible to them. 

Ask them to narrate each step, and they stall, because the knowledge has become muscle memory rather than something they can consciously retrieve.

The framing I use to get at it is to imagine you've just hired an intern with a PhD-level education in nearly everything. 

Brilliant, fast, forgets nothing, and has never worked a single day or heard of your company. You wouldn't hand that person a stack of orders and say, "Process these." 

You'd explain why certain customers get priority, how to handle the supplier who always sends things in a broken format, and which product codes look alike but mean entirely different things. 

That walkthrough is the operational logic. It's what any system needs before it can do the work, automated or not, and it almost never exists in writing.

I call it the Brilliant Intern Test. 

Before you build anything, ask: could you hand this process to someone brilliant who knows nothing about your company and has never done a day of the work? If the answer is no, and it almost always is, you haven't mapped the process yet. 

Building on top of it means building on a guess, and the guess is what you'll spend the back half of the project unwinding.

The reason clients underestimate this is that the work looks simple. Watch someone process orders, and it seems effortless. 

The simplicity is an illusion created by expertise. Pulling the knowledge back out is slow, and it takes several passes as forgotten details surface. Skip it, and you don't save the time. You move the discovery to after you've built the wrong thing, which is the most expensive place to do it.

The Narrow Slice Rule: what the first two weeks are actually for

The third pattern is about the opening phase, and it's where the first two either get caught or get baked in.

When an engagement starts, there's pressure to show something working quickly. That pressure is healthy. But it pushes people to treat the early weeks as a build problem, and they aren't. 

They're an organisational one. You're learning how a business actually works, finding the people who hold the real knowledge, surfacing dependencies you don't control, and earning enough trust that operators will be honest with you about their workarounds.

There are two ways to get this wrong. The first is to skip it, jump straight to building, and discover the real workflow only when the thing you built gets rejected. 

The second is the opposite: to disappear into discovery for so long that the client starts wondering what they're paying for, and momentum dies before anything ships.

The discipline that resolves it is what I think of as the Narrow Slice Rule. 

Get one real, working piece of the process live inside the first two weeks. Not a polished demo, something that handles actual work. Then use it as the anchor for every conversation that follows. 

A live slice forces the right people to respond to something concrete rather than describe the work in the abstract. People who cannot tell you how their process works will happily tell you why your version of it is wrong, and that reaction is worth more than any requirements document.

Every shortcut in those early weeks comes back later, as a feature gap or a blocker at the worst possible moment. The technical part is rarely what decides things. The organisational part almost always is.

What the repetition tells you

None of these three is unique to AI, and none is unique to my corner of the work. A forward-deployed engineer feels them sharply because the pace is fast and the stakes are visible, but anyone who has implemented complex software inside an organisation has met all three. That is rather the point.

When you only work with one client at a time, it's easy to file each of these under that client's dysfunction. This company had a difficult champion. That one had undocumented processes. The other moved too slowly to get started. 

When you watch the same failures recur across companies that have nothing in common, the explanation changes. They aren't accidents of a particular client. They're the actual shape of the work.

None of this means the engineering doesn't matter. It does, and people who are weak at it don't last in the role. 

You have to be able to build the thing, debug it under pressure, make sensible architectural choices, and know when a simple script beats a model. That competence is the price of entry. It just isn't what separates a project that works from one that doesn't. 

Two engineers of equal skill will get very different results, and the difference is almost never in the code. It's in who they chose to build with, and how well they understood the work before they wrote any of it.

And if that's true, it should change how we think about the role. 

When I consider what I'd want in a new colleague, most of the list is things no interview process tests for: getting a wary operator to show you the workaround they're not supposed to use, noticing when an answer describes the process as designed rather than as run, judging when to stop asking questions, and shipping a narrow slice. 

We screen hard for the code and leave the rest to chance. 

So the question I keep returning to is this. If the engineering is the table stakes and the organisational work is what actually decides the outcome, and if building keeps getting easier while the human part stays exactly as hard as it has always been, why do we still hire and train for this role as though the code were the difficult part?