A forward deployed engineer spends the week inside a customer’s business: discovery on Monday, a working slice by midweek, and a handoff on Friday that the customer’s team can run. The days below are a composite drawn from published accounts, a pattern rather than a timetable.
Key takeaways
- What a forward deployed engineer actually does from Monday discovery to Friday handoff.
- Why the mix of building, customer time and product feedback shifts across an engagement.
- How the role is measured, and why employers are hiring for it now.
What is a Forward Deployed Engineer? Role, lifecycle and how FDEs are measured
What a forward deployed engineer does and where the role began
A forward deployed engineer (FDE) is a software engineer embedded with a customer to make a product work in that customer’s environment. According to First Round Review, the FDE builds the “last mile” of the product to work in production, and unlike a solutions consultant or sales engineer is still an engineer who writes and debugs production code.
The Pragmatic Engineer reports that Palantir created the role in the early 2010s and called it “Delta”, and that until about 2016 the company had more FDEs than ordinary software engineers. Other accounts, such as Plank, date it to around 2006, so the exact year is disputed. What is not disputed is the logic: the software was powerful, and customers needed an engineer beside them to make it useful.
AIU built the Certified Forward Deployed Engineer (CFDE)™ as the first certification standard for the role. The programme teaches, and a separate examination certifies. The rest of this article is the work itself.
Monday: discovery before any code
Monday is for listening. An illustrative start: the engineer joins the customer’s stand-up, then spends an hour watching an analyst do the workflow by hand. In one published account from Vibe Engines, the analyst performs two undocumented steps she never mentions in meetings, and one of them invalidates the engineer’s data model.
Discovery can also be a workshop. Georgia Southern University’s careers office describes a Monday spent with a customer’s data team, scoping which of twelve fragmented data sources matters for a forecasting use case. Either way, little code gets written. The same handbook puts discovery weeks at about 15% building and 70% customer time. Engineers who measure themselves in commits find this uncomfortable, and it is where the engagement is won or lost.
The unglamorous work starts early too. A long security questionnaire done in week one, rather than at the end, is the difference between shipping and a good proof of concept that IT vetoes months later.
This is one stage of a longer arc, and a single week often touches several stages at once.
AIU teaches the deployment lifecycle in seven stages: post-sale handoff, discovery, scoping, build, deploy, iterate and hand-back.
Tuesday and Wednesday: build on their data, demo to their people
By midweek the engineer is building the narrowest thing that changes one decision. According to Paraform, a typical Tuesday is heads-down building inside the customer’s environment, and Wednesday is demos, requirements gathering and turning needs into specifications.
The obstacles are mostly the customer’s own infrastructure. In the Vibe Engines account, a third source system returns a 403 error from inside the customer’s network because of egress rules, and ninety minutes go on working it out with their network team, much of it waiting. The engineer uses the wait to write the evaluation that will define what “working” means. That habit matters: without an agreed definition of working, every demo becomes an argument about taste.
The handbook describes prototype weeks as roughly 60% building, with weekly demos on the customer’s data and scope shifting each time. A demo is a discovery tool as much as a progress report: five new “can it also” requests will arrive, and two of them will reveal the real problem.
If the system includes an agent, permissions are part of the build. AIU teaches this as graduated autonomy.
A production agent earns write permissions after read-only trust is established.
Thursday: things break, and the evaluation decides what to do
Thursday is where the customer’s reality arrives. Paraform lists the typical Thursday as firefighting: a broken data pipeline, a model regression, or an integration due before a deadline. Georgia Southern’s example is live incident response with the customer team waiting on a fix.
A worked example shows why the evaluation set earns its keep. In the Vibe Engines account, an evaluation run against the golden set finds two regressions: one is a genuine bug, and the other is a labelling disagreement between the customer’s own experts, which the handbook calls a meeting, not a fix.
That distinction is most of the skill. The engineer fixes what is broken and takes the disagreement to the people who own the definition of correct. Writing down what changed, and what is deliberately not being built, keeps the next scope conversation short.
Friday: handoff, feedback and what the customer can now do alone
Friday closes the loop in two directions. Paraform’s version of the day is shipping fixes and feeding edge cases back to the core product team. The Pragmatic Engineer adds that when a capability the customer needs is missing, the FDE can do the development work of adding it to the product.
The other direction is toward the customer. The Vibe Engines handbook shows the launch and handoff phase as about 25% building and 45% customer time, and notes that the customer share rises because real users arrive at launch. Expect training, adoption chasing and a short write-up of what should become a product capability.
A handoff is only real if the customer’s people can operate the system without the engineer in the room. AIU frames that check as the handover rehearsal.
Five tasks the client team performs while the deployment engineers observe.
Passing it means Monday’s question, “what does this team need to be able to do?”, has an answer you can watch.
How real weeks differ, and how the work is measured
No week looks exactly like this one. A common pattern is extended time on site during discovery and launch, with remote build days in between. The Vibe Engines handbook also treats a customer-site day as roughly a third of the calendar, so the “deployed” in the title is real but not constant.
AIU teaches how an FDE’s week is judged, and none of it is lines of code.
AIU teaches that Forward Deployed Engineers are measured on three things: deployment velocity, customer success and product feedback quality.
Employers are paying attention to the role. According to CNBC, citing Lightcast, US postings for forward deployed engineers exceeded 7,300 in the first nine months of 2026, up from fewer than 200 in 2023, though these are advertised positions, not completed hires. The same report says AWS has committed $1 billion to a forward-deployed engineering initiative and Anthropic is putting $100 million into a programme to train 10,000 FDEs by the end of 2027.
Posting counts say little about whether an individual can do the Monday to Friday work above. That is a question of practice, not headlines.
If you want to practise this rhythm under review, the next step is below.
Explore the CFDE Foundation programme →
Frequently asked questions
What does a forward deployed engineer do in a typical week?+
A forward deployed engineer splits the week between discovery with the customer, building inside the customer’s environment, fixing what breaks, and feeding lessons back to the product team. According to Paraform, a typical week runs from joining the customer’s stand-up on Monday to shipping fixes and passing edge cases to the product team on Friday. The mix shifts with the phase of the engagement.
Do forward deployed engineers work on the customer’s site?+
Often, but not all the time. According to the Vibe Engines handbook, a common pattern is extended time on site during discovery and launch, with remote build days in between. Time on site varies by employer and by how sensitive the customer’s systems are.
Where did the forward deployed engineer role come from?+
It began at Palantir. According to the Pragmatic Engineer, the company created the role in the early 2010s and called it "Delta", and until around 2016 it employed more FDEs than ordinary software engineers. Other sources date the origin earlier, to the mid-2000s.
