Every other page on this site assumes you want the job and prepares you to win the interview loop. This page serves the decision that comes before that: whether to enter the loop at all. The engagement arc — discovery through handover — is taught in Customer Outcomes; the subject here is the job as lived, assembled from the public record: how much you travel, where a week's hours actually go, how long you stay with one customer, how the role is measured and paid, and why people leave. Where the record is thin, or where the source has an interest in the answer, that is said plainly.
The week
How much you travel
The most detailed first-person account is Nabeel Qureshi's 2024 essay on his years as a Palantir forward deployed engineer. FDEs, he writes, were "typically expected to 'go onsite' to the customer's offices and work from there 3-4 days per week, which meant a ton of travel". In his case that meant a year in Toulouse, at Airbus, four days a week.
Company-side figures run lower. The Pragmatic Engineer's deep dive on the role reports that Palantir expects around 25% of an FDE's time onsite, that Commure expects up to 50%, and that OpenAI's pattern is a couple of days onsite for scoping, then a few days per week onsite during delivery. (That article is paywalled from mid-way; every figure quoted here sits in the free portion.) Anthropic's posting for its Applied AI forward deployed engineer role listed "Potential Travel (based on location) to customer sites to build in person with customers. - Estimated 25%" alongside a $200,000—$300,000 USD band. That posting stopped accepting applications by July 2026 and survives on the portfolio-board mirror linked here, so treat both figures as historical; for current roles, see companies hiring FDEs.
The widest numbers come from postings math rather than from measurement. Henley Wing Chiu's analysis of ~1,000 forward deployed engineer job ads (November 2025, updated January 2026) found that 68% of the roles require travel, with builder-type FDE postings advertising 30–50% travel alongside 70–90% coding. Read those as what employers advertise. No published source measures how much FDEs actually travel once hired; the first-person accounts above are the closest available ground truth.
Where the hours go
Two kinds of source describe the weekly split, and they disagree. Decoding Google's FDE posting in May 2026, Gergely Orosz estimates the week at roughly 25% coding, 50% integration and plumbing, and 25% meetings and customer hand-holding. The bloomberry postings analysis, by contrast, reports builder-type FDE ads advertising 70–90% of time spent coding. The gap has a plain explanation: job ads are written to attract engineers, while a decoded posting and first-person accounts describe delivered weeks. Plan against the lower coding share and treat anything above it as upside.
The same decoding article translates the posting's "founder's mindset" requirement into operational terms: no one provides a spec, and scope creep is your problem to manage. It also warns the role is likely to stay unattractive to experienced developers, "for whom being a consultant may feel like a step down" — the consulting comparison this page takes up below.
Palantir has published its own account, a company-blog "day in the life" of a forward deployed software engineer (November 2020): a chunk of the day designing, writing, and testing workflows; a portion configuring the platform; and reserved time for communications, email, meetings, and stand-ups. That broadly matches the decoded split, but weigh the source — this is the company describing its own role in its best light.
One day, reconstructed
No source narrates a full onsite day end to end, so this subsection assembles one. It is a reconstruction: a composite Tuesday, built from the accounts above at the granularity they support — the blocks come from the sources; their order within the day is this page's arrangement. The setting is Qureshi's — at the customer's offices three to four days a week, which in his case meant a factory in Toulouse, working "alongside the manufacturing people four days a week."
Morning is spent at the customer's office, inside the customer's systems and permissions. This is where the roughly half of the week that goes to integration and plumbing lives, and Qureshi breaks that work down: getting access to enterprise data, which usually means negotiating with the data's owners inside the organization; cleaning and sometimes transforming it into a usable form; and putting it somewhere the whole team can reach. The raw material is the customer's own, much of it unstructured files and spreadsheets, and when the morning stalls, the blocker is often organizational: the team that controls the data source you need may justify its existence by gatekeeping it.
Then a block of building. Palantir's day-in-the-life engineer describes the maker portion in two parts: "a chunk of my day is spent designing, writing and testing workflows", and another portion spent "configuring Gotham to unlock new functionality within the platform" — in his case "configuring new data models or working on stability improvements and upgrades." The decoded Google split prices the pure-code share of the week at about a quarter. One weight on the source: that engineer gave the interview while working "remotely full-time due to COVID-19" — his location that year differs from the onsite pattern this page documents, and the task list is the durable part.
Then the meetings. The same engineer reserves time each day "for comms, emails, meetings and stand-ups" and filters the vendor's own calendar with a standing question: "Does this discussion have to be a meeting? And do I have to be there?" The customer's calendar filters less easily. The data-access negotiation above is conducted in the customer's rooms at the customer's pace, and Qureshi's account of what success required is partnering with corporate or government counterparts "at the highest level" and gaining their trust. The decoded posting reserves about a quarter of the week for meetings and customer hand-holding. No source counts a day's meetings, so this reconstruction gives no count.
Evening. Where the customer is far from home, embedding means living there: Qureshi moved out to Toulouse for a year, and in his first month could not fly out of the city because the air traffic controllers were on strike every weekend. The norm behind that schedule was cultural: "get on a plane first, ask questions later."
What this day leaves blank — the exact meeting count, the specific tools at a specific customer, the hours worked — is blank in the sources too.
The engagement
Analyst descriptions give the arc a consistent shape. Everest Group's November 2025 note describes engagements that open with a rapid prototyping sprint on the client's own data, aimed at one or two high-value problems, then layer in further use cases, eventually standing up a Center of Excellence inside the customer.
The documented timelines run longer than the sprint framing suggests. In a secondary writeup of an OpenAI talk on the Morgan Stanley engagement, the pipeline was built within 6–8 weeks, followed by about four months of pilots, feedback, and evaluation refinement — the point of the talk being that technical readiness alone was insufficient. The same writeup describes an FDE team embedded onsite for several weeks with a semiconductor customer. At the far end, Qureshi's Airbus embedding ran about a year.
Teams are small. Qureshi describes Palantir's customer-facing teams as typically 4–5 people, fast and autonomous, paired with a separate product-development team that generalizes field solutions into product features. The Pragmatic Engineer reports that OpenAI's John Deere project was staffed by the Head of FDE plus one FDE.
One operational fact the public record does not answer: how many engagements a single FDE runs at once. The first-person accounts describe one deep embedding at a time, but no source states a load, so none is given here.
Where you sit
The role is post-sale. In the bloomberry analysis, zero of the ~1,000 postings examined mention a quota; the role is measured instead on production uptime, adoption, and technical outcomes. The analysis offers a screening rule you can apply to any posting: if it carries a quota or commission, it is a sales-engineer role, whatever the title says. The same ads-versus-delivered-week caution as above applies — what postings omit is evidence about the advertised role — but here the first-person accounts point the same way.
There are edges. The Pragmatic Engineer reports that sales sometimes offers an FDE pre-sale, to help an undecided customer integrate. And the business logic that pays for the role is expansion: Everest Group describes forward deployed teams as the engine of land-and-expand, with revenue tilting toward software subscription over time. Andreessen Horowitz (a16z) makes the same argument from the investor side in its essay on services-led growth: forward deployed teams need close alignment with account executives but should avoid carrying quotas, which can lead to counterproductive behavior; the strategic thesis is trading margin for moat, with feedback loops from the field into the product.
So is it consulting?
The cleanest structural test comes from Thomas Otter: "If you invoice this work to the customer it is consulting, if you don't it is customer success, support or presales." By that test, most FDE work sits on the second side — the customer buys the software subscription, and the engineer's time is the vendor's own investment in making the subscription land and grow.
The pattern is also older than the title. Otter points out that early SAP was built at customers like ICI and John Deere. The remaining differences from consulting are structural: The Pragmatic Engineer notes that consultants make one-off recommendations while FDEs work with customers long-term, and Everest Group draws the line as consultants selling time and expertise versus Palantir deploying its own people, on its own stack, into production.
Otter adds a structural warning worth knowing before you join: when a company's strongest technical people are project-facing, it struggles to build standard product. That tension between field and product is the organization you would be sitting inside, and it is the reason the paired product-development teams described above exist.
For the adjacent-role distinction — forward deployed engineer versus solutions architect, and how the title varies by company — see Company Differences, which draws that line from primary sources.
Where it leads, and why people leave
The best-documented exit is founding a company. Concept Ventures' deep dive counts over 111 companies founded by Palantir alumni, which had raised $11.6 billion by 2024, finds Forward Deployed Engineer the most common founder background among them, and names Mati Staniszewski of ElevenLabs and Quinn Slack of Sourcegraph. Qureshi's explanation is that ex-FDE founders succeed on an instinct for rooms, dynamics, and power, and he observes that Y Combinator (YC) batches typically contain more ex-Palantir founders than ex-Google founders, despite Google's vastly larger headcount.
The attrition signal is equally on the record. Barry, a Palantir deployment strategist for roughly five years, describes engineer burnout as a cost the model accepted, in a post on FDE culture. No company publishes attrition figures for the role; that first-person line is the honest signal available.
One newer structural fact, reported by The Pragmatic Engineer in 2026 and worth verifying at offer time: OpenAI and Anthropic are pushing FDE hiring into separate entities — The OpenAI Deployment Company, and an Anthropic venture with outside investors. If that reporting holds, the equity in an offer may be in the new entity rather than in the parent company. Read the offer documents closely if parent-company stock is part of the role's appeal to you.
When it fails
Both first-person accounts address failure directly, and they write at different altitudes. Barry writes at the level of the portfolio, in a post on FDE culture. He describes customer pilots staffed like small bets: a few FDEs, a tight timeline, and a mandate to make it work, with many not surviving. The losses he recounts were material, with large sums spent on pilots that in some cases ran at no margin because the work was done for free, with no monetization strategy set in advance and a high failure rate. He also names engineer burnout as one of the recurring costs the model absorbed. Read it as one insider account, qualitative rather than a measured failure rate.
Qureshi writes at the level of the single deployment, in the same essay cited throughout this page. He describes the obstacles as mostly political: the data-access gatekeeping described earlier could consume an entire engagement, so that a two-to-three-month pilot went largely to getting access, with only a final scramble left to produce something to demo. He argues the role demanded a strong sensitivity to social and organizational context, and that without it an engineer was unlikely to integrate the customer data or drive adoption, which meant the engagement failed. The less glamorous parts he names are smaller-grained: field code that tends toward technical debt and workarounds, and travel spend that ran high for a long time.
Grade all of this as what it is: two insiders describing one company, Palantir, and both treating failed engagements as a cost the model was built to absorb. What neither account gives is a number. Barry's "Most didn't make it" is the closest the record comes to a pilot failure rate; no source quantifies it further, and nothing published describes who — on the vendor's side or the customer's — carries the blame when an engagement is cancelled.
Should you want this?
The facts above support some fair inferences about fit. You will likely dislike this role if:
- You want to be near the core product or the model. The work happens inside a customer's organization, and a separate product team generalizes what you build into features; the field is structurally one step removed from the product.
- You need a spec, and owning scope drains you. The decoded Google posting is explicit that "founder's mindset" means no one provides a spec and scope creep is yours to manage.
- Weekly travel, or living onsite for months, is a dealbreaker. The first-person account is 3–4 days a week at the customer, and 68% of analyzed postings require travel.
- You resent building things another team will rewrite. Generalizing field solutions into product features is explicitly a separate team's job, so the version you shipped is often raw material for someone else's version.
- Being the face the customer blames lands hard on you. The role is measured on adoption and uptime inside someone else's production environment, and Barry's account of burnout describes what absorbing that pressure for years can cost.
The mirror also holds. You will likely want the role if a customer's metric moving is a satisfying unit of reward — the role is measured on exactly that — if ambiguity reads to you as room to operate, and if the founder-shaped skill set is the one you intend to build: the Palantir alumni record documents where that path can lead.
Sources, and what they can carry
Next: The Interview Method — if the job still sounds like yours, here is the loop that hires for it.NextThe Interview Method