The rise of the Forward Deployed Engineer

Forward Deployed Engineer is by no means a new role, but it’s having a moment right now. At a high level, it’s a really compelling mix of client-facing and technical work. As a Forward Deployed Engineer, you get to embed with a company and help them solve real problems. Not “here’s how you can use our product”. It’s “I’m going to understand your specific pain points and goals, and we’re going to build a solution together”.

I’ve been going down a rabbit hole on open Forward Deployed Engineer roles for the past week, and I’ve come to an interesting conclusion: I don’t think anyone agrees on what this job actually is.

The obvious comparisons don’t quite work. It’s not just a solutions engineer who codes, and it’s not really professional services either. The more I dug in, the more it felt like everyone was using the same title to describe slightly different jobs.

If you zoom out, though, there is a useful way to think about how these roles differ.

The simplest way I’ve been thinking about it: solutions engineers help you use the product, consultants help you implement something specific, and FDEs are responsible for making the whole thing work when it doesn’t cleanly fit. That last part is where the role starts to feel meaningfully different.

Companies aren’t hiring Forward Deployed Engineers just to solve one-off customer problems. They’re trying to close a gap between what the product is designed to do and what customers can actually make work in their environment.

In more traditional products, that gap is smaller. You can rely on documentation, onboarding, and support. In AI and data-heavy systems, that gap is actually much wider.

These systems are powerful, but they’re not simple. They don’t plug cleanly into existing workflows, they depend heavily on the shape of your data, and they often require a fair amount of adaptation before they’re useful in a real environment.

If you’re an enterprise customer, that gap shows up quickly. You buy into the potential, but getting from “this is possible” to “this is actually working for us” can be overwhelming. That’s the gap these roles are trying to close.

So what ends up happening is that Forward Deployed Engineers don’t really get to stop at understanding the problem. They’re the ones responsible for making it work. That means getting into the details: how the customer’s systems actually operate, where the constraints are, what’s breaking, and what needs to exist that doesn’t today. Sometimes that’s writing production code. Other times it’s building integrations, shaping workflows, or stitching together systems in ways they weren’t originally designed for. Some Forward Deployed Engineers don’t have a background in traditional software engineering; they're in Product or Customer Success.

There’s a consulting element to it, but it’s not just advisory. You’re responsible for driving the solution all the way through to something that actually works in practice.

So now we have multiple elements at play: consultative, solutions-focused, product-minded, hands-on delivery, and influential. What this is telling me is that Forward Deployed Engineers are classically T-shaped: great if you’re into doing a lot of things, but challenging if you’re looking for your next role. It feels a lot like reaching your hand into a jar filled with folded sheets of paper, and the sheets you grab are the skills you’ll need for one specific company.

_{A thank you from this week’s sponsor:}

ChatGPT is a superpower if you know how to use it correctly.

Discover how HubSpot's guide to AI can elevate both your productivity and creativity to get more things done.

Learn to automate tasks, enhance decision-making, and foster innovation with the power of AI.

Download the free guide

To test this theory, I looked at the kinds of companies hiring for these roles and how different they look depending on the product.

At Stripe, the role looks like an evolution of professional services. You’re still working with enterprise customers, but instead of delivering scoped implementations, you’re building production systems and feeding what you learn back into the product.

At Zapier, the work is less about building from scratch and more about making systems actually work together. You’re shaping workflows, connecting tools, and turning something flexible into something usable. It’s not a software engineering role. (We recently hired our first Forward Deployed Engineer!)

And in a lot of the newer AI-native companies like Glean, the role is much closer to product development. You’re identifying entirely new use cases, building them alongside the customer, and in many cases those solutions end up becoming part of the core product.

Same title, very different expectations.

That’s what makes this role confusing at first. Companies aren’t using the title incorrectly. It’s that they’re all dealing with slightly different versions of the same problem: how far the product gets you on its own, and who owns everything after that.

The part that really matters is what happens after the implementation. In the better versions of these roles, you’re going beyond solving the problem in front of you to identify where the product falls short, see patterns across customers, and push that back into product and engineering. That feedback loop is the whole point.

Without it, this turns into expensive custom work. You end up solving the same problems repeatedly without anything actually improving. With it, it becomes a way to learn faster than you would from inside the product team alone.

This is also why the role doesn’t look consistent across companies. Some are very code-heavy, others look closer to implementation engineering or solutions architecture, and some sit in go-to-market while others are tightly coupled with product and engineering. The implementation varies, but the responsibility is consistent: close the gap between what the product does today and what the customer actually needs.

The more complex the product, the wider that gap tends to be. And right now, that gap is widening.

AI is accelerating this, but it’s not the only reason. These systems are flexible, but they’re not standardized. They behave differently depending on the environment they’re dropped into, which means the work shifts from “build the product” or “help customers use it” to “figure out how this actually works in practice.”

I wouldn’t think about this as just another flavor of solutions engineering.

The people who do well in these roles aren’t just strong technically. What “strong” looks like depends heavily on the company. In some cases it’s traditional software engineering. In others it looks closer to systems thinking, integrations, or implementation work. I’d consider that variability to be a feature, not a bug.

What is consistent is how they operate. They’re comfortable without a clear playbook, they can understand a business problem without it being translated into requirements, and they’re willing to make decisions in environments where the right answer isn’t obvious. This is less about building clean systems and more about making systems work in the real world.

What stands out to me is what this says about how we build software right now. We’ve gotten used to treating product, engineering, and implementation as separate phases: build the thing, ship it, then help customers adopt it. That model assumes the product can stand on its own. In more complex systems, that assumption breaks pretty quickly.

The boundary between product, engineering, and implementation is starting to blur. That’s what the rise of the Forward Deployed Engineer is really about. Someone has to own that gap, and that’s what this role is emerging to do.