If you have spent a few years delivering projects at an IT services company, you already do most of a forward deployed engineer's job. You get into client systems, build against old databases, ship to a release date and hand over. What's missing is two skills.
The first is scoping: turning a vague business ask into a problem with a number that proves it worked. The second is judging model output: knowing whether an LLM system is right on the client's own questions, and measuring it.
Why it matters to you: most "how to become an FDE" guides hand you a long list of things to learn. After reading, you'll know which two to practise and how to describe the other four in an interview.
What this post covers
- What the FDE job is, broken into six steps
- A worked example where both gaps show up at once
- What you already have from services work
- Gap 1, scoping, and how to practise it
- Gap 2, judging model output, and how to practise it
- The skills gap worksheet, a habit from the field, and what to do today
Yesterday's post compared FDE with solutions architect, consultant and SWE. This one assumes you picked FDE.
First principles: the FDE job in six steps
Kavya spent six years at a large IT services company and now works as an FDE at an AI startup. In her first week, a client's ops lead hands her a one-line ask and expects it live soon. Nobody has written a spec. That moment is where the job differs from services work.
A forward deployed engineer builds and runs software inside one client's company, on that client's data. The role is usually traced to data-platform companies that sent engineers to sit with customers. AI vendors hire for it because an LLM system only proves itself on the client's messy documents.
Break the job into the steps of one engagement:
- Get into the client's systems.
- Turn a vague ask into a scoped problem.
- Build and wire into their legacy systems.
- Judge whether the model's output is right.
- Ship to a date and handle incidents.
- Hand over so the client can run it.
Steps 1, 3, 5 and 6 are what services delivery trains you in. Steps 2 and 4 usually belong to someone else on a services project, or did not exist before LLMs.
A worked example: Kavya and the assistant that folds
Here is that week in full. Kavya's client is a tax advisory firm.
The firm's research assistant gets the first answer right. But when a user pushes back, it gives up a correct answer. The senior partners push back the most.
The client's ops lead is clear. "Make it more confident. Tell it never to change its answer."
Kavya's services instinct says: that's the spec, update the prompt.
Her senior asks one question. "When it changed its answer, was it right first, or wrong first?"
Kavya didn't know. So she pulled every conversation where the answer changed and split them in two:
- Caved: right on turn one, wrong after the pushback.
- Corrected: wrong on turn one, right after the user pointed to a source.
"Never change your answer" would kill the second bucket too. The fix was narrower. She scored the answer at the last turn, not the first. Then she let the answer change only when new evidence arrived, such as a cited document. That call is made by a separate model call that sees the question and the cited document, but not the user's pushback.
The ops lead asked for confidence. The firm needed an assistant that stops dropping right answers. Finding that need behind the ask is scoping. Splitting changes into two buckets and scoring the last turn is judging model output.
What you already have from services work
Translate your experience into FDE language:
- Access. You have raised VPN requests, chased firewall approvals and waited on change boards. FDE projects often stall right here.
- Legacy integration. You have wired code into old databases and batch jobs. Client AI projects run on exactly those.
- Delivery under a date. Release windows, on-call and root-cause notes are daily FDE work.
- Handover. You have written runbooks and run knowledge transfer. A pilot with no runbook tends to break the week its builder leaves.
On your resume and in interviews, describe each one as an outcome for a client.
Gap 1: scoping a vague ask
Technically, a scoped problem has an input, an output, a test, and a number that says it worked. "Summarise complaints" is not scoped. "Summaries the complaints team accepts without edits, measured on 50 real cases" is.
On the business side: on a services project, a business analyst or onsite lead usually turns the client's ask into a spec before it reaches you. As an FDE, you are in the room when the ask is still vague, so you do that translation.
How to practise this week:
- Take any ticket you're working on.
- Write the business question behind it in one line.
- Write the number that would tell the client it worked.
- Ask your lead or the client if you got it right.
Gap 2: judging model output
Technically, an LLM system gives different answers to similar inputs. You judge it with an eval set: real questions from the client, the expected answer, and a pass rate you re-run after every change. Kavya's pushback test is one eval case.
On the business side, "it looks good in the demo" won't get past the client's finance or risk team. A pass rate on their own questions will.
How to practise this week:
- Build a small LLM app on any document set you can legally use.
- Write 20 questions with the answer you expect.
- Score the app, change one thing, score again.
- Add five pushback cases and score the last turn.
The full skills gap worksheet is in the FDE Field Manual. Preview:
Skills gap worksheet (preview)
- Score yourself on the six FDE steps, with evidence from your own projects
- Rewrite three services projects as FDE outcomes
- A four-week practice plan for your two weakest steps
Create a free Inherent account to get it.
From the field: repeat the ask back as a decision
Good advisors rarely start work on the client's first sentence. They repeat it back as the decision it serves: "So you need to decide whether partners can rely on this for client advice. Is that right?"
Often the client corrects them, and the real scope appears before any code is written. Try it in your next client call, even before you switch roles.
TL;DR
- A services-company engineer already covers four of the six FDE steps: access, legacy integration, delivery and handover.
- The gap is two skills: scoping a vague ask, and judging model output with an eval set.
- Practise scoping by writing the business question and the success number behind each ticket.
- Practise judging by building a small eval set and scoring every change, including pushback turns.
What to do today
Open your last project. Write which of the six steps you owned, with one line of evidence for each. The two steps where you have no evidence are your practice plan.
Then get the FDE Field Manual with a free account. It holds the full skills gap worksheet and each playbook from this series as it ships.
