How a forward deployed engineer works: an engagement, step by step

Day one: sitting next to the people who do the work

A forward deployed engagement does not start with a framing workshop. It starts next to someone doing their job. The engineer arrives, sits down, and watches. He does not ask how the process is supposed to run. He watches how it runs on an ordinary Tuesday, with the interruptions, the exceptions and the workarounds nobody ever wrote down.

Day one has one rule: the engineer proposes nothing. Questions are there to understand, not to place an idea. Why is that file permanently open. Why is that column typed by hand when the value exists elsewhere. Who calls whom when a case is stuck. What the person does when the application has no answer for the case in front of her.

The reason is practical. A process described in an internal note is an intention. The real work is a chain of small actions, many of which exist because the note does not hold. That is where the time goes, and what can be tooled. Software built from the note cannot handle the cases that fill half the day.

On the client side, day one asks for one thing: that someone agrees to be observed without feeling audited. The engineer is not assessing people, he is trying to understand the work. Said by the manager in front of the team, it makes everything after easier.

Mapping: the actions, the tools, what gets retyped

From those observations, the engineer builds a map. Not an architecture diagram: a map of the work, readable by a business manager, answering four questions.

• Which actions make up the day: opening a message, pulling an attachment, checking an amount, chasing a supplier, producing a summary.
• Which tools carry them: the ERP, the mailbox, one or several spreadsheets, a shared folder, sometimes a notebook.
• What gets retyped from one place to another. The strongest signal on the map: every copy proves two systems do not talk to each other, and opens a place where an error enters unseen.
• Where the work waits: an approval, a reply, a monthly export, one person on holiday who is the only one who knows how.

The map gets corrected by showing it. The engineer reads it back with the users, line by line. Almost always, someone says "we stopped doing that" or "you are missing the Friday step". A map validated by the people doing the work is something you can decide on. Produced alone, it is an opinion.

The map also surfaces the real state of the data: free text where a list is needed, duplicates, identifiers that do not match across systems. Stated now, not at go live, because it changes what is feasible. That work belongs as much to data and integration as to development.

Choosing the first piece of work, and saying what is left out

Mapping produces a list of irritants, always longer than one engagement can handle. The first piece of work is chosen on explicit criteria, stated in front of the client:

• Frequency. Something done daily by several people beats a heavy annual operation.
• Time spent. Not assumed time: time observed with the users.
• Error risk. A manual copy of an amount or a due date: the mistake stays invisible until the day it costs money.
• Reversibility. Start where you can step back without damage, not in the middle of invoicing.
• An owner exists. If nobody on the business side can say "yes, that is right" every week, start elsewhere.

The most important move is not choosing, it is excluding out loud. The engineer states what will not be handled, and why: too rare, data not ready, dependent on a project already running, gain too small for the complexity. That list is written and shared: it protects everyone when the question comes back.

The choice is phrased in terms of work, never technology. You do not decide "we are building an agent", you decide "matching documents must stop eating up the team's mornings". Whether that becomes an automation, an agent or a full application comes later, and can change along the way.

The first useful deliverable, in one or two pairs of hands

The first deliverable is not a demo. It is a tool that really does the work, on real data, in the hands of one or two volunteers. Deliberately narrow: it handles one case well, and says clearly when it cannot.

That is a design rule. A tool that answers plausibly when it lacks the information is more dangerous than one that stops. Anything that commits the company, a price, an availability, a reference, is computed server side from the source and checked before display. The model never invents it.

Choosing the volunteers matters as much as the code: people who do the action every day, experienced enough to spot an anomaly, blunt enough to say the tool slows them down. A polite user who will not criticise costs more time than a declared opponent. The manual path stays open throughout.

This deliverable is not in production yet. It runs on real data with real users, without being the department's mandatory path. The difference between this stage and production is covered in the prerequisites for moving to production.

The loop: real use, feedback, fixes, rollout

Then comes the part that makes the difference and shows up least on a plan. The engineer stays on site while the tool is used. He watches the cases that fall outside the frame, fixes them, comes back. A brief, regular session, a visible fix in between.

Three things come back, to be told apart:

• Defects. The tool is wrong or breaks on a case. Fixed immediately.
• Gaps. A real case is not covered. Add it now, add it later, or leave it manual. The client decides.
• Extension requests. "Since the tool does that, it could also...". Good sign, and the main danger of an engagement. They go on a list, not into the current work.

Rolling out to the team only happens after a period where the volunteers use the tool without complaining and without going back to the manual path. That signal beats an acceptance test. And the engineers do not train the team: the volunteers do, because they speak the language of the job and lived through the defects. This is where change management happens, far more than in a message from the top.

What the client decides, and when

A well run engagement does not ask the client to decide all the time. It asks for decisions at specific moments, with enough to choose on. Set from the start:

• After mapping: confirm the map describes the work, and pick the first piece.
• Before the first deliverable: accept the exact scope and the written list of what is excluded.
• At rollout: decide to go beyond the volunteers, and what happens to the manual path.
• At go live: accept that the tool becomes the official path, with the support and responsibility attached.
• At handover: name the internal owner, and decide what comes next, stop, maintenance or more work.

Between those points, the engineer moves without escalating every small trade off. The client decides what commits the company, not the colour of a button. This model is described on the FDE as a service page.

What the client has to put in

Let us be blunt: this model asks for work on the client side. An engagement where the company just waits for a deliverable does not work. Three commitments.

Team time, not only meeting time

Users have to be observed while they work, then test, then say what is wrong. That time is real and it comes out of current production. The expensive part is the loop: someone must answer the engineer's questions the same day, not next week. A manager who protects that time beats a steering committee.

Access, opened early

Read access to the business system, real or anonymised data, somewhere to deploy, the necessary rights. Start this first: it depends least on us and blocks most often. Access granted weeks late is time spent waiting. Handle it with IT and compliance during framing: hosting, data location, traceability, retention. We work with hosting in France and data in Europe, which simplifies that discussion without replacing it.

A named person on the business side

Not a distant sponsor: someone who knows the work, is available every week, and is allowed to decide on scope. Their job is to say "yes, that is right", "no, that case does not exist", "keep that one manual". Without them, the engineer decides in their place, and decides badly. The most underestimated condition of all.

Measurement: take a reading before, take it again after

We do not promise a gain figure at the start: nobody knows what a tool that does not exist yet will produce, and a percentage announced in advance becomes a target to defend rather than something to observe.

What we do is record a starting state. During mapping, with the users, we note how many cases are handled over a period, the time they say they spend on them, the reworks, the delay between a request and its answer, and the moments where the work waits. These readings are self reported and imperfect. Their merit: they exist before the tool.

After go live, we take the same indicators, the same way. We also look at two signals no dashboard gives: how often users went back to the manual path, and which cases the tool refused. The second often points at the next piece of work.

This measurement supports decisions, not communication. It can conclude that the gain is real, small, or simply moved elsewhere. An honest engagement accepts all three. Running cost belongs in that assessment, as we explain about the cost of an agent in production.

Handover: what stays when the engineer leaves

An engagement is judged on what still works long after the engineer has gone. Handover is prepared during the work, not at the end. Four things must be in place.

• Short, useful documentation. What the tool does, what it does not do, where the data lives, how to restart it, who to call. Written for whoever takes the job later.
• A named, trained internal owner. They do not necessarily write code. They can explain the tool, spot an anomaly, talk to a supplier. They were part of the decisions, not shown the tool at handover.
• Access in the company's name. Accounts, code repositories, keys, hosting, domain names: all held by the client, checked in their presence. A tool whose access belongs to the supplier does not belong to the company.
• A fallback path. What happens if the tool stops. There is always one, and it is written down.

Handover gets tested: the internal owner performs a routine operation while the engineer is still around. If it gets stuck, the documentation is the problem, and someone can still fix it.

What makes an engagement fail

Failures look alike, and they show early.

• Scope creep. Every addition looks reasonable, and go live slips week after week. The cure is the exclusion list, read back every session.
• No owner on the business side. Questions go unanswered, the engineer decides alone, the tool drifts from the real work. When the owner is not named, pausing beats continuing.
• Access never granted. Work happens on fictional data, everything runs, and go live reveals reality looks nothing like the sample.
• A tool imposed without the users. Decided in committee, announced by memo, never tried by the people who will use it. They go back to the spreadsheet.
• Confusing a demo with a service. A demo that succeeds on a few chosen cases says nothing about a real flow, with its missing documents.
• Starting too big. Replacing the department's core system in one go gives a long, visible, fragile project. A narrow automation delivered without breakage builds the confidence the next one needs.

A last cause, less visible: a team that does not know what to do with the tool once delivered. Not solved by a training session at the end, but by involving users throughout and by steady work on bringing teams up to speed.

Going further

This sequence is the practical translation of a role described in the pillar page of this series, what a forward deployed engineer is. If you have a repetitive task in mind, start from a real case: that is what our diagnostic is for. It produces a map and a ranked list of candidate projects, whether you continue with us or not.

Frequently asked questions

Does the engineer have to be on site the whole time?

No, but physical presence matters most at the start, during observation and mapping, and again when users take hold of the tool. Between those periods the work runs perfectly well remotely, with short, regular sessions. What does not work is a fully remote engagement where the engineer never sees the real work.

Can we start if our data is in poor shape?

Yes, and it is common. The state of the data is part of what mapping reveals, and it drives the choice of the first piece of work: start where the data is clean enough to hold, not where a long remediation would be needed before anything ships. Trying to clean the whole estate first is the surest way never to start.

What happens if our priorities change mid engagement?

They often do, and short pieces of work exist for that reason. A change of priority is handled at a decision point: finish what is in progress and usable, then set the next choice. The problem is changing scope in the middle of a piece of work, because it produces a tool half finished in two directions.

Will our teams think this is about cutting jobs?

The question almost always comes up, and it is better answered before it circulates in the corridors. What we can speak to is what we do: we tool specific actions that the people concerned identified as painful, and they take part in the design. What the company does with the time freed up is a management decision, and it has to be announced by management, not by the supplier.

How do we know whether our case calls for an engagement or an off the shelf tool?

If the need is standard and the work can adapt to the tool, off the shelf software costs less and maintains itself. An engagement is justified when the work is specific to your organisation, when several systems have to talk to each other, or when the value lies precisely in the way you do things. The diagnostic is also there to settle that question, including by concluding that buying is the right answer.