How forward deployed engineering teams work

It is easy to picture a forward deployed engineer as one person at a customer site. The work is done by teams, and the way those teams run explains a lot about the interview.

This post covers how a forward deployed team is shaped, how it reuses what it built before, what the first weeks on an account look like, and how it leaves. Each part ends with what it means for what you learn and show.

How is a forward deployed team organized?

A forward deployed team is a small pod placed with one customer, with the authority to make decisions there. Barry McCardel spent almost five years in Palantir's forward deployed role. He describes its customer pilots as "little seed startups, given a few FDEs and a tight timeline." Marty Cagan of SVPG writes that the people sent are usually engineers, and increasingly product managers or designers.

A useful way to read any pod is by the three loops it has to cover.

• The problem loop: framing the problem with the customer and agreeing what success means.
• The build loop: writing and shipping software inside the customer's environment.
• The stability loop: keeping pipelines, integrations and environments running.

In a bigger pod, a product manager, an engineer and a platform engineer might each own one loop. In a small pod you hold two or all three, and each pulls time from the others.

For the interview: stakeholder and scoping rounds test the problem loop. Debugging and build rounds test the other two.

Why do forward deployed teams get so much autonomy?

Because the people at the customer can see the problem, and waiting on head office for every call kills momentum. McCardel puts the core of the culture as "a radical deference to teams in the field." He links it to Auftragstaktik, or mission command: senior leaders set only the high-level objectives, and the field team makes the other decisions.

That autonomy is why the interview leans on ambiguity. Nobody hands you a spec on an account, so the loop often doesn't either. A round that opens with a one-line brief is checking whether you ask the right questions and then commit to a plan. The customer round post shows what that sounds like.

What is a reference architecture, and why do FDE teams keep them?

A reference architecture is a solved problem turned into a pattern the next team can deploy, so each account doesn't start from zero. A solution architecture fits one customer. A reference architecture generalizes it to a class of problems: the customer-specific parts become settings, it has an owner, and it carries a version.

At Palantir, McCardel writes, customer deployments were "proving grounds for new technologies." What worked moved toward the core platform and dev teams took it over, while FDEs moved on to the next problem. Cagan describes the same loop: a platform product team generalizes what FDEs learn into reusable capabilities.

Teams that do this well share a few habits.

• They keep a decision log during the build: what was chosen and why, the general pattern behind it, and when it shouldn't apply. Reasons not written down that day are hard to recover later.
• They promote a pattern once it repeats. Two accounts making the same call under similar constraints is a reasonable trigger.
• They give each template an owner and a version, and revisit it when deployments keep deviating from it.
• They measure it. Time to first production deployment should fall across accounts that use the same template.

For the interview: design rounds reward knowing when to reuse and when to build. Twenty product teams each maintain their own CI/CD pipelines, databases, and monitoring. Design the fix, and tell me how you would know whether it worked. is this problem inside one company. So is standardizing LLM access across teams.

What happens in the first weeks on an FDE account?

The first weeks go to access, real data and agreeing what done means, before much AI gets built.

1. Get real access. You need write access to the data platform, the model registry and compute settings, not a read-only sandbox. Without it you can advise but not ship.
2. Join their workflow. Take tickets in their tracker, sit in their sprint planning, and get on the incident channel. If nobody pages you when the pipeline fails, you aren't embedded.
3. Work on production data from week one. A clean one-off export hides the pipeline problems you'll hit later.
4. Write the pass criteria before the prompts. Agree on the tests that decide whether it ships, the subject of evals and production readiness questions.
5. Name the production owner and start the security review. Approvals take time, so run them alongside the build.

Access matters more than it sounds. Full Stack Deep Learning's lecture on ML teams describes a research-style team with no control over its data and usually no data engineers. Its models, the lecture notes, are rarely deployed into production.

For the interview: this is the scoping round. Clearing up a misunderstanding like the stakeholder who believes the model connects to the internet is week-one work.

How does an FDE team hand over to the customer's team?

It writes the exit criteria at the start, and counts the handoff done only when the customer's engineers have run the system without help. Good exit criteria describe what people can do, not which documents exist.

• At least two of their engineers can explain every pipeline component without you.
• They have shipped one change end to end without you.
• They have resolved one production incident without you, and it is in the runbook.

Then verify it live. Their engineer explains the runbook in their own words, runs it while you watch in silence, and every hesitation becomes a fix to the runbook. Book this in the final week, not the final day.

For the interview: if you're asked how you'd hand a system over, answer with these criteria, not a list of documents.

What should you learn and show to join an FDE team?

Show that you can cover more than one loop, and that you leave behind a system someone else can run.

• A project with a real user and a written scope, for the problem loop.
• A deployment to a cloud you don't control, with monitoring, for the build and stability loops.
• A decision log or architecture decision records from that project, for reference architecture thinking.
• A runbook someone else ran, and what you changed after watching them.

For the build loop, the free course Claude Code for Forward Deployed Engineering is four recorded sessions on building AI agents with Claude Code. Practice the rounds on the question bank. When you're ready to apply, browse Core FDE roles and Deployment Strategy roles on the board. For the full path in, see how to become a forward deployed engineer. For the loop itself, read the interview, round by round.