Role guide
What is a Forward Deployed Engineer?
A Forward Deployed Engineer works with customers to understand a problem, ship software in their environment, and help their team run it. The role combines engineering, discovery, and ownership of a customer outcome.
What the job actually looks like
A forward deployed engineer works with customers to understand a problem, build and integrate a solution, and help people use it successfully. They also bring findings from customer work back to the product team. The balance of these responsibilities varies by employer.
- Understand the customer's work. Watch the task happen, trace a real example, and find out where it actually breaks. The written brief usually describes a symptom rather than the cause.
- Build and integrate software. Write code against their data, their systems, their authentication and their release process, and get it running somewhere they can see it.
- Help people use it successfully. Test it with the people who will operate it, fix what trips them up, write the runbook, and confirm someone has agreed to keep it running.
- Bring findings back to the product team. When something you hit at one customer looks like a product gap, send a reproducible example with what you observed and what remains uncertain.
Day to day the work alternates between two modes. In client mode you are in rooms asking the question the brief avoided, learning who can say yes and who can quietly block. In build mode you are in an unfamiliar codebase with unfamiliar data, shipping a change that runs end to end.
The hardest part is neither. It is continuity: holding weeks of context, decisions, constraints, and promises across an ambiguous engagement, and being able to defend all of it when a VP asks why on week six.
A real week, day by day
This is an illustrative sequence, not a fixed timetable. Engagements differ, but this is a shape many FDEs converge on:
| Day | Focus | What has to exist by end of day |
|---|---|---|
| Mon | Kickoff and sponsor alignment | One sentence naming the outcome and the person who accepts it |
| Tue | System and data access | Credentials, a schema map, and the list of what you were not given |
| Wed | User interviews | The workaround people built to survive the current process |
| Thu | First working build | A running end-to-end path on real data, ugly but true |
| Fri | Demo and scope reset | A revised plan the sponsor argued with and then agreed to |
By Friday, show what you learned, what you tested and what happens next. Build a working example when access and scope allow.
Responsibilities depend on the team
Titles alone do not establish the job. Ask what you will build, how much time you will spend with customers, and who operates the result after release.
Engineering responsibility
Understand which code, integrations and production checks you own, and who reviews the work.
Customer responsibility
Establish who agrees scope, approves changes and accepts the outcome. Access to a sponsor is not authority over every decision.
FDE and adjacent roles
These roles can overlap. Compare the actual responsibilities rather than treating the title as a boundary.
| Role | Work to ask about |
|---|---|
| Forward deployed engineer | Customer discovery, implementation, integration and operation of the result. |
| Product engineer | Shared product capabilities, technical quality and user outcomes. |
| Solutions engineer | Technical discovery, demonstrations, evaluation and the handoff to delivery. |
| Consultant | The agreed advisory or implementation scope and responsibility for the result. |
| Support engineer | Diagnosis, recovery and preventing recurring customer problems. |
How the work connects
These activities connect across an engagement. A new project may start with discovery; an inherited system may begin with an audit or a production problem.
Establish context
Agree the problem, permitted scope, people involved and how progress will be assessed.
Investigate the work
Compare the request with real workflows, data and constraints.
Plan a change
Choose a bounded approach, its dependencies and observable checks.
Deliver and verify
Implement, test and release within authority, with recovery appropriate to the risk.
Measure and learn
Keep expected benefits, observed results and actual acceptance distinct.
Transfer responsibility
Confirm who will operate the result and what they can do without the departing engineer.
FDEOps provides task instructions for these activities. See how the skills work together.
What separates good from great
Engineering, judgment and continuity
The failure mode of the role is not bad code. It is a rebuilt context. Week six arrives, the sponsor changes, the original constraint is forgotten, and the team relitigates a decision that was already made and already right. Every hour spent re-deriving is an hour not spent shipping.
Three habits that compound
- Write the decision, not the meeting. Who decided, what was chosen, what was rejected, and why.
- Track the promise separately from the plan. Plans change. Promises are what you get judged on.
- Name the risk out loud before it lands. A risk you flagged is a shared problem. A risk you hid is your fault.
That discipline is exactly what FDEOps gives an AI coding agent: one engagement folder, a structured fieldbook, and skills that propose judgment updates for review. The Claude Code plugin can also capture mechanical session state through enabled hooks.
Who should and should not do this
- You get energy from unfamiliar domains and unfamiliar people.
- You would rather ship something imperfect and true than perfect and late.
- You can be the calmest person in the room when the demo breaks.
- You want ownership years before a product org would give it to you.
- You want to own and refine one system for years.
- Ambiguity without a spec drains rather than energises you.
- You dislike being the person who says no to a stakeholder.
- 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?
It can include both engineering delivery and advisory work. Check how much hands-on implementation the specific role requires and who owns the software after launch.
Which companies hire Forward Deployed Engineers?
Look at software vendors whose customers need integration, adaptation or operational support. Search related titles as well, and confirm current openings on employer careers pages. Finding roles explains what to compare.
How much travel does an FDE do?
There is no single schedule. Ask the specific team about customer visits, office presence, trip duration and how travel expectations change during an engagement.
Is it a good career move?
Consider whether the role offers the engineering work, customer contact, learning support and operating responsibility you want. Evaluate the actual position against your goals.
Use FDEOps with your coding agent
FDEOps provides reusable instructions for tasks such as discovery, implementation, review and handoff. Use a task on its own, or use the fde coordinator for an ongoing engagement with a local customer record. You remain responsible for decisions, permissions and the evidence behind your claims.