Managing Forward Deployed Engineers: The Playbook Nobody Wrote

2026-09-01 · 11 min read · Team Health

A forward deployed engineer works inside your customer's company. Not on a call with them, not building integrations for them from your office — physically or functionally embedded in their environment, writing code against their systems, sitting in their standups, absorbing their priorities.

Palantir popularised the model. The current wave of AI companies rebuilt it out of necessity: when your product is a capability rather than a workflow, someone has to go and turn it into the customer's workflow. So FDE, forward deployed AI engineer, field engineer, deployment strategist — different labels, same shape.

The role gets written about constantly. Managing the role gets written about almost never, which is a problem, because nearly everything an Engineering Manager normally relies on stops working.

What actually breaks

You lose ambient signal

Managing a product team, you learn things without asking. You skim PRs. You notice someone's been quiet in design review. You see a branch that hasn't moved in two weeks. None of it is deliberate — it's ambient, and it's most of how you form a picture of someone.

With an FDE, that's gone. Their commits land in the customer's repository. Their design decisions happen in the customer's docs. Their hard week happened in a meeting you weren't in, at a company you don't work for.

You are managing someone whose work is structurally invisible to you, and the natural response — asking more questions — reads as surveillance to someone already under pressure.

Their output is someone else's outcome

"What did you ship?" has no clean answer. An FDE might spend three weeks on integration plumbing that produces nothing you'd recognise as a feature but unblocks a seven-figure renewal. Another might write almost no code and change the account's trajectory by convincing the customer's architect to stop fighting the data model.

Every velocity metric you have — PR cycle time, deployment frequency, throughput — was designed for a team shipping into a codebase you own. Applied to an FDE they measure noise, and worse, they systematically undervalue the person doing the highest-leverage work.

The customer becomes a second manager

This is the structural one, and it's rarely named.

Your FDE has a customer stakeholder with urgent needs, real authority in the room, and no responsibility for that engineer's career, workload or growth. That person will ask for things. Your engineer, wanting the deployment to succeed, will say yes.

You have a report with two managers, one of whom is optimising for something other than their wellbeing. Unmanaged, priorities get set by whoever is most present — and that is never you.

Promotion evidence lives in a customer's environment

At review time you need specifics: what they did, what changed, at what scale. For an FDE, that evidence is inside another company's systems — sometimes under an NDA that prevents you from writing it down in useful detail.

The result is a promotion case built from a manager's vague recollection of a hard deployment. That loses in calibration to a product engineer whose contribution you can link to directly. Not because the FDE did less, but because the evidence was harder to hold on to.

The FDEs on your team likely already suspect this, which is why the role has a reputation for being a career dead end. It doesn't have to be — but only if you fix the evidence problem deliberately.

What to do instead

Replace ambient signal with a deliberate cadence

You can't skim their PRs, so the 1:1 has to carry more weight than it does for a product engineer. Weekly, not fortnightly, and protected — an FDE's calendar is the first thing a customer escalation eats.

Change what the meeting is for. With a product engineer you're often unblocking. With an FDE you're doing something closer to reconstruction: what happened, what's actually hard right now, what the customer is asking for that they shouldn't be. See the complete 1:1 guide for the mechanics; the difference here is that you genuinely do not know the answers in advance.

Ask about the customer relationship explicitly, not just the work. "How are they treating you?" is a real question with an FDE and it surfaces problems months before the work does.

Log impact as it happens, not at review time

This matters more for FDEs than any other role, because their evidence decays fastest. A product engineer's work is recoverable — the PR is still there in December. An FDE's contribution exists in your memory of a conversation in March.

So write it down when they tell you. Not the task — the outcome. "Rebuilt their ingestion pipeline; cut nightly processing from 6 hours to 40 minutes; the renewal conversation stopped being about performance." That paragraph, written in March, is worth more in calibration than a week of reconstruction in November.

Where NDAs constrain what you can record, write the shape without the specifics: the technical difficulty, the scale, the business consequence, anonymised. Something defensible is always recordable.

This is the whole argument for logging impact stories continuously, and for FDEs it's the difference between a promotion case that lands and one that doesn't.

Measure differently, and say so out loud

Stop reporting FDE work in engineering velocity dashboards. It will look bad, and the comparison is meaningless.

What's worth tracking instead:

• Time to first value — how long from engagement start to the customer doing something real with the product
• Escalation trend — is this account getting calmer or louder over time
• Product feedback converted — how many customer problems became roadmap items rather than one-off fixes
• Reusability — how much of what they built survived as product, versus staying bespoke

That last one deserves emphasis. An FDE who turns customer-specific work into product capability is doing the highest-leverage work in the company, and no standard metric captures it. If you don't measure it, you'll implicitly reward whoever wrote the most custom code — which is the opposite of what you want.

Say the measurement difference out loud to the engineer. FDEs frequently believe they're being judged on invisible criteria. Often they're right.

Manage the second-manager problem directly

Don't leave your engineer to negotiate scope alone with a stakeholder who outranks them in the room.

Concretely: be the escalation path, and be explicit that you are. "If they ask for something that pushes this past Friday, you don't have to decide — send them to me." This is the single highest-value sentence you can say to an FDE, and most never hear it.

Build a relationship with the customer's counterpart yourself. Not to supervise your engineer — so that a scope conversation is between two managers rather than something your engineer must absorb personally.

And watch for the drift where an FDE quietly becomes the customer's employee: taking their tickets, attending all their meetings, defending their priorities in your planning. It's a gradual failure and it's on you to catch, not them.

Take burnout seriously, because the structure creates it

FDE burnout looks different from product-team burnout, and it's structural rather than incidental.

The pressure is external and always live — a customer's urgency doesn't respect your sprint boundary. There's often travel. There's the isolation of working somewhere your team isn't. And there's a specific exhausting dynamic: being the sole representative of your company in a room where things are going badly.

The usual burnout signals apply, but two are FDE-specific:

Advocacy fatigue — they stop pushing back on the customer. Sounds like maturity, usually means they've given up.

Identity drift — they start saying "we" about the customer and "they" about your company. Worth noticing early; it's rarely disloyalty and usually loneliness.

Rotation helps. So does making sure they aren't the only person who knows an account — a single-threaded FDE can't take a holiday without something slipping, which is a management failure, not a staffing inevitability.

Fix the career story before they ask

FDEs leave for a predictable reason: they conclude the role doesn't lead anywhere. If you wait for them to raise it, they've usually already decided.

Get ahead of it:

• Write down what senior and staff look like for this role, not translated from the product ladder. Scope for an FDE is account complexity, ambiguity absorbed and product influence — not systems owned. Your career ladder probably doesn't describe that yet.
• Make product influence a named expectation. An FDE who consistently converts field learning into roadmap is operating at Staff level by any sensible reading — make sure the ladder says so.
• Create a route back to product engineering. Knowing the door is open is often enough to stop someone walking out of the building instead.

Hiring for it

Briefly, because it shapes what you'll be managing.

The failure mode is hiring a strong product engineer and deploying them. The skills only partly overlap. What actually predicts success:

• Tolerance for ambiguity. The requirements will be wrong and nobody in the room knows the right ones yet.
• Reading a room. Much of the job is noticing that the person who hasn't spoken is the one who'll block you.
• Comfort being the least knowledgeable person present about the customer's domain, without losing authority about yours.
• Knowing when to stop building. Sometimes the right move is telling a customer the thing they asked for is wrong. That's a temperament, not a skill.

Standard interview loops select for none of this — see interviewing beyond LeetCode.

The underlying point

Forward deployed engineering breaks the assumption most engineering management rests on: that you can see the work.

Everything above is a compensation for that. Deliberate cadence replaces ambient observation. Continuously logged impact replaces recoverable artefacts. Explicit escalation replaces the org chart doing the work for you. Written-down career criteria replace the implicit understanding a product team has.

None of it is exotic. It's ordinary management practice, done consciously rather than absorbed by proximity — which is exactly what proximity was doing for you all along.

The teams that get this right treat their FDEs as the sharpest signal the company has about whether the product actually works. The ones that get it wrong treat them as a services function, and then wonder why the good ones leave after eighteen months.

Emtricks exists for exactly this problem — logging impact as it happens, keeping 1:1 history in one place, and having promotion evidence ready when the work itself is invisible. Try it free for 30 days — no credit card required.