“Forward deployed engineer” is a job title that has started appearing in places where companies buy software. It sounds like jargon, and half of it is: “forward deployed” is borrowed from the military, where it means stationed close to where the work happens rather than back at headquarters. Strip the borrowed half away and what is left is simple. A forward deployed engineer is a senior engineer who works inside your company, on your problem, instead of at arm's length from it.
The distinction matters more than it sounds. Most technical work you buy arrives in one of two shapes. Either you buy a document, where somebody studies your business and hands back a recommendation, or you buy a project, where somebody takes a written specification away and returns with software built to it. Both shapes assume that the hard part is doing the work, and that the question was already clear before anyone started. In a lot of AI work, that assumption is simply wrong. The hard part is finding out what the system actually has to handle, and you find that out by running something against last month's real cases, not by writing a longer specification.
The forward deployed model is the answer to that. Instead of receiving a specification, the engineer sits where the work is done, watches one full cycle of it, agrees on a single outcome with somebody who can say yes, and then builds towards it, changing course as the real cases teach them what they missed. They are accountable for the result rather than for a list of tickets. When it works, the difference a client notices is not the technology. It is that nobody is waiting for anybody else to write something down.
Where the title came from
The title was popularised by Palantir, an American software company that has used it publicly on its own careers pages for years, for engineers sent to work on site with customers rather than building a product at a distance from them. The pattern spread. AI labs and enterprise software companies now publicly advertise roles under this title or a close variant, because what they sell has to be shaped around each customer's data and process before it is worth anything.
There is an honest reason the model exists. General purpose systems solve the general part of a problem and then stop. The value left over is locked inside one company's own mess: the exceptions, the local rules, the spreadsheet somebody maintains by hand, the three systems that describe the same customer differently. No amount of product work at a distance unlocks that. The only way in is to send somebody into the mess.
What the person actually does
The first two months look much the same wherever the model works. Week one is spent watching the work being done and getting access to the systems it touches, and it ends with one page saying what the outcome is and how it will be measured. A good forward deployed engineer spends more of that week asking questions than writing code, and that is not a delay: it decides whether the rest of the work is aimed at anything.
- Week one: watch one full cycle of the work, get access, and agree one page on the outcome and the measure.
- Week two: something narrow runs on the real data, in front of the people whose job it changes.
- After that: the errors it makes are the specification for the rest of the work.
- Around month two: in production, with a human override, documented so the team can run it alone.
How it is different from the things you already buy
A consultancy leaves a document. That is the right purchase when the decision is the bottleneck. It is the wrong purchase when everybody already agrees what should happen and nothing is happening. A forward deployed engineer leaves a running system instead, which is worth less than a document if the decision was the hard part, and a great deal more if it was not.
Contractors and staff augmentation sell capacity. Somebody on your side writes the tickets and carries the risk of asking for the wrong thing, and the supplier is judged on whether the tickets closed. A forward deployed engineer is judged on whether the process got faster or cheaper, and helps decide what gets built.
A fixed scope project needs the answer to be knowable before the work starts. When it is, take the fixed scope: it is cheaper and the risk of a wrong estimate sits with the supplier. When it is not, a fixed price is either padded to cover the unknown, which makes it expensive, or held to the letter, which delivers what was written and nothing anybody needed.
When it is the right choice
- You can name the process that costs the most hours but not the fix, and nobody in house could build it.
- Somebody delivered a strategy document about your AI opportunities and nothing has run since.
- Hiring would take months, and it is not yet clear the work justifies a permanent role.
- The exceptions in your process are the hard part, so any scope written today would be a guess.
All four have the same shape: the question is still open. Where the question is open, buying an outcome beats buying a plan or a pair of hands.
When it is not
- You already know exactly what to build. Buy the build: it is cheaper and the risk sits with the supplier.
- Nobody on your side can decide inside a week. The model runs on a fast yes or no, and without one the engineer stalls while you pay for the stall.
- Access to your data and systems will take three months of approvals. The clock starts anyway.
- What you need is more hands on a backlog that already exists. That is staff augmentation, a different and cheaper product.
A supplier who never tells you that one of those applies is selling you something. The question is not whether they do forward deployed engineering. It is what they would talk you out of.
What to ask before you agree to one
- Who exactly is being embedded, and can I speak to that person before signing anything?
- What will be written down at the end of week one, and how will the outcome be measured?
- What will be running on real production data at the end of week two?
- Where does the code live, and who owns it if the engagement ends early?
- What is the notice period, and is there an exit fee?
At Pluscode we work this way because it is the only way we have found to get a result out of the messy, specific, half documented processes that real companies run on. If you can name the job that costs your team the most hours, we will spend thirty minutes on it with the engineer who would do the work, and tell you honestly whether this is the right way to do it or whether something smaller and cheaper would be enough. That conversation costs nothing and does not commit you to anything.