FDE Academy

Module 1 · The FDE role and mindset · Chapter 1

What an FDE actually does

12 min1 simulation3 checks
The problem A bank's VP says: "We need AI for our supply chain." Your company has a great product, three engineers already wrote the integration spec, and the customer still can't use any of it. Someone has to go sit with the customer and make it work. That someone is the Forward Deployed Engineer.

Three jobs share one title

An analysis of about 1,000 FDE job postings by Bloomberry found roughly 60% were builder roles (writing production code at the customer), about 30% were sales-engineer-plus roles, and about 10% built internal go-to-market tooling. Same title, very different days. This course targets the builder FDE, and shows you how to read a posting so you can tell which one you are applying for.

Where the time actually goes

Click through the roles. The bars are illustrative, not measured: they show where each role spends its attention, and why moving from SDE to FDE feels like a different job rather than a promotion.

Illustrative profiles. The FDE is the only role that is high on both customer time and production ownership.

The engagement lifecycle

Every FDE engagement moves through the same five stages. Step through it. Notice where the work changes character: a proof of concept is a magic trick, and production is plumbing.

FDE engagement lifecycle Five stages in a row: Discover, Proof of concept, Pilot, Production, Expand. A feedback path runs from the field back to the product team and then back to Discover. Discoverreal problem Proof of conceptthe magic trick Pilotreal users, data Productionthe plumbing Expandnext use case Product teamcore engineering learnings become product
  1. Sit with the customer. The stated ask ("AI for our supply chain") is rarely the real problem. You leave with a problem statement, a named champion and a measurable success criterion.
  2. Build the smallest thing that shows the idea working, fast. It runs on sample data and your laptop. Be careful: a good demo creates expectations you now have to meet.
  3. Real users and real, messy data. Permissions, edge cases and "this doesn't match our process" all appear here. Many projects stall at this stage when nobody owns the move to production.
  4. Monitoring, access control, security review, runbooks, on-call and a rollback plan. This is where an SDE's habits help the most, and where the customer-facing skills matter just as much.
  5. A working deployment earns the next team and the next use case. You reuse what you built instead of starting over.
  6. An FDE does not only deliver. Hacks that worked at one customer get turned into product features, so the next deployment is faster. That loop is what separates an FDE from a consultant.
Customer-facingAI / prototypeYour running systemProduct org

The gap between a working demo and a system the customer trusts is where projects commonly stall. Demos run on clean sample data and skip access control, monitoring and ownership. Closing that gap is a large part of what customers pay an FDE for, and it is why this course spends whole chapters on the production side (Modules 5 and 6).

Try it: your first customer call

The VP just said "We need AI for our supply chain." Choose how you respond. There is no single right answer, but some choices build trust faster and others quietly set up a failure three months out.

Check your understanding

Recap

In the field A team demoed a document-search assistant that answered beautifully on a folder of sample PDFs. On the pilot they connected the real file share and discovered that half the documents were scans, and that the assistant happily quoted HR files to anyone who asked. The demo was real. The product wasn't ready. Fixing document ingestion and permissions took longer than building the demo. Chapters on these come later in the course.

Chapter quiz

Four questions. Score 70% or more to mark this chapter complete.

Review