“Forward Deployed Engineer” is a title people nod at and then quietly map to whatever role they already understand — consultant, solutions engineer, contractor. Those mappings are wrong in ways that matter on day one. This is how I draw the lines, and what the job actually reduces to.
FDE vs consultant vs solutions engineer
All three sit between a product and a customer. The difference is where the work stops.
- The consultant produces recommendations. The deliverable is judgement — a strategy, an assessment, a plan. Someone else builds it, and whether it works is, contractually, someone else’s problem.
- The solutions engineer makes an existing product fit a customer: demos, integrations, configuration, unblocking the sale. The product’s boundaries are mostly fixed; the work is landing it inside them.
- The forward deployed engineer ships working software inside the customer’s environment, against their real constraints, and owns whether it runs. When the product’s boundaries don’t fit the problem, I move the boundaries — write the missing piece — rather than route around them with a slide.
The short version: a consultant hands you a map, a solutions engineer fits you into the existing vehicle, and an FDE builds the vehicle on your road and drives the first mile with you.
TODO — add the two-axis diagram (owns-the-outcome × writes-the-code) placing all three roles, plus product engineer and platform engineer for contrast.
Owning outcomes, not deliverables
A deliverable is a thing you hand over: a document, a repo, a demo. An outcome is a change in the customer’s world: a process that’s faster, a decision that’s better, a cost that’s gone. It’s possible — common, even — to ship every deliverable and change nothing.
Owning the outcome changes what I do:
- I define done as “it’s in use and holding up,” not “it’s delivered and signed off.” Sign-off is a milestone, not the finish line.
- I instrument the thing so I can see whether it’s actually being used, and how it fails, without waiting for a status meeting to tell me.
- I treat the first weeks after go-live as part of the build, not warranty. That’s when the real inputs arrive and the real gaps show.
This is uncomfortable, because outcomes depend on things outside the code — adoption, politics, data that’s messier than promised. Owning the outcome means owning those too, or at least surfacing them early instead of hiding behind a green checkmark.
TODO — write up the deployment where every deliverable shipped on time and adoption was still near zero until we changed the workflow it plugged into.
Working inside the client’s constraints
The constraints are not obstacles to the interesting work. They are the work. If the problem could be solved without them, the customer wouldn’t need someone deployed forward to solve it.
The constraints I plan around from the first conversation:
- Data that can’t leave. Regulatory or contractual walls that rule out the convenient hosted path and force the architecture to come to the data.
- Users who won’t change. Established workflows, real switching costs, and people who have seen tools come and go. The tool adapts to them, not the reverse.
- Systems that predate the internet. Integrations against software older than some of the team, with no clean interface and no one left who wrote it.
- The audit. Someone will eventually ask why did it do that, and “the model decided” is not an answer that survives a regulator. Traceability is a requirement, not a feature.
Designing inside these is more interesting than designing without them. Anyone can draw the clean-slate architecture. The craft is the one that ships here.
TODO — add the legacy-integration pattern (read-only shim + reconciliation) I keep reaching for against systems with no API.
Shipping as the unit of trust
Trust on these engagements isn’t won in the kickoff or the strategy deck. It’s won the first time something I built is running in their environment, doing real work, and doesn’t fall over. Everything before that is a promise; shipping is the evidence.
So I optimise for getting something real into their hands early — narrow, unglamorous, but genuinely in use — and widen from there. A small thing in production teaches more, and earns more trust, than a large thing in a demo. Each shipped increment is a repayment on the trust I’m asking for to do the next, larger one.
The whole role compresses to this: be the person who turns “AI could probably help here” into something running in production that the customer would notice if you switched it off. Everything else is in service of that.
TODO — add the first-30-days playbook: how I pick the narrowest useful thing to ship first on a new deployment.