The impossible FDE requisition usually starts reasonably. The company needs someone who can understand the customer, write production code, and work across product. Then it adds security judgment, data architecture, executive communication, change management, commercial instinct, incident ownership, and the ability to turn field work into product strategy.
Calling the role “senior” does not make those responsibilities compatible at unlimited scale.
Early teams can succeed with a remarkable generalist because one person holds the deployment in working memory. The scaling mistake is to search for an even rarer person. Design the responsibility topology instead: what must be owned, which artifacts connect the work, and which node is actually overloaded.
Public role snapshots show decomposition
Current public pages offer clues, with an important limitation. They are volatile hiring and company snapshots, not organization charts. They do not prove reporting lines, staffing ratios, or actual team composition.
Cursor's careers page currently separates roles such as AI Deployment Manager, Field Engineer, Forward Deployed Engineer, Forward Deployed Strategist, Product Education Engineer, and Solutions Architect. Sierra's careers page lists deployed-infrastructure roles alongside product, platform, identity, security, and agent engineering.
Writer says its customer organization spans professional services, forward-deployed engineering, AI adoption, and transformation directors. Glean describes an internal team and a parallel customer-facing AI Outcomes team. Decagon's public material uses both agent deployment engineering and Agent Development language.
These companies may organize work differently. The narrower, durable signal is that early FDE responsibility can separate into deployment, infrastructure, strategy, education, adoption, transformation, and product-learning functions.
A five-node topology
These are responsibility nodes, not five mandatory hires.
1. Deployment lead
Qualification, workflow scope, stakeholder decisions, delivery cadence, risk, and the expand-or-stop call meet here. The deployment brief is the control artifact: user, workflow, baseline, dependencies, acceptance condition, and accountable customer decision-maker.
2. Solution and build
This is the working system: agent behavior, applications, integrations, data flows, test harnesses, and technical decisions. Repositories, architecture decisions, evaluation sets, release records, and technical handoff make the work inspectable.
3. Platform and control
Environment, identity, permissions, security engineering, observability, reliability, and change control need a technical home. The authority-and-control map connects what the system can do to approved action and runtime operation. It does not replace accountable customer security, privacy, or legal decisions.
4. Adoption and outcome
Release is not adoption. Someone must own user readiness, workflow change, baseline evidence, observation of use, support design, and the next decision. The evidence plan separates activity from an agreed operating result.
5. Product learning
Field-created work needs a disposition: product requirement, reusable delivery asset, bounded exception, or discard. A product-learning decision record names the pattern, evidence, accountable product party, and next step. It does not grant permission to retain or reuse customer data, code, or proprietary artifacts.
The topology changes emphasis over the deployment lifecycle. Qualification leans on the deployment lead and customer workflow party. Build intensifies solution and control work. Rollout shifts attention toward adoption, runtime operation, and evidence. Stabilization and transfer require all five nodes to agree on what remains, who carries it, and what field-created work returns to product. Designing those transitions prevents a role that was right for discovery from becoming the accidental owner of production forever.
Nodes are responsibilities, not headcount
A young vendor may have one person cover deployment lead, build, and product learning while a platform engineer covers controls. A larger field organization may split the nodes across teams. A complex customer may supply workflow, control, and adoption leadership while the vendor supplies build and product learning.
All can work. Combining roles is not the failure. Leaving a responsibility implicit because one talented person has been absorbing it is.
This distinction creates a useful overload diagnostic:
- Engineers waiting for workflow decisions point to a deployment-lead gap.
- Releases blocked on access, environment, or assurance point to platform and control.
- Working systems with weak use point to adoption and outcome.
- Customer forks and repeated manual delivery point to product learning.
- A growing backlog of unfinished integrations points to solution-and-build capacity or an unbounded scope.
Adding another generalist may help one symptom while leaving the decision system unchanged.
Artifacts are the interfaces
Org charts show reporting. Deployments move through artifacts.
A deployment brief connects customer context to build. An evaluation set connects desired behavior to working evidence. An authority-and-control map connects capability to permitted action. An adoption plan connects release to use. A disposition record connects field learning to a product decision.
Each needs one accountable party, named contributors, and an acceptance point. The handoff should contain something inspectable: a reviewed decision, runnable test, observed workflow, or accepted operating procedure. Meetings support those artifacts; they do not replace them.
Transfer by design begins here. If the customer will operate the system, customer parties enter the topology before the final week. If the vendor will operate it, runtime and escalation obligations must be explicit. Senior field talent cannot compensate for an ownerless production boundary.
Hire for the missing node
The topology creates more credible career paths. An FDE does not need to be equally exceptional at every node. A systems engineer can grow deployment judgment. A consultant or integrator with strong workflow and change skills can deepen technical delivery. Another practitioner may specialize in product learning across repeated deployments.
Breadth still matters because field work crosses boundaries. But candidates can be evaluated against the responsibility mix the company actually needs, not a mythology of the perfect generalist.
Before opening the next requisition, map the five nodes for deployments already in flight. Inspect the artifacts. Find the decisions that wait, the work that forks, and the handoffs that fail. Then hire, assign, or partner for the missing responsibility.
The scalable FDE organization makes senior judgment, technical depth, controls, adoption, and product learning work as one delivery system—even when no single person carries all of it.