Forward-Deployed Engineering
It’s the late seventies, and you are Larry Ellison. You’ve read a paper published by an IBM employee detailing his thoughts on relational databases, laying the philosophical groundwork for what will eventually be database languages like SQL and R. You’re shocked by this and assume IBM is jumping on the opportunity as quickly as possible.
Somehow, they aren’t interested. They already have the best selling database system on the market, the Information Management System. Producing another system that does essentially the same thing would compete with an already profitable product. There’s no reason, they seem to think, to waste time in that way.
But you are Larry, and you see the potential much more clearly than IBM seems to. You start poking around looking for potential customers who take in huge amounts of data, need ways to sort and examine the implications of that data, and have deep pockets.
Soon, you get the interest of the CIA.
They pony up $50,000 in cold, hard cash to get the ball rolling. You’ve been doing a lot of consulting work, so you decide to implement a bespoke version of relational databases in a project called Oracle. In the process, you figure out the exact needs of the CIA and how they can be best met with the technology of the day. By the time you are done, they have a working SQL database that revolutionizes their entire analysis process. On your end, you have built a working system that uses SQL, a general database language that will go on to dominate how information is stored for at least the next 45 years.
And just like that, you’ve founded Oracle.
A lot of the work that Ellison did in that story took place over a keyboard and a brilliant insight around the potential of a relational database as opposed to a hierarchical one. Those two pieces alone might have floundered, though, if it weren’t for another more important element of how Ellison did business.
The most important component of Oracle’s early progress can be split into four logical steps:
Identify a customer who might benefit from Oracle’s products and capabilities
Get closer to the customer, understand their needs better, and articulate a vision on how Oracle can specifically design a solution for their technology troubles
Build out those changes off of Oracle’s core product, satisfying one customer and creating at least one profitable transaction
Learn from what you built, generalize it into your company’s standard set of offerings, and profit from it again and again as you sell the solution to companies with similar needs
By the mid-90s, something close to 20% of Oracle’s revenue was coming not from sales of their existing product, but from consulting fees having to do with customizing the deployment and maintenance of those products in specific areas of need. Here are solutions, Oracle said, but if you don’t understand them or need something more custom-fit, we are glad to get closer, manage your Oracle implementation, and succeed alongside you.
Palantir
Popping forward in history a few decades, you are now Alex Karp and starting Palantir. Oracle’s days of being a consulting behemoth are over, and the new trend is now software as a service. They’ve revamped their company, cutting down on the consulting efforts and instead focusing on cloud and license businesses. These days, companies like Salesforce and Google are the new kids on the block, and everyone wants to be like them.
Where Ellison “just” had to implement one database program to revolutionize the entire world’s relationship with data, the average company now operates in a world where dozens of programs interlock with each other to provide optimized solutions. It’s not enough to just have an Oracle database now. There’s a product for querying that data (Snowflake), there’s another product for analyzing the data (Databricks), and heck, there’s even a product to put the data into a nice dashboard (Tableau).
So where do you find your edge? How do you grow Palantir from a large company to an unstoppable behemoth?
In Palantir’s case, the answer is to be Larry Ellison again and turn the software consulting experience into a more formalized process. Enter the term Forward Deployed Engineers (FDEs), a narrow-focus developer who is oriented completely towards the customer. Instead of building a product and then convincing the customer to buy it, you instead just sell the “engineer.” More specifically, you point at the problem of data. The internet has dropped the marginal cost of collecting data to zero, and not everyone knows how to build the pipelines to extract those insights.
And just like Ellison, you find your first customers in government intelligence agencies thanks to introductions from your primary outside venture capital firm, In-Q-Tel.
Over time, customers come to you because you’re the McKinsey of software engineering, and you arm the FDEs with a philosophy of getting close to the problem, program tailor-made solutions that go far beyond drop-in solutions, and deliver value. It also helps that the dot-com bubble just burst. The best engineers made their way to “product” companies while legacy institutions didn’t know how to properly recruit, train, or incentivize technical talent. That means your biggest competition in the space is… Tata Consulting Services (TCS).
But you don’t stop there. Like how Ellison used his consulting experience to build a more generalized version of the product, you also hire a team of product engineers who examine the bespoke work the FDEs produce, look for generalizable solutions that they wouldn’t have otherwise thought of, and productize them.
Some time later, you end up with Forge, which “is generating billions in revenue and relied on to power decisions at many of the world’s most important institutions.” [0]
Again, a behemoth was born. Like Oracle, Palantir became one of the largest and most important companies in the software space. And like Oracle, they were driven by the same tactic of starting with consulting-level problem-solving and then generalizing the lessons learned to create a product or platform.
AI Companies
Ellison and Palantir interacted with the building elements of development in the traditional way. A problem, usually correlated to data, was identified and then was solved via programming out the bespoke tools their customers needed. Their products were specific programs, and in the best case those specific programs became general products anyone could use.
But what happens when you have a general-use LLM that can do a lot of things? They can do much of the work an accountant does, for instance. They can read documents, parse them, and populate columns with what they’ve learned. They can even run calculations based on a diverse data stream in seconds and, broadly, get the right answers.
There are limitations, however, at the company scale. Not every person on every team is AI-proficient, and getting there requires significant human effort investment. Not every task you’d like an AI to handle presents itself in a straightforward way. Getting Claude’s chat product to address a task in the way you intend is often the work of hours, and work that often needs to be duplicated in later sessions as token limits are reached and quality degrades.
Today, there are applied AI companies responding to that need by building a general-use harness on top of frontier AI models and then integrating that within a company’s data to provide discrete units of work. To the second part of the equation, they’ve hired a bunch of FDEs to implement their product within different companies.
Not all of these FDEs are equal.
You already know of Cursor, which throws a saddle on AI capabilities for the general task of coding. You’d think that a coding IDE built around AI doesn’t need FDEs to implement it within organizations - Cursor’s selling to engineers after all, and pretty much every engineer worth his or her salt knows their way around an IDE. Yet, Cursor also exists within a crowded market where Claude Code, Codex, Antigravity, and countless other products do essentially the same thing.
So how does Cursor stand out and gain enterprise adoption? They’ve built out a field engineering team (their equivalent for FDEs) over 10+ strong, a significant portion of their total engineering staff. And they’re doubling down, hiring for a Field CTO. Yet based on the responsibilities and market that they’re serving, these FDEs serve mostly as strong support engineers. Each time they sign an enterprise contract for organization wide licenses, Cursor engineers are there to succeed alongside the company. It’s an important job, but these FDEs aren’t general-purpose like the original Palantir FDEs. Instead, they’re more similar to Oracle software consultants, meant to implement Cursor within an organization.
Another startup with a strong FDE team is Harvey, which makes specialized LLM tools for the legal profession. Their headline pitch is “Engineered for every task.” They’ve wrangled general-purpose LLMs into a tool that generally helps an entire profession and pitched it as a drop-in solution for any number of legal tasks.
Once again, they’ve turned to FDEs to “map out workflows, de‑risk constraints, and define crisp success metrics for custom builds.” LLMs are not ready to simply mesh into workflows without tailoring and human users are not ready to finagle them into compliance, and so expertise is needed.
The lessons of Oracle and Palantir point in a very particular direction: the general is not enough when there’s a technology shift.
Oracle rode the wave of organizations incorporating databases and ERPs into their day-to-day operations. Palantir found itself with customers who were drowning in a mountain of data and software tools. Today, the trend is AI. At this point, almost every company believes that AI has the potential to change their industry. Almost every company is also nervous about their AI strategy.
Where a tool like ChatGPT or Claude is broadly useful, companies need specificity and are willing to pay for it. The rise of applied AI in spaces like coding, customer service, and legal are testaments to that. Creating general products is only one half of the equation. The other half is figuring out each company’s problem and then building the right AI-shaped solution for them.
Not every FDE-first effort will produce a Palantir or Oracle, but in a world that’s reorganizing itself around LLM capabilities, there simply isn’t a lot of runway for a company to keep on an only-general-product footing. For better or worse, even the large AI labs have recognized this. Both Anthropic and OpenAI have large FDE teams and have signed contracts with major software consulting firms like Accenture, BCG, and McKinsey.
After a couple of decades, it’s finally time for forward-deployed engineers to step forward.