FDE team structure works best as a small, embedded pod: one technical lead, two to three engineers matched to the problem, and a delivery owner who manages scope and adoption. The pod ships to production inside your environment on a weekly cadence, writes the runbooks as it goes and plans the handover from week one.
What a forward deployed engineering team actually is
A forward deployed engineering team is a group of engineers who build production software inside a customer’s systems, rather than handing over specs from a distance. They sit with the people who own the problem, work in the real data and ship code that runs on day one.
The label covers different set-ups. Some companies run lone engineers attached to accounts, others run pods, and some treat FDE as a full function next to product engineering. Practitioner write-ups agree on the core idea but disagree on where the team reports and how long engagements last, so you should design the structure around your goal rather than copy one company’s model.
For a client engagement, the question is simpler than it is for a vendor building an FDE function. You need a team that can work inside your security rules, reach production on a real use case and leave your engineers able to run what was built. Everything in the structure below serves those three goals.
The four common FDE team models
Most FDE teams fall into one of four models, and each breaks at a different scale. Pick the one that matches how many projects you need to run in parallel and how much product work you expect the team to absorb.
| Model | How it works | Where it breaks |
|---|---|---|
| Lone engineer | One FDE per account, wearing every hat | Knowledge sits in one head; burnout and slow handover |
| Embedded pod | 3–5 people with clear roles, one client at a time | Needs a repeatable playbook to scale beyond a few pods |
| PS-adjacent | FDEs sit inside professional services | Drifts into billable customisation with no product feedback |
| FDE as a function | A standing team with its own leadership and tooling | Heavy to stand up; overkill for a first use case |
Core roles in an FDE pod
An FDE pod needs one person who owns the technical design, engineers who build, and one person who owns the outcome with the business. Industry write-ups describe a common split: the deployment strategist decides what the code should solve and drives adoption, while forward deployed engineers own the build.
At tkxel we keep the pod at three to five engineers and add specialists only when the work calls for them. Here is how the roles usually break down.
Tech lead (forward deployed lead)
Owns architecture, security review and the production bar. Writes code most days and is the single technical point of contact for your platform and security teams.
Forward deployed engineers
Two to three engineers matched to the problem: agent and LLM engineering, data engineering, or integration work against your systems of record. They ship, test and document.
Delivery owner or deployment strategist
Owns scope, the success metric and adoption. Runs discovery with process owners, keeps the backlog honest and reports progress in business terms.
Rotating specialists
A data scientist, security engineer or domain expert who joins for a sprint or two when the work needs them, then rolls off.
Ratios and pod size
The right ratio is roughly one tech lead and one delivery owner for every two to three builders. Below three people, the pod has no slack for reviews, on-call or a sick day; above five, coordination overhead starts to eat the speed that made the model worth using.
Run one pod per use case rather than stretching one pod across several. If you have two unrelated workflows to automate, two small pods with separate success metrics will usually beat one large team juggling both.
- 3 people: tech lead, one engineer, part-time delivery owner. Good for a narrow proof of value.
- 4 people: tech lead, two engineers, delivery owner. The default for one production agent or integration.
- 5 people: adds a data or security specialist when the data is messy or the workflow is regulated.
Where your own people fit in the pod
Your people are part of the pod, not an audience for it. At minimum you need a process owner who knows the workflow, a platform or security contact who can grant access, and one or two engineers who will own the system afterwards.
The process owner should give the pod three to five hours a week: discovery interviews, weekly demos and quick answers on edge cases. The platform contact unblocks environments, credentials and reviews, which is often the slowest dependency in the first fortnight.
Your future owners should join stand-ups and code reviews from the start and take tickets from the second or third sprint. That is the cheapest handover you will ever get, because knowledge moves while the work is happening rather than in a rushed final week.
Rituals that keep an embedded pod shipping
Embedded pods stay effective through a short weekly loop: plan, ship, demo, review. The rituals are ordinary, but the difference is that your people attend them, so decisions get made in the room rather than in a status report.
- Weekly demo with the process owner, using real data, not slides.
- Daily 15-minute stand-up that includes at least one engineer from your team.
- Fortnightly risk and security review with your platform or security lead.
- A running decision log so nobody has to rediscover why something was built a certain way.
- A metric review every two weeks against the baseline agreed in discovery.
Plan the handover from week one
Handover works when you treat it as a deliverable from the start, not a farewell meeting. Practitioner accounts of FDE handoffs point out that the real cost is the weeks of rediscovery afterwards, because so much account knowledge lives in the engineers’ heads.
We write an ownership schedule before the first sprint, pair your engineers into the code from early on and write symptom-first runbooks as features ship. The final weeks are a reverse shadow, where your team runs the system and on-call while the pod watches.
Write the handover criteria into the statement of work: which runbooks exist, who has been on call, which incidents your team has resolved alone. When those are met, the pod rolls off, whatever the calendar says.
- Name the internal owner of each component before build starts.
- Write runbooks by symptom: what you see, what to check first, where to look.
- Test portability at milestones by having someone who did not build it fix a staged issue.
- Move on-call last, once your team has handled real incidents with support.
Trade-offs to plan for
The honest limitation of a pod model is that it depends on your side showing up. If the process owner cannot give a few hours a week, or access to systems takes a month, a small pod will stall faster than a large outsourced team that can work around gaps.
Pods also cost more per head than staff augmentation because you are paying for a lead and a delivery owner, not just hands. The return comes from fewer handoffs and a system your team can run, so the model fits work that needs to reach production, not open-ended capacity.