You already do half of a Forward Deployed Engineer's job. Here is how to describe it, how to close the AI gap in 90 days, and how to get picked, internally or outside.
I first published this on Medium. Cross-posting here because a lot of the people asking me about this role are on DEV.
By Pankit Kumar, Senior Data Scientist and Lead Instructor at NeuraPath Academy
If you've ever sat in a client's office at 11 at night because a batch job failed and the business head wants to know why the morning report is empty, you know a particular kind of pressure. The runbook doesn't cover what broke. The person who built the integration left two years ago. The client's firewall team won't open a port until a ticket is approved, and the approver is on leave. You find a workaround, explain it to someone who only wants a time estimate, and by 2 a.m. the report is back.
Then you update a tracker that calls all of it "Resolved P1 incident."
I have spent ten years building production systems in regulated pharma and clinical settings, and now I teach people moving into Forward Deployed Engineering. The engineers in Indian IT services who come to me usually have more real-world deployment experience than the product engineers they compete with. What they lack is the language to describe it, a modern AI layer on top of it, and proof that anyone outside their account can see.
This piece is for services engineers with two to eight years behind them. My earlier piece explained what an FDE is; this one is about making the move.
Why your background is closer than you think
Palantir, which coined the role, explains the difference in its post Dev versus Delta. A product engineer builds "one capability, many customers." A forward deployed engineer, a Delta in their vocabulary, works on "one customer, many capabilities."
Think about your last account. One client: their SAP, their legacy Oracle, their half-finished cloud migration, their security reviews. You touched all of it because the client needed it to work.
Akshay Kokane, who moved from a backend role at Microsoft to an FDE role at Salesforce, writes that after the recruiter call he googled "what is an FDE" and realised he had been doing the job unofficially. I hear a version of that from most services engineers I counsel.
The demand side is real too. Salesforce describes its FDEs working in pods, and Sarah Khalid put the business reason plainly in their post on the role: "Without FDEs, we risk having thousands of customers stuck in pilot purgatory," meaning signed up but never successfully deployed. If you have ever watched a client buy a platform and then never use it, you have seen pilot purgatory.
Translate your work into FDE language
The problem is vocabulary. Services résumés are written for services recruiters, and they use words that sound like process compliance to an FDE hiring manager. Here is the translation I use with learners.
| What you call it in services | What an FDE hiring manager hears |
|---|---|
| Onsite coordination | Customer discovery: sitting with users and finding the real requirement behind the stated one |
| Production support, P1 calls | Owning production: diagnosing failures in an environment you don't control |
| Change requests | Iterating with a client: shipping, getting feedback, shipping again |
| KT sessions | Handover and enablement: making the client's team self-sufficient |
| UAT | Acceptance with the customer: agreeing what "done" means and proving it |
| Requirement gathering | Scoping: turning a vague business problem into something buildable |
| Status calls with client managers | Stakeholder communication: explaining technical risk to non-technical people |
| Environment and access issues | Working inside real constraints: firewalls, approvals, data residency |
None of this is spin. The right-hand column describes what you achieved instead of the ticket category it was filed under.
Rewrite your résumé bullets
Most services résumés describe tasks. FDE résumés describe outcomes for a specific customer. These are illustrative examples, so don't copy them; use them as a pattern for your own facts.
Before: Handled production support for a banking client's loan processing application.
After: Owned production for a loan-processing system used by a retail bank's branch staff; cut repeat P1 incidents by tracing three recurring failures to a single upstream data feed and fixing the validation.
Before: Worked on change requests as per client requirements.
After: Shipped twelve change requests over six months for an insurance client's claims team, sitting with two adjusters weekly to reprioritise based on what was slowing them down.
Before: Conducted KT sessions for the client team.
After: Wrote the runbook and ran handover for a reporting pipeline so the client's internal team could operate it alone; support tickets to our team dropped to near zero within a quarter.
Before: Participated in UAT and defect fixing.
After: Defined acceptance criteria with the client's finance lead for a reconciliation tool, then fixed the gaps that UAT exposed before go-live.
Two rules matter more than the wording. Every number must be true and defensible in an interview, because a good interviewer will pull on it. And keep confidential client names out unless your employer allows it; "a large Indian private bank" works fine.
The gap, stated honestly
Services experience gets you halfway. Three things usually stand between you and an FDE offer.
The first is the modern AI layer. Look at what employers are asking for. On our FDE jobs board, as of 12 October 2026 we had 138 open roles at 84 companies, pulled from employers' own careers pages, which is a fraction of all postings. AI agents came up in 55 of them, LLMs in 31 and RAG in 30, next to the older staples: AWS in 38, Python in 36, APIs in 35, Azure in 33. If you have never called an LLM API, built a retrieval pipeline or written an evaluation for one, that is your biggest hole.
The second is end-to-end ownership. Large services accounts slice work: one person does the ETL, another the API, a third the deployment, and a manager talks to the client. FDE roles expect one person to carry a problem from first conversation to production. If you have only owned a slice, you need one project where you owned everything.
The third is public proof. Everything you have built sits behind a client NDA, so a hiring manager cannot see it. Het Trivedi got his FDE role at an AI startup after a co-founder read his blog post about deploying a model. One honest write-up can do more than a polished résumé.
Experience requirements are less scary than people assume. Of the 43 postings on our board that stated a minimum, 2 asked for a year or less, 15 asked for 2 to 3 years, 13 for 4 to 6, and 13 for 7 or more. The median was five years. A services engineer with three to six years is squarely in range.
A 90-day plan at 8 to 10 hours a week
This assumes a full-time job and roughly an hour a day on weekdays plus a longer weekend block. Each stage ends with something you can show.
Weeks 1 to 2: get comfortable with LLM APIs. Pick one provider, write a small Python script that takes a messy input from your domain (a support ticket, an invoice description, a log line) and returns structured JSON. Handle the failures: bad JSON, timeouts, rate limits. Deliverable: a GitHub repo with the script, a README and ten test inputs.
Weeks 3 to 5: build retrieval over real-looking documents. Write or generate a set of synthetic documents that resemble something you know, such as an internal SOP, a policy manual or a product FAQ. Build a RAG pipeline that answers questions with citations to the source passage. Deliverable: a working app plus a short note on where it gives wrong answers and why.
Weeks 6 to 7: add evaluations. This is the step most people skip and most hiring managers ask about. Create 30 to 50 question-answer pairs, score your system against them, change one thing (chunk size, prompt, retrieval count) and measure again. Deliverable: a results table showing before and after, including the changes that made things worse.
Weeks 8 to 10: turn it into an agent that does something. Give the system one or two tools, such as creating a ticket or querying a small database, with guardrails on what it is allowed to do. Log every step. Deliverable: a recorded five-minute demo where you walk through a request, the tool calls and one failure case.
Weeks 11 to 12: deploy it and write it up. Put it somewhere a stranger can use it, even a free tier. Then write a post the way you would write a client post-mortem: the problem, what you tried, what broke, what you measured, what you would do next. Deliverable: a public URL and a published article.
Week 13: package and apply. Rewrite your résumé with the translated bullets, link the project, and start conversations. Deliverable: an updated résumé and ten tailored applications or internal conversations.
If you fall behind, cut scope, never the evaluation or the write-up.
The internal route
Something unusual is happening in Indian services right now: the large firms are building FDE teams from within. Moneycontrol reported on 21 July 2026 that TCS plans to move 1 to 1.5 per cent of its workforce into FDE roles, HCLTech is training selected freshers as FDEs, LTM's AI1000 programme aims to build 1,000 FDEs and Coforge is targeting more than 100.
So you may not need to leave. But internal selection rarely runs through an application form. People get picked because someone senior already links their name with AI work that went well in front of a client. Create those moments.
Volunteer for the AI pilot on your account. Every large account has one now, usually under-staffed and slightly chaotic. Being the person who made it work is worth more than any certificate.
Own the client demo. Offer to prepare and run it. Demos are where delivery leaders see who can explain a system to a business audience, and that is a core FDE skill.
Write the internal post-mortem. When a pilot struggles, most people go quiet. The person who writes a clear account of what happened and what should change becomes visible to exactly the people who staff new teams.
Then tell your manager and practice head directly that you want FDE work. Quiet competence just gets you renewed on the same account.
The external route
Outside your firm, three kinds of employer hire FDEs: AI startups, product companies selling into enterprises, and global capability centres building AI internally. Startups move fastest and weigh public proof most heavily. Product companies want a credible engineering record plus evidence you can handle a customer. GCCs often value services backgrounds directly, because their internal customers behave much like your clients.
One staffing firm's bands, TeamLease Digital's as quoted in the same Moneycontrol piece, put entry FDE roles at ₹18 to 25 lakh, mid-level at ₹30 to 45 lakh and senior at ₹50 to 85 lakh. Treat those as one firm's view of the market, not a promise. Many roles carrying the title are closer to solutions engineering.
What the interviews tend to probe
I won't claim to know any company's process, but FDE-style interviews tend to test three things beyond coding.
The first is a scoping conversation. You get a vague problem, something like "our support team is drowning, can AI help?", and the interviewer watches whether you ask about users, data, constraints and how success will be measured before proposing a solution. Services engineers are often good at this, then undersell it by jumping to architecture.
The second is debugging, frequently in an unfamiliar codebase or a system described verbally. They want to see how you narrow a problem down, not whether you know the answer.
The third is explaining a trade-off to a non-technical person. Why the cheaper option is riskier, why you need two more weeks, why the model can't be 100 per cent accurate. You have done this on status calls for years. Practise doing it in under two minutes.
You will almost certainly hear some version of "tell me about a time a client's environment broke your plan." Here is how I would shape an answer from typical services material, using the STAR structure.
Situation: "I was the onsite engineer for a data migration at a manufacturing client. We'd planned a weekend cutover moving three years of orders to a new cloud warehouse."
Task: "I owned the load scripts and the validation, and I had to sign off that the numbers matched before the business went live on Monday."
Action: "On Saturday afternoon we discovered the client's network policy throttled outbound transfers far below what we'd tested in the lower environment. The plan assumed eight hours; at that rate it would take three days. I split the load by month, prioritised the last ninety days because that was all the business needed on Monday, and moved the history to a staggered load across the week. Then I called the client's operations head, explained in plain terms what they would and wouldn't see on Monday, and got written agreement."
Result: "Go-live happened on schedule with current data. The history finished by Thursday. I added a network throughput check to our pre-cutover checklist, and the account used it on the next two migrations."
That answer shows a constraint you didn't control, a decision under pressure, a plain-language stakeholder conversation and a lasting fix. You almost certainly have stories like it. Write them down.
The honest risks
Travel can be heavy. Many FDE roles expect real time at customer sites, sometimes abroad. If you left onsite work deliberately, think hard before going back.
Ambiguity is the job. If you enjoy well-defined work with clear boundaries, you may find FDE work exhausting. Het Trivedi called it "like being a firefighter crossed with a plumber and a translator." Some people love that. Some people burn out.
Success is often tied to adoption. Your system can be technically excellent and still count as a failure if the client's team doesn't use it. Some performance reviews will reflect that.
So who should stay put? If you are on a strong product or platform team inside your firm and you enjoy deep technical work, there is nothing wrong with becoming excellent at that. If you dislike client conversations, FDE roles will put you in more of them, not fewer. And if you are switching only because of the salary headlines, the first difficult customer will test that motive quickly.
What to do this week
Take your last two years of work and run it through the translation table. Write down three stories where a client's environment forced you to change a plan, with real numbers you can defend.
Rewrite your top five résumé bullets using the before-and-after pattern above.
Find out whether your account or practice has an AI pilot, and ask the person running it how you can help. Do this in person or on a call, not by email.
Block your calendar for weeks 1 and 2 of the plan, and write the first script this weekend.
If you want a running list of open FDE roles and our notes on preparing for them, both are free at neurapath.in/forward-deployed-engineer.
Over to you: if you have made the move from a services account into an FDE or solutions role, what was the one thing that got you the interview? I'll add the useful answers to the next edition of this guide.
Pankit Kumar is a Senior Data Scientist at Parexel with ten years in data science and AI, much of it building production systems in regulated pharma and clinical settings. He leads the forward deployed engineering programmes at NeuraPath Academy in Noida.
Top comments (0)