What is FDE — Engineers Deployed to the "Front Lines" and the Explosion of 2026
In a word, an FDE is "a software engineer deployed at the customer's 'front line' rather than at the company's own headquarters, responsible for building things that work there." The term "Forward Deployed" itself derives from the military concept of front-line deployment, and in contrast to developers who polish products from the safety of the rear, FDEs are expected to deliver value in the most unglamorous, constraint-laden customer environments. The role was invented by Palantir Technologies (founded 2003), a big-data analytics company. Palantir initially called this role "Delta," and Shyam Sankar — who joined as the company's 13th employee and later became CTO and EVP — is credited with conceiving this model of embedding engineers directly inside customer teams. The key to understanding the role lies in Palantir's own description: "like the CTO of a startup." Working with a small team, the FDE owns an entire high-stakes project end-to-end, and Palantir has long contrasted Devs ("one capability, many customers") with Deltas/FDEs ("one customer, many capabilities"). Bob McGrew, former Chief Research Officer at OpenAI, captured the same essence when he called this model "Productized Consulting."
Abstract descriptions only go so far, so here are concrete examples. One Palantir veteran lists "on top of Airbus's final assembly line" and "inside an airgapped system physically isolated from external networks" as places they have worked. OpenAI's FDEs partnered with agricultural giant John Deere to use LLMs to build and scale farm-specific agronomic advice (interventions) directly with farmers in the field, all within the tight deadlines of the planting season. In a case from Tomoro — the AI implementation firm Palantir acquired in May 2026 — an AI support agent built for mobile gaming giant Supercell reportedly handles roughly 110 million users, processes around 500 million tokens per day, cut support costs by approximately 90%, and improved satisfaction scores by around 20%. Rather than delivering reports or design documents and walking away, the FDE leaves behind something that runs inside the customer's live operations and moves real numbers — that is the clearest distinction between FDEs and everything else.
The distinction becomes even sharper when compared with adjacent roles. The biggest difference from consultants lies in deliverables and goals. To borrow a framework from Japanese design firm Goodpatch: while consultants and SIers deliver reports, design documents, and custom development with "project completion" as the goal, the FDE's deliverable is "adoption and entrenchment of the company's own product," with the goal being a state where "the customer can operate independently (self-serve)." Moreover, where knowledge goes is different. In consulting, insights remain within the engagement; for FDEs, they flow back into the company's own product, directly increasing the company's asset value. In the Palantir framing cited by Pragmatic Engineer, FDEs build solutions "on" the product rather than "around" it. The difference from Solutions Architects (SAs) is equally clear: at OpenAI, SAs play an advisory role and rarely write code on production infrastructure, whereas FDEs write code directly into customers' production systems, operate amid far greater ambiguity, and drive product improvements by working backward from what is needed on the ground. The distinction from on-site contract engineers also lies in owning the entire chain — from design through implementation, operations, and "feedback into the product." In short, the FDE is a role that combines the analytical thinking of a consultant, the observational acuity of a data scientist, the implementation skill of a software engineer, and the resolve of a project manager, all in one person.
The term FDE has existed for more than a decade, but demand exploded between 2025 and 2026. The backdrop is the "enterprise AI production gap": despite abundant appetite for investment in generative AI, many projects stall at the proof-of-concept stage and never reach production, blocked by dirty data and the difficulty of integrating with existing systems. The industry has come to recognize FDEs as the ones who bridge that gap. Job growth has been staggering: according to a16z, monthly FDE job postings increased by more than 800% from January to September 2025, and job analytics service bloomberry's data shows a roughly 729% year-over-year increase, from 643 postings in April 2025 to 5,330 in April 2026.
What sealed the trend was a series of structural moves by major players in 2026. On May 12, OpenAI announced the formation of "OpenAI Deployment Company" (informally "DeployCo"), with initial capital of $4 billion and a valuation of $14 billion. It is a commitment-based joint venture with 19 co-investors, led by TPG, with Advent International, Bain Capital, and Brookfield as co-lead founding partners, and participation from SoftBank, Goldman Sachs, McKinsey, and others. OpenAI simultaneously agreed to acquire UK-based applied AI firm Tomoro (founded 2023), bringing approximately 150 experienced FDEs and Deployment Specialists — who had worked with Tesco, Virgin Atlantic, Supercell, and the NBA — on board from day one. Anthropic moved first, announcing on May 4 a partnership with Blackstone, Hellman & Friedman, and Goldman Sachs to establish an AI-native enterprise services company at a scale of approximately $1.5 billion. The target is portfolio companies in healthcare, manufacturing, and finance held by private equity (PE) firms, with Anthropic's engineering and partnership resources embedded directly inside the new entity — precisely the Palantir-style forward deployment model. The company explains that "Claude's capabilities change on a monthly, sometimes weekly basis, creating engineering challenges fundamentally different from traditional software deployment." The consulting and systems integration industry itself has also FDE-ified. On February 23, OpenAI announced the "Frontier Alliance" with McKinsey, BCG, Accenture, and Capgemini as founding partners; EY launched an FDE role in the UK and Ireland in April (initial cohort of around 50), becoming the first major consultancy to institutionalize it; Deloitte has a dedicated practice; PwC launched "AI-Native Engineering" in January; and Google Cloud has been hiring FDEs at scale under Thomas Kurian. A way of working that Palantir refined over 20 years has been elevated to industry standard in just one or two.
FDE Compensation & Structure — The "Top-Tier" Role Where Equity Makes Up the Majority
FDEs are known for their exceptionally high compensation, even among engineering roles. According to a16z and job market data, the average total compensation (TC) for FDEs in the United States is approximately $238,000, with a typical range of around $205,000–$486,000, with Palantir, OpenAI, and Anthropic sitting at the upper end of that range.
The gap widens further when broken down by company and level. According to levels.fyi, compensation for Palantir's Forward Deployed Software Engineers (FDSEs) generally falls in the range of $171,000–$415,000, with a median of approximately $215,000. Frontier labs (OpenAI/Anthropic), by contrast, far exceed this. A 2026 compensation report by Perspective AI aggregating data from 1,200 FDEs found that mid-level total compensation had a median of approximately $385,000, senior was approximately $560,000–$785,000, staff had a median of approximately $610,000 (with top earners reaching $750,000–$1,000,000), and principal-level roles at Anthropic and OpenAI can exceed $1,200,000. Looking at base salary alone, OpenAI is estimated at approximately $230,000 for mid-level, $290,000 for senior, and $330,000–$370,000 for staff, while Anthropic is estimated at approximately $220,000 for mid-level and $275,000 for senior.
The critical factor in the compensation structure of this role is the proportion of equity. The same report notes that at frontier labs, equity accounted for 60–70% of total compensation as of 2026, a significant increase from 35–45% two years prior. Since equity as a share of compensation remains at only 15–25% at large enterprises like Fortune 500 companies, FDEs at frontier labs earn 2.0–3.5x more than their Palantir-style counterparts at the same level, with the difference attributable almost entirely to equity. Annual bonuses have remained stable at roughly 15–25% of base salary. The 25–40% premium that FDEs command over traditional software engineers at equivalent levels is attributed to the rarity of combining exceptional coding ability with customer-facing skills.
The structure and compensation levels of the Japanese market are also beginning to take shape. Based on job postings, LayerX lists "from ¥12 million" and Loglass lists "¥10 million–¥25 million," both notably higher than the same companies' software engineering roles (¥6 million–¥12 million). It should be noted that the striking figures cited by domestic media—"¥27 million–¥37.5 million for junior, ¥60 million–¥94.5 million for senior"—often refer in practice to yen-converted figures from U.S. frontier labs and should not be read as representative of domestic Japanese market rates (the same report also notes that compensation outside the United States is approximately 50–70% of U.S. levels).
In terms of organizational structure, OpenAI's approach serves as a useful example. Colin Jarvis, Head of Forward Deployed Engineering, launched the function in early 2025 with just two people and grew it into a team of over ten spanning eight cities across three continents—New York, San Francisco, Dublin, London, Munich, Paris, Tokyo, and Singapore. Each FDE's work generally falls into three phases. The first is scoping: entering the field, mapping business processes, identifying high-value opportunities, and prototyping with synthetic data. The second is validation: building evaluation criteria, iteratively improving performance, and confirming that the scoped solution actually delivers value. The third is delivery: integrating data on-site and building and demonstrating something that works in production. Jarvis has said, "FDEs work with enormous amounts of ambiguity. What customers describe during scoping often doesn't match the reality of their data and systems on the ground." The organizational philosophy of small teams, on-site presence, and a production-first orientation is common to FDE organizations around the world.
Hard Skill ① — The Technical Ability to "Build Something That Works" in the Real World
From here, we enter the core subject of this article: the required skill set. The heart of the hard skills is, needless to say, the technical ability to "build something that actually works in the field."
An FDE is fundamentally a full-stack software engineer who writes code directly on the customer's infrastructure, debugs it, identifies root causes, and integrates and configures data. A typical day looks like this: connecting to a production database from a laptop brought into the customer's office, writing a script to normalize a garbled product master, methodically resolving authentication failures in an API gateway one by one, and tracing logs to discover that the mysterious "response drops only in the middle of the night" are caused by a conflict with the customer's own nightly batch jobs — an endless series of unglamorous tasks that would never arise in a neatly prepared environment. Job requirements are converging across companies. Anthropic's job posting explicitly calls for "production LLM experience — including advanced prompt engineering, agent development, evaluation (eval) frameworks, and deployment at scale," along with solid implementation skills in Python, TypeScript, Java, or similar languages, and a track record of shipping production applications. At Japanese companies like LayerX and Loglass, the baseline requirements include "3+ years of Python development experience," "front-end development experience," and "lifecycle experience from requirements definition through operations."
What distinguishes the FDE role in 2026 is that the center of gravity in technical skill has shifted toward AI engineering. Anthropic specifically cites deliverables such as MCP (Model Context Protocol) servers, sub-agents, and agent skills for production workflows. In an insurance claims assessment context, for example, this means standing up an MCP server that securely connects Claude to internal policy databases and historical payment records, running sub-agents assigned to specific points of contention, and having a human adjuster give final approval — all assembled on the spot to fit the customer's security requirements. OpenAI's FDEs have improved the product itself through building evaluations in the field. In one voice-automation engagement, an evaluation framework built by an FDE surfaced a performance gap, which led the Research team to improve the Realtime API in ways that benefited all customers. FDEs were also major contributors to the Agents SDK. In other words, technical skill encompasses not just the ability to use existing libraries, but the ability to work backward from field constraints to design evaluation criteria — and, when something is missing, to reach into the platform itself and fill the gap. Attachment to a particular language is not prized; instead, what is valued is a language-agnostic mindset of "use whatever it takes to make the problem in front of you work."
Crucially, this technical ability must be capable of withstanding "ambiguous, messy reality." It must work not in clean test environments, but in air-gapped environments, legacy core systems, and sites heavily constrained by regulation. Imagine sitting next to a bank's core accounting system with no internet connection whatsoever, only a single USB drive allowed in, and a process requiring an application and several weeks just to install an additional library — and still having to deliver something that works under those constraints. For professionals coming from Japan's SE and SIer backgrounds, this can turn out to be an unexpected strength. A deep understanding of core system architecture, combined with experience developing under strict security constraints, becomes a reliable asset when connecting the latest AI to existing systems.
Hard Skill ②――"Grand Design Ability" to Draw a Reusable Foundation
Another hard skill on par with technical ability is grand design capability — not the ability to build individual features, but the architectural vision to conceive of a customer's entire business operations and the long-lived, reusable foundation (platform) that sits beneath them. This is the watershed that elevates an FDE from "a well-paid coder" to "an architect who drives the business," and it is the central argument a16z places at the heart of its discussion of "Palantirization."
According to a16z's analysis, the reason Palantir avoided becoming just another "consulting + software" shop is that its frontline teams did not build systems from scratch for each customer — instead, they assembled reusable primitives (data models, workflow engines, authorization layers, and so on). FDEs play the role of "selecting and validating" primitives, while the product team is responsible for creating new primitives themselves. This discipline of "configuration over code" prevents the endless swamp of customization and enables the reuse of code and knowledge across engagements. Concretely: when a retail chain asks for demand forecasting, a mediocre engineer builds only that one feature. An FDE with grand design capability first distills the core business concepts — "products, stores, inventory, purchasing, and suppliers" — into a single ontology, so that demand forecasting, automated replenishment, and shelf-space optimization can all be layered on top of the same foundation later. Rather than writing more code every time a new request arrives, the answer comes from simply reconfiguring what already exists — that is the real face of "configuration over code." Furthermore, Palantir did not merely automate existing operations; it practiced "opinionated integration," guiding customers toward new operating models. Drawing the ontology of data (a structured map of business concepts) and stacking multiple business functions on top of it — this end-to-end design is the concrete expression of grand design capability.
In the context of 2026, a new layer of difficulty has been added to this design capability: "build with the assumption that things will keep evolving." As noted earlier, Anthropic has stated that "Claude's capabilities change week by week and month by month," demanding implementations that evolve as models improve. This means an FDE's grand design is not merely about building something that works today — it is about sketching a skeleton that will not need to be rebuilt when a better model arrives six months from now. For example, if model calls are not hardcoded into business logic but instead mediated by an interface that allows swapping in evaluation datasets, then when a new model ships the following week, running the evaluation and hot-swapping the model is all it takes to lift the performance of the entire system. Implementations that cut corners here, by contrast, will demand a rebuild every time the model improves. To embody Palantir's "one customer, many capabilities," what is required is not a laser focus on the single feature in front of you, but the vision to survey the full problem space of that customer — and to draw a precise line between what belongs in a shared foundation and what stays in customer-specific code. The questions a16z asks when identifying "Palantir-style entrepreneurs" — "Where does the common product end and customer-specific code begin?" "What does the margin of a mature customer look like three years out?" "What breaks when you scale to fifty customers?" — serve equally as litmus tests for the grand design capability demanded of FDEs.
Soft Skill ① — "Logical Thinking" to Structure Chaos
Half of an FDE's job lies in the process of "structuring chaos" before a single line of code is written. What works here is logical thinking — the ability to untangle problems that have never been put into words and logically define what needs to be built.
The words of Colin Jarvis, mentioned earlier, are symbolic of this. "What customers describe during scoping often doesn't match the reality of their data and systems on the ground." That is precisely why FDEs are expected to have the decomposition skills to avoid taking customers' self-reported accounts at face value — to observe in the field, look at the data, and identify the true bottleneck. Imagine a concrete scenario: the accounting department says, "Invoice processing takes too long; we want to automate it with AI." But when you embed yourself on the floor and measure each case one by one, it's common to discover that the actual bottleneck is not data entry — rather, sixty percent of the total time is consumed by double-entering the same figures into two separate internal systems and then reconciling discrepancies at month-end. What the FDE should do here is not build an "invoice AI," but instead restructure the problem itself into a design that eliminates double entry. Goodpatch describes this as the ability to "receive the user's voice on the ground and find the essential issue" and to "organize complex business workflows." In OpenAI's three-phase model, the process of "creating evaluation criteria and improving performance through iterative hill-climbing" during the evaluation phase is itself a continuous loop of logical thinking — forming hypotheses, measuring, and disproving them. This corresponds to the "brain" in the analogy of "the brain of a consultant, the eyes of a data scientist, the hands of a software engineer, and the heart of a project manager."
Logical thinking extends beyond technical judgment to the design and communication of ROI. The goal is to demonstrate, in terms that resonate with both executives and front-line staff, which business processes AI should be applied to and how much cost reduction, revenue growth, or quality improvement can be expected. For example: "Seventy percent of inquiries are standard FAQs; each one takes an average of five minutes; translated into operator labor costs, that amounts to a meaningful expense — automate responses with an agent and you free up hundreds of hours per month." This means breaking the argument down into base volumes, unit costs, and reduction rates. The ability to promise such figures in advance through sound reasoning — and then prove them after the fact, as in the Supercell case of "90% reduction in support costs and 20% improvement in satisfaction" — is what is truly being tested. The MECE frameworks and hypothesis-driven thinking that consultants have honed apply directly here. The reason Japanese consulting and DX professionals are said to transition easily into FDE roles is that they share this common language of logical reasoning.
Soft Skill ②――"Internal Political Savvy" That Moves Organizations
It may come as a surprise, but the soft skill most demanded of FDEs is "internal political acumen" — or more precisely, the ability to read the organizational dynamics of both their own company and the customer's, and to navigate politically in ways that move people to action. Even a technically correct solution will never reach production if it is derailed by on-the-ground resistance or siloed organizational structures.
Joe Schmidt of a16z repeatedly emphasizes the importance of FDEs "being there in person." Physical presence on-site drives adoption and surfaces the "organizational dynamics" that never appear in any documentation. AI deployment often involves redesigning the very workflows it touches, demanding changes from customers on the scale of "software becoming an active coworker rather than a tool." This is pure change management — and it cannot move forward without the political skill to identify whose work changes and how, to distinguish resistors from champions, and to build consensus through behind-the-scenes groundwork and stakeholder engagement. A common scenario looks like this: the operational team on the ground welcomes AI, while the compliance department halts it with "we can't maintain accountability," and IT says "we can't allow access to production data." Even a technically perfect solution will never reach production if this three-way deadlock is left unresolved. The FDE wins over the business unit head championing the initiative, reassures compliance by showing audit logs and human final-approval steps, and offers IT a landing zone with a limited-scope pilot — this kind of groundwork, visible only to those embedded in the field, is what determines success or failure. What Palantir prioritized from the beginning was the idea of "insulating" FDEs from bureaucratic friction so they could focus solely on "how to make it work." The flip side is that the FDEs themselves must be people who can, in the midst of the customer organization's political currents, carry a message to both technical and business stakeholders with equal conviction.
What works here is a low ego and a high degree of collaborative spirit. Anthropic's requirements explicitly list, alongside "communication skills to convey technical concepts to diverse stakeholders," a "low ego and collaborative attitude," "high agency to navigate ambiguity," and "a strong collaborative mindset to work across organizational boundaries." Equally essential is the discipline not to be swallowed by unlimited requests — "the ability to say no to meetings and demands." It is common for a customer's key person to pile on small requests one after another — "just add one more button to this screen" — but accepting them all turns the product into a disposable, customer-specific artifact and erodes any reusable foundation. The real test is whether you can be well-liked and yet draw the line with a smile: "That's not something we'll carry as a shared feature." The reason a16z includes "Can the leader say no to customization requests?" among the questions for identifying a "Palantir-type operator" is precisely because it probes for this political strength — the ability to be liked by customers without being dragged along by them. FDEs must also exercise political skill within their own organization. Delivering field insights to the product roadmap requires continuously engaging with Research and Product teams. The reason OpenAI's FDEs share insights with Research every two weeks, deliver regular reports to Product leadership, and post "FDE Field Notes" to internal Slack is to build a mechanism for exercising influence across organizational boundaries.
Strategic Skills――The Concept of "Management Capability" and Product-Led Growth
Finally, what elevates the FDE from a merely excellent implementer to someone who carries the business on their shoulders is strategic skill — in other words, business acumen. Palantir's oft-repeated analogy that "an FDE is like the CTO of a startup" is no exaggeration. With a small team, they simultaneously bear responsibility for profit and loss, deadlines, and customer satisfaction, making decisions from end to end. Indeed, there is an observation that AI startups have begun deliberately hiring prospective "future founders" into FDE roles.
The best framework for understanding this business acumen is the "Services-Led Growth (SLG)" model proposed by a16z's Joe Schmidt. In contrast to the product-led growth (PLG) that Silicon Valley has long championed, SLG prioritizes "becoming an indispensable system of work by capturing the entry point for a customer's operational data, even at the cost of sacrificing early margins." Schmidt's analogy is apt: "A company buying AI is like a grandmother who just got an iPhone — she wants to use it, but she needs someone to set it up for her." The FDE is the one doing that setup, and the more they integrate AI into a customer's internal systems, the more operational data accumulates there, creating a moat that competitors cannot easily replicate. Concretely, this means deliberately accepting thin margins on the initial deployment in order to position one's product as the "conduit" for a customer's core data — their orders, inventory, and so on. Run that for three years and you accumulate a volume of operational data and know-how that no competitor can reproduce overnight, making it effectively impossible to dislodge. An FDE's move is not about the near-term profitability of a single engagement, but about securing this "conduit." Implementation-heavy businesses start with low initial margins, but as ServiceNow improved from 63.2% gross margin at IPO to 79% by 2024, and Workday from 54.1% to 75%, they pivot to high margins once they have locked in the market. That is why Schmidt declares, "The only metric companies should be optimizing for right now is growing total gross profit as fast as possible." The business acumen required of an FDE is nothing less than the ability to understand the economics of this moat and flywheel — and to connect each on-the-ground decision to that overarching strategy, rather than fixating on the unit price of the moment.
That said, a16z also warns of the "Palantirization trap." Many imitators, while touting software-level valuations, are in reality running high-cost service businesses that accumulate no compounding advantage whatsoever, eventually degenerating into "the Accenture of [insert industry]." For example, even within the same category of "AI deployment for manufacturing," if each engagement is handled by writing one-off bespoke code, revenue can only grow in proportion to headcount — a labor-intensive trap. Conversely, if the work built for each engagement can be absorbed into a shared data model and evaluation infrastructure, the next customer's onboarding becomes faster and margins improve with each successive engagement. The same on-the-ground work produces vastly different financial results three years down the line depending on which path is taken. Avoiding this trap requires a strategic eye to calmly assess: Is the problem mission-critical? Is the customer base small and enterprise-scale? Are the workflows similar enough to be reusable? Does the domain carry the gravity of regulation or proprietary data? For the FDE as an individual, the true value of this role hinges on maintaining an owner's perspective — constantly asking whether what one is building in the field is becoming a "reusable asset," or whether it amounts to nothing more than "disposable contract work."
What It Means for Japanese Consulting, SIs, and VCs — Can They Break Free from the "Man-Month" Model?
Finally, I want to synthesize all of this from the perspective of Japanese consulting, SI, and tech-focused venture capital. What the FDE role poses to Japan is a fundamental question: can the country break free from the "man-month business" and "multi-tiered subcontracting" models that have long defined its IT industry?
What Japanese SIers and consultants have traditionally offered is labor priced essentially as "man-hours × unit rate." The onsite client-resident SE resembles the FDE in terms of physical presence, but their expertise is consumed by each engagement and never compounds as a proprietary asset. The disruptive power of the FDE model lies precisely in reversing this dynamic. The more problems you solve in the field, the more refined your own product becomes — and the company's asset value rises automatically. As Goodpatch articulated, the man-month business "does not scale easily," whereas the FDE model "can transition to product revenue — and therefore can scale." The fact that OpenAI and Anthropic have begun running alongside consulting firms and SIers not as their clients, but as platforms that host their own FDEs — through structures like Frontier Alliance and Wall Street joint ventures — signals a tectonic shift for Japan's SI and consulting firms, one that threatens to strip them of the upper tiers of the value chain. The successive institutionalization of FDE organizations by EY, Deloitte, and PwC, McKinsey's positioning of QuantumBlack, and Accenture's pivot toward implementation support are all mirror images of this very anxiety. Media coverage has likewise framed FDE not merely as a new job title, but as "a challenge to the consulting industry itself (Fortune)" and "the fastest-growing job in AI (PYMNTS)" — marking it as an inflection point in industry structure.
Layering in the tech VC perspective sharpens the implications further. The fact that a16z endorses "service-led growth" and champions the strategy of turning early-stage margins into a moat has direct implications for how Japanese SaaS and AI startups are built. Domestically, companies including LayerX (its AI/LLM division's FDE organization), Loglass, SmartHR (Enterprise Success Unit), AI Shift (newly established FDE roles), Taylor, and SoftBank-affiliated entities are reported to be actively recruiting FDE-type talent. For Japanese VCs, the key questions for evaluating portfolio companies become — as a16z frames it — "Where does the shared product end and customer-specific code begin?" and "What will margins look like in three years?" In other words, companies that possess an FDE organization capable of delivering gritty, ground-level value in the field *and* elevating that work into a reusable platform are the ones that will scale past the man-month ceiling — and this kind of discernment will likely determine who wins in Japan's next generation of enterprise AI.
Conversely, for individuals who aspire to become FDEs, mastering the five skills examined in this piece — technical depth, grand design capability, logical thinking, organizational navigation, and business acumen — is itself the most direct path to becoming a future CTO, founder, or VPoE. Compensation levels are merely a byproduct. The FDE is, at its core, the crystallization into a job title of the rarest capability in the AI era: the ability to create value end-to-end in the field, and then transform that value into a business.