TL;DR: An FDE operating system is the small set of shared layers that keep a growing FDE team coherent: playbooks, shared context, tasks, briefs, and time. Teams are inventing it under pressure, with FDE roles up 1,165% year over year. The load-bearing layer is shared context, not process. Get it right and you get outcomes like 3x rollouts per engineer at Aircall. Honest caveat: FD work is a direction with tasks generated on the fly, so the OS should hold state, not impose phases.
Forward deployed engineering is being invented at scale right now. FDE roles grew 1,165% year over year by one placement firm's data, and monthly job listings rose more than 800% between January and September 2025. Most of the people hired into those roles joined teams that didn't exist eighteen months ago. The role is new, so the way of running a team of them is being improvised in parallel, usually by a head of FDEs who is also carrying accounts.
That improvisation now has a name, or several. We keep hearing FDE teams describe an internal "FD OS" or "FDE operating system" they're trying to assemble. An FDE at a vertical AI startup described his team's project to us directly: "we're trying to come up with some what we call internal FD OS or FD operating system. Just to create, like, a shared context repository for for everyone." A head of FDEs at a workflow-automation platform, building the same thing independently, told us "I actually called it, like, FTE operating system."
This article maps what those teams actually converge on. Five layers, one of which does most of the work, and one honest admission that separates the useful versions from the shelfware: FD work doesn't follow phases, so the OS can't be a phased playbook.
Why every FDE team ends up sketching an operating system
A forward deployed engineer is an engineer who spends roughly half their time with customers understanding the problem and half building the solution for that specific customer. One FDE runs on personal systems and heroics, and that genuinely works. The trouble starts at two or three, when each engineer is running accounts their own way, and nothing about account state, method, or capacity is legible across the team.
The pressure to formalize comes from three directions at once. Hiring: with a roughly three-month time-to-fill and a thin candidate pool, every hire has to ramp fast, which requires something transferable to ramp onto. Credibility: Palantir CTO Shyam Sankar's jab that "only Palantir has FDEs. Everyone else has sparkling sales engineers" lands because a function without shared systems does look like ad hoc heroics from the outside. And load: the manual version of team coherence is people writing reports, and 72% of project professionals already spend half a day or more collating reports every month.
What is an FDE operating system?
Working definition: the minimum set of shared layers that lets each FDE run their accounts their own way without the team losing the state. It's an operating system in the literal sense, the thing programs run on, not the programs themselves. The engagements stay bespoke. The substrate is shared.
You'll also see "FDEOps" emerging as a name for the same idea. Nobody owns the term, and we'd be skeptical of anyone claiming to. The practices it points at were being assembled by FDE teams themselves before anyone tried to brand them, as the quotes above show.
One framing rule matters more than any tooling choice: the OS serves the FDE first. A layer that mostly produces reporting about FDEs will be starved of input within a month, and deservedly. Every layer below earns its place by giving the individual engineer back time or context, with team-level legibility as the byproduct.
The five layers teams converge on
Across the teams we talk to, the sketches differ in tooling and vocabulary but keep resolving into the same five layers.
The playbook and SOP layer
The repeatable edges of engagements: kickoff checklist, security questionnaire, environment setup, go-live cutover. This layer is real but thin, because only the edges repeat. Teams that try to playbook the middle of an engagement end up with documents nobody opens. What's worth writing down, and how to keep it honest, is its own topic, covered in FDE playbooks and repeatability.
The shared context layer
This is the load-bearing layer, and notably it's what the FDE quoted above named as the point of his whole FD OS: "a shared context repository for for everyone." Per account, it holds what was promised, what was decided and why, what's at risk, and what's next, each fact with its source. It's the layer that makes the others cheap: briefs generate from it, ramp runs on it, handoffs point at it. The full argument is in the shared context problem for FDE teams.
It's also the layer teams most often build themselves, and where builds struggle. In our experience a regular home-built brain (Obsidian and the like) drifts somewhere between 500 and 1,000 facts, because reconciliation is nobody's job. Context drift in home-built brains covers why, and build vs buy for the shared context layer covers the decision. Done well, the payoff is the one Aircall reports: "We're seeing engineers confidently run rollouts they've never been on a call for. The memory belongs to the team, not the person," per Tom Chen, CPO at Aircall.
The task layer
FDE tasks are generated on the fly, from calls, from broken integrations, from a customer's Tuesday panic. So the task layer is deliberately boring: any tracker works if tasks link back to the account context that explains them. Teams that force FD work into a phased project plan here find the plan fictional by week two. More on tool choices in the FDE stack for 2026.
The brief and reporting layer
The brief exists for the FDE first: it's what lets them walk into a call prepared without an hour of scroll-back, and it's what answers "how's the Acme rollout?" so they don't have to. A manager or a sales counterpart reading the same brief is the byproduct that kills the status meeting. The practical bar: briefs on demand or on a schedule, delivered where people already are, including Slack, and generated from the context layer rather than written. That's what replaces the half-day monthly collation ritual.
The time and capacity layer
The quietest layer, and the one heads of FDE teams ask for last but need for pricing and staffing. A cofounder running the FD team at a data-migration startup told us effort varies wildly between clients paying the same. Without some record of where effort actually goes, that variance is invisible, accounts get priced wrong, and the most conscientious FDE silently absorbs the overload. The point of this layer is capacity math and fair loading, not timesheet policing, and teams that let it become policing lose the other four layers with it.
FD work is a direction, not a phased playbook
Here's the honest part, and the reason so many process-first FD OS attempts die. Forward deployed work doesn't decompose into phases you can gate. An engagement has a direction (make this customer succeed with this system) and a stream of tasks generated on the fly as reality talks back. The 2025 DORA research found that AI amplifies what's already there rather than fixing a team, and the same is true of process: an OS layered onto improvised work amplifies the improvisation instead of replacing it.
So the useful FD OS optimizes for legible state, not controlled process. It doesn't tell the FDE what to do next, they know better than the OS does. It makes sure that whatever they did, the promises, decisions, and risks it produced are queryable by the next person who needs them. That's also why the context layer is load-bearing and the playbook layer is thin, and not the other way around.
Where each layer lives today
- Spreadsheets + Slack. Playbook layer: Pinned posts, tribal memory. Context layer: Scroll-back and trackers, per person. Brief layer: Written by hand, varies by team. Maintenance cost: Low tooling cost, high human cost.
- Docs and a wiki. Playbook layer: Good fit. Context layer: Snapshots that decay, unquantified. Brief layer: Collated by hand monthly. Maintenance cost: Someone's side job.
- DIY build (vault, scripts, vector store). Playbook layer: Varies. Context layer: Works solo, drifts at team scale. Brief layer: Scripted, brittle. Maintenance cost: An unbudgeted internal product.
- AI workspace with an account brain. Playbook layer: Linked from context. Context layer: Source-linked, synced from calls, Slack, tickets. Brief layer: Generated on demand or scheduled. Maintenance cost: Curation and approval, not upkeep.
Row one is the real incumbent, and it deserves respect: it's free, universal, and every team starts there. It just concentrates the OS in individual heads, which is exactly what the OS exists to stop.
How to stand up an FD OS without stopping delivery
You can't pause accounts to build internal systems. The sequence below works incrementally.
- Write down the three plays you actually repeat. Kickoff, security review, cutover, whatever your true edges are. Keep it to three rather than thirty, and resist documenting the middle of engagements, because that part doesn't repeat.
- Stand up the shared context layer before buying or building anything else. It's the layer the others generate from, and the one with the worst failure mode when skipped. Decide build vs buy explicitly, with drift as a named criterion.
- Make briefs generate from the context layer. The week status reports stop being written by hand is the week the team starts believing in the OS, because it's the first layer that gives time back instead of asking for it.
- Add the task and time layers in the open. Keep the tracker you have, link tasks to account context, and introduce time data with its purpose stated: capacity and pricing, visible to the FDEs it describes, serving them first.
- Revisit the OS at every hire. Each new FDE is a live test of whether the OS transfers. If ramping the second FDE still requires weeks of the senior narrating history, the context layer isn't done, whatever the wiki says.
What stays manual
Direction stays with the FDE. The OS holds state, it doesn't decide what tomorrow's tasks are, and any team promising otherwise is selling phases again under a new name.
Judgment and the customer relationship stay human, which is why ramp and handoffs still involve paired calls even with a complete context layer. The playbooks are written and pruned by people who run the plays. And in Tandem specifically, agents draft and a human approves: briefs, risk summaries, and synced updates only guide customer-facing work after someone on the team has said yes. What syncs into the brain is chosen, not automatic.
What the OS buys you
The point of the five layers is capacity without hiring ahead of revenue. Sellsy's version of the outcome: 3x accounts per implementation manager, same team, same quality. At larger scale the math gets explicit. Qonto's onboarding org runs about 90 specialists. Tandem's automated coordination and day-three delay detection let the team absorb 34% more volume and avoid roughly 23 hires. At €80K to €100K fully loaded per specialist, that is €1.8M to €2.3M in avoided payroll against a Tandem cost of about €0.85M a year, a 2 to 2.7x return in year one.
Tandem is the AI workspace for implementation and deployment teams, and it's built to be the context, brief, and risk layers of exactly this OS. See it hold the state on your real work: book a demo and watch Tandem flag the risks on one of your live engagements, sources attached.
FAQs
What is an FDE operating system?
The minimum set of shared layers (playbooks, shared context, tasks, briefs, time) that keeps a multi-FDE team coherent while each engineer runs engagements their own way. Its business outcome is capacity: more accounts per FDE and faster ramp for each hire. It holds state rather than dictating process, because FD work doesn't follow phases.
Is FDEOps a real category?
It's an emerging term for the practices described here, and the practices are real. The teams we talk to were building "FD OS" repositories on their own before any tooling category formed around the name. Judge any tool against the five layers and the FDE-first rule, not against the label.
Do we need all five layers on day one?
No. Solo FDEs need almost none of it, and the trigger is the second or third hire. Start with the shared context layer, generate briefs from it, and add playbooks, task linkage, and time data as the team's size makes each one pay for itself.
Isn't this just process overhead for engineers?
That's the failure mode, and it's earned when the OS is built to produce reporting about FDEs. Built right, the flow reverses: the FDE gets call prep, ramp context, and freedom from status meetings, and legibility for the rest of the company falls out as a byproduct. If a layer costs an FDE more time than it returns, cut it.
Can't we run the OS on spreadsheets and Slack?
You already do, that's the incumbent. It works until the second FDE, the first handoff, or the first month where collating status eats days. The layers don't change when you tool up, they just stop living in one person's head and evening hours.
Key terms
FDE operating system (FD OS): The shared layers a forward deployed engineering team runs on: playbooks, shared context, tasks, briefs, and time. Coined independently by multiple FDE teams describing their internal builds.
FDEOps: An emerging synonym for the same set of practices. The term is unowned, and the practices predate it.
Forward deployed engineer (FDE): An engineer who spends roughly half their time with customers understanding the problem and half building the solution for that specific customer.
Shared context layer: The per-account record of what was promised, decided, at risk, and next, source-linked and queryable by the whole team. The load-bearing layer of the OS.
Brief: A generated summary of account state, produced on demand or on a schedule and delivered where people work, including Slack. Exists so nobody writes status by hand or answers "how's the rollout?" from memory.
Account brain: Tandem's product implementation of the shared context layer, with risk detection, Tandem agents operating under human approval, and a customer workspace.