Deciding Whether Your Team Needs an FDE: Six Signals

The short answer

You likely need an FDE when the same failure pattern repeats at the customer boundary: requirements arrive wrong, implementations slip, pilots never productionize. One strong FDE compresses discovery, build, and operations into one accountable person - often cheaper than the coordination cost you're silently paying.

Six signals you need one

1. Implementation debt. Sales closes with promises; delivery discovers reality; every project starts with a rebuild.
2. Discovery lottery. Project success depends on which engineer got the requirements call.
3. Pilot graveyard. AI/automation POCs wow internally, die before production (no owner for the last mile).
4. Escalation dependency. Your best engineer is the single point of failure for every angry customer.
5. Integration backlog. Real revenue blocked on connecting two systems, queued behind product roadmap.
6. Churn after go-live. Deployments work but customers can't operate them; support tickets, low adoption.

When you don't need one

• Product is young and customers configure, rather than integrate (a good support engineer covers it).
• Deliveries are genuinely one-time (contract it; don't hire the function).
• Your problem is sales qualification, not delivery (hire/fix presales first - an FDE won't fix bad scoping upstream).

Cost framing

Compare honestly: FDE salary vs the current spend - senior engineers' context-switch hours, failed implementations, delayed integrations, pilot write-offs. Most teams find the FDE is revenue protection, not overhead: they convert blocked integrations into live systems.

First hire profile

For the first FDE: senior, broad, high-communication, allergic to ambiguity. Weight discovery and ownership over niche stack fit - the stack changes; the judgment doesn't. Then onboard deliberately.

Continue: Hiring playbook · Talent network