For much of the software era, the division of work appeared relatively clear. Product engineers built the platform, implementation teams configured it, consultants helped align it with business requirements, and customer success teams supported adoption after deployment.
Enterprise AI is making those boundaries harder to maintain.
A model may perform impressively in a controlled demonstration and still struggle when introduced into an operating environment shaped by legacy systems, fragmented data, security policies, regulatory requirements, user behaviour, and workflow exceptions. The technical capability may exist, but making it useful within the realities of an enterprise is a different challenge altogether.
This gap is bringing renewed attention to the Forward Deployed Engineer, or FDE.
The role is often described as sitting at the intersection of engineering, product, implementation, and customer success. Forward Deployed Engineers typically work close to the customer, helping discover the problem, adapt the technology, integrate it into existing systems, and carry the solution into production.
But the more useful question may not be why companies are hiring FDEs.
It may be what the rise of the role tells us about how engineering capability itself is changing.
Enterprise AI products can often be accessed quickly. A team can test a model, develop a proof of concept, or demonstrate a promising use case within weeks.
Production value usually takes longer.
The solution must connect with enterprise data, applications, permissions, infrastructure, and operating processes. Its outputs must be evaluated within a specific domain. Teams must determine where human review is required, what should happen when the system is wrong, and how it will behave outside the ideal use case.
This is not simply an installation or configuration problem.
AI systems are probabilistic, context-dependent, and influenced heavily by the workflows around them. Making them useful may require changes to the product, the integration architecture, the user experience, and sometimes the way work itself is performed.
That creates a difficult space between traditional product development and conventional implementation. A product may be technically capable, yet still fail to create value because it does not fit the customer’s environment, operating constraints, or day-to-day decisions.
The Forward Deployed Engineer is designed to operate in this space.
Rather than handing over a completed product, the engineer works alongside the customer to understand the problem, shape the solution, adapt it to the environment, and support its movement into production. The emphasis shifts from delivering a feature to enabling an outcome.
It can be tempting to describe an FDE as a more customer-facing Full Stack Developer. That comparison is useful, but incomplete.
A Full Stack Engineer may already work across frontend systems, backend services, APIs, databases, infrastructure, and deployment. The role can involve considerable technical breadth and product ownership.
An FDE may use many of the same engineering skills. The difference is generally found in the context in which those skills are applied.
A product engineer usually works within a defined or evolving product roadmap. A Forward Deployed Engineer often begins with a customer problem that is still ambiguous. The work may require understanding why a workflow exists, how users currently behave, what systems must be connected, which constraints are non-negotiable, and what outcome the customer is actually trying to achieve.
The product engineer asks how a capability should be built into the platform.
The FDE may need to ask whether that capability will work in this particular environment, what must change before it can be adopted, and how its value will be recognised once it is deployed.
Neither role is inherently more advanced. They are simply oriented towards different forms of complexity.
One manages complexity within the product. The other manages complexity at the boundary between the product and the customer’s operating environment.
What makes the Forward Deployed Engineer notable is not any one technical skill. It is the combination of capabilities brought together in the role.
The engineer must often be able to write and review production-grade software while also understanding enterprise architecture, integration constraints, business workflows, and user needs. They may need to communicate with developers in one meeting, security or infrastructure teams in another, and business stakeholders shortly afterwards.
The work also demands comfort with incomplete information. Requirements may evolve as the customer and engineering team learn more about the problem. A solution that initially appears technically correct may need to be rethought once it encounters production data, operational edge cases, or adoption barriers.
This makes the role different from conventional technical support. It is also different from consulting that stops at recommendations or solution design.
The FDE is expected to remain close enough to the implementation to carry technical accountability for whether the solution actually works.
In practice, this can mean combining:
These capabilities are not new individually. What is changing is the expectation that one role may need to bring several of them together.
Forward-deployed models existed before the current AI cycle. What has changed is the frequency with which AI products require this level of proximity to become operationally useful.
Traditional enterprise software often begins with a reasonably stable set of product behaviours. Configuration and integration may be complex, but the application is generally designed around known processes and predictable outputs.
AI introduces additional uncertainty.
The provider and the customer may need to learn together which use cases are viable, what context the system requires, how performance should be evaluated, and where human intervention belongs. The challenge is not always to deploy a fixed product correctly. It may be to discover the right form of the solution while it is being deployed.
This makes customer proximity strategically valuable.
A Forward Deployed Engineer does not only bring the product into the customer environment. The engineer also brings evidence from that environment back into the product organisation.
That feedback may reveal where the model performs well, where it breaks down, which integrations repeatedly matter, what prevents users from adopting it, and which customer-specific solutions should eventually become reusable product capabilities.
The field is therefore no longer only the destination of the product. It becomes part of the product-development system.
The FDE role has historically been associated with companies such as Palantir and, more recently, frontier AI businesses. But the underlying model is becoming relevant across a wider range of enterprise technology companies and services organisations.
This is understandable. As AI products become more capable, customers may require fewer demonstrations of what the technology can do and more support in determining how it should work within their organisation.
The bottleneck begins to move.
It shifts from access to technology towards integration, workflow design, governance, adoption, and measurable business value. Companies then need engineers who can move comfortably between the technical system and the context in which that system must operate.
This raises the possibility that FDE is not only a role within an AI product company. It may also become a broader delivery model for enterprise technology.
An engineer working inside a consulting firm, systems integrator, managed-services organisation, or internal transformation team may perform much of the same work without carrying the title. The common factor is not where the engineer is employed. It is the ability to connect technical capability with a real operating outcome.
The current conversation often treats FDE as a hiring category. That may be too narrow.
Some organisations may need a dedicated forward-deployed team, particularly when their products are evolving rapidly, customer environments vary significantly, and implementations require sustained engineering involvement.
Others may need the capability without necessarily creating the title.
They may need solution architects who can build rather than only design, product engineers with greater customer exposure, implementation specialists with stronger software capability, or consultants who can remain accountable through production deployment.
This also creates a workforce-development question.
Can organisations find these engineers ready-made, or will they need to develop them from adjacent talent pools?
A strong Full Stack Engineer may already have the technical depth but need more exposure to customer discovery, domain context, and implementation ambiguity. A solutions engineer may understand customer environments but need deeper production engineering capability. A consultant may know how to frame the business problem but need stronger ownership of the technical solution.
Building FDE capability may therefore be less about creating an entirely new profession and more about combining skills that have traditionally developed in separate career paths.
That has implications for hiring, learning, career mobility, and workforce planning. Organisations may need to assess engineers not only on coding depth, but also on how they navigate ambiguity, understand systems, communicate with customers, and connect technical decisions to operational outcomes.
The rise of the Forward Deployed Engineer reflects a broader change in where technology value is created.
As products and models become more capable, access to technology becomes less differentiating. The ability to connect that technology with a specific workflow, system, decision, or business outcome becomes more important. Engineering work does not necessarily end when the feature is shipped. In many enterprise AI deployments, that may be where some of the most consequential engineering begins.
The FDE role gives this work a name. Whether it remains a distinct role is less certain.
It may continue as a specialised function within companies whose products require deep customer integration. It may also become a capability pattern that spreads across product engineering, consulting, architecture, implementation, and customer success. For technology and workforce leaders, the question may therefore be larger than whether more Forward Deployed Engineers should be hired.
It is whether customer proximity, systems thinking, technical depth, comfort with ambiguity, and ownership of real-world outcomes are becoming necessary across a much wider share of the engineering workforce.
Agile adoption in a changing landscape
Learn More
Redefining clean coding with AI
Learn More
Reshaping developer experience and workflows
Learn More
