Forward Deployment: The roles, the myths and the legends

Slightly more than a year ago I spent an hour on a call with someone who has done forward deployment for a decade at the company that invented the term. Over the last 12 months, I’ve collaborated in different shapes and forms with people in building their forward deployment engines. I still feel no piece of content does justice to what all forward deployment includes.

When I spoke to my friend, I asked how the famous discovery process actually works. The answer was almost embarrassingly physical, at least at first when you only look at things at the surface level. You fly in. You spend two days meeting everyone who touches the problem. The ERP manager gives you a theory class on purchase orders. Then they walk you to the shop floor so you can watch what the theory leaves out. Then you spend three weeks asking them one question a day while you wire the data. I asked if there was a formula. He said the formula is getting as much time as possible with the people who know. Ten years in, that part has never changed.

However, this can be misleading if you don’t dive deeper. Yes, they spend a lot of time with the customers. However, good forward deployed engines build the model in advance. Great deployment engineers and deployment strategists recognize that they won’t understand everything, but they’re very fast to build things and iterate with the customers. The first workflow is the immediate goal. Ontologies are used as a way of extending that tool to an operating system gradually. Where, good forward deployment engines shine is in the fact that a lot of the context comes from the team, from the Subject matter experts, and they kind of stitch it all together to a large extent even before they meet the customer for the first time. That piece has improved over time and is the true reason why some engines compound and some don’t.

I immediately had two thoughts. You probably have them if you’ve not paid attention to what good forward deployment is so I urge you to read on.

My first thought was what happens when you don’t have any clue about customer’s workflows? You would start from a lot of interviews, right? My friend said no because no one likes to be interviewed but he shared a story. His team once built a routing engine for a logistics company that had dispatchers assigning daily tickets to drivers or routes by relying on manual judgment and looking at maps, distances, landfill location, and other operational constraints. My friend built a tool that gave dispatchers recommendations, but the first issue was that the dispatchers often rejected the recommendation based on intuition and could not clearly explain why. To handle that, his team has to surface all the different possible assignment permutations and then they used that visibility to compare human decisions against simulated outcomes. This was the first time someone had mapped all permutations on a screen and thus it was the first time folks had a moment to reflect on whether the decision they were making based on intuition was backed by data at scale. It let the team at logistics company audit the workflow itself, understand whether the process logic was actually right, and refine the digital twin so it better matched how the business operated in practice. They also enjoyed the process because it never felt like an interview but instead it for the first-time allowed them to see all the pieces of the puzzle on one board.

My next thought was how does the addition of agents change the whole process today from it was a couple of years ago? The response my friend gave was it simply implied that we can develop a lot faster using agents and have more context at tribal knowledge layer but that’s just part of the puzzle. He said the magic sauce in their FDE model when it comes to these pilots is nothing Einstein worthy. In some cases, even now, while they do pilots, they’re simply hearing the steps and outcomes, verb-mapping and giving the customer a team of five to just be their dedicated engineers. These engineers codify everything and then they can just disappear and the customer can keep using the solution. The agents do help in the sense that they accelerate and deepen the codification process by making it easier to incorporate more context and tribal knowledge from across the customer’s systems. Agents have become a way to move beyond just direct user feedback and instead pull in historical and operational context, things like emails, sales process changes, status changes in systems such as Salesforce, and other traces of how the organization has worked over time. That makes it easier to model customer workflows in a richer way, connect together fragmented sources of knowledge, and build systems that not only represent the business through a digital twin but also help automate or support the decisions people currently make manually.

I’ve a few paragraphs from my call transcription with him.

So, so the way we start is we always focus on speed to value. We don't always follow a procedural approach such as all right, let's make the ontology. Then let's make the application on top. Then let's go to the user. No. In some aspects, we follow it but, in other aspects, we just ask the customer, what's the biggest value add we can build for you or what's the biggest impact we can deliver you right now? Explain to us the problem in your business and now the problem you think we can solve.

Once the customer shares, we kind of go to the drawing board and say, okay, let's just chop a version one of the ontology, build a version one of the application as well within like a week and let's test it out. So it's very much like, you know, how would you build a startup. Often we find, they might come up with an idea of a use case, but as they're speaking, we uncover another entirely potential use case that we can just solve for. And we'll just build that, like even though they thought they needed something else. At the end of the day, we try to tune for what is the biggest problem they need solving.

We'll build something for that quickly and build five objects in terms of the ontology. If we’re doing something related to say the ERP system, which can be quite complex, even after getting the integrations done, we're hitting up that ERP expert, a couple times for a one hour jam session type thing or a half an hour ad hoc meeting during the week. And then once we've proven ourselves there, then look for that second, third, fourth use case to the point that we can build like an enterprise OS for their entire company.

We usually do this in the form of an onsite. We'll just fly in, we'll say okay give us like two days. We get to meet with the stakeholders like everyone that can be there together or else 1:1. In many cases, when people are busy, we'll just sit next to them and try to understand their sales process or your kind of client interaction. We'll try to understand from their perspective what's happening and we don't try to condense the time with customer. Actually we keep leaning into it more and it’s something that's never changed in 10 years. At times, we will spend entire weeks with the clients. We've never tried to get away from it and make our platform fully automated in any way when it comes to discovery.

A central idea in the discussion was that codification happens through iteration, not through heavy documentation. The team builds a “digital twin” of the company directly in code, using data integrations, operational context, and Subject Matter Expert input to represent how the organization functions in practice. But that data model alone is not enough. The harder and more valuable layer is the business logic - the understanding where intervention matters, what actions should be recommended, and how experienced operators actually make decisions. All of this is not just surfacing information, but helping users evaluate tradeoffs, validate workflows, and eventually encode decision support into the product itself.

The rest of my conversation dived deeper into how this work does not depend on having deep domain experts embedded from the start. The expectation is that forward-deployed engineers can enter unfamiliar environments, learn quickly, and build credibility by producing useful systems fast. Early engagements often begin with a short boot camp, supported by pre-built prototypes and sample data, designed to demonstrate value quickly and earn the right to deeper deployment. From there, the relationship can expand from a single use case into a broader operating system for the customer, with the long-term goal of codifying workflows so effectively that the team can eventually step back while the client continues using the solution.

This is a highly relevant playbook for a new venture now being built. This is forward deployment. Everything else is maybe decoration.

The law of compounding

Forward deployment is expensive, slow to show up in gross margin, and hard on tidy planning. Founders feel this and start asking whether the effort matches the unlock. Eventually some leader says it out loud, we are putting in 2x the effort and getting 2x the result.

That sentence is a red flag for certain industries if it’s implying that forward deployment is not the right model. I understand a founder’s impatience having been one myself but there is a thin line between naivety and impatience. For the businesses that work better with a forward deployed engine, anyone doing this math in multiplication has not understood the job. If 2x effort buys 2x outcome, you have hired consultants and dressed them as engineers. You will add bodies in lockstep with revenue forever, your margins will never escape, and the honest name for what you built is a staffing agency that ships code or provides support. People who are not clear about what they are building almost always end up with mediocre outcomes, and this particular confusion compounds against you.

Forward deployment only makes sense if the math bends. Deployment one is allowed to be ugly, handmade, economically indefensible. Its job is to teach. Deployment two must be cheaper because deployment one left behind a template, an integration, a documented pattern, a piece of platform. By deployment ten, most of what the first team did by hand should happen through configuration, and the humans should be a level up, solving problems that did not exist a year ago even in the eyes of the customer. The distance between those two numbers in month 1 and month n is compounding, and that curve is the actual thing you are buying when you fund a forward deployed team. Compounding is the whole point. Calling yourself forward deployed without an engine that compounds is simply stupid.

A software engineer and a forward deployed engineer differ mainly based on the amount of time a SWE spends writing code that maintains stuff, supports stuff or else builds stuff on roadmap vs what the FDE spends discovering stuff that’s often not on roadmap but unlocks customer value, deploying it and passing it to the product when the pattern starts repeating across customers.

The word everyone uses and almost nobody means

The idea has a specific origin. Two decades ago, a founder asked why great French restaurants are great, and landed on the waiter. In a great restaurant the waiter is part of the kitchen, so when they recommend something, it is the kitchen speaking. Palantir built the engineering version of that and gave the role a military name, because its customers were military. The name gave field work deserved status and rightfully so. It paid so well that twenty years later everyone wants the name but I’m not sure how many people get the work.

In a way a forward deployed team has to do what a founder has to do in 0-1 phase. You’re often discovering what you could ship that will not just lift a vanity metric but help your customer really grow their business. This is another real example from my friend’s conversation. His team was hired by an EV charger manufacturer that wanted to increase production by roughly 10x. That was the brief. Can you guess the result because it was definitely not a strategy deck. The company’s goal was simple on the surface: increase EV charger output by 10x. What the forward deployed team actually did was go on-site and learn the operation from multiple layers of the business. They spent time with the ERP owner to understand the system of record, purchase orders, work orders, supply, and demand. They then went to the shop floor to see how production really happened in practice. At the same time, they spoke with executives to understand the strategic version of the problem, because what frontline operators say is wrong or urgent does not always perfectly match what leadership sees as the constraint that matters most. The work, then, was not to build a new production line directly, at least not from what was said in the meeting. It was to build a digital twin of the operation and then identify where software could intervene in the workflow for example, around issues like critical part shortages, timing of purchase orders, safety stock, and other operational decisions. The outcome described was a system that could surface risks earlier and recommend actions, rather than a physical change to manufacturing itself. I hope this explains what I mean when I say ex-founders can be exceptional forward deployed folks.

Look underneath today’s job experience (not descriptions) and you find engineers who write production code inside a customer’s systems and own what happens after go-live including support. The rest are sales engineers with a better business card, judged on the demo, plus a tail of internal automation roles that borrowed the word because it is fashionable. The adjacent confusions on what forward deployment is are worse. Running an expert network through a hundred domain interviews is research but that’s not forward deployment. When a private equity rolls up companies and sends in a transformation squad, it’s useful, sometimes brilliant, but not necessarily forward deployment. I say this because nobody in those two motions owns what I call work-closure.

Work-closure is the unit this entire discipline is denominated in. Not a shipped feature, not a resolved ticket. A piece of the customer’s work, carried all the way from standing worry to something nobody thinks about anymore. The contract signature is the border between the professions that get confused here. A sales engineer works up to it. A forward deployed team starts at it, because agreeing that something should work is not the same as it working. If the person carries a quota, you are looking at sales. If the person is still in the customer’s logs three months after launch, you are looking at forward deployment. A company that sells a marketing product will send in sales engineers to get the deal signed and to deploy and configure things. A true FDE might come to a conclusion that none of the workflows the product supports will help the customer in question and something completely new will directly impact the top or the bottom line and then they build that workflow. This needs being an expert at Mom’s test (read the book), understanding that customers don’t care about your feature but about how they do better business, understanding what your product is capable of and shipping at a fast pace so that you can iterate with the customer on the live workflow.

So here is the definition I would put on the wall. Forward deployment is standing in the distance between what you shipped and what the customer needed, closing that distance with your own hands, inside their world, in a way that teaches your product to close it alone the next time.

The second half of that sentence is where almost everyone fails.

Why this is suddenly everywhere

For seventy years software helped people do work. Now it is starting to do the work. That flips a hidden assumption. A tool can afford to be adopted slowly. A worker cannot. The moment you sell outcomes instead of seats, someone has to make the outcome come true inside a company that behaves nothing like your demo environment.

The models stopped being the constraint somewhere in the past two years. Deployment became the constraint. The most cited study of enterprise AI pilots found roughly nineteen out of twenty producing no measurable P&L impact, and the autopsy is almost never model quality. It is software that never learned the workflow. The documented process has four steps. The real one has nine, and the missing five live in one woman’s memory, in a personal tracker she built years ago, and in a favor she trades with another woman in another building. In older industries the work runs through systems installed before your engineers were born, held together at the edges by fax machines and phone calls. None of it has an API. In the oil fields, somebody puts their ear against the rig to assess if the sound indicates something they should be worried about. on the ship transferring squids from India to the USA, with a stoppage in London, rates and prices are decided based on hunch, limited weather data, and what visually appears to be the quality of the stock. Tribal knowledge is the load bearing layer of every company, and nobody has ever shipped an SDK for it. The industrial platform graveyard of the last decade taught this lesson with billions of dollars. Transformations do not die in the architecture. They die at adoption.

The money has noticed. Microsoft committed two and a half billion dollars and six thousand people to embedding experts inside customers. AWS put a billion behind the same idea weeks earlier. OpenAI and Anthropic each stood up dedicated deployment companies with some of the world’s largest investors behind them. You can call this fashion. Capital at this scale is rarely a costume. The labs priced their own pipelines and discovered that the buyer was never short of intelligence. The buyer was short of hands. The failure lives in the last mile, and the last mile is where the moat gets dug. It took 10 yrs of aggressive work on LLMs to get to where we are. It might take much more if we were to get these models to have an understanding of workflow and human decision making framework.

Why do you need a business person on that team

The engineer exists because the gap is closed with code, on the customer’s infrastructure, against the customer’s edge cases, usually within days. What the users describe in the morning should be running in front of them within days, not quarters. That speed is how trust gets built with people who have watched three year transformation programs produce a slide library.

The business person exists because the hardest problems in deployment are not technical, and pretending otherwise is how technical teams fail. Somebody has to find out what the work actually is before anyone automates it. Somebody has to decide which three of the twenty escalations matter, whose workflow is the real bottleneck, which executive’s silence will kill adoption, and what outcome would justify the entire engagement. Somebody has to be good at reading when a customer is flinching and when they are saying things just to be polite. Somebody has to run the most delicate interface in enterprise AI, the one between what your product does today and what you sold as inevitable six months from now. I think of the deployment strategist as the company’s futures desk. They sell what the product will become, at a price the relationship can survive, and they make sure the position never defaults. High stakes deals are won on that desk, and blown without it.

The failure modes tell you which role you are missing. Deals stalling because the product will not run in the customer’s world or scenarios where the product supports only workflows that exist inside the product means you lack the engineer. Engineers shipping requested features and being busy but revenue not climbing as much or scenarios where the FDE has gone on 100+ calls but the contracted revenue is still an order of magnitude higher than realized revenue or silos of custom workflows that don’t improve the system means you lack the strategist.

In the best teams the two roles blur, and the blur is the point. The engineer grows business instinct, the strategist learns to read a schema, and what you get is the closest thing a company can hire to a founder. Forward deployment is what every founder does for years before the org chart hides it, sitting inside customers’ messes, closing work with whatever is at hand, letting what they learn redraw the product. The role is a founder’s week on someone else’s cap table. It is also why these teams mint founders at a rate that embarrasses big tech. If you run an FDE pod, you should brace yourself with succession planned from day one because chances are founders that build a decade later will all have been FDEs in their past life which is unfolding today.

How to know if you actually have one

You cannot judge a forward deployed team from a snapshot, because on any given day a great one and a fake one look identical, smart people flying to customers and shipping heroics. Five checks expose it.

#1 Effort per customer. A team that served five customers last year and serves five this year is compounding nothing. A team that now serves fifteen is feeding a product that absorbs what the field learns. With every customer, internally your team should develop a subject matter expert.

#2 The novelty of the work. If the fourth deployment repeats the third, nobody owns the pipe from field to platform. Somebody has to be paid to hunt repetition across accounts, because repetition is the roadmap writing itself.

#3 The shape of the second deployment in a segment. If customer ten costs you what customer one did, you are not scaling a product. You are franchising a project.

#4 The reporting line. Inside product or engineering, the loop can close. Inside a sales or services silo, the learning leaves in trip reports nobody reads, and the team quietly becomes margin.

#5 The customer’s own scoreboard. Activity is theater. Usage numbers can look spectacular while nothing downstream improves. The only measurement that survives contact with a CFO is an evaluation the customer helped write, scoring the work against their outcomes on their data, built in week one and tracked in the open. Keep one human test beside it. When something breaks in their business that has nothing to do with your product, are you the first call? Every dashboard ever built is an attempt to approximate that phone call.

And watch for the dark pattern, because it is everywhere right now. In some companies the forward deployed team is not a learning engine but a concealer. The product does not quite work, so a human is stationed at every gap. Because the humans are heroic, the gaps never reach the roadmap. Because the gaps never reach the roadmap, the product never improves, and the humans can never leave. Product feels no pressure because the field keeps absorbing it. The field writes nothing down because it is too busy saving accounts. The invoices keep arriving because the customer is, in fact, being served. The machine is in balance, and the balance is the problem. Companies live inside it for years, growing field headcount exactly as fast as customers and calling it forward deployment. It is not. It is the absence of a product, billed monthly. It is also why so many talented people in these seats feel like they are failing. They were hired to compound and staffed to conceal.

What it looks like at each stage

Early stage, do not hire it. Be it. The founders are the forward deployed team, and the worst thing you can do with your scarce understanding is delegate its acquisition. Take the two-day trips yourself. Sit with the dispatcher. When you finally hire, hire people who make you faster at closing work, never people who stand between you and the customer.

Growth stage is where forward deployment goes to be misunderstood, because from the outside it looks like slowing down. Your board watches engineers spend weeks inside single accounts while competitors announce features weekly. The accounting makes it worse. Deployment sits in cost of revenue even though the work behaves like R&D, so the better you learn, the worse you look. Hold both truths without lying in either direction. In the ledger it is cost. In strategy it is research. The resolution is not a story, it is guardrails that force the research to pay. Time-box every engagement. Tie each one to a single named business outcome. Harvest quarterly, meaning every quarter something the field built by hand becomes something the platform does alone. We will productize it later is the sentence that kills companies at this stage, because later has no owner.

At scale the question changes shape. You have hundreds of customers paying millions, and you already employ solution consultants, implementation teams, managed services, account executives, customer success. Leaders at this stage genuinely do not know where a forward deployed team sits, so it gets bolted on as a fourth tier of support and dies of ticket volume. The answer is that every existing function runs a playbook, and the forward deployed team exists only where no playbook exists. The ten most ambitious accounts. The new vertical. The workflow the whole industry says cannot be automated but which you feel you uniquely can automate. It reports into product, it is chartered to make its own work unnecessary, and it hands every solved pattern to the teams who run playbooks, which is how the playbooks stay alive. Uber’s version of this is instructive. They paired their most AI-fluent engineers with domain experts from finance, legal, and support, gave each pair two weeks, and required building beside the person who owns the workflow instead of presenting to them. Two days of shadowing, one day of choosing the target, live by day ten. Sixteen pods rewired sixteen functions in two months, and a report that took two days now takes ten minutes. The unit of automation was never the task. It is the workflow, and workflows reveal themselves only to people sitting inside them.

The same job wears different clothes in every industry

In defense and government, presence is the product. Clearances, disconnected networks, rooms your laptop cannot leave. In healthcare, the job is workflow archaeology. The real process runs through twenty-year-old systems of record, with fax machines and phone trees still carrying the exceptions, every facility running its own unwritten variant. A team that assumes a standard anything loses a year. In financial services the customer is buying judgment under compliance, the deliverable is often an evaluation a regulator could read, and the deepest anxiety is not data leakage but judgment leakage, the decision patterns of their best people walking into someone else’s model. In manufacturing and logistics, truth lives on the floor and the constraints are physical, which is why discovery cannot happen over video and the systems of record are archaic, visibly complex and often disconnected from cloud. In consumer businesses the loop runs in days instead of quarters, and the scarce skill is taste, knowing what the brand sounds like and when a machine should stop talking. And the newest territory is your own company. The same pods, deployed into your own finance and legal and support functions, because the gap between what AI can do and what your organization actually does is the same gap, one building away.

The terrain sets the tactics, and the tactics are negotiable but the sequence is not. Sit with the work, close the work, feed the product.

Who is actually good at this

The inventor, Palantir still runs the deepest version, and the detail everyone forgets is that the model was born before the product. In the beginning there was nothing to configure, only a bet that if you sat inside broken institutions long enough, products would reveal themselves. They did, and today the same company runs shorter, more templated engagements, because once the product exists, compounding is the religion.

The new generation is easiest to read in the customer service agent companies. Sierra runs its field function as agent engineers, and the loop is deliberate. Solve it for one customer, spread what worked inside the company, then graduate the winners into the platform so every customer inherits them. When their engineers learned, across dozens of deployments, exactly when an agent should stop retrying and hand the customer to a person, that judgment became a reusable component. Then they built Ghostwriter, an agent that does the building, fed on call transcripts, SOPs, and whiteboard photos, running on a platform they rearchitected so an agent could operate it directly. A bet on Sierra is, in large part, a bet that its deployed teams will keep discovering workflows nobody else has seen. Decagon went the systems route, audited its deployments for work that had no reason to be bespoke, cut the custom engineering behind each agent by eighty percent, and then said the quiet part in public, that delivery, not product, was becoming the moat. Ramp staffs its field team heavily with former founders, points them at the entire customer lifecycle from first call to long-tail support, and drills one habit above all, question the requirement before you build it, because the stated request is usually the symptom, not the disease.

Once you know the shape, you see it in every serious vertical. Harvey embeds former practicing lawyers inside law firms, proof that the deployed person does not have to be an engineer at all, only accountable. In finance, Rogo staffs nearly half the company with ex-bankers deployed into the institutions they came from, while Hebbia sends engineers to build the last mile inside the world's largest asset managers. Abridge is standing up deployment pods with hospital systems, because taking an AI scribe to twelve thousand clinicians is not an install, it is a campaign. HappyRobot embeds with freight brokers, Gecko Robotics puts builders on navy ships, Applied Intuition sits inside most of the world's large automakers, and Cursor (SpaceX) runs a forward deployed team that wires the tool your engineers already love into banks and telecoms.

Different shapes, one physics. The field feeds the factory, or it is not forward deployment.

The strongest case against, because it deserves one

There is an argument that this whole profession is an apology. You were sold a kitchen that cooks by itself, and it arrived with a chef who now lives in your house, on your payroll, at the vendor’s markup, with no move-out date. The pitch requires you to believe two things at once, that the machine is brilliant enough to replace your cooking and helpless enough to need a live-in minder. If the product needs a resident human, the product is not finished.

Take this seriously, because for many vendors it is simply true. The test that separates the species is the same one this article keeps repeating. If the human at the gap is permanent, the critique wins, and you are renting a patch. If the human at the gap is compounding, closing work in a way that removes the need for themselves, the critique dies at the second deployment. What it misses is that most of the work was never product-finishing. It is context acquisition. The five undocumented steps, the dispatcher’s unspoken intuition, the favor traded across buildings. No finished product will ever ship with those, because they are different inside every company. Someone has to go get them. The only question that matters is whether what they fetch compounds into an asset or evaporates into invoices.

Where this goes

Four shifts are already underway.

Context becomes the asset. What a deployed team really builds at each customer is a working model of how that company runs. The ontology, the twin, the map of who decides what and why. Investors have started calling it the company brain, and the name is sticking because every company is going to need one. More of it than people think can be bootstrapped before anyone gets on a plane, because customers leak their own truth constantly, in support tickets, call transcripts, emails, escalation threads. Start there. But the deepest layer, the knowledge people cannot verbalize, still requires presence and mirrors, tools that let insiders audit their own intuition until it turns into logic. Whoever holds that map holds the account, which raises the question every CEO is about to ask every AI vendor. I am renting the intelligence, but who owns the learning? If one shared model absorbs credit judgment from every lender in a market, the sharpest underwriter in the pool is training her competitors and paying for the privilege. There is a test any CFO can run. Swap model vendors tomorrow, on paper, and check whether everything you taught the system walks out the door with it. Expect contracts, teams, and eventually companies to reorganize around a single line. Rent the intelligence, own the learning.

Agents join the team. The forward deployed agent already exists in early forms. Onboarding agents that compress an afternoon of integration work into minutes. Deployment agents that read their own transcripts overnight and propose improvements to their own skills. Watch what that does to the human role. Every manual intervention stops being the work and becomes a training signal, and the team’s job inverts, from doing deployments to running the factory that does deployments. Staffing models the way managers staff people. Writing evals the way managers write reviews. The deeper inversion is in who the user is. Products are being rebuilt so agents can operate them directly, and the first discovery question at a customer is quietly changing from what does your team need to what does your agent need. The same flip is hitting the revenue side, where one person with an agent fleet now runs the pipeline a floor of people used to, and post-sale software is rebranding itself from tools into outcome-owning services, retention as a service today, expansion as a service tomorrow. And when your customer’s agents start negotiating with your agents, the humans left on both sides of the table will be doing the two things loops cannot close alone, deciding what is worth wanting and certifying that it actually happened.

The floor drops. Deployments that took five million dollars of elite engineering a few years ago now take a few hundred thousand and a sharp generalist with good agents, and the price is still falling. Forward deployment stops being a Fortune 500 luxury and becomes how mid-market software gets sold. The constraint stops being engineering supply and becomes judgment supply.

The title dissolves. Every engineer at a serious company is becoming partly forward deployed. Backend engineers sit on customer calls. Product engineers ship against call transcripts. Soon the percentage of time facing the customer is the only difference between an FDE and a software engineer, and titles will stop pretending otherwise. Which carries a warning nobody prints in the job post. This work converts builders into diplomats, and many brilliant engineers chose building precisely because rooms full of strangers drain them. Respect the introvert by not deploying them, and respect the role by never using it as the place you park engineers who were mediocre at engineering. It is the opposite. It is where you send the people you would trust to found something.

The oldest job in the company

Strip away the terminology and forward deployment is the founder’s original posture, kept alive inside a company that grew big enough to forget it. Sit where the work is. Close the work. Let what you learned change what you build. Every enduring company did this before it had a name for it. Most companies stop doing it the day they can afford to.

So the real question was never whether to hire forward deployed engineers. It is whether you are willing to run a company where the people closest to reality have real power, where effort is judged by its slope, and where nothing learned in the field is allowed to die there. Build that, and the title takes care of itself.

What is the last piece of work your team closed so completely that the customer stopped thinking about it? When was the last time a customer renewed not because they got the value from your product suite but because they know you will build things they didn’t even know they needed to grow their business? Start counting there.