What a forward deployed engineer actually does
Forward deployed engineering explained by someone who's done it for over a decade: what the role is, how it differs from consulting, and when you need one.
A forward deployed engineer is an engineer who works inside the customer's team instead of behind a ticket queue. They learn how the work gets done, find the part worth building, build it, and stay until it runs.
It sounds like a military title. It's a simple idea, and I've worked this way since long before it had a name. Here's what it means in practice.
What does the work look like, week by week?
- 01Week 1Sit with the people doing the work
- 02Week 2Agree one problem and how to measure it
- 03Weeks 3 to 6Build, ship small, ship often
- 04After launchFix what real use uncovers
Why start by sitting with the work?
The first week isn't spent writing code. It's spent watching how the work is done today. Who opens which tool, where they copy and paste, what they complain about, and where the real decisions get made. Most requirements documents miss half of this.
How do you decide what to build?
Clients usually arrive with a big idea, like "an AI assistant for the whole company." A forward deployed engineer's job is to find the smallest piece that delivers real value in weeks, and to say no to the rest for now.
How is it different from consulting?
This is the big one. A consultant hands over a recommendation. A forward deployed engineer hands over working software in production, then stays to make sure it keeps working.
| Question | Consultant | Contractor | Forward deployed engineer |
|---|---|---|---|
| Hands over | A recommendation | Code to a spec | Working software in production |
| Works from | Interviews | A ticket | Inside your team |
| Writes the spec | Yes | No, you do | Yes, with you |
| After launch | Gone | Usually gone | Still there |
What happens after launch?
Live systems break in ways demos don't. Data arrives in strange formats, an upstream API changes, users do something nobody predicted. Being embedded means you're there when that happens and you fix it, instead of reading about it in a support ticket.
When do you need one?
- You have a clear business problem but no in-house AI experience.
- You've tried an off-the-shelf tool and it didn't fit your workflow.
- Your engineers are busy and you need someone who can work alongside them without slowing them down.
If that sounds like your situation, let's talk.