FDE operating models for India's GCCs
Global capability centres in India are putting a lot into AI. In HFS Research's GCC study, only 15% of centres under 500 people had AI embedded across their delivery workflows (HFS Research). The under-500 group in that study is small, so read it as a signal, not a benchmark.
Investment is not the gap. Ownership is. A GCC has engineers, licences and a long list of pilots, but often no role whose job is to take one workflow all the way into a business unit's daily operations and hand it over.
That role is the forward deployed engineer. For GCC leaders the real question is which operating model to run them in.
FDE, solutions engineer and consultant: draw the lines first
Before choosing a model, be clear what you are building. The Pragmatic Engineer's deep dive quotes Palantir's distinction. A product developer's focus is "one capability, many customers". A forward deployed engineer's is "one customer, many capabilities".
In GCC terms:
| Solutions engineer | Consultant | Forward deployed engineer | |
|---|---|---|---|
| Main output | A convincing proof of concept | A recommendation or design | A running system, handed over |
| Stops at | The sale or the PoC | The document | A business team running it alone |
| Writes production code | Rarely | Rarely | Yes, most of the time |
| Measured on | Wins, adoption | Client satisfaction | Workflows in production, reuse |
Bloomberry's analysis of a thousand FDE job postings found about 60% describe this "builder" FDE, and that sales targets are mostly absent from the responsibilities (Bloomberry). If a GCC's "FDE" role reports into presales and is measured on PoCs, it is a solutions engineer with a new title.
Three FDE models for India's GCCs. Model 1, a central pod of two or three seniors plus a lead, time-boxed, one business unit at a time, watch for reuse. Model 2, embedded FDEs in business units plus a platform spine, which needs 500 or more people. Model 3, partner-led, where the partner leads, a GCC engineer shadows, then leads by the third engagement. Pick by size and maturity, not by fashion.
Model 1: the central FDE pod
A small pod, two or three senior engineers plus a lead, sits in the GCC's AI or platform group and deploys into one business unit at a time, on time-boxed engagements.
Works when the GCC serves many business units with similar data platforms and leadership wants a visible production win quickly.
Watch for the pod turning into an internal consultancy that never builds reusable pieces. Track what the fourth engagement reuses from the first three.
Model 2: embedded FDEs with a platform spine
FDEs are assigned to specific business units, such as finance, procurement or supply chain, for longer periods. A central platform team owns the shared parts: identity, retrieval, evaluation harness, model gateway, logging.
Works when the GCC is large enough to sustain both. HFS's GCC study helps here. Against that 15%, 56% of centres with 501 to 1,000 people have AI embedded across delivery workflows. Below that size a separate platform spine is hard to staff.
Watch for FDEs drifting into the business unit's general backlog. Their mandate is production workflows, not every request that comes in.
This is close to what Marty Cagan describes at SVPG: engineers embedded with several "customers" so they see the similarities and the differences, and feed a shared product.
Model 3: partner-led FDE with internal shadowing
An external partner supplies the FDE lead for the first few deployments. Each lead is paired with one or two GCC engineers who shadow, then lead, then hand back.
Works when the GCC has nobody who has taken an agentic workflow through security review and handover before, and it needs to learn fast.
Watch for the partner staying forever. Write the capability transfer into the terms: by the third engagement the GCC engineer leads and the partner only reviews. This is the scaffolding idea from a16z's "Palantirization of everything" applied inside one company.
What all three need
Whichever model a GCC picks, the same five things decide if it works.
- A business owner per workflow who commits weekly time and signs off the evaluation.
- A pre-agreed path through data access and security review, so each engagement does not renegotiate from zero. I go through it in the data-access negotiation.
- A shared evaluation harness, so every workflow is scored the same way. HFS found that only 15% of centres still piloting, and 17% of centres with AI embedded, cite testing and QA as a top source of AI value. Few centres treat testing as a source of value, and that is the first thing I would fix.
- Time-boxed engagements with an exit, budgeted internally by milestone. See pricing an FDE engagement.
- People assessed on what they ship. Attendance-based training will not close the ownership gap. Training where engineers ship a bounded use case and get assessed on it can.
Org design questions to settle early
- Reporting line. FDEs who report to sales optimise for the account in front of them. FDEs who report to product or platform leave behind something the next deployment can use. This point comes through clearly in lessons attributed to Palantir's FDE practice.
- Career path. If FDE is a dead end, your best engineers leave it. Define the path from FDE to senior FDE to platform or architecture lead.
- Time zone and travel. Many GCC FDEs deploy into business units in other regions. Budget overlap hours and some on-site time. This work does not go well entirely over tickets.
- Metrics. Workflows in production, time from readiness to production, cost per workflow, and share of components reused. Not number of PoCs.
Where I fit
I work with GCCs and services firms in two ways. As an architect through Aurelia Innovatives, leading or reviewing the early deployments (that is Model 3). And as a trainer, running the AIXL Academy Forward-Deployed AI Engineering cohort where engineers ship real use cases and get assessed on them. Dates and fees are on the AIXL Academy page. The method behind this is set out in forward-deployed engineering.
Common questions
What is a forward deployed engineer in a GCC?
An engineer who takes one AI workflow from a business unit's problem to a running, handed over system, including data access, evaluation, security review and handover.
How is an FDE different from a solutions engineer?
A solutions engineer usually stops at a proof of concept or a sale. An FDE writes production code and is measured on systems running in production that a business team can operate.
Which FDE model should a small GCC choose?
Centres under about 500 people usually do best with a small central pod, or a partner-led model with internal shadowing, because a separate platform team is hard to staff.
How should GCCs measure FDE teams?
By workflows in production, time from readiness to production, cost per workflow and reuse of shared components, not by the number of pilots.