Forward-Deployed Didn't Start in Tech

Everyone is hiring forward-deployed engineers, but where are those skills actually built?

Andreessen Horowitz recently called the forward-deployed engineer “the most in-demand role in AI.” Every enterprise AI company is hiring for the position, and the job listings all trace the lineage back to Palantir, where Shyam Sankar coined the term in 2007 to describe engineers who work directly inside customer environments instead of from headquarters.

The term is useful. The origin story is incomplete.

The structural skill underneath “forward-deployed engineering” is the ability to embed inside a complex operating reality, diagnose problems that are only visible from inside the workflow, and build to the specific shape of that environment instead of a generic one. That skill was not invented at Palantir, or in Silicon Valley, or in the software industry at all. It was the default mode of technical work in defense, heavy industry, and government for decades before anyone gave it a name.

In my opinion, the distinction matters because the current hiring screen has the signal inverted. Companies are pattern-matching on job titles and tech pedigree when the deepest pool of this skill exists in populations they are not looking at.

The skill before the name

In defense and heavy industry, forward-deployed was never a philosophy or a delivery model. It was the only way the work got done.

You cannot fix a production line from a slide deck. You cannot implement a compliance system without sitting inside the regulatory workflow it needs to serve. You cannot integrate technology into an institution’s operating reality without spending enough time inside that reality to understand its actual shape, which is almost never the shape described in the requirements document. The engineers, subject matter experts, and program managers who did this work were embedded by default, traveling to the site, working inside the customer’s environment, and building solutions fitted to what they found there.

Over time, these environments trained a specific set of capabilities that formal engineering education does not teach and that most software companies have never had to develop.

The first is diagnosing problems that only manifest in the operating environment. The spec says one thing, the simulation says another, and the field reveals what actually breaks. The ability to see the gap between designed behavior and operational reality is a skill built through years of repetition in environments where the gap has real consequences.

The second is earning credibility with domain experts who have been doing the work for decades. A career machinist, a procurement officer with twenty years in the role, a plant manager who has seen three technology vendors come and go does not defer to your job title or your company’s brand. You earn the seat by demonstrating that you understand their operating reality well enough to be useful inside it, and that dynamic is fundamentally different from selling a product to a buyer.

The third is operating inside institutional complexity. Procurement rules, safety regulations, cross-organizational coordination, audit requirements, classification systems. These are not obstacles to route around. They are the operating environment itself, and the skill is building within them rather than treating them as friction.

The fourth is adapting to the specific shape of each deployment. Every facility, every agency, every program has a shape. The forward-deployed skill is reading that shape accurately and building to it, instead of expecting the institution to reconfigure itself around a generic product.

These capabilities were trained in environments where failure had physical consequences, timelines were measured in years, and the people across the table had been doing the work longer than most software engineers have been alive.

The pattern is common

My own path followed this structure without my recognizing it as a pattern for over a decade.

At twenty, I was working at a fluid power research firm in Oklahoma that had helped define many of the international testing standards still used across the industry, embedded inside industrial and defense clients solving hydraulic and pneumatic failures that required being physically on-site. I was providing recommendations to engineers twice my age and significantly more senior because the expertise was earned through proximity to the problem, not through seniority or credentials. From there I moved to the Pentagon, embedded in joint chemical and biological defense operations across aerospace platforms and biosurveillance missions, where I was eventually insourced from contractor to federal civilian because the embedded role was valuable enough to convert. Then to the White House, where I helped design and run a program that deployed private-sector technologists directly into federal agencies. Then I built Leverage AI around the same structural posture, flying into customer facilities on regional jets and connecting flights to second and third-tier cities, sitting alongside procurement teams, learning the specific shape of each customer’s supply chain before writing a line of code.

Each of those environments was completely different, but the posture was the same. The embed skill transferred across domains because the underlying pattern, go inside the operating reality and build to its shape, is not industry-specific. The specifics change. The structural posture does not. That portability is what I wrote about in The Operator’s Supercycle as the generalist operator advantage, and forward-deployed experience across multiple industries is, in my view, the mechanism that creates it.

Palantir, the company that coined “forward-deployed engineer”, crossed my path twice during those years. They were a subcontractor providing data aggregation on a defense mission I was running, long before I understood Silicon Valley or knew who Peter Thiel was. They were just another vendor doing data work for the broader mission set. Years later, they approached my startup with acquisition interest. The company that named the pattern recognized the posture before either of us had the language for it.

My experience is not unique as there are countless examples of others who found success by placing themselves within the customer environment. Thomas Lee Young, the founder of Interface, grew up around oil rigs in Trinidad and worked inside Jaguar Land Rover’s manufacturing lines studying human factors and safety design before building an AI company that audits industrial operating procedures. His pitch to oil and gas executives works because he grew up in their operating reality. Blake Hall spent years as an Army Ranger leading combat patrols in Iraq before building ID.me into the identity verification layer used by twenty federal agencies and hundreds of private sector companies. His credibility with government institutions was not learned from a sales playbook. The career path of defense, government, or heavy industry followed by company-building is common among operators in their thirties and forties, and the skill exists at scale in populations that do not show up in conventional tech hiring pipelines.

Why this matters now

I wrote earlier this year about where defensible value moved when code got cheap and about why generalist operators are positioned to win this AI cycle. The argument in that second post was that breadth across industries is an advantage when build cost collapses. This post is about where that breadth actually comes from. It is not accumulated by reading about industries or advising them from the outside. It is built by embedding in them sequentially, carrying the forward-deployed posture from one domain to the next, and recognizing which patterns transfer.

Both posts argued that AI collapsed the cost of building software on the periphery while the moats, the regulated workflows, institutional trust, and infrastructure, did not move.

The forward-deployed implication is specific. The software layer around the embed got an order of magnitude cheaper. The embed itself did not.

Building custom integrations, internal tools, workflow automation, and reporting layers used to require a full engineering team per customer deployment. AI tools compressed that to one or two engineers working with strong tooling. The cost of acting on a forward-deployed engagement dropped by an order of magnitude, which is why every enterprise AI company is now adopting the model.

What did not drop is the cost of embedding credibly: reading a customer’s operating reality accurately, earning trust with domain experts, navigating institutional complexity, and building to a specific shape rather than shipping a generic product. Those skills take years to develop and no model accelerates them.

The ratio shifted. As the industry moves from pure SaaS toward services-led delivery, companies are optimizing for people who can build fast, which is exactly the skill AI is commoditizing. The scarce resource is the person who can embed credibly, and that skill compounds with experience in complex operating environments. The most valuable version of this skill is one that has been tested across multiple operating environments, because that is the person who can embed into your industry even if they have never worked in it before. Someone who has moved from defense to government to industrial manufacturing, carrying the embed posture across each transition, has demonstrated something that a single-industry specialist has not: the ability to read a new operating reality quickly and build to its shape without years of domain-specific ramp time. That portability is what separates a forward-deployed operator from someone who is simply experienced in one field.

The screen

The question I keep coming back to is what the first-principle characteristics are that distinguish real forward-deployed capability from the job title on a resume. I think it reduces to four things:

• Has this person spent years inside operating environments where they had to diagnose problems that only manifest in the field?
• Have they earned credibility with domain experts who have decades of experience in the industry?
• Can they operate inside institutional constraints rather than treating them as friction to be eliminated?
• Do they build to the specific shape of each customer’s reality, or do they default to standardizing the customer into their product?

That background is more likely to come from defense, government, industrial engineering, or management consulting than from other software companies. The founders and operators with the deepest forward-deployed instinct often do not have conventional tech pedigrees, and I think that is not a gap in their profile but the most valuable thing on it.

The term is new, the skill is not, and the people who have been running it the longest have a structural head start that this cycle finally rewards.