> ## Content Index
> Fetch the complete content index at: https://www.martechtherapy.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# What is a forward deployed engineer, and who is paying for the one in your team?
- URL: https://www.martechtherapy.com/what-is-a-forward-deployed-engineer-and-who-is-paying-for-the-one-in-your-team/
- Published: 2026-09-28T08:22:19.000Z
- Updated: 2026-09-28T08:22:18.000Z
- Description: Vendors are embedding their own engineers to build your stack. One Martech company's accounts show the implementation running at a gross margin of 0.08%.
- Author: Matthew Niederberger
- Tags: Martech contracting, Martech strategy

At the Martech World Forum in London this month, Nate Wardwell from Hightouch talked about forward-deployed engineers and described them as a service Hightouch provides that is helping its customers. I wrote it up [in my recap](https://www.martechtherapy.com/martech-world-forum-london-2026-recap/) and left that question hanging.

Isn't that what independent consultants do?

I went and looked properly.

What I found wasn't really about job titles.

## What a forward-deployed engineer actually is

In short, someone the vendor employs, who sits inside your team and builds the thing. Not a trainer, not a support contact, not a consultant who writes a plan and hands it over. An engineer, in your standups, working in your systems, changing your configuration while the project is live.

Palantir is usually credited with inventing this, though I couldn't find a primary source for that. What's easy to find is everyone else adopting it. OpenAI has a Forward Deployed Engineering team. So does Salesforce, which says [it tripled the size of its own in six months](https://www.salesforce.com/news/stories/forward-deployed-engineers-making-ai-jobs-more-human/?ref=martechtherapy.com). Hightouch is hiring a Forward Deployed Analytics Engineer. Twilio has one, sitting in its go-to-market group rather than in Segment.

![](https://storage.ghost.io/c/57/c5/57c5ffb5-ecd9-4bf6-b870-68986d981176/content/images/2026/09/image-1.png)

They're everywhere.

## Is a forward deployed engineer different from a solutions architect?

Here is the best thing I found, and it immediately settles the question of how new this is.

[Databricks](https://www.martechtherapy.com/tag/databricks/) is hiring a Senior Forward Deployed Engineer. The web address of that advert still reads `resident-solutions-architect`, and the reference number on it is the same one it has always had. The people managing these engineers now *report to a Director of FDE*.

The job didn't change. *The label did*. Definitely not new in Martech, am I right? Anyway, further down the advert, the embedding turns out to be travel to customers twenty percent of the time, which is one day a week.

![](https://storage.ghost.io/c/57/c5/57c5ffb5-ecd9-4bf6-b870-68986d981176/content/images/2026/09/f2-same-job-relabelled.svg)

***Figure 1** *. One posting on the Databricks careers site, read on 17 September 2026.*

Adobe and [Tealium](https://www.martechtherapy.com/are-mcps-the-usb-c-of-ai-tealium/) still describe their consultants as an extension of your team, which is the older phrasing for the identical offer. [Snowflake](https://www.martechtherapy.com/how-snowflake-recruited-zeotaps-composable-cdp/) calls its version a *Resident Solutions Architect*, dedicated to you and delivered remotely by default.

So no, the arrangement isn't new. Something else is.

## Why vendors give the implementation away

What's new is that the commercial logic has been written down, and it's unusually frank.

Joe Schmidt at Andreessen Horowitz published a piece in June 2025 called [Trading Margin for Moat](https://a16z.com/services-led-growth/?ref=martechtherapy.com). His advice to software companies is to *stop protecting their margin and grow gross profit instead*, to *sell implementation at cost*, and to keep sales targets off the people doing the implementing. His evidence is that ServiceNow floated on a 63.2% gross margin and reached 79% by 2024, while Workday went from 54.1% to 75%.

> Give the services away early, take the margin back later.

What the services buy, in his own phrasing, is control of where and how the data enters the system.

Read that again if you have ever sat in a CDP selection. The implementation isn't the cost of winning the deal. The implementation is the thing being bought.

## Do vendors actually make money on implementation?

Look, I wanted to know whether this was investor writing or something already happening in our category, so I spun up some agents to sift through SEC filings of the Martech companies that publish enough detail to tell.

Sprinklr does.

In the financial year ending January 2026, it earned $100,861,000 from professional services and spent $100,783,000 delivering them. That is a gross profit of seventy-eight thousand dollars on roughly a hundred million of implementation work. *A margin of *0.08%**.

The year before was minus 3.3%. The year before that, plus 0.7%. Subscription margin over the same period sat at 76.4%.

![](https://storage.ghost.io/c/57/c5/57c5ffb5-ecd9-4bf6-b870-68986d981176/content/images/2026/09/f1-two-businesses.svg)

***Figure 2** *. Sprinklr's software business and its implementation business, gross margin by financial year.* ***Source** *: Sprinklr FY2026 Form 10-K.*

Three years hovering within a few points of zero isn't a exactly scheduling accident. It's a strategically calculated price. Somebody decided that implementation would be sold at what it costs to deliver, and the subscription would carry the business, and that is exactly the advice above showing up in an audited set of accounts.

To be fair to the argument, *this is a choice rather than a law*.

[Klaviyo's](https://www.martechtherapy.com/map-cep-or-cdp-klaviyos-james-fang/) filing says its product-led approach has limited reliance on professional services teams for implementation, and it doesn't break services out as a line at all. Braze combines its services costs with its hosting costs, so nobody outside can see the split.

Two different bets about how much help a customer needs before the product works.

[MAP, CEP, or CDP? Klaviyo’s James Fang on where marketing automation is headedKlaviyo’s James Fang on CDPs, MAPs, AI, and why the future of marketing automation is about consolidation and real business impact.![](https://storage.ghost.io/c/57/c5/57c5ffb5-ecd9-4bf6-b870-68986d981176/content/images/icon/Martech-Therapy-Icon-Only-Square-4c1ee3ef-8036-40b9-a4ce-c69aac82acea.png)Martech Therapy: CDP strategy and agentic AIMatthew Niederberger![](https://storage.ghost.io/c/57/c5/57c5ffb5-ecd9-4bf6-b870-68986d981176/content/images/thumbnail/https-3a-2f-2fsubstack-video-s3-amazonaws-com-2fvideo_upload-2fpost-2f171404917-2f9d7258ba-7291-48d4-bea8-fdfc133f87f4-2ftranscoded-1755674863-png-67837606-b1ec-479f-9d2b-16117ca79e68.jpg)](https://www.martechtherapy.com/map-cep-or-cdp-klaviyos-james-fang/)

## Why OpenAI says the limit is your organization, not the model

In February, [OpenAI announced multi-year partnerships](https://openai.com/index/frontier-alliance-partners/?ref=martechtherapy.com) with BCG, McKinsey, Accenture and Capgemini. Each firm is building a dedicated practice certified on OpenAI's technology, working alongside OpenAI's own forward deployed engineers. Accenture is putting ChatGPT Enterprise in front of tens of thousands of its own people.

The sentence that stopped me is in OpenAI's announcement:

> The limiting factor for seeing value from AI in enterprises isn't model intelligence, it's how agents are built and run in their organizations.

A frontier model company saying the constraint is not the technology but the organization buying it. Not exactly rocket science in 2026, Sam.

I've been making that case about Martech for years and calling it [readiness](https://www.martechtherapy.com/tag/martech-readiness/). It's strange to see it arrive from that direction, and it took Salesforce roughly a decade to assemble the partner ecosystem OpenAI has put together in about twelve months.

## Sign up for free

Receive my independent Martech insights and thoughts directly in your inbox.

Subscribe 

Email sent! Check your inbox to complete your signup. 

No spam. Unsubscribe anytime.

## Where an embedded engineer helps, and where it goes wrong

Peter Bendor-Samuel, who founded the analyst firm [Everest Group](https://www.everestgrp.com/?ref=martechtherapy.com), wrote the most useful skeptical piece I found on this. His distinction is that

> Embedded engineers make sense in systems that change continuously, where waiting for a release cycle would break the business, and are actively harmful in traditional systems built for stability, because changing production code in real time walks straight past testing, validation and release management.

I think he is right and I think *Martech inverts his risk*.

His warning assumes there is governance to walk past.

In most Martech stacks there isn't much.

No release process worth the name, no test environment anyone trusts, change control that amounts to a message in a Slack or Teams channel. So the embedded engineer ends up supplying the only controls you have.

That feels like a gift right up until the day they leave.

## What level of engineer are you actually getting?

Something to ask before any of the above, and almost nobody does.

These are laddered roles. Databricks runs forward deployed engineer, senior and staff as separate rungs. Salesforce advertises the job at more than one level in a single posting, and the experience line in that advert reads three or more years, or six to ten for the senior levels. Three years and ten years, same title, same advert.

Your contract will say a forward deployed engineer. It will rarely say which one.

The difference doesn't show up in whether the work gets built, because somebody three years in will build what you asked for and build it competently. It shows up in whether anyone tells you that what you asked for is going to collide with the thing running on the other side of the business.

That judgement comes from having watched a few stacks go wrong in similar ways, and there's no shortcut to it.

So name the level in the statement of work, and ask how many deployments the person actually turning up has finished. Not the pod. The person.

## Did the capability stay when they left?

The promise attached to all of this is **capability transfer**, and the vendors write it down themselves. Salesforce's own forward deployed engineer advert asks the person to co-build alongside customers, sharing best practices and enablement as they go, leaving teams more capable after each engagement than before.

That's a testable claim, and it's the only part of this you will control.

I would test it with the three things I always come back to.

1. Did anything about how your team is organized change?
2. Did the work simply route around your team to the visitor?
3. Is the capability still in the building after the engagement ends?

And is the process that now runs your stack yours, documented somewhere you can find it, or is it theirs. Ok, so four things.

There is an uncomfortable part underneath, and I want to state it without making it an accusation.

> The person embedded in your team has a **renewal** behind them.

Their employer's revenue depends on you *continuing to need the platform*, and possibly on continuing to need them. That's not a character flaw in a good engineer, most of whom I've found to be excellent.

It's how they're paid.

You already apply this instinct elsewhere. It's the same reflex as asking who published the page, which I [spent a month measuring](https://www.martechtherapy.com/can-you-trust-ai-to-research-martech-vendors/) across three thousand sources that AI assistants cite about buying a CDP. The sources you research with are mostly published by sellers.

Now the person who builds it works for one too.

## What forward deployed engineers mean for independent consultants

Back to my own question, since I am an independent Martech consultant.

If a vendor can put a capable engineer in your team and charge you roughly what that engineer costs, then every independent, every boutique agency and every systems integrator is quoting against a price that isn't really a price.

Honestly, in year one that is a hard thing to compete with, and I suspect it's part of why [Martech work has felt slower this year](https://www.martechtherapy.com/is-martech-work-slowing-down/) for a lot of people I talk to.

I don't think that's a scandal either, and on day one it's a decent deal for the buyer.

Year one is not the whole of it though.

I have seen what a vendor bills per hour for this kind of work. Two hundred and seventy five dollars. That is not a rate an independent needs to be frightened of, as long as nobody gets greedy, and an independent usually turns up having seen more than one stack, which tends to be the thing you are short of.

I'm biased here.

There's a hole in my own argument I should name.

If the services really are sold at cost, the vendor isn't earning anything on that engineer, which takes the rate argument away from me entirely. It also answers the question of what the engineer is there to protect.

> The money is in the subscription, so the engineer's job, structurally, is to make the subscription stick.

That's not cynicism about the individual, *it's where the margin sits*.

Which means my case was never really the rate. It's that I don't have a renewal behind me, making me more objective.

The part worth modelling is the second and third year.

![](https://storage.ghost.io/c/57/c5/57c5ffb5-ecd9-4bf6-b870-68986d981176/content/images/2026/09/f3-year-three.svg)

***Figure 3** *. Illustrative, not data. The same two days a week of help, priced two ways, over five years.*

If the capability genuinely transfers, the help you buy should shrink every year, because *your team needs less of it*.

If it doesn't transfer, it doesn't shrink, and the line keeps climbing at the angle it started at.

That is most of the difference, and it has very little to do with the hourly rate.

The other cost isn't money at all. The person who knows how your stack works, why that field is there, which of your decisions were deliberate and which were a workaround nobody wrote down, is on somebody else's payroll. That knowledge leaves when the engagement does, and it doesn't leave a document behind.

The honest version of my own position is that hiring someone independent doesn't remove that problem. It moves it. I have my own incentives, and you should ask about them.

## What to ask before you accept a forward deployed engineer

Ask who pays the person, out loud, at the start, and not as a challenge.

It changes how you read the advice, the same way knowing the publisher changes how you read a page.

Then *put the capability transfer in the contract* instead of the kickoff deck, next to [the dates and the rights you already argue about](https://www.martechtherapy.com/the-martech-contracts-dates-and-rights/). What gets documented, who reviews it, what your team is expected to be able to do without them by a named date.

Back in London I asked whether this pattern means we are understaffed, underskilled, or buying tools that are still too complex to absorb.

I said I had no idea, maybe all three.

I have half an answer now.

Sprinklr's accounts say the vendors have already concluded that *the tools can't be sold without someone coming along to build them*, and they have priced that in. Which of the three that is, I still couldn't tell you, but it's no longer a question anyone is leaving open.

It has been settled already, in the margin line.

Do you have any questions after reading this article?  
Or need ****independent support** with your Martech projects?

[Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)