Forward Deployed Engineering Is New. The Underlying Ideas Aren’t.

Udhesh Vivekanandan -

How professional services, Customer Success and product engineering are converging in the AI era


TL;DR: Forward Deployed Engineering may be new as a label, but its ingredients are familiar. What has changed is the urgency to embed AI into core business operations. The opportunity is a better operating model that brings customer proximity, engineering, adoption, and learning together. The risk is carrying forward the same old incentives around utilization, dependency, and fragmented accountability.

Forward Deployed Engineering (FDE) is having a moment. Technology companies are creating dedicated FDE teams, AI companies are embedding technical talent directly with customers, and consulting and services organizations are increasingly adopting the language.

Yet underneath the enthusiasm for a new operating model sits a problem enterprise technology has been trying to solve for decades:


the persistent gap between technological capability and realized business outcomes.

That problem has survived almost every major technology cycle. Mainframes transformed enterprise computing. Client-server architectures brought technology closer to individual business functions. The internet reshaped how companies interacted with customers and markets. Cloud dramatically lowered the barriers to accessing infrastructure and gave organizations unprecedented speed and flexibility. AI now promises to go further still, changing not just the technology stack but potentially how work itself gets done.

Despite all of this progress, one question keeps resurfacing: how do we turn technological capability into meaningful business change and outcomes?

Technology alone has rarely been enough. Someone still has to understand the business problem, translate it into something technology can address, navigate the realities of the operating environment, help people adopt new ways of working, and remain close enough to determine whether the intended business outcome ever materialized.

Over time, different functions have emerged to solve different parts of this problem. Professional services focused on implementation and transformation. Solution architects connected business requirements to technical design. Customer Success focused on adoption and value realization. Transformation teams dealt with organizational change. Product organizations increasingly sought closer feedback loops with customers.

Forward Deployed Engineering is interesting because it appears to bring many of these ideas together.

The question is whether that convergence represents a genuinely better operating model, or whether we risk carrying many of the limitations of the models that came before it into the AI era.

1. FDE looks new. Its ingredients are not.

Many of the principles associated with FDE are familiar to anyone who has worked in strong professional-services or customer-transformation organizations.

The best professional-services teams have never viewed their role simply as delivering against a Statement of Work. They embed themselves deeply enough to understand the customer's business, share responsibility for the problem being solved, and adapt as their understanding evolves. The objective is not merely to complete an implementation, but to connect technology decisions to tangible business outcomes.

Customer Success grew from a related realization. Software or solutions being deployed does not mean value has been created. Customers still need to adopt them, change behaviors, and translate usage into business impact. In parallel, product organizations learned that proximity to real customers dramatically improves their ability to understand what works, what fails, and what should become part of the product.

Transformation teams contributed another important lesson: technology outcomes are rarely determined by technology alone. Processes, governance, incentives, organizational structures, and people often determine whether an implementation succeeds or fails.

FDE draws from all of these disciplines. Embedded technical teams, shared customer goals, close interaction with business users, ownership beyond implementation, and rapid feedback into product engineering are not individually new ideas. What is notable is that they are increasingly being brought together into a single operating model.

2. What changed is the urgency to operationalize AI.

Enterprise AI itself is not new. Companies have been investing in machine learning, automation, and AI-driven systems for years.

What has changed is the expectation surrounding it.

For much of the previous cycle, organizations could afford to treat AI as a portfolio of experiments: establish an innovation team, run proofs of concept, identify promising use cases, and gradually determine where the technology belonged.

That posture is becoming harder to sustain. There is now significant pressure to move AI into core workflows, decision-making processes, and operating models. The question is shifting from where can we experiment with AI? to how do we make AI part of how the business actually operates?

That transition changes the delivery problem.

A successful demonstration is no longer enough. AI systems have to function with real enterprise data, security models, governance requirements, users, processes, and organizational constraints. They have to survive production, and they increasingly have to demonstrate measurable value quickly.

This makes the traditional separation between functions more costly. When the people building the technology are too far removed from the business problem, it becomes easier to optimize the wrong thing. When product teams are disconnected from real operational usage, learning slows down. When implementation is separated from adoption, organizations can celebrate successful deployment while the expected business value never appears.

FDE becomes particularly relevant because it shortens the path between technical delivery, realized business outcomes, and reusable learning from the field.

3. FDE is a convergence model.

I therefore find it more useful to think about FDE not as an entirely new discipline, but as a convergence model.

It inherits deep customer context and transformation capability from professional services. It shares Customer Success's concern with adoption and value realization. It brings engineering closer to the customer problem, allowing teams to build against real operating conditions and capture learning from the field. And it recognizes something transformation leaders have long understood: technology only creates value when the surrounding processes, people, and operating model evolve with it.

These capabilities have traditionally lived in different organizational structures, often with different leaders, budgets, incentives, and measures of success.The customer, however, has never seen them as separate problems.

From the customer's perspective, there has always been one fundamental objective: turn the technology they purchased into meaningful business value.

Most organizational models fragmented that journey. FDE potentially reconnects it.

That is what makes the model compelling.

4. Convergence also brings baggage.

But bringing functions closer together does not automatically produce a better operating model. Each discipline contributes valuable capabilities, but each also brings historical incentives that can shape behavior.

Professional services can become optimized around utilization, project revenue, and extending engagements. Customer Success can become driven by retention mechanics and reducing cost-to-serve. Sales organizations naturally focus on expansion. Product teams can become disconnected from the messy operational reality of enterprise customers. Engineering organizations can define success as reaching production even when the deployment produces little meaningful business change.

If FDE combines the capabilities of these functions while retaining their underlying incentives, the result may look new while behaving remarkably like what came before.

FDE could become a premium professional-services organization staffed with stronger engineers. It could become another revenue-generating delivery engine measured by billable utilization. Or it could create a culture of exceptional engineers repeatedly solving bespoke customer problems without enough of that learning becoming reusable product or delivery capability.

I have already seen examples of these patterns emerging.

None of these models is inherently without value. But they fall short of what makes FDE potentially transformative.

The more interesting possibility is an operating model that combines customer proximity, engineering capability, adoption, business-outcome ownership, and reusable learning while deliberately redesigning the incentives around them.

That is a much harder problem than creating an FDE job title.

5. The real questions start here.

This is where the subject becomes more interesting to me.

For providers: what kind of FDE model are we actually building?

For providers, the first set of questions is about the model itself.

Commercial model: how should FDE create economic value?
Is FDE primarily a revenue engine, a customer-outcomes function, or both? What behaviors do utilization, engagement duration, and deployed headcount incentivize? And can the model grow without making customer dependency economically attractive?

Operating model: how should FDE actually work?
Where should FDE sit relative to Customer Success, Product, Engineering, Sales, and transformation teams? What should success be measured against? How should learning from the field become reusable rather than remain trapped in individual engagements?

Talent and leadership model: what kind of organization does this require?
What capabilities should an FDE team combine? How do you avoid building a hero-engineer culture or simply scaling through more headcount? And what should leaders optimize for if the goal is customer outcomes, capability transfer, and reusable learning?

For customers: what exactly are we buying?

The customer side starts with a different set of questions.

Procurement model: what are we actually buying?
Engineering capacity? A technical deliverable? A measurable business outcome? Or an accelerated path to a capability the customer ultimately expects to own?

Readiness and shared responsibility: what must the customer contribute?
What needs to be true on the customer side for the intended outcome to materialize: data, governance, process change, leadership sponsorship, adoption, or operating-model change? And how should those responsibilities be made explicit from the beginning?

Capability and exit model: what should the customer own when the engagement ends?
What should the customer be able to operate, modify, govern, diagnose, and extend independently? What does successful handover look like? And when should the training wheels come off?

These provider- and customer-side questions will form the basis of the rest of this learning series.

They matter because FDE gives us another opportunity to rethink a problem enterprise technology has wrestled with since long before AI: how to consistently translate technological capability into realized business outcomes.

The rest of the series will explore these questions more deeply: the commercial and operating model, what an outcome really means, how FDE should be measured, how customer capability and dependency should be understood, where Customer Success fits, and how customers should procure FDE.

FDE may offer a better way to connect technology, the customer, and the business problem. Whether it fulfils that promise will depend less on what we call the role and more on the operating model, incentives, responsibilities, and measures we build around it.

That is where the rest of this learning series begins.

References

References & further reading