- Keep the team's responsibilities narrow enough to test, or the FDE negotiates every decision while the customer waits.
- Give the FDE lead the standing authority to stop or change a delivery plan, so escalation does not depend on personal influence.
- Do not set a customer-per-FDE ratio: a configuration project and a high-risk integration are different loads.
- Handoff is finished when a named operator can run the workflow and recover it, not when the delivery date passes.
- Review the team after a few engagements on delayed decisions, failed handoffs and repeated work, not on headcount.
Five things to write down first
Write down five things for the first set of engagements:
- the problem and the users the team serves
- what the FDE builds, configures or advises on
- what counts as a production handoff
- which decisions need product, engineering, security or sales review
- how the team records repeated problems and evidence from delivery
FDE work can include planning what the customer deploys first, integrating and configuring the product, proving it works before the sale, keeping customers running after launch, or building for teams inside the company. Those are related, and they are not a reason to hand one team every customer-facing and internal technical task.
Give each partner a clear responsibility
| Partner | Owns | Must receive from the FDE team |
|---|---|---|
| Engineering | Product reliability, shared platform code, security fixes, technical standards | Reproducible issues, implementation context, production evidence |
| Product | Priorities, supported workflows, decisions about repeatable needs | Patterns across engagements, user impact, the cost of leaving a gap open |
| Sales or account team | The commercial relationship, commitments, expectations | Delivery scope, risks, conditions that affect the commitment |
| Support or operations | The support path and incident handling after handoff | Runbook, ownership boundary, monitoring, escalation details |
| FDE team | Discovery, solution delivery, validation, agreed handoff | Access to the people and systems needed to do that work |
Assign customers by work, not by count
Keep a written assignment record: the customer, the goal, the current phase, the named FDE owner, the engineering and product partners, the next decision, the risks, the access requirements, and the handoff condition. Track what consumes capacity: active deployments, unresolved incidents, review time, travel days, waiting on access, and work returned after handoff.
Make handoff a deliverable
- The named operator knows the workflow and can perform the routine tasks.
- Monitoring or checks show whether the workflow is working.
- Failure behaviour and rollback steps are written down and tested.
- Security, access, data retention and support ownership are clear.
- Open limitations are visible to the customer or internal team.
- Product and engineering have what they need to decide what becomes a shared capability.
Handoff does not mean the FDE disappears. Define the support path, the time-bound follow-up, and the owner for future changes. If the same workaround appears across several engagements, take the pattern to product rather than adding another private fix.
Keep travel purposeful
Travel belongs in the role when the work needs access to a customer's environment or an in-person operating change. Say when it is expected, what remote work covers, and how the team handles a change in the customer's schedule. Travel is not a substitute for a missing owner, runbook or access process.