FDE operating model

An FDE operating model describes where forward-deployed engineers sit in an organisation, who they report to, how they are assigned to work and how their skills are kept current. There are three common patterns: a central pool that is assigned to projects, embedded teams that stay inside one business unit, and a hub and spoke design where a small central group sets standards and supports regional teams.

The choice matters because it decides who owns the system after handover, which is the question I see teams settle last when they first try the role.

In practice

For a single client, I usually start with an embedded deployed team, because the context is the constraint. For a firm that runs many engagements, a central pool with clear rotation rules works better, provided each assignment ends with a handover to a named owner. For a global capability centre (GCC) that serves several business units, hub and spoke gives the most consistent standards, and the hub must be small enough to avoid becoming a gate.

I cover the GCC variants in more detail in the article on operating models for Indian GCCs.

Example

[Composite] A services firm had forward-deployed engineers spread across six accounts with no common standards. The fix was a hub of two senior engineers who owned the evaluation templates and the handover pack, while delivery stayed in the accounts. Handover defects dropped because every account used the same pack.

Common mistakes

• Creating a central pool without an owner for each system. Engineers move on; the system must stay with someone.
• Making the hub a review board that every project waits for. Standards should be templates, not approvals.
• Copying an operating model from another company without matching the number of clients and the regulatory load.