What a forward deployed engineer does, stage by stage
A deployment runs through five stages, and they are consistent even when the industry is not. First, translating the problem: what the customer described and what is actually wrong are rarely the same thing, and finding the difference is the first week’s work rather than a preliminary to it. Second, getting at the data, which reliably consumes more of the calendar than anything else and appears in none of the marketing. Third, building, which is genuine engineering against one organisation’s constraints. Fourth, adoption, which decides whether any of the previous three counted, because a correct system that nobody uses has failed. Fifth, handing back what was learned to the product team, which is the reason a product company pays for this role rather than outsourcing the work. Most failed deployments failed at stage two or stage four, almost never at stage three.
Stage one: translating the problem
The customer has described something. It arrived through a sales process, so it has been simplified at least twice, and it is phrased in their vocabulary, which uses ordinary words to mean specific things. "Customer" may mean four different entities in four systems. "Approved" may describe a state that exists in a spreadsheet and nowhere else.
The work here is not requirements gathering in the traditional sense, because the people who know are usually not in the meeting. The technique that works is to ask someone to show you the last five times they did the thing, rather than to describe how they do it. Descriptions are idealised. The five examples contain the exceptions, and the exceptions are the project.
This stage ends when you can state the problem in a sentence the customer recognises and that also contains something they had not said out loud. If you cannot, you have not finished, and moving on anyway is the most expensive mistake available in this job.
Stage two: getting at the data
This is where deployments die, and the causes are almost never technical. The data lives in systems owned by teams who were not part of the purchase decision and have no obligation to help. Access requires a credential that requires an approval that requires a security review that has a queue. The person who understands the schema left in 2023.
An engineer who treats this as an obstruction to be routed around will fail. It is the job. The specific skill being exercised is finding the one person in the organisation who actually knows where things are, which is frequently someone quite junior with no formal authority, and making it worth their while to help you. That is not a technical skill and it cannot be delegated to the account manager.
The measurable output of this stage is unglamorous: a working read path to real data, a written account of what the fields actually contain as opposed to what they are named, and a list of the known lies in the dataset. That last artefact is worth more than it sounds. Every organisation has fields that are systematically wrong in a predictable way, and the people who correct for them mentally have never written it down.
Stage three: building
This is the stage that looks like software engineering, and it is. Connectors, retrieval, prompts and evaluation, error handling, and the specific discipline of making a system fail visibly rather than confidently in front of someone who does not trust it yet.
The unusual constraint is that generality is not a virtue here. Code that solves this customer’s problem and no one else’s is the correct output, provided the engineer knows that is what they are writing. The failure mode is an engineer with strong product instincts building the general version, which takes three times as long and is worse at the specific case.
The evaluation set built during this stage is the political instrument of the whole project. Its cases come from the customer’s files and its labels from the customer’s experts, and the arguments about what belongs in it surface the disagreements inside the organisation that would otherwise emerge three months later as a claim that the system does not work.
Stage four: adoption
A system that is correct and unused has failed, and this is the stage most engineers are least prepared for. The people whose work changes did not ask for this, may be measured on the old way of working, and have no reason to cooperate beyond politeness.
What works is sitting with them and watching them not use it. Not a training session, not a demo: watching. The reasons people abandon a working system are rarely what they say when asked. It is three clicks too deep. It does not show the one number they are accountable for. It was wrong once, in front of their manager, and they have not trusted it since.
The other half of this stage is finding the person who wants it to work and giving them the credit. Every organisation has someone who has been arguing for this change for two years. A deployment that makes them look right propagates on its own. A deployment that makes the vendor look clever stops the day the vendor leaves.
Stage five: handing back what you learned
The stage that gets skipped, and the reason the role exists as an employee rather than a contractor. The engineer has just seen, first-hand, which parts of the product do not survive contact with a real organisation. Nobody else in the company has that.
Doing it properly means something more specific than a retrospective. It means naming the two or three product changes that would have removed the most work from this deployment, with the evidence, and making sure they reach people who can act on them. Engineers who do this consistently become disproportionately influential inside their own company, because they are the only source of a kind of information product teams cannot otherwise buy.
The parts that are in no job description
Three things occupy real time and appear in no posting. Waiting, which is structural rather than a sign of poor planning: approvals and access requests have their own clock. Repeating yourself, because the person who needs to understand the system in month four was not in the room in month one, and resenting this is pointless. And deciding what not to build, which is the most valuable judgement in the job and the hardest to demonstrate, because the evidence is a project that finished on time rather than an artefact anyone can point at.
