A forward deployed engineer (FDE) writes production code that lives inside someone else's company. That one fact shapes the whole week.
Your code runs on the client's data, behind the client's firewall, for people who never asked for a new tool. So most of your week goes to four jobs: understand the problem, get to the data, ship inside their systems, and prove it works.
Why it matters to you: if you are a backend or full-stack engineer at a services company, you already do half of this. The gap is ownership. An FDE answers for whether the thing works at the client, long after the ticket is closed.
What this post covers
- What an FDE is, where the role came from, and how it differs from the jobs around it
- The week, day by day, with what goes wrong on Thursday
- The four jobs underneath every week, as one map
- How a good Friday check-in with the client sponsor runs
- What to do today if you want this job
After reading, you will be able to decide whether this is work you want, and explain the week in an interview without sounding like a job description.
What a forward deployed engineer is
Kavya spent six years at a large IT services company. Last month she joined an AI startup as an FDE. Her first client is a global bank's customer-onboarding team.
On Thursday morning, the onboarding ops lead calls her.
"Some customers got the same welcome email twice. One got two screening checks. What did your agent do?"
Kavya checks the logs. A deploy went out last night. The agent restarted, then replayed each open conversation from the start.
Her senior FDE asks one question. "Did it crash, or did it resume?"
"It resumed. And it re-ran every step, including the ones that had already happened."
Kavya's morning covers most of the job. The bug sits between her code and the client's real process, and she is the only person in the room who can see both.
A forward deployed engineer is a software engineer who works inside one customer's environment to build, deploy and run software against that customer's data and workflows. The defining trait is where the work happens: on their systems, not yours.
Where it came from: the role is usually traced to a data-analytics software company whose product could not be demoed from a distance. Its customers had security rules, messy data and approvals that took weeks, so it sent engineers to sit with the customer and build there. AI companies now hire for the same role, because LLM products have the same problem. The model works in the demo. The deployment fails on the client's documents, permissions and edge cases.
Where it sits among the jobs you already know:
- Product engineer: builds one capability for every customer. Generality comes first.
- Solutions engineer: wins the deal with demos and a proof of concept before the contract.
- Consultant: advises and designs. Often does not write or run the production code.
- FDE: after the deal, builds and runs the thing for one customer, and carries what it learns back to the product team.
The week, day by day
- Monday, sit with the users. Watch the actual workflow, not the slide deck about it. Write down the questions people ask out loud. Those become your test set.
- Tuesday, get to the data. Raise access requests, find who owns each source, pull a sample. Projects often stall here, waiting in an IT queue.
- Wednesday, build on their data. A narrow slice that works end to end on real documents beats a broad demo on clean ones.
- Thursday, something breaks in their world. Kavya's agent re-ran steps after a restart. The fix: record the result of every outside action, replay recorded results on resume, and make every email or check safe to attempt twice. Then write the incident note before anyone asks for it.
- Friday, prove it and report. Demo to the sponsor on their own questions. Send one status note. Send product feedback home: "three clients have asked for this; build it once."
The four jobs underneath every week
Group the days and you get four jobs. Each day belongs to exactly one of them.
| Job |
What you produce |
The question that tells you it worked |
| Understand |
The user's real questions, in their words |
Can the ops lead say "yes, that is my problem"? |
| Get to data |
Access, a sample, a named owner per source |
Can you query real data by Wednesday? |
| Ship in their environment |
A narrow slice running on their systems |
Does it survive their deploy, their permissions, their edge cases? |
| Prove and report |
A demo on their questions, a status note, product feedback |
Does the sponsor know what decision you need from them? |
The trap for engineers from services companies is spending the whole week in job three. Job three is what you are good at. The client judges you on jobs one and four.
The full week-at-a-glance map, with the questions to ask each day and a Thursday incident template, is part of the FDE Field Manual. Preview:
FDE week-at-a-glance (preview)
- Monday: three questions to ask the person who does the work, not their manager
- Tuesday: the access request that names a data owner and a date
- Thursday: a five-line incident note (what happened, who saw it, fix, prevention, open risk)
- Friday: a status note whose first line is the decision you need
The full map is in the Field Manual, which collects each playbook from this series as it ships. Create a free Inherent account.
From the field: how a good Friday check-in runs
A well-run client check-in is short, and its first line is a decision the sponsor has to make.
The pattern: one page. Line one is the decision you need from the sponsor, with a date. Then what changed this week, in the client's words. Then one risk with an owner. The demo comes after, as proof.
Most engineers put the demo first and the ask last, by which time the sponsor has left for their next meeting. Put the ask first.
TL;DR
- An FDE builds and runs production software inside one client's environment, and owns the outcome there.
- The week has four jobs: understand, get to data, ship in their environment, prove and report.
- Thursday always brings something from the client's world your tests did not cover. Fix it and write it down.
- Engineers from services companies are strongest at shipping. Practise the first and last jobs.
What to do today
Take your current project. Write one line for each of the four jobs: the user's real question, the data owner, what runs in production, and the decision you need from your sponsor. If you cannot fill a line, that is the skill to build first.
Then get the FDE Field Manual with a free account. The Field Manual collects the full week-at-a-glance map and each playbook from this series as it ships. When your first client deployment stalls on getting their documents into a usable, permission-aware state, Inherent is the context layer built for that step.
If you already work with client data, read the RAG ingestion field guide for FDEs next.
