From Client Site to FDE: A Transition Guide for Indian IT Services Engineers

If you've ever stayed at a client office until 11 p.m. because a batch job failed and the business lead is asking why the morning report is blank—you understand that pressure. The runbook doesn't cover this failure, the person who built the integration left two years ago, the client's firewall team needs approval to open a port, and the approver is on leave. You find a workaround, explain it clearly to people who just want a time estimate, and by 2 a.m. the report is restored. Then you log a record in the tracking system and classify the whole thing as a "resolved P1 incident."

This is what Indian IT services engineers do every day. And this work is, in fact, the core of what a Forward Deployed Engineer (FDE) does.

Why your background is closer to FDE than you think

Palantir created the FDE role and laid out the key distinction in its article "Dev versus Delta": product engineers do "one capability, many clients," while forward deployed engineers (known internally at Palantir as Deltas) do "one client, many capabilities."

Think back to the last client you owned: they ran SAP, a legacy Oracle system, a half-finished cloud migration, and a security review process. You touched every part because the client needed the system to work.

Akshay Kokane, who moved from a Microsoft backend role to a Salesforce FDE, wrote that he searched "what is an FDE" after getting a recruiter call, then realized he'd been doing the job informally all along. Most service engineers who get consulting offers feel the same way.

The demand side is just as real. Salesforce describes its FDEs working in "pods," and Sarah Khalid put the business logic bluntly in her article: "Without FDEs, we risk thousands of customers stuck in pilot purgatory"—signed but never successfully deployed. If you've seen a client buy a platform and never actually use it, you've seen pilot purgatory.

Palantir and the origins of the FDE role

Palantir Technologies was founded in 2003, and its early customers were U.S. intelligence agencies and defense departments. These customers' data environments were highly customized, sensitive, and impossible to standardize, so the traditional product engineer model of "one product sold to all customers" didn't work. Palantir therefore created the Forward Deployed Engineer (FDE) role: engineers embedded directly at the client site, deeply understanding the client's specific business problems, then using Palantir's platform capabilities to build tailored solutions.

"Dev versus Delta" is a classic article circulated internally at Palantir to explain the division of labor between the two types of engineers to new hires. In the article, "Dev" is the product engineer, responsible for polishing reusable platform capabilities that serve many clients; "Delta" is the forward deployed engineer, working around multiple problems for a single client. This framework of "one capability serving many clients" versus "one client, many capabilities" was later cited across the industry as the defining description of the FDE role, and it explains why FDEs need both engineering ability and strong client communication and on-site adaptability.

Translate your work into FDE language

The problem is vocabulary. Services resumes are written for services recruiters, and the wording sounds like process compliance to an FDE hiring manager. Here's the translation table I use with my mentees:

Services industry phrasing	What an FDE hiring manager hears
On-site coordination	Client discovery: sitting with users to find the real need behind the stated one
Production support, P1 calls	Owning production: diagnosing failures in an environment you don't control
Change requests	Iterating with the customer: ship, get feedback, ship again
Knowledge transfer sessions	Handover and enablement: making the client team self-sufficient
UAT	Validating with the customer: confirming the definition of "done" and proving it
Requirements gathering	Scoping: turning a vague business problem into something buildable
Status calls with account managers	Stakeholder communication: explaining technical risk to non-technical people
Environment and access issues	Working within real constraints: firewalls, approvals, data residency

This isn't spin. The right column describes the outcomes you actually achieved, not a ticket category.

Rewrite your resume bullets

Most services resumes describe tasks; FDE resumes describe outcomes for a specific client. Here are example patterns—don't copy them, apply them to your own facts:

Before: Provided production support for a loan processing application for a banking client.

After: Owned production for a loan processing system used by branch staff at a retail bank; reduced recurring P1 incidents by tracing three repeat failures to a single upstream data source and fixing the validation logic.

Before: Handled change requests based on client requirements.

After: Delivered twelve change requests over six months for a claims team at an insurance company, sitting with two claims adjusters weekly and re-prioritizing based on the blockers they actually hit.

Before: Conducted knowledge transfer for the client team.

After: Wrote runbooks and completed handover of the reporting pipeline so the client's internal team could run it independently; support tickets to our team dropped to near zero within a quarter.

Two rules matter more than wording: every number must be real and survive follow-up questions in an interview; and don't keep client names unless your employer allows it—"a large Indian private bank" is enough.

Look at the gap honestly

Services experience gets you halfway, but three things usually stand between you and an FDE offer.

The modern AI layer. Take NeuraPath Academy's FDE job board data: as of October 12, 2026, 138 open roles across 84 companies, all sourced from employers' own career pages. AI agents were mentioned in 55 roles, LLMs in 31, RAG in 30, followed by traditional skills: AWS in 38, Python in 36, APIs in 35, Azure in 33. If you've never called an LLM API, built a retrieval pipeline, or written evaluations for one, this is your biggest gap.

End-to-end ownership. Large services accounts slice work into pieces: one person does ETL, another does APIs, a third does deployment, and a manager handles client communication. The FDE role expects one person to own everything from the first conversation to production launch. If you've only owned one slice, you need a project you owned end to end.

Public proof. Everything you've built is behind client NDAs, invisible to hiring managers. Het Trivedi landed an FDE role at an AI startup because a co-founder read his blog post about deploying models. One honest article is more useful than a polished resume.

The experience bar is looser than people assume. Of the 43 roles on the job board that specify a minimum number of years: 2 require 1 year or less, 15 require 2-3 years, 13 require 4-6 years, and 13 require 7+ years. The median is five years. Services engineers with three to six years of experience are well within range.

What RAG, LLM, and AI agents actually mean

Three high-frequency skill keywords in the article deserve elaboration. LLM (Large Language Model) refers to models like GPT, Claude, and Gemini trained on massive text corpora that can understand and generate natural language; calling their APIs is the foundation of modern AI applications. RAG (Retrieval-Augmented Generation) is an architecture that lets an LLM answer questions based on an external knowledge base: first retrieve relevant passages from a document store, then hand them to the model along with the question to generate an answer, which reduces hallucinations and supports source citations. AI agents go a step further, letting the model not only answer questions but also call tools and execute multi-step tasks (such as creating tickets or querying databases), adjusting its next action based on intermediate results. Together these three form the typical tech stack for enterprise AI applications moving from "can chat" to "can do work," which is why they come up repeatedly in FDE hiring.

A 90-day plan at 1 hour a day, 8-10 hours a week

Each phase ends with a demonstrable output.

Weeks 1-2: Get comfortable with LLM APIs. Pick a provider, write a Python script that takes messy input from your domain (support tickets, invoice descriptions, log lines) and returns structured JSON. Handle the failure modes: bad JSON, timeouts, rate limits. Output: a GitHub repo with the script, a README, and ten test inputs.

Weeks 3-5: Build a retrieval system over real documents. Write or generate a corpus of synthetic documents resembling content you know well, such as internal SOPs, policy manuals, or product FAQs. Build a RAG pipeline that answers questions and cites source passages. Output: a working app plus a short write-up of where it gives wrong answers and why.

Weeks 6-7: Add evaluation. This is the step most people skip and the one hiring managers ask about most. Create 30-50 question-answer pairs, score the system, change one variable (chunk size, prompt, retrieval count), and measure again. Output: a before-and-after results table, including changes that made things worse.

Weeks 8-10: Make it an agent that takes actions. Give the system one or two tools (such as creating a ticket or querying a small database) and add guardrails on what it's allowed to do. Log every step. Output: a five-minute screen recording demonstrating a request, a tool call, and a failure case.

Weeks 11-12: Deploy it and write about it. Put it somewhere a stranger can use, even on a free tier. Then write an article the way you'd write a client retrospective: the problem, what you tried, what broke, what you measured, what you'd do differently. Output: a public URL and a published article.

Week 13: Package and apply. Rewrite your resume with the translated bullets, link the project, and start conversations. Output: an updated resume and ten tailored applications or internal conversations.

If you fall behind, cut scope—never cut the evaluation or the writing.

Why the evaluation step matters so much

In LLM application development, "evaluation" refers to systematically measuring output quality using a set of test questions with reference answers. Hiring managers ask about it repeatedly because LLM outputs are stochastic—the same question can yield different answers, and changing a prompt or chunking parameter can make things better or worse, which you simply can't judge by spot-checking a few examples by eye. Without evaluation, you can't answer the most basic question: "did this change actually make the system better?"

In practice, this usually means preparing 30-50 question-answer pairs covering typical scenarios and edge cases, defining scoring criteria (such as whether the answer is correct and whether it cites the right source), then holding all other variables fixed and changing just one (such as chunk size or retrieval count) to compare scores before and after. This process exposes the system's real weaknesses and is the dividing line between "I built a demo" and "I can deliver this to a client." Hiring managers value it precisely because people who skip evaluation tend to discover, on their first encounter with real data at a client site, that the system isn't reliable.

The internal path: what's changing in Indian IT services

Something unusual is happening in Indian IT services: large firms are building FDE teams from within. According to a July 21, 2026 Moneycontrol report, TCS plans to move 1%-1.5% of its employees into FDE roles, HCLTech is training selected fresh graduates as FDEs, LTM's AI1000 program aims to produce 1,000 FDEs, and Coforge is targeting more than 100.

So you may not need to leave. But internal selection rarely happens through an application form. People get picked because a senior person has already associated their name with AI work that landed successfully in front of a client. Create those moments.

Volunteer for AI pilots on your account. Every large account has one now, usually understaffed and somewhat chaotic. Being the person who makes it work is worth more than any certification.

Lead client demos. Volunteer to prepare and run demos. Demos are where delivery leadership sees who can explain a system to a business audience—and that's the core FDE skill.

Write internal retrospectives. When a pilot struggles, most people stay quiet. The person who writes clearly about what happened and what should change gets noticed by exactly the people staffing new teams.

Then tell your manager and practice lead directly that you want to do FDE work. Quiet competence just gets you renewed on the same account.

What a GCC (Global Capability Center) is

A GCC (Global Capability Center) is an internal technology and operations center that multinational companies set up in low-cost regions like India. Unlike traditional IT outsourcing, a GCC serves the parent company's internal business units, doing core work like product development, data analysis, and engineering support rather than delivering projects to external clients under contract. In recent years, as India's engineering talent pool has matured, many multinational banks, retailers, pharma companies, and tech firms have established or expanded GCCs in India, placing AI capability building within them.

For services engineers, a GCC is a particularly useful springboard: its "internal clients" are also business units, with the same vague requirements, priority conflicts, and adoption problems, so the working style closely resembles the external client services you already know—except you're inside a product company's engineering culture. This is why the article says GCCs "often value services backgrounds directly": the skills you built at client sites transfer directly here, while you also gain productized engineering experience.

The external path and salary benchmarks

Three types of employers hire FDEs externally: AI startups, product companies selling into enterprises, and GCCs building AI capabilities internally. Startups move fastest and value public proof most. Product companies want a convincing engineering track record plus evidence you can handle clients. GCCs often value services backgrounds directly, because their internal clients behave much like your external ones.

According to salary ranges from TeamLease Digital cited by Moneycontrol: junior FDE roles pay 1.8-2.5 million rupees, mid-level 3-4.5 million, and senior 5-8.5 million. Note that this is one recruiting firm's view of the market, not a promise. Many roles carrying this title are closer to solutions engineering.

What interviews usually test

FDE-style interviews typically test three things beyond coding.

A scoping conversation. You'll be given a vague problem, like "our support team is drowning—can AI help?" The interviewer watches whether you ask about users, data, constraints, and how success will be measured before proposing a solution. Services engineers are usually good at this but often underestimate themselves by jumping straight to architecture.

Debugging, often on an unfamiliar codebase or a verbally described system. They want to see how you narrow down a problem, not whether you know the answer.

Explaining trade-offs to non-technical people. Why the cheaper option is riskier, why it needs two more weeks, why the model can't be 100% accurate. You've done this for years on status calls. Practice saying it in two minutes.

You will almost certainly hear "tell me about a time a client's environment threw off your plan." Structure the answer with STAR: situation, task, action, result. Show a constraint you couldn't control, a decision under pressure, a stakeholder conversation in plain language, and a lasting fix. You almost certainly have stories like this. Write them down.

The honest risks

Travel can be heavy. Many FDE roles require actually being at client sites, sometimes abroad. If you deliberately left on-site work behind, think twice.

Ambiguity is the job. If you like clearly defined, well-bounded work, FDE can burn you out. Het Trivedi described it as "like a mix of firefighter, plumber, and translator." Some people love it; some burn out.

Success is often tied to adoption. Your system can be technically excellent but still a failure if the client team doesn't use it. Some performance reviews reflect that.

Who should stay where they are? If you're on an internal product or platform team and love deep technical work, becoming an expert in that is no bad thing. If you don't enjoy client conversations, an FDE role will put you in front of more of them, not fewer. And if you're switching only for the salary headline, the first difficult client will test that motivation quickly.

What to do this week

Go through the last two years of your work against the translation table. Write down three stories where a client environment forced you to change your plan, with real numbers that survive follow-up questions. Rewrite your five most important resume bullets using the before-and-after patterns above. Find out whether your account or practice has an AI pilot and ask the lead, in person or on a call, how you can help. Block time on your calendar for the Weeks 1-2 plan, and write that first script this weekend.

One-line Summary

Indian IT services engineers' experience overlaps heavily with FDE work—close the AI skills gap, translate your resume's language, and build public proof to make the switch.

Paragraph Summary

The article argues that the core of the Forward Deployed Engineer (FDE) role—embedding deeply at client sites, delivering within real constraints, and taking things from vague requirements to production—overlaps heavily with the daily work of Indian IT services engineers. The biggest barrier isn't capability but language and visibility. The author provides a "services terminology to FDE terminology" translation table and before-and-after examples for rewriting resume bullets. The real gaps cluster in three areas: modern AI skills (LLMs, RAG, AI agents), end-to-end ownership experience, and public proof outside NDAs. The article lays out a 90-day plan at 8-10 hours a week, stressing that evaluation and writing are the most commonly skipped yet most valued by hiring managers. It also notes that TCS, HCLTech, LTM, Coforge, and others are building FDE teams internally, so services engineers may not need to leave—the key is to volunteer for AI pilots, lead client demos, and write internal retrospectives so decision-makers can see them.