What a Forward Deployed Engineer Actually Does — and Why It's a Client-Facing Job

The title says engineer, and the job ads read like engineering: full-stack, production-grade, containers, pipelines, LLMs, real testing, real deployment. All of that is true, and the bar is real. But if you take a Forward Deployed Engineer role believing the job is the code, you will fail at it — probably within the first month — because the load-bearing skill is something else entirely. It is requirements-gathering, done live, in the customer's room, under time pressure, with the authority to change the product. The code is how you close the conversation. The conversation is the job.

I have spent more than fifteen years in product and technology, mostly in UK regulated fintech, and for much of that time I sat on the other side of this table: the customer side, watching vendors send engineers in to make their product work inside our particular mess. The ones who succeeded were not reliably the strongest programmers. They were the ones who could sit with an operations team, work out what we actually needed — which was rarely what we had asked for — and have something small working in our environment by the end of the week. That is the whole job, compressed into a sentence. Here is the longer version.

What the day actually looks like

The morning is spent in the customer's world. Not a discovery workshop with slides — next to the person who does the work, watching them do it. The requirements document said "integrate with the case management system". Sitting beside the case handler, you learn there are three systems, that one of them is a spreadsheet with a name everyone pretends not to be embarrassed by, and that the step everyone complains about is not the one the project sponsor thinks it is. None of this was in the document. None of it would ever have reached you through an account manager. You get it because you are in the room, and because you ask the kind of questions that only occur to someone who will personally have to build the answer.

The afternoon is engineering, and it is unglamorous in a specific way: you are building in their environment, not yours. Their identity provider, their network rules, their data with all of its historical horror. The skill is not architectural brilliance; it is shipping a thin, correct slice through hostile terrain without breaking anything that was already working.

By Friday, something runs. Small, real, demonstrable to the person who signed for the product. Not a prototype — a piece of the actual solution, doing an actual job. The following week repeats the loop, informed by what the slice taught everyone, including the customer, about what they really wanted.

And underneath all of it runs the channel that gives the role its name. Forward deployed means you are the product organisation's sensor in the field. What you learn in that room — the missing feature, the wrong assumption, the workflow nobody at head office imagined — flows back and changes the core product. You are not just delivering the product to the customer. You are delivering the customer to the product.

Why the room is the job

Three pressures make the client-facing half load-bearing rather than incidental.

The first is time. An FDE engagement has a clock on it. Someone senior at the customer spent political capital buying this product, and they need proof it was the right call — visible proof, soon. You do not get a quarter to gather requirements properly. You get the meeting you are in, and the requirements you extract from it are the requirements you build against.

The second is authority. This is what separates the seat from every adjacent one: you can change the product. That sounds like a perk, and it is — it is also why the requirements work carries so much weight. A support engineer who misunderstands a customer wastes a ticket. An FDE who misunderstands a customer can push that misunderstanding into the core product, where every future customer inherits it. The privilege of changing the product is exactly what makes getting the requirement right expensive to fumble.

The third is that nobody else is going to do it for you. There is no business analyst producing a specification, no product manager translating. You are the translation layer. Engineers who treat the customer conversation as the interruption between them and the real work fail here in a characteristic way: they build precisely what was asked for, build it well, and watch it not matter — because what was asked for was a guess, and they were in the room where the guess could have been corrected, with their camera off, waiting to get back to the code.

FDE, solutions engineer, sales engineer, Field CTO

The adjacent titles get tangled together, and the differences are worth being precise about, because they decide what your week contains.

A sales engineer works before the deal closes. The job is to prove the product could work: demos, proofs of concept, technical answers to procurement questions. It is a real technical craft, but it is measured on deals influenced, and it ships nothing into production. When the contract is signed, the sales engineer moves to the next prospect.

A solutions engineer — or solutions architect, or implementation engineer — works after the deal, inside the product's existing surface. Configure, integrate, glue. When the customer needs something the product cannot do, the solutions engineer files the gap, manages expectations, and works around it. The product itself is someone else's to change.

A Field CTO is a vendor's most senior technical voice in front of customer executives. It is a talking seat — deeply technical in conversation, almost never hands-on, with its lineage in pre-sales. Nothing gets built.

The Forward Deployed Engineer is defined by answering yes to two questions the others each half-answer. Do you personally ship production code? The sales engineer and Field CTO do not. Can you change the core product? The solutions engineer cannot. The FDE does both — embedded after the sale, writing real software into the customer's environment, with a live channel back into what the product becomes. That combination is the job, and it is also the test to hold any job ad against.

What makes someone good at it

Listening, first — and I mean the specific skill of hearing the process someone actually runs rather than the one they describe. People narrate their work as it appears in the operating manual. The FDE's questions have to reach the version with the workarounds in it, because that is the version the software has to survive.

Scoping, second. The customer's want-list is always longer than the engagement. The craft is finding the thinnest slice that proves real value — and having the discipline to leave the rest for later, out loud, in writing, so nobody believes it was promised.

Saying no, third, and this is the one engineers underestimate. Customers will ask for things that would fork the product into a bespoke build only they can use. The good FDE declines — warmly, with reasons, offering the version of the request that generalises. Saying no while keeping the room on your side is a craft, and it is the difference between a product company and a body shop.

Then shipping something small that works by Friday. This is not a productivity habit; it is how the whole engagement stays alive. Momentum earns trust, trust earns access, access earns better requirements, and better requirements make the next slice land harder. The flywheel starts with the small thing working, which is why the instinct to go quiet for three weeks and return with something impressive is exactly wrong.

The engineering itself still matters — boring, reliable, tested code, produced fast, and these days accelerated hard by AI coding tools. But notice what that acceleration does to the shape of the role: generating code has become cheap, and knowing what to build has not. The tools will type with you. They will not sit in the meeting for you.

What the interview loop should test — and usually doesn't

Most FDE loops test the half of the job that was already easy to test: algorithms, system design, perhaps a take-home. All of it measures whether the candidate can build. Almost none of it measures whether they will build the right thing, which is where the role actually lives. A loop that took the job seriously would look different.

It would include a discovery exercise: an interviewer playing a stakeholder with a vague problem and a confident, wrong self-diagnosis, and a candidate whose task is to leave the conversation knowing what is actually needed. It would include a scoping exercise: here is everything the customer asked for — what ships by Friday, what do you refuse outright, and defend both. It would include an explanation test: take a real trade-off you made and explain it to a non-technical operator without jargon and without condescension. It would ask for evidence of end-to-end shipped production software — whole systems with deployment scars, not components. And it would ask the question that predicts more than any other: tell me about a time the customer insisted on something that would have hurt them. What did you do?

One more, rarely asked: request a writing sample. The follow-up email that confirms what was agreed, what is in scope and what is explicitly not — that email is a deliverable of this job, and a candidate who cannot write it precisely will spend the engagement relitigating scope.

A loop that is coding puzzles all the way down tells you something useful too: the company has not understood the role it is hiring for, and you will likely be measured on the wrong things once inside.

A real FDE role, or a support engineer in a fashionable title

The title is fashionable, which means it is being applied to jobs it does not describe. The body of the ad always tells you; the title never does. Hold it against these questions.

What do you ship — production software, or configurations and escalation responses? Where does what you learn go — into the core product through a real channel, or into a knowledge base? Who owns you — the engineering and product organisation, or the support organisation with its queue and its response-time targets? Who do you face — named customers with outcomes attached, or a rotation of tickets? What does week one look like — in the customer's building working out what to build, or in a tooling suite learning the triage workflow?

An ad that says "understand the customer's problem, determine what needs to be built, take responsibility for delivering a working solution" is describing the real job. An ad whose responsibilities are escalation handling and workaround delivery is describing support engineering — honest, necessary work, but a different job with a different ceiling, and you should price the title inflation accordingly.

The part the title hides

If you are an engineer who resents meetings, this is the wrong seat, and there is no shame in that — the industry is full of seats where the code is the whole job. But if you are the engineer who keeps ending up in the room anyway — the one who finds out what is actually wrong by asking, and then closes it personally in working software — this is one of the best seats currently on offer. Just walk in knowing what the title obscures. The client-facing part is not the tax you pay to do the engineering. It is the job. The engineering is how you do it.