Over the last few years, I’ve spent hundreds of hours consolidating my work across a few foundational disciplines that have become part of The Business Engineer’s core curriculum.
Now that AI has dramatically accelerated this process, I felt it was time to launch the Foundation Series.
The Forward-Deployed Engineer is another book in that series.
If you’re already a paid member, simply reply to this email, and we’ll send it your way.
The AI era has a distribution problem. Frontier models are extraordinary, but they are increasingly available to everyone. An insurer, manufacturer, bank, software company, and startup can all rent roughly the same underlying intelligence. The API is not the moat. Access to the model is not the deployment. Possessing frontier capability says remarkably little about whether an organization will ever turn it into operating value.
This is the paradox now showing up across enterprise AI. Capability is spreading faster than implementation. Model performance rises, inference gets cheaper, commitments to AI infrastructure grow, and yet an enormous amount of enterprise activity still dies somewhere between the demonstration and the P&L. That gap is the real market: the distance between what intelligence can do in principle and what a particular company can make it do inside its own systems, with its own data, under its own policies, around its own exceptions, with actual people accountable for the consequences.
The generic model knows none of this. It does not know that the supposedly standardized claims workflow actually branches into twelve exception paths; that the process diagram has not described the process for three years; that one spreadsheet maintained by a twenty-year employee quietly coordinates half the operation; that one risk will never survive compliance; that the ERP contains three definitions of the same customer; or that a step everybody officially follows disappeared from actual practice years ago.
The last mile is not merely technical integration. It is organizational reality. That is why the forward-deployed engineer has become one of the defining roles of the AI era.
An FDE is an engineer embedded at the customer’s constraint, building production machinery from the customer’s real work, with a second responsibility running in the opposite direction: what repeats in the field must eventually travel back into the product. Both directions matter. Without the first, the technology never truly reaches the customer. Without the second, the vendor becomes a consultancy.
The role therefore sits on one of the most valuable boundaries in the current economy: the boundary between general intelligence and specific work. Models can be deployed in minutes. Value takes longer because value has to be installed.
The origin: one company, under pressure
The role did not emerge from a human-resources exercise. It emerged because a company ran into a structural problem with its business model.
In the 2000s, Palantir was attempting to sell data software into some of the most complex institutions in the world. The promise of the platform was general, but the environments into which it landed were anything but general. Every customer had different source systems, schemas, operating processes, security constraints, definitions, politics, and ways of deciding what counted as truth. A generic platform could arrive technically complete and still be economically inert.
The missing component was not more software in the abstract. It was someone capable of crossing the boundary between the platform and the institution. So engineers went into the field. Not account managers who could describe the product. Not consultants who would study the organization and leave behind recommendations. Engineers who could understand the institution, touch the systems, build the implementation, and remain accountable for whether the thing actually worked.
That distinction created the forward-deployed model. The engineer lived close enough to the problem to discover what the product team could not see from headquarters. The customer’s real ontology emerged from the customer’s own data. The workflow emerged from watching the work. Requirements that had sounded important in meetings turned out to be irrelevant. Edge cases that had never appeared in specifications turned out to dominate production. The field became a source of truth.
The economics were equally important. The early phase of a customer relationship could be expensive. Engineers spent time learning an institution before the software produced meaningful leverage. In ordinary software economics, that looked ugly: high-cost people sitting with individual customers performing work that appeared difficult to scale. But the motion had a different logic: Acquire. Expand. Scale.
During acquire, the vendor absorbs the cost of understanding the institution. The field team learns the systems, vocabulary, workflow, constraints, and exceptions. Margins can be poor because the vendor is effectively financing discovery.
During expand, the first successful deployment creates evidence. Trust rises, adjacent workflows become easier to enter, and both sides now know the platform can produce value inside the customer’s actual environment.
During scale, the relationship changes character. The ontology already exists, the reusable infrastructure is in place, the customer understands the operating model, and new use cases can be layered onto what has already been learned. Field intensity per dollar of revenue falls, and the economics increasingly resemble software rather than bespoke services.
This is the essential trick: the field work is not supposed to remain field work forever. It is supposed to create leverage.
For years, this made Palantir easy to misunderstand. From the outside, a company employing large numbers of engineers around individual customers looked suspiciously like a consultancy wearing a software valuation. The criticism was not irrational. Any company can call services “deployment” and promise software will appear later. The test is whether the residue actually moves into the product.
That is what eventually matters. Patterns discovered across deployments become primitives. Repeated integrations become connectors. Recurring data structures become ontology patterns. Common controls become platform capabilities. Lessons paid for by one generation of customers harden into software sold to the next. The margins then tell the story.
What looked like an inefficient delivery model can become the manufacturing process through which the product itself is discovered. The field is part of R&D. The customer is not merely where the product is installed; the customer is one of the places where the product is found.
The role itself has changed as the underlying product has changed. At one point, the FDE might have been primarily concerned with platform stability. Then data integration became dominant. Then came turning data into operational decisions, enablement at scale, and now AI-speed deployment. Different vintages can look almost like different professions, but one continuity remains: the FDE owns the distance between technology delivered and outcome achieved.
AI has made that distance more important, not less. The modern model is vastly more general than the software stacks of the 2000s, but the organization it lands inside remains specific. In fact, the more general the intelligence becomes, the more valuable the installation layer can become, because the remaining problem concentrates around everything the generic model cannot know in advance.
That is why the old field-engineering idea has escaped its birthplace. The motion is spreading because the problem that created it has spread.
Why now
Four forces have converged to make the forward-deployed model unusually important.
Commoditization above. Frontier capability is becoming easier to procure. A company does not need to train a foundation model to access world-class language, coding, vision, or reasoning capability. It can rent those capabilities from a growing set of providers, and the models continue to leapfrog one another. This pushes differentiation upward. If every serious competitor can access excellent models, the question becomes what each competitor builds around them: the harness, context, workflow, evaluation suite, permissions, integration, institutional knowledge, and operating design. The installation becomes the product.
Stall below. Enterprise appetite for AI is enormous, but appetite and deployment are not the same thing. Organizations can sign large cloud commitments, buy model access, run pilots, create task forces, and still fail to change how a meaningful workflow operates. The failure tends to happen where abstractions meet organizations. The demo assumes clean data; the company has seven systems. The workflow assumes the documented process; operators use another one. The agent assumes it can take an action; compliance requires approval. The model assumes context is available; the decisive information lives in a PDF, an inbox, a person’s memory, and a badly maintained database. These are not edge conditions. They are the enterprise.
Imitation across the market. The role that once looked idiosyncratic is being reproduced across the AI stack. Frontier AI companies, cloud providers, data platforms, and rapidly scaling applied-AI businesses increasingly use field-heavy engineering motions because all of them are discovering the same thing: the product does not finish at the API boundary. The interesting signal is not that companies copy a fashionable title. It is that companies with very different products keep rediscovering the same organizational structure.
The window. Every technology cycle contains a period in which humans manually perform the work that software will later absorb. The early web was full of hand-built pages before content-management systems standardized publishing. Early cloud adoption required armies of migration specialists before the process itself became increasingly automated. Enterprise AI is in the same phase.
Today, field teams manually discover workflows, structure context, build evaluation sets, identify failure classes, configure permissions, encode domain language, and wire agents into production systems. Some of that work will disappear. It is supposed to. The important question is who captures what is learned before it disappears.
Every deployment produces residue: recurring problems, common integrations, reusable ontology patterns, repeated evaluation structures, standard approval flows, predictable objections, common governance requirements. The company that captures that residue gets a roadmap paid for by real customers. The company that fails to capture it simply sells more labor.
The manual work of this decade is the raw material of the products of the next one.
The field is where that material is being generated.
What the role is — and is not
The title is already suffering from its own success. “Forward-deployed engineer” can now mean implementation engineer, solutions architect, data engineer, customer engineer, technical account manager, AI consultant, product engineer, pre-sales engineer, or some hybrid of all seven. Titles are cheap. The structure is what matters.
A useful definition has three clauses: an engineer embedded at the customer’s constraint, building production machinery from the customer’s real cases, with an explicit duty to convert repeated deployment learning into product.
Each clause eliminates a neighboring role. Remove embedded at the customer’s constraint, and the engineer can remain technically excellent while being too far from the real problem. That is conventional product development. Remove building production machinery, and the role can diagnose, recommend, facilitate, and advise without ever carrying the outcome into operation. That is consulting. Remove convert repeated learning into product, and the company can become extremely good at bespoke implementation while never producing leverage. That is a body shop.
The FDE sits at the intersection.
This is also why the comparison with consulting is useful but incomplete. Traditional consulting built enormous businesses around a leverage pyramid. Senior judgment was scarce and expensive. Junior labor gathered information, created analysis, produced artifacts, and moved the project forward. The model scaled because many hours could be sold underneath a smaller number of senior people.
AI attacks the bottom of that pyramid first. Research, first drafts, analysis, reconciliation, formatting, documentation, and many forms of implementation can increasingly be performed by machines. The part that remains scarce moves upward toward judgment, architecture, domain understanding, trust, and accountability.
The forward-deployed model is almost the inversion of the old pyramid: send fewer, unusually capable people armed with enormous machine leverage; build the operating system instead of the recommendation; encode knowledge into the customer’s machinery and the vendor’s product; optimize not for utilization but for the speed at which customer-specific work becomes reusable capability.
This is why the FDE should not be measured as an expensive implementation resource. The right question is: what does each deployment leave behind? If the answer is only revenue, the motion is weak. If the answer is revenue plus customer capability plus reusable product knowledge, the motion compounds.
The motion, in five moves
1. Pick the wedge
The first use case determines much of the engagement’s fate. Enterprise AI programs often begin with the wrong instinct: find the largest imaginable opportunity. The transformation office wants something strategic enough to justify executive attention, so the first project becomes a moonshot. That is usually backwards.
The first deployment should maximize the probability of producing a verified, meaningful win. Score the wedge against six properties: volume, whether the work happens often enough for improvement to matter; specifiability, whether the task can be described precisely enough for a machine to attempt it; verifiability, whether success and failure can be judged without relying entirely on opinion; pain, whether solving it matters enough that the organization will notice; then reversibility, whether early failures can be contained; and data proximity, whether the information required to perform the work is actually accessible.
This creates an important discipline: refuse both ends of the temptation curve. Refuse the moonshot whose prestige disguises terrible deployment characteristics, but also refuse the trivial automation nobody will care about. A tiny administrative win may be easy, but if nobody feels the outcome it generates no organizational momentum. The first deployment has to be small enough to succeed and important enough to recruit the second one.
The scorecard itself should become an artifact. Write down why the wedge was selected, why other candidates were refused, what success means, what must remain reversible, and what evidence will count. The FDE is already teaching the customer an important habit: AI deployments should be chosen by operating properties, not executive excitement.
2. Embed at the constraint
Once the wedge is selected, the real discovery begins. Most companies already possess process documentation. The FDE’s job is not to believe it.
The first phase is process archaeology. Watch the work happen. Ask what happens after the flowchart ends. Find the manual exceptions, duplicated data entry, emergency paths, informal approvals, CSV exports, shadow systems, and spreadsheets nobody mentioned. The gap between the official process and the practiced process is often where the product opportunity lives.
This requires humility. The engineer cannot arrive assuming the customer’s strange behavior is irrational technical debt waiting to be corrected. Many apparent workarounds exist because the formal system failed to encode an important constraint. The ugly spreadsheet may contain twenty years of institutional knowledge. Understand why it exists before replacing it.
Everything discovered should move into a durable record from day one: terms, exceptions, decisions, policies, source systems, known failure modes, ownership, escalation paths. The deployment should progressively externalize the process from people’s memories into something humans and machines can inspect.
At the same time, construct the golden set. Not synthetic cases and not vendor-created demos: real cases drawn from the customer’s historical work, adjudicated by the people who know what correct means. Sixty, eighty, a hundred cases can reveal an enormous amount if selected properly: routine work, difficult edge cases, known failures, policy boundaries, ambiguous inputs, and examples where experts themselves disagree.
The customer’s expert should sign the set. Once the evaluation suite belongs to the customer, the conversation changes. The vendor is no longer grading its own homework. The suite becomes a neutral referee between product enthusiasm and operational reality.
3. Build what compounds
Once the process is understood and the golden set frozen, the FDE builds the working system. The model sits behind a clean joint. The customer’s record supplies context. Their red lines become controls. Their repeated standards become reviewer instructions and mechanical checks. Their permissions determine what the system may touch. Their escalation structure defines where autonomy stops.
The objective is not to create a magical demo. It is to build a unit whose performance survives contact with the customer’s real cases.
This is also where AI changes the cadence of field work. Historically, the customer explained what was wrong, the vendor took notes, engineers returned elsewhere, changes entered a backlog, and another review happened days or weeks later. Agentic engineering compresses this loop.
Arrive with something built. Let the customer break it. Capture why it failed. Feed the objections back into the system. Rebuild. Run the suite again. Return in hours rather than weeks. Repeat.
A team capable of completing ten serious iteration cycles while another completes one is not merely moving ten times faster. It is learning under a different compounding function. Each turn changes the next: the procedure becomes sharper, context cleaner, exceptions explicit, evaluation harder, guardrails more precise, and both sides understand the actual problem more deeply.
This is iteration compounding. Trust stops being theatrical and becomes empirical. The field role begins manufacturing something more valuable than an implementation: it begins manufacturing fit between a general model and one organization’s substance.
4. Publish the numbers
AI programs do not scale on enthusiasm for long. They scale when somebody can point to an operating panel.
Once the first unit works, measure it visibly. How many human minutes does one accepted outcome require? What percentage of cases pass on the first attempt? How many failures are repaired inside the machine loop without human intervention? What is the cost per accepted outcome? How often does the system escalate? What happened to cycle time? How is performance trending against the customer’s frozen suite?
These are more useful than generic model benchmarks because they measure the thing the business actually bought.
Publish them. Weekly if necessary. Numbers create a different internal sales motion. Adjacent teams no longer hear that AI could transform a workflow. They see that another team has already returned hundreds of hours, shortened a process, reduced error, or increased throughput. The customer starts bringing the next use cases to the vendor.
At this point the deployment architecture should begin splitting in two. There are the retail units: individual workflows, each with its own charter, context, evaluation suite, and owner. Beneath them sits the wholesale substrate: shared identity, permissions, record, observability, model routing, evaluation infrastructure, and governance.
The first few deployments can tolerate duplication. The tenth cannot. Around the third serious unit, the FDE should already be asking which components are customer-wide rather than workflow-specific. That is how each next deployment becomes cheaper than the previous one.
5. Harvest the residue
This is the move that decides whether the FDE motion becomes a software company or an expensive delivery organization.
Every engagement produces specifics, and most should remain specific. But across enough deployments, patterns repeat. The harvest has three levels.
Playbook. A recurring deployment lesson becomes written method. The next team does not have to rediscover it, so deployment time falls.
Toolkit. The pattern repeats often enough that documentation is no longer sufficient. It becomes reusable machinery: templates, evaluators, connectors, schemas, libraries, deployment primitives. Deployment cost falls.
Product. The pattern has repeated across enough customers, under enough variation, that it deserves to become part of the standard platform. Now the business model changes.
The hierarchy is simple: Playbook → Toolkit → Product. Every promotion converts experience into leverage.
If an organization performs fifty deployments and number fifty costs roughly what number one cost, it has learned remarkably little. If number fifty contains the accumulated residue of the previous forty-nine, the field has created a compounding asset.
There is an important ownership boundary. The customer’s substance belongs to the customer: their data, confidential context, proprietary operating decisions, business rules, and specific process knowledge should not become somebody else’s asset simply because an engineer helped encode them. But the generalizable pattern discovered through solving the problem can belong to the vendor, subject to the contractual structure both sides agreed to.
And there is a deeper implication. If the motion succeeds completely, parts of the FDE’s own work should disappear. Process discovery becomes partially automated. Integration gets easier. Evaluation construction becomes assisted. Standard governance patterns become product features. The next FDE does less manual work than the previous one.
This is not a threat to the role. It is the objective.
The job of the forward-deployed engineer is, in part, to automate the job of the forward-deployed engineer.
The firm that understands this harvests its field organization into product. The firm that does not eventually discovers it has built a consultancy with unusually technical employees.
The two sides of the table
There is a reason enterprises should both want the FDE model and fear it. An engineer embedded deeply enough to reconstruct your operating machinery can create extraordinary capability transfer. The same engineer can also help create one of the deepest vendor dependencies an organization has ever accepted. Both statements can be true. The difference is architecture.
For the buyer, the governing concept is institutional sovereignty: the organization’s ability to retain control over the decision rights of its own business even when outside intelligence, software, and infrastructure are deeply embedded inside it.
Four exposures matter. Lock-in: once AI becomes part of a production process, replacing it can become much harder than changing an ordinary SaaS application because context, evaluation sets, workflows, policies, and human behavior begin adapting around it. Subsidy: consumption paid to an outside intelligence provider may finance a company that eventually moves into adjacent parts of your own value chain. That does not automatically make the relationship irrational; it makes the dependency worth pricing. Rule change: a vendor can alter model behavior, pricing, terms, limits, or product architecture. In consumer software this may be irritating; in a plant, hospital, bank, insurer, or ministry it can be operationally intolerable. Cost: not every task needs frontier intelligence, and using the most capable model for routine work can turn technological ambition into structurally poor unit economics.
Sovereignty is therefore not binary. It is a gradient. At one end, the enterprise relies heavily on external providers but protects itself contractually and architecturally through portability, data rights, clean interfaces, and tested exit procedures. Further along, it owns more of the harness, context, evaluation infrastructure, and operating logic while continuing to rent models. At the structural end, particular workloads may justify owned infrastructure or task-specific models.
Different processes deserve different answers.
The deepest asset in this analysis is the decision loop: data seen → reasoning applied → action taken → outcome observed. A warehouse of raw records tells you what happened. A decision loop begins to tell you what the organization saw, what it believed, what it did, and whether the decision worked. That is far richer material from which increasingly specific intelligence can be built.
Whoever owns the loop owns the compounding.
The contract should therefore be written around artifacts, not vague assurances. The ownership schedule should be a table. Who owns the raw data? Derived context? Evaluation suite? Procedures? Deployment-specific code? Generalized components? Logs? Corrections? The record of model decisions? Can each artifact be exported, in what format, and how often is portability actually tested?
“Portable” should not mean a salesperson promises that migration is theoretically possible. It should mean someone has demonstrated the export.
The same principle applies to commercial structure. AI pricing increasingly follows two variables: attribution and autonomy. When the product assists a human and the connection between software and business outcome is weak, seat pricing remains natural. When the system works autonomously but the value of each completed task is difficult to attribute cleanly, usage pricing can make sense. When the system owns a clearly verifiable business result, outcome pricing becomes possible.
But outcome pricing creates an uncomfortable requirement: someone has to stand behind the outcome.
That is another reason the forward-deployed role matters. The FDE is not merely there to configure software. The FDE can become the person who creates enough operational certainty for the vendor to move from selling access to selling results. The stronger the guarantee, the stronger the need for somebody technically credible to own the reality underneath it.
Then comes the handover. A field engagement should not finish when the vendor believes the system is complete. It should finish when named customer operators can run it, hands off. The acceptance test should include routine operation, failure handling, escalation, context updates, evaluation, and recovery.
That yields the only reference worth having: the customer could leave, and chooses to expand instead.
Lock-in is weak evidence of value. Voluntary dependence after proven portability is much stronger.
There is also a point at which enterprises should stop purchasing the motion and build their own. Four conditions push toward internalization: strategic workflows, regulatory density, data gravity, repeat volume across business units. If one is present, negotiate ownership and portability aggressively. If all four are present, ask the harder question: are we paying somebody else’s margin to accumulate operating knowledge that should compound inside our own institution?
For those firms, the internal FDE practice becomes strategically attractive. The motion looks similar, but the economics invert. The practice is funded by the P&L it improves rather than an external sales organization. Internal sponsorship replaces selling. Deployment residue accumulates into the enterprise’s own harness. The knowledge base becomes institutional memory. Evaluation suites become company assets. The organization’s experts become teachers of the system.
The correct shape is not scattered AI enthusiasts inside independent business units. It is a central practice deploying into the units and bringing the accumulated method home: local intimacy, global compounding.
The career
For an individual engineer, the forward-deployed seat is unusual because it sits diagonally across disciplines the labor market traditionally separated. Most career systems reward depth along one axis. The FDE requires depth across several, and that scarcity creates the opportunity.
The skill stack has four layers, in order.
Engineering depth. Not theoretical familiarity with AI, but the ability to take an ambiguous workflow and turn it into an operating unit: define the charter, access the systems, construct the context, build the evaluation suite, implement the harness, create gates, instrument the workflow, and read the gauges. The role loses its center if the engineer cannot build.
Domain fluency. The FDE does not need to begin as the world’s greatest insurance adjuster, manufacturing planner, banker, or supply-chain operator, but they need to learn the domain at practitioner grain. Vocabulary is not enough. They need to understand where judgment enters, which exceptions matter, why the process evolved the way it did, what failure costs, which data is trusted, and which shortcut an experienced operator notices instantly.
Field craft. The ability to conduct process archaeology without humiliating the people who built the process; absorb skepticism without becoming defensive; distinguish a political objection from a technical one; recognize when the room is telling you the system failed even though nobody will say it directly; bring something imperfect into the room early enough that the customer can correct it; and translate between the person doing the work and the executive funding the transformation. These are not soft skills. They determine whether the engineering reaches reality.
Commercial literacy. The FDE sits too close to the economics of deployment to remain commercially naive. They should understand the ownership schedule, where implementation effort is being subsidized, which pieces create reusable product leverage, when an outcome can be priced, and whether the current contract is building the customer’s moat, the vendor’s moat, or both.
The engineer who understands these things can turn deployment into strategic position. The engineer who does not may spend years building somebody else’s compounding asset for a salary.
There is also a natural ladder inside the role. At the first rung, the engineer proves they can operate as a second chair, with an artifact as evidence: an evaluation suite the customer accepts, an integration that survives production, or a subsystem that can be handed over. The next rung owns the wedge, one use case from discovery through measured production. The next owns the engagement, including multiple units, governance, substrate, and handover. Then comes the cascade lead, responsible for turning one working deployment into a program across teams or business units. At the top sits the principal, whose real artifact is the harvest: what became playbook, toolkit, and product across the portfolio.
Promotion in this career should run on exhibits, not tenure.
The title itself should be interrogated carefully. Because the role has evolved through several vintages, two people can both be called FDE while holding radically different jobs. Ask what vintage the seat is. Is it really platform reliability? Data integration? Workflow engineering? Customer enablement? AI-native rapid build? Is it post-sales or pre-sales? Does the engineer write production code? Who owns the outcome? Who owns the customer relationship? What percentage of learning is expected to flow back into product?
The title tells you very little. The operating model tells you almost everything.
The career paths out of the seat are particularly interesting because they all monetize the same asset: deployment residue. One path leads into product leadership, carrying unusually rich knowledge of what paying customers actually needed. Another builds the practice, scaling the motion itself. A third leads to founding: if the same painful pattern appears across three independent deployments, the FDE may be staring at a company before the market has named it. A fourth crosses the table and builds the internal enterprise motion, bringing the field discipline inside a large organization.
That is why the deployment record can become an extraordinary startup thesis. Many founders begin with an imagined market problem. The FDE can begin with one already observed repeatedly under production conditions, attached to real budgets, failure modes, and buyers.
The seat’s compensation is the salary. The career’s compensation is the residue.
Building the motion, and what it buys
A company should not begin by hiring twenty forward-deployed engineers. It should begin by proving that there is something worth deploying repeatedly.
The motion starts after the pattern. Founders or a small core team should first complete two or three deployments themselves. They need evidence that the same class of problem appears repeatedly and that solving it creates meaningful customer value. Hiring a field organization before discovering the wedge creates a dangerous structure: a body shop with a software narrative.
Once the pattern exists, build around a founding pair. One side owns the technical outcome; the other owns the commercial and organizational motion around it. Exact titles matter less than complementarity. Enterprise deployments fail for both technical and political reasons. Somebody has to build the machinery, and somebody has to help the customer create the conditions under which the machinery will actually be adopted.
Then build the operating system before adding headcount. First, the deployment record: every engagement should produce comparable artifacts, including the wedge scorecard, process map, golden set, architecture, ownership schedule, gauges, decision log, and handover result. Second, the harvest channel: there must be an explicit process through which repeated field patterns are reviewed for promotion into playbook, toolkit, or product. If the path is informal, field knowledge remains trapped in individual teams. Third, the meters: the organization must know whether the motion is becoming more leveraged over time.
Only then scale.
The early team should not be built entirely from mythical perfect FDEs because the profile is too scarce. A better structure combines experienced principals with diagonal-in-progress people who have one strong axis and can learn the others in the field. A domain operator who becomes technical may be more valuable than a generic engineer who never learns the domain. A production engineer with unusual customer instinct may grow faster than a conventional solutions person.
The apprenticeship matters. The field is where the profile is finished.
Six meters tell the company whether the motion is compounding. Time-to-magic: how long from engagement start to the first verified result on real customer work? Expansion rate: how reliably does one successful unit recruit the next? Outcome conversion: how much revenue is moving from access or effort toward measurable results? Productization rate: what share of repeated field learning becomes reusable toolkit or product? Margin trajectory: do the economics of an account improve as the relationship matures? Title cleanliness: are the FDEs actually doing forward-deployed engineering, or has the role become a bucket for every difficult customer problem the organization does not know where to place?
The last meter is more important than it sounds. A role without boundaries becomes an organizational dumping ground. FDEs are unusually capable, so organizations will try to give them everything: demo the product, fix the integration, write the feature, handle the escalation, run the workshop, support the account, close the deal, train the users, create the roadmap. At first this can look like leverage. Eventually it destroys the motion because the people responsible for harvesting the most valuable deployment knowledge spend their time absorbing miscellaneous organizational failure.
A durable FDE organization therefore needs a refusal log. Which engagements did we decline? Which customer requests do not belong to this motion? Which “strategic” projects failed the wedge scorecard? Which integrations should become standard product rather than field work? Which recurring requests reveal an upstream product defect?
Refusal prices discipline.
Then come the returns. The first is revenue with proof attached. Field engineering can unlock contracts ordinary software sales cannot because the customer sees the product working on its own substance before being asked to imagine the value.
The second is a demand-side moat. After enough deployments, the company possesses something competitors cannot reproduce by copying features: a detailed map of what hundreds of real organizations actually require for the technology to work.
The third is the product itself, and this is the most important. The field organization becomes an external sensory system for product development. Instead of a roadmap assembled from abstract feature requests, the company receives repeated patterns exposed through paid production work. Customers fund the discovery. Engineers validate the requirement. The harvest system identifies recurrence. Product absorbs the stable pattern. The next deployment begins further ahead.
That is the flywheel.
The fourth return is position. The company operating a successful forward-deployed motion sits exactly where the economics of the AI era become interesting: the point where abundant general intelligence meets scarce, contextual, proprietary work. That junction contains the customer relationship, context, exceptions, operating feedback, evaluation standard, and evidence of value.
The model layer may continue commoditizing. This layer does not necessarily commoditize with it. It can become more important because as raw intelligence becomes abundant, the scarce question shifts from Who has the smartest model? to Who knows how to make intelligence work here?
The Library — Mental Models of the Playbook
The ground
The Last Mile: capability is increasingly available; installed value is not.
Deck vs. Machine: the test of a deployment is what continues operating after the presentation and the people who made it leave.
Product Development in the Field: deployment is not downstream from product development; properly structured, it is one of its inputs.
The Three Stalls: data, adoption structure, and trust are where abstract capability most often encounters institutional reality.
Time-to-Magic: the distance from kickoff to the first verified win on the customer’s own cases.
The Vintages: the FDE title has covered several different jobs; accountability for the customer outcome is the continuity.
The motion
The Wedge Gates: volume, specifiability, verifiability, pain, reversibility, and data proximity. Score before building.
Process Archaeology: study the process as practiced rather than the process as described; the undocumented layer often contains the product.
The Golden Set: real, adjudicated cases signed by the customer’s expert become the engagement’s neutral referee.
Agent Cadence: arrive with something built, invite the customer to break it, rebuild while the context is still fresh.
Iteration Compounding: radically shorter feedback loops create more than linear speed because every correction changes the next attempt.
Graduate in Public: agree on thresholds before seeing the result and publish performance against them.
Retail Units, Wholesale Substrate: individual workflows remain local; identity, context, permissions, evaluation, and observability become shared infrastructure.
The Residue Hierarchy: playbook, toolkit, product. Every promotion converts experience into leverage.
The Job Is to Automate the Job: field work that repeats should progressively disappear into the product.
The two sides
The Capture Question: embedded engineering can create rapid capability transfer or deep dependency; architecture determines which.
Institutional Sovereignty: the enterprise retains control of its own operating decision rights.
The Sovereignty Gradient: rent or own depending on consequence, strategic importance, regulatory density, and portability requirements.
The Decision Loop Is the Alpha: data seen, reasoning applied, action taken, result observed; whoever controls the loop controls the richest form of organizational learning.
The Ownership Schedule: every artifact has an owner and an exit test.
Attribution × Autonomy: seats, usage, and outcomes correspond to progressively stronger relationships between machine action and measurable value.
The Guarantee: outcome pricing requires somebody capable of standing behind the outcome.
The Handover Test: complete means customer operators run it unaided.
The Four-Part Test: strategic workflow, regulatory density, data gravity, repeat volume. The more boxes checked, the stronger the case for building the motion internally.
The Central Practice: deploy locally, accumulate globally.
The team and the career
The Diagonal Hire: the rare profile combines technical depth, domain learning, field temperament, and product instinct.
The Skill Stack: machinery, domain, field craft, commercial literacy, in that order.
The Rung Ladder: second chair, wedge owner, engagement owner, cascade lead, principal; each rung proved by an artifact.
The Vintage Question: before accepting the title, ask which version of the role the company actually means.
The Four Arcs: product, practice, founding, enterprise; each monetizes deployment residue differently.
Start After the Pattern: scaling field headcount before proving a repeatable wedge creates services economics by default.
The Founding Pair: technical outcome and organizational change need owners from the beginning.
The OS in Order: deployment record, harvest channel, meters, then headcount.
The Six Meters: time-to-magic, expansion, outcome conversion, productization, margin trajectory, title cleanliness.
The Refusal Log: what a field organization declines reveals whether it possesses a discipline or merely a willingness to help.
With massive ♥️ Gennaro Cuofano, The Business Engineer