How to Build a Forward Deployed Engineering Team

The first forward deployed engineer, or FDE, at a company gets by on judgment and stamina. They sit with the customer, write the code, answer the late-night message, and remember why every decision was made.

The fifth can't work that way. Now there are several customers, several engineers, and a sales team that has noticed how useful they are. Without some rules, the team turns into an expensive buffer. Sales promises custom work nobody scoped. Product can't tell real patterns from one-off requests. Customer code ends up with no owner. And the best engineers burn out doing permanent support.

This guide is for the person setting up or running that team. It covers ten steps: what the team owns, where it reports, how big to start, how to hire, how to plan its time, and how people grow in it. If you're an engineer deciding whether to join an FDE team, skip to what to look for as a candidate.

Step 1: Write down what the team owns

Answer three questions in writing before deciding anything else.

What does the team own? High-value customer deployments where nobody yet knows exactly how to make it work. That includes the early conversations, the design, the production build, the rollout, getting people to use it, measuring the result, and feeding lessons back to Product.

What doesn't it own? Routine support, setup work that's the same every time, maintaining a customer's app forever, every custom request attached to a big deal, and features that most customers need, which belong in the core product.

What does each project leave behind beyond one deal? Some mix of a customer result, a bigger contract, reusable software, deployment tools, product insight, and a better playbook.

Read the FDE hiring decision framework first. It checks that an FDE team solves a real bottleneck before you design one.

Step 2: Choose where the team reports

Every reporting line comes with a trade-off.

Reports to	Strength	Risk	Best fit
Engineering	Strong code quality, hiring, and connection to the product	Urgent customer needs may lose out	Technical platforms and early FDE teams
Customer Engineering	Balances delivery with an engineering identity	Can become a cut-off middle layer	Growing companies selling to large customers
Professional Services	Clear delivery and billing management	Keeping people billable can crowd out product impact	Paid, scoped implementations
Sales or GTM	Strong deal context and urgency	Short-term custom work and conflicting incentives	Founder-led or early enterprise sales, with firm limits
Product	Excellent path from the field to the roadmap	Delivery habits may be weak	Products still working out how to sell to large companies

The safest default is a home in Engineering or Customer Engineering, with three regular meetings: a weekly one with Sales to decide which projects to take, a review every two weeks with Product and Engineering on what should become product, and a monthly review with leadership on results and capacity.

The org chart matters less than who gets to decide what. The delivery side must be able to reshape or turn down a project. Product must decide what goes into the core platform. Customer Success or Support must agree to take over once things are stable.

Step 3: Start with the right size

Early teams need coverage, someone to pair with, and enough variety to test whether the idea works.

Pilot: one senior engineer on a time-limited rotation, with a named sponsor on the product side and the customer side.

First real team: two or three FDEs. That gives you pairing, code review, shared knowledge, and coverage when one person is on-site or out.

Growing team: four to eight FDEs plus a lead who still builds. Add light specialties, like data, security, or AI testing, only after real patterns show up.

Large team: pods or segments with senior technical leaders, a shared team that builds tools and training for everyone, clearer levels, and people dedicated to deployment operations. Keep rotating people and reviewing each other's accounts so the team doesn't split into isolated customer islands.

These ranges are practical rules of thumb, not measured benchmarks. Team size should follow the amount of real work you've agreed to take, how much time each phase needs, and the economics.

Step 4: Organize around results, not tickets

For complex projects, build a small pod:

FDE: technical owner and builder
Deployment or program lead: scope, dependencies, decisions, and updates for executives
Customer outcome owner: a person at the customer who's accountable for adoption and the business change
Product partner: decides what field work belongs on the roadmap
Customer Success owner: gets ready to own adoption and growth long term

Early on, one person may cover several of these. But each responsibility still needs a name next to it. If nobody at the customer owns the result, the vendor can't force adoption from outside.

Don't send FDE work through a general ticket queue. A queue is built for fast responses and high volume. Forward deployment is built for one result, reached through deep knowledge of one customer.

Step 5: Agree how the team works with everyone else

Sales

Sales brings the deal context and access to the customer. FDE leadership checks scope, technical risk, timeline, and staffing before anything is promised. Keep one simple rule: no custom delivery gets promised without a named delivery owner.

Solutions Architecture

Solutions architects prove the product fits and write down the technical risks. The FDE takes over once a qualified deal needs real production work. Use a written handoff covering the result the customer wants, the people involved, the design, open questions, promises made, and how success will be measured.

Product and core Engineering

When the same problem keeps showing up in the field, write a short memo to Product. Include the customer pattern, how often it happens, what it costs the customer, the current workaround, the evidence, and a suggested fix. Product decides whether the answer is a core feature, a place customers can plug in their own code, a deployment tool, documentation, or nothing.

Customer Success

Customer Success owns the ongoing relationship, the adoption plan, and growing the account once the system is stable. The FDE shouldn't vanish at launch, but shouldn't stay on as the account owner forever either.

Support and reliability

Agree on how serious incidents are ranked, who's on call, how problems get escalated, what's in and out of scope, and the point where a deployed piece moves into normal support. Code running for customers can't live outside the company's normal reliability process.

Step 6: Hire for both halves of the job

Test engineering and customer ownership. A candidate who is strong at only one will struggle.

Use five stages:

Experience screen: evidence of delivering something end to end and working directly with users.
Production coding: a realistic task that needs clean, tested code the candidate can explain.
System design: a design under real customer, data, security, and timeline limits.
Discovery case: turn a vague request into a clear problem, a scope, and a way to measure it.
Judgment and communication: explain trade-offs, handle pushback, and write an update for an executive.

Score candidates on production engineering, breaking down problems, customer discovery, product judgment, running delivery, communication, learning speed, and operational discipline. Don't let charm make up for weak engineering, and don't let a great algorithms round make up for poor listening.

The FDE interview guide has a full scoring rubric and a sample case.

Step 7: Plan capacity by project phase

"Accounts per engineer" hides the real workload. A project in early discovery, one in active build, one rolling out, and one that's stable each take very different amounts of time.

Use rough capacity units for internal planning:

Discovery and qualification: 0.2 to 0.3 FDE
Active build: 0.6 to 1.0 FDE
Production rollout: 0.4 to 0.7 FDE
Stable account, advice only: 0.1 to 0.2 FDE
Turning field work into product, documentation, and learning: reserve at least 20% of total team capacity

These are starting guesses, not measured figures. Check them against real time and results after the first ten projects. And don't schedule anyone at 100%. Customer work brings urgent requests, travel, and the cost of switching between contexts.

If time for turning field work into product is the first thing cut when demand rises, the team gets harder to scale every quarter. Treat it as delivery work, not side work.

Step 8: Onboard people for range

Good onboarding mixes deep product knowledge, field judgment, and supervised delivery.

Weeks 1–2: build a working internal deployment, finish security and production-readiness training, and review three projects that went well and three that didn't.

Weeks 3–4: shadow customer discovery and support, reproduce a real deployment problem, and write a memo to Product.

Weeks 5–8: pair with a senior FDE on a small piece of a project, ship code through the normal review and deployment process, and join user testing.

Weeks 9–12: own a small phase of a project, with a written goal, plan, risks, and a definition of done. Review the work with engineering, product, and customer leaders.

Keep a library of past projects: problem statements, design decisions, reusable pieces, security patterns, adoption results, handoffs, and look-backs. Writing things down means less depends on what one person remembers, without pretending every deployment is the same.

Step 9: Build a career ladder

FDEs need a path that rewards technical depth and impact across customers, not just the number of accounts they carry.

FDE I: owns well-defined technical work, with support. Learns discovery and production standards.

FDE II: owns a phase or a small deployment. Works directly with customer engineers and contributes reusable patterns.

Senior FDE: owns complex results, shapes the design, mentors others, and influences product decisions.

Staff FDE: has impact across many customers through platforms, playbooks, technical direction, and better ways of working across teams.

FDE Manager or Lead: builds the team, decides which work to take, manages capacity, keeps standards up, and develops people while staying close to delivery.

Let people move into core Engineering, Product, Solutions, Customer Engineering leadership, and management. Palantir's own blog describes engineers moving between forward-deployed and product roles. Moving around keeps customer knowledge from becoming a career dead end.

Step 10: Keep a steady meeting rhythm

Keep meetings few, and make each one end in a decision.

Weekly project review: goal, current phase, evidence, risks, decisions, next checkpoint.

Weekly Sales meeting: new requests, account value, how uncertain the technical work is, capacity, and a yes or no.

Every two weeks, product review: repeated patterns, product requests, places to let customers extend the product, ownership, and roadmap decisions.

Monthly review: time to production, adoption, results, capacity, economics, product impact, and team health.

At each phase with the customer: scope and goal at the start, evidence and a go or no-go at the end.

Use the Forward Deployed Engineering playbook for project checkpoints and the FDE metrics guide for the scorecard.

A worked example

This is a made-up company, to show how the steps fit together.

Northwind sells data software to hospitals. Its first FDE, Priya, has been with three hospital customers for a year. She's good, she's tired, and two more hospitals have signed with promises of "custom integration."

Northwind's VP of Engineering writes the one-page charter from Step 1. It says the team takes new hospital integrations, not ongoing report requests. Then she hires two more engineers so Priya has someone to pair with, and sets up the weekly Sales meeting from Step 2.

At the first meeting, one of the two new deals turns out to need a feature every hospital will want. That goes to Product, not to an FDE. The other becomes the new hires' first project, with Priya reviewing.

Priya's three old accounts each get a handoff plan to Customer Success. The team protects one day a week for turning repeated integration work into a shared connector. Nothing here needed a big reorg. It needed written rules and a few meetings that end in decisions.

Mistakes to avoid

Hiring before there's enough qualified work
Making the FDE team a catch-all escalation team
Reporting to Sales without the power to turn down projects
Reporting to Engineering without measuring customer results
Measuring how busy people are instead of the results they get
Letting customer code skip production standards
Leaving career growth and travel expectations unspoken
Assigning people to accounts forever with no plan to hand off
Building product from one story, or ignoring a pattern that keeps repeating
Growing headcount before the first projects produce anything reusable

The guide to why FDE teams fail covers how to recover from each of these.

If you're a candidate reading this

Most of this page is for the person running the team. If you're deciding whether to join one, use it as a checklist in your interviews. Ask whether the team can turn down projects, how much time is set aside for reusable work, who takes over an account after launch, and what the career ladder looks like above your level. A team that can't answer those is likely running on heroics.

To prepare for the job itself, read how to become a forward deployed engineer.

Frequently asked questions

Should FDEs be assigned permanently to accounts?

Usually no. Deep context is valuable, but a permanent assignment turns into ongoing support and limits what the rest of the team learns. Work in defined project phases with handoff rules, and keep someone on an account only when a new high-value problem justifies the extra scope.

How do you prevent FDE burnout?

Control travel, protect time for reusable work, limit how many active builds one person carries, pair people on risky projects, rotate accounts, make escalation clear, reward saying no to bad projects, and build technical career paths. A team that depends on heroes has a capacity-planning problem, not a personality advantage.