What a forward deployed engineer actually does, and the first week of an engagement done properly: finding the real problem, reading a system you did not build, scoping something shippable, and saying it clearly to the person paying for it.
Begin with: Connect a software capability to a working customer workflow
Start free lesson →25 min · Free · no account needed
Syllabus
Free lessons need no account. Sign in free for Plus lessons. Premium unlocks the full course.
The role
What the job is for, how it differs from the roles it gets confused with, and the loop an engagement actually runs on.
Discovery
Finding the problem worth solving, the people who can stop you, and a written scope that survives contact with the engagement.
- Test the stated request against the work people actually doVideo explainer · 11:1028 minfree
- Map the people, decisions and prerequisites behind the pilotVideo explainer · 10:1325 minfree
- Write a scope that can be tested, approved and changed deliberatelyVideo explainer · 12:0830 minfree
- Lab: turn a customer's request into a pilot you can actually judgeproject90 minpremium
Reading systems
Orienting fast inside software you did not build, finding the boundaries that matter, and locating the failure modes before they find you.
Code that survives in someone else's system
The craft half of the job: the seam that isolates their system from your logic, failure handling that holds at three in the morning, and tests that still run when you cannot reach their environment.
Data that fights back
The part of every engagement that nobody budgets for: reconciling data you cannot fix at source, and building pipelines that survive being run again.
- Profile the data and turn uncertainty into a scoped planVideo explainer · 10:5428 minsign in
- Make replays safe without overwriting newer factsVideo explainer · 10:3230 minsign in
- Investigate undocumented behavior with bounded evidenceVideo explainer · 9:5528 minsign in
- Lab: assemble a pipeline and reconcile every replayproject150 minsign in
Modelling their world
The data half of the craft: resolving one real-world thing across systems that disagree about it, shaping tables an analyst can query without asking you, and keeping history when the business changes its mind.
The proof of concept
Building the smallest thing that settles the argument, faking the rest without lying about it, and putting it somewhere the customer can actually open.
Your first AI feature
Shipping something probabilistic into a customer environment: why retrieval is the part that fails, why the evaluation comes first, and how to design for being wrong in public.
- Trace the evidence before changing the promptVideo explainer · 10:2922 minpremium
- Write the evaluation before the feature, or you will never know if it worksVideo explainer · 11:0525 minpremium
- Design for being wrong, because the system will be wrong in front of the customerVideo explainer · 10:5624 minpremium
- Project: repair a streaming assistant and prove which run owns each writeproject120 minsign in
Operating what you shipped
Configuration and secrets that survive four environments, the three signals worth instrumenting, and a service level chosen with the customer rather than inherited from a blog post.
- Validate configuration before serving and make credential changes testableVideo explainer · 9:4430 minsign in
- Connect operational signals to outcomes and expose missing evidenceVideo explainer · 10:3430 minpremium
- Define service levels with explicit denominators and a usable response policyVideo explainer · 11:1730 minpremium
Saying it
The written update, the demo, and the handover. The engineering only counts once somebody who was not in the room understands what you did.
- Lead an update with the decision and keep its evidence intactVideo explainer · 10:5728 minpremium
- Demonstrate a customer workflow with visible evidence and honest limitsVideo explainer · 10:3328 minpremium
- Transfer operational capability with evidence, rehearsal and accepted ownershipVideo explainer · 11:4430 minpremium
Capstone
One project that runs the whole loop: discover a real workflow, scope it, build the thin slice, put it where someone else can open it, and hand it over. The artifacts double as interview evidence.
About this course
Before you start: You can program and have shipped something. No customer-facing experience assumed, and none of the modules require a particular language or cloud.
Most engineering courses teach you to build a system for users in general. This one teaches you to build for one customer in particular, which is a different job with different failure modes.
The forward deployed role exists because enterprise software keeps stalling in the same place: the distance between a capability that works in a demo and a workflow somebody uses on a Tuesday. Closing that distance is technical work, but it starts with a conversation and ends with an argument about value, and the engineering in the middle is only as good as those two.
Ten modules and a capstone, in order. The early ones are the ones people skip and then regret: discovery, reading unfamiliar systems, scoping. The later ones are where most of the code is, and the capstone runs the whole loop once on a real workflow, which is where familiarity becomes evidence. If you only have a week before an interview, read modules one, two and ten: the role, discovery and communication.
When you finish, you can
- Explain what an FDE is for, and how the role differs from a solutions engineer, a consultant and a product engineer
- Run a discovery conversation that finds the real problem instead of confirming the stated one
- Read an unfamiliar system fast enough to make a decision about it
- Scope a first slice that ships in weeks and answers one question
- Build a small AI feature and say honestly whether it works
- Write a status update and give a demo that a busy executive can follow
- Run one small engagement end to end in the capstone, and keep the six artifacts it produces
