Role guide
What is a Forward Deployed Engineer?
A Forward Deployed Engineer finds a customer's real problem, ships software in their environment, and leaves their team able to run it.
What the job actually looks like
The balance of the work varies by employer. The loop below does not.
01
Understand the customer
Watch the real task. The brief usually names a symptom, not the cause.
02
Build and adapt
Ship against their data, systems and release process, where they can see it.
03
Help people use it
Test with the people who will run it. Check weeks later that they still do.
04
Carry the learning forward
When one customer hits a product gap, send the product team an example they can repeat.
See how FDEOps maps a skill to each stage →
Client mode
in the room
Ask the question the brief avoided. Learn who can say yes and who can quietly block.
Build mode
in the codebase
Work in unfamiliar code with unfamiliar data, and ship a change that runs end to end.
The hardest part is neither. It is continuity.
Holding weeks of context, decisions, constraints and promises, and being able to defend all of it when a VP asks why in week six.
Why the role exists
Demos run on clean data. Customers run on real systems, real data and real people.
Works in a demo
clean data, one happy path
People rely on it
their data, their team, every day
what closes it
An outcome with a number
Turnaround, error rate or hours of manual work, measured before and after.
The people who do the work
Not only the sponsor. The people whose day changes are in the room.
Real systems and data
A sandbox with sample data proves the demo, not the job.
A way to check progress
A fixed set of real cases, scored every week against an agreed pass mark.
then, in this order
- 1Prove it on real work
- 2Make it reliable
- 3Make it repeatable
One engagement, start to finish
Twelve weeks, one fictional engagement. Each beat shows the line it left in the record.
- Week 1
Kickoff: the brief names a solution
- Brief
- Add monitoring to the payment reconciliation service.
- Question
- What changes the week after a perfect delivery? “I stop hearing about it from finance.”
- Found
- Alerting was built last year and switched off. Its builder was not in the kickoff.
- Hypothesis
- The job is not unmonitored. It is unowned.
success.md > reconciliation failures reach a named owner within 15 min (baseline: 4h, found by finance)
- Next
Discovery and plan: three tasks, not eight
- Baseline
- Finance finds failures after about four hours. One person’s spreadsheet is the real fallback.
- Task 1
- A failure reaches a named person within 15 minutes, tested in an approved staging drill.
- Deferred
- The service rewrite. The failure is ownership, not architecture; the sponsor agreed and it is recorded.
decisions.md > service rewrite: deferred, the failure mode is ownership not architecture (Priya accepted, Jun 12)
- Week 3
Report: bad news first
- Measured
- Detection in 12 minutes across two real incidents, against the four-hour baseline.
- Problem
- One alert was acknowledged 40 minutes late. The rota had one name, and that person was on leave.
- Ask
- A second name on the rota by Wednesday.
value ledger > promised 4h → 15min / measured 12min over 2 incidents / accepted by - → claimed, unaccepted
- Week 12
Close: claimed, not green
- Status
- The result is measured, but the agreed acceptance owner has not accepted it, so it closes as claimed.
- Handoff
- Written for whoever is paged at 2am: failures seen, how to recover, who knows the old job.
patterns.md > "unowned job" presents as "unmonitored job" (it has now happened twice)
How AI is changing the role
Same job. Different tools, and a different thing to hand over.
| Shift | Before | Now |
|---|---|---|
| Writing code | You typed most of it. | Agents write much of it. Your leverage is the spec, the constraints, the checks and the review. |
| What you deliver | Configured software and integrations. | Often an AI system. It needs the customer's data, tests of how it behaves, limits on what it can do, and a fallback. |
| Choosing the tool | The platform you were hired to deploy. | The simplest thing that works. A rule or a query can beat an agent; a request for AI is not proof. |
| Proving it works | A demo on clean data. | A scored test on real cases, hard exceptions included, run before and after every change. |
| When you are done | It runs in production. | People use it and do not drift back to the old way, and their team can extend it without you. |
FDE and adjacent roles
| Role | Work to ask about |
|---|---|
| Forward deployed engineer | Customer discovery, implementation, integration and operation of the result. |
| Product engineer | Capabilities shared by many customers. Rarely owns one customer's outcome. |
| Solutions engineer | Technical discovery, demonstrations, evaluation and the handoff to delivery. |
| Consultant | Traditionally a recommendation or plan. The line is blurring: ask whether you leave working software behind and own the result. |
| Support engineer | Diagnosis, recovery and preventing recurring customer problems. |
What separates good from great
Engagements rarely fail on bad code. They fail on lost context.
- The sponsor changes
- A constraint is forgotten
- A settled decision is reopened
Write the decision, not the meeting
Who decided, what was chosen, what was rejected, and why.
Track the promise apart from the plan
Plans change. Promises are what you are judged on.
Name the risk before it lands
A risk you flagged is shared. A risk you hid is yours.
Make the second time faster
If the next engagement like this takes as long, nothing was carried forward.
FDEOps keeps this record for your AI coding agent.
Who should and should not do this
You will enjoy it if
- Unfamiliar domains and people give you energy.
- You would rather ship something imperfect and true than perfect and late.
- You stay calm when the demo breaks.
- You will ask the basic question in a room full of experts.
- You enjoy explaining what you built as much as building it.
Think twice if
- You want to own and refine one system for years.
- Ambiguity without a spec drains you.
- Unpredictable weeks and occasional travel are a dealbreaker.
FAQ
What does a Forward Deployed Engineer do?
Works with customers to understand needs, build or integrate software, and help people use and operate the result. The balance of these responsibilities varies by team.
Is it an engineering role or a consulting role?
Engineering. You may advise, but you also build, ship and stay until it works. If a role ends at a recommendation, it is consulting under another title.
Which companies hire Forward Deployed Engineers?
Software vendors whose customers need integration and support, and services firms that deliver it. Search related titles too. Finding roles explains what to compare.
How much travel does an FDE do?
It varies by team. Ask about customer visits, office days and trip length before you accept.
Does AI make the FDE role less necessary?
It moves the work. When a better model makes your custom build unnecessary, take the harder problem. Someone still connects AI to real data and gets people to use it.
Is it a good career move?
If you want to see your work used by real people within weeks, and you learn fast in unfamiliar domains, yes. If you want to refine one system for years, probably not.
Use FDEOps with your coding agent
A method for each stage, from discovery to handoff, and a local record of every engagement. Use one task on its own or run a whole engagement. The decisions stay yours.