On-Site Vendor Engineers Don’t Make the Vendor Accountable

← Back · ACT III · Chapter 19: Preemptive Value Architecture

Accountability is architectural, not proximate. The vendor lock-in evidence is 40 years old.

The value-selling discipline is evolving in public. A recent essay from the value-consulting community lays out what it calls the Forward Deployed mindset for value consultants, inspired explicitly by Palantir’s Forward Deployed Engineer model. The pitch: Value Engineers and Value Consultants should stop supporting deals from the sidelines. Instead, they should embed with customers, work alongside them in real time, shape the problem and the solution together, stay present through implementation and adoption, and be accountable for delivering measurable outcomes rather than just building the case for them.

It is a well-crafted argument. It also names a real gap in seller-side infrastructure. Traditional value consulting has weaknesses. The consultant builds a business case, throws it over the wall, and hopes for the best. Post-signature, the value story often ceases to exist. That gap is real.

But the Forward Deployed vendor model is not new, and the argument for it should not be evaluated as if it were. SAP has been running exactly this model since the 1990s. The historical record of what Forward Deployed vendor produces at scale, over decades, is available. It is worth consulting before the value-consulting profession commits to a career reinvention around a 40-year-old delivery model dressed up as innovation.

SAP as the Original Forward Deployed Vendor

SAP’s business model has always relied on customer-embedded professional services delivery. R/3 required extensive customization to fit any real business. Customization required SAP-certified personnel, either directly from SAP or from the system integrator partners (Accenture, Deloitte, IBM, PwC, Capgemini) that grew to their current global scale largely by servicing this model. Implementation projects ran for years and were followed by upgrade projects that required continuing SAP-blessed presence, and by integration work that only SAP-certified consultants could do. That is the Forward Deployed model in its original form, running at very large scale for more than thirty years.

A customer that has run the model for several decades shows what it produces. The customization that makes the platform fit the customer’s workflows becomes the constraint that keeps the customer on the platform, because each custom module, each integration point and each business process written against the platform’s data structures is another cost that has to be paid before anyone can leave.

Consider the extraction economics. Once a platform has been customized against for long enough, a competitor could hand over its entire stack for nothing and the customer still could not realistically move, because migration cost, business disruption risk and re-training would swallow the saving. That arithmetic holds across every large enterprise software category once the model has been running for more than a few years, whether the entanglement runs through a permanent integrator relationship, heavy customization, an integration web, or workflows so bound to the platform that migration means redesigning the process itself.

The largest systems integrators are the size they are in good part because they service this model at customer sites. Forward Deployed is closer to the default operating architecture of the enterprise software industry than to a special mode.

Palantir Did Not Innovate the Model

Palantir’s contribution to Forward Deployed vendor is branding and segment adaptation, not the model itself. Palantir successfully brought the standard enterprise-software professional services delivery into markets (defense, intelligence, then adjacent F500 verticals) where the buyers were less experienced with SAP-and-Oracle historical baggage. Its marketing rebranded the standard model as innovative capability delivery. What matters to a buyer is not whether that rebranding is fair, but what the model does over time, and it does the same thing wherever it runs. Practice teams grow inside the customer, extraction paths get harder, and adjacent purchases follow the people who are already in the building. A buyer signing up for embedded delivery now should expect to be having the same conversation about switching costs in a decade that long-tenured platform customers are having today.

This matters for how the Forward Deployed argument should be evaluated. Recommending that value consultants adopt the Forward Deployed mindset is recommending they become the SAP-model professional services delivery mechanism for their own vendor. That is less an evolution of the value engineering role than an invitation to participate in buyer-capture mechanics the enterprise software industry has been running for four decades.

Why the Model Fails the Buyer at Any Scale

The economics of large enterprise contracts justify the vendor’s cost of embedding personnel. That is why the model is viable at the top of the market, where a single account carries enough contract value to fund a permanent onsite team. But economics justifying the vendor’s cost is not the same as the buyer being served by the model. Five structural dynamics run against the buyer at every scale where the model operates.

First, portfolio-level coordination burden. A Fortune 500 buyer with meaningful contract exposure is not managing one Forward Deployed vendor. It is managing dozens at once, each with embedded personnel requesting context, meeting time, workspace attention, and internal introductions. Coordination cost multiplies non-linearly with vendor count. Vendor influence maps become impossible to maintain across the portfolio. Cross-vendor politics emerge, sometimes destructively. Buyer employee time gets consumed servicing vendor personnel in ways that never show up on any invoice.

Second, visibility asymmetry that NDAs do not neutralize. Buyers withhold visibility from paid partners for valid, defensible reasons. Roadmap plans that would give vendors advance notice of changing requirements. Competitive evaluation criteria across the vendors under consideration. Political dynamics between executives that shape decision timing. Cost pressure decisions. Layoff plans. Board dynamics. Regulatory investigation status. NDAs constrain what a vendor may legally do with information; they do not prevent the information advantage from accumulating, and they do not stop the vendor’s strategy function from analyzing everything embedded personnel learn. Mature buyer information hygiene depends on not putting a vendor in the room in the first place. Once the vendor is there, the information reaches them regardless of contract language.

Third, the corporate sponsorship gap. Sponsors leave, get reassigned, lose political capital. The embedded vendor personnel remain. When a vendor embed persists past the sponsor who authorized it, the vendor becomes a political free agent inside the buyer organization: accountable to no one on the buyer side, but influential across many buyer decisions. The question “who owns this vendor” can go unanswered for months. Formal contract governance ceases to control what is actually happening on the ground.

Fourth, rogue activities. Vendor embedded personnel routinely act outside their contractual brief, and most of what they do is invisible to buyer governance. Building relationships with buyer executives their contract does not authorize. Discussing product roadmap with buyer teams outside their engagement scope. Introducing colleagues from adjacent vendor practice areas informally. Recommending vendor solutions to problems the buyer team had not formally identified as vendor territory. None of this is malicious. All of it serves the vendor’s account growth, and the vendor’s account growth is not the buyer’s interest.

Fifth, and this is the load-bearing point: the model is anti-agnostic by structural design. It creates dependency, not accountability. Buyer teams become reliant on the embedded vendor’s knowledge of buyer systems, workflows, and data. Switching costs compound with each month of embedding. Adjacent problems get routed to the vendor because the vendor is already there and understands the environment. The vendor becomes de facto sole source for problems the buyer had not originally scoped as this vendor’s territory. Vendor-agnostic evaluation becomes structurally impossible because one vendor is inside the information environment and the others are outside. The buyer trades a permanently altered evaluation position for expertise it believes it cannot get any other way, and that trade is very hard to reverse once it has been made.

Proximity Is Not Accountability

The deeper move in the Forward Deployed frame is to substitute proximity for accountability. If the vendor is closer to the buyer, embedded and present and alongside, then, the argument goes, the vendor is accountable in some meaningful sense. But proximity is not accountability. Accountability requires that the accountable party bear a cost when the outcome fails. Vendor employees, however close to the buyer’s operations, do not bear that cost. The CFO who signs the certification bears it. The COO who owns the operation bears it. The board that answers to shareholders bears it.

This is not a moral criticism of value consultants who work hard on customer engagements. Many do. It is a structural observation about where accountability actually lives, and where proximity can sometimes be mistaken for it. When a vendor is embedded in the room, the room can begin to feel more accountable than it is. The visible presence of vendor personnel signals engagement, effort, and shared purpose. It does not, by itself, transfer accountability from the buyer’s chair to the vendor’s. Thirty years of SAP customer experience document exactly this pattern at scale.

A Buyer-Side Answer

The question the Forward Deployed frame implicitly poses (how does the buyer secure real accountability for outcomes across the value lifecycle?) has a different answer when you locate the response in the buyer’s chair rather than the vendor’s.

That answer is architectural, not proximate. When the buyer publishes a declared value-governance standard before commercial engagement begins, several things become true at once. The evaluation criteria are the buyer’s, not the seller’s translation of the buyer’s. The value hypothesis being tested is written down in advance, not reconstructed post-hoc from a deck. The checkpoints where the hypothesis is verified against actual delivery are scheduled and defined by the buyer, not by the vendor’s release cadence. The venue where accountability lives (the CFO’s certification, the CIO’s governance report, the board’s risk oversight) operates against the declared standard whether or not a vendor consultant is in the room.

In that architecture, the vendor does not need to be embedded, because the standard is embedded, and the standard is the buyer’s own. The buyer sets the definition before any vendor arrives to translate it. The buyer is not dependent on which value consultant happens to be assigned to the account, or how well that consultant handles internal politics, or whether the champion changes jobs mid-implementation. The standard operates independently of any of those variables. Vendor personnel can still be genuinely helpful, often are, but their helpfulness is a supplement to the buyer’s governance, not a substitute for it, and never a mechanism through which the vendor extracts information advantage the buyer would otherwise withhold.

Parallel Swim Lanes

This is not a case against Forward Deployed value consultants specifically or against the discipline generally. The gap the essay identifies on the seller side is real. Its answer works for the seller who wants to demonstrate outcome commitment. It works for vendors at contract scales where economics justify the embedded delivery model. It works when the buyer explicitly wants deep vendor engagement and has the governance maturity to manage the risks safely. None of those cases disappear.

What the buyer side needs, separately and in parallel, is an architecture that works when the buyer does not want deep vendor entanglement, when the buyer wants outcome accountability without vendor influence over internal decision-making, when the buyer has learned from thirty years of SAP-style lock-in what customer capture looks like from inside and prefers not to sign up for the next iteration of it. These are two different problems for two different disciplines, sitting in different chairs at the same table, and both are worth building. Only one of them keeps the buyer in control of value definition and vendor-agnostic evaluation over time. The reason a published standard is a realistic ask where seller-side reform is not is adoption cost.

Accountability is architectural rather than proximate, and when the buyer publishes the standard the vendor does not need to be in the room to be held to it. Thirty years of enterprise software history are available to anyone who wants to check what happens when the arrangement runs the other way.

Keep reading: ACT III · Chapter 19: Preemptive Value Architecture