What is a Forward-Deployed Engineer (and Why Should You Care)?

If you’ve been paying any attention to tech media as of late, you’ve undoubtedly seen articles about the rise of AI’s hottest new role: the forward-deployed engineer (FDE). If the term is new to you, let’s start off with a basic definition of what an FDE is:

A forward-deployed engineer is an engineer who is taken from the core product team and “forward-deployed” into a customer environment.

That’s it. It’s not rocket science. An FDE is just a regular ol’ engineer who gets sent out into the field. So why is this such a big deal? And why now?

The History of the Forward-Deployed Engineer

The folks from Palantir’s PR department would have you believe that their company invented the forward-deployed engineers in 2011. Although they can certainly claim credit for having originated the modern job title, the practice of sending engineers from the core product team into the field long predated their adoption of it.

I know this because I built and ran a team of “forward-deployed engineers” back in 2009 (more on that later).

Generally speaking, sending highly-specialized engineers from HQ into customer environments isn’t an optimal use of a company’s resources. Notwithstanding brief trips into the field to get “real-world experience”, product engineers are almost always more valuable working on the product than they are deploying and/or customizing it. That’s why the vast majority of technology companies build separate organizations (staffed with less expensive hires) for field engineering tasks.

But every once in a while, a new technology emerges for which demand spikes before it is mature enough to be deployed by arms-length professional services workers. That happened with application servers in the late-90s. It happened again with big data platforms in the late-00s / early-10s.

And it’s happening today with AI.

What a Forward-Deployed Engineer Really Is (and What It Is Not)

Before we go any further, I think it’s helpful to know what an actual forward-deployed engineer is (especially given how quickly we’ve already progressed in the “hype cycle” of the term).

A true forward-deployed engineer is someone who has spent time working on a company’s core product and is later “forward-deployed” into customer environments in order to help with installation, deployment, customization and/or sales.

Despite what some articles suggest, a forward-deployed engineer is not just a rebranding of a solutions engineer/field engineer/integration engineer. Yes, the title sounds cool (and, yes, there are actual gains to be had by simply giving professional services workers a trendy new title). But the distinction is important as it goes to the unique capabilities that a forward-deployed engineer brings to the table — particularly for early-stage startups.

Solutions engineers and their ilk generally have strong technical backgrounds and experience working in customer environments but they rarely have deep insights into how the product was developed or how it works beneath-the-hood. Their effectiveness comes from the combination of advanced training, access to “employee-only” functionality, and a direct line-of-communication into the engineering department. Ultimately, solutions engineers can be thought of as supercharged power users who specialize in installing, deploying and customizing the product.

The didn’t build it, but they’re really good at installing it

In contrast, forward-deployed engineers understand the how and the why of a product’s operation by virtue of having contributed to its development. As we’ll see later, it is this experience and understanding that is critical to delivering customer value when demand for a new technology surges ahead of the its maturity.

When are Forward-Deployed Engineers Required?

In a typical technology company, the team responsible for installing, deploying and customizing the product for customers exists independently from the product team. This evolution happens surprisingly early on — and for very practical reasons — but demands a key prerequisite: the product must be mature enough that responsibility for installing/deploying/customizing it can be “handed off” to individuals who have little-to-no understanding of how it actually works.

This isn’t usually a challenging requirement. Case in point: the rise of SaaS software was entirely predicated on the notion that most tasks related to installation/deployment/customization could be automated (and those that couldn’t were easily encapsulated into standalone configuration tasks).

If we think about it within the context of the technology adoption lifecycle, most new technologies are relatively mature from an installation/deployment standpoint before early adopters come on board (and absolutely before they “cross the chasm” into the early majority). That’s because startups are usually able to work out the kinks in their deployment processes through beta testers and their earliest customers (innovators).

But what happens when customer demand surges before the product is ready? Or more precisely, what happens when customer demand surges before the process for installing/deploying/customizing the product is ready?

That’s what we are currently seeing with AI.

And while we’re not used to this dynamic after 10+ years of relying on easy-to-install vertical SaaS solutions, historically speaking it’s fairly common.

To illustrate this, let’s take a look at the rise of big data.

A Case Study in Forward-Deployed Engineers

For those of you who are too young to remember, there was a time not so long ago when large-scale data analytics was impossible. At the turn of the millennia — a decade before Snowflake or Databricks were founded — complex analytics could only be performed on data that was physically collocated on a single server. In those days, we already had web servers and mobile devices generating tons of data. We also had systems capable of storing all that data. But if you wanted to perform anything more than the most rudimentary statistical analysis on it…too bad.

By the mid-noughts, a handful of startups were trying to figure out how to make complex distributed analytics a reality. I was the first engineer at one such startup, Aster Data, which was founded by three of my friends from grad school.

We were much younger in those days…

By 2007, we had a handful of notable customers and enough revenue to raise our Series A. We used those funds to hire a number of experienced sales reps to scale our go-to-market efforts. And scale they did. The promise of distributed data analytics was so clear and compelling that demand surged. Fortune 500 companies were tripping over each other to schedule trials and pilots with Aster Data and our competitors. But we quickly discovered that our ability to install/deploy/configure the product couldn’t keep up with sales (and we weren’t alone in that regard).

Our first attempt to build an independent field engineering organization began as most such efforts do. In parallel to hiring our first sales reps, we brought on a number of experienced “pre-sales” and “post-sales” engineers from companies like Oracle and Business Objects. These individuals had spent years working alongside sales reps to understand the technical requirements of prospective customers and subsequently deploy database software into their organizations. Yet every single one of them struggled upon joining Aster Data.

The issue? Our product — and distributed data analytics technology more broadly — wasn’t mature enough to be deployed by individuals who didn’t have a deep understanding of how it worked beneath-the-hood. The installation and configuration of those early “big data” systems depended on a litany of variables, including the nature of a customer’s data, the types of queries they intended to ask of it, and even the brand and configuration of the servers that they planned to deploy it on. Our core R&D team — and those of our competitors — were still trying to understand and quantify exactly how all of these variables coexisted, so it was unreasonable (and, in fact, impossible) for anyone outside of the core product team to take on this responsibility.

Having failed multiple times to scale our field organization with traditional hires, in late-2008 I was tasked with figuring out a path forward. And there was only one solution we could come up with: to “deputize” some of our core product engineers into the field.

If you’ve ever tried to convince an engineer to trade in their IDE for the opportunity to be joined at the hip with an enterprise sales rep, it’s not exactly an easy sell. But we were able to convince four of our early engineers to sign on for 6-month field deployments (including two who relocated to New York and Chicago for their stints).

The results were incredible. But almost as important as the increase in sales was the fact that the strategy bought us enough time for the product to mature to the point that it could finally support a truly independent field organization (which we started building after raising our Series B).

Why Forward-Deployed Engineers are Critical to AI Adoption

By this point, the parallels between what’s happening with AI and my big data anecdote should be pretty clear.

Much like with big data, the enticing potential of AI has caused demand to surge amongst early adopters well before the processes for installing/deploying/customizing these products have matured. We can already see the impact of that imbalance in the pitiful numbers of companies that have managed to successfully get these systems into production.

One dirty little secret of the big data era was that a significant percentage of the industry’s early revenue came from R&D spend, as Fortune 500 companies tried to figure out how to get actual value from these systems. Sounds a lot like early token spend, doesn’t it?

Go on…

The parallels don’t stop there.

A few weeks ago, I wrote about the return of solution selling as the preferred sales methodology for AI. With AI technology significantly ahead of where the market is, sales teams are returning to a go-to-market approach that focuses on selling solutions to business problems. The return of forward-deployed engineers is a well-worn strategy for taking those early customers into deployment while we await the maturation of the technology.

But there is one big difference from what happened two decades ago. Both founders and VCs today understand the critical role that forward-deployed engineers can play in making sure these early customers are successful. Which is why the hype around FDEs is almost as loud as AI itself. Instead of wasting valuable time trying to build traditional field organizations, many AI companies are skipping right to engineers. And their VCs are following close behind with support.

A few weeks ago, a16z announced a fellowship for forward-deployed engineers. Such programs are normally launched as a means for VCs to find new founders to invest in. But in this case, if a16z can accelerate the development of the individuals who are critical to deploying early AI systems, the impact on their portfolio companies will be massive.

(And if they become known as the VC who understands the best way to get nascent AI products into production…well, that will undoubtedly help them win future deals.)

In the coming years, AI will mature and we’ll get to a point where arms-length professional services teams can once again drive the majority of installation/deployment/configuration (at which point the title forward-deployed engineer will return to being little more than the “ninja” of professional services). But I suspect that we’re a few years away from that.

In the meantime, if you’re struggling to get from sale to production (or even from interest to pilot), don’t be afraid to forward-deploy core engineering resources to make it happen. It can be scary at first to think about slowing down your product roadmap, but in the long run, it’s 1,000% worth it.