ChatGPT
Claude
PerplexityThe most upvoted opinion about forward deployed engineers is that the role is consulting with better branding.
That opinion deserves a hearing rather than a rebuttal, because the people holding it have done the job under both labels. This page takes the accusation seriously, presents the evidence that supports it, presents the evidence that does not, and ends with the four attributes that actually separate the two delivery models. Some of what follows is unflattering to the category.
Engineers on r/ExperiencedDevs call the forward deployed engineer a renamed implementation consultant
The charge is not a fringe view. On an r/ExperiencedDevs thread from six months ago asking what the role really is, two of the most upvoted replies were blunt.
One, which Google surfaces at 83 votes: “This is just being an implementation consultant, but with a new title right?”
Another, at 79 votes: “It’s consulting without the dirty ‘c’ word.”
A larger and more recent thread in the same subreddit, posted two months ago and now past 70 comments and 76 answers, asks why the openings are all senior. Its top answer defines the role in one line: an on-site customer engineer, filled by developers with consulting experience and solution architects.
A separate thread from November 2025 opens with the same framing, that forward deployed engineer is a fancy new name for something that already existed. On r/salesforce two months ago, a developer weighing the move got 26 answers, and the top one endorsed the switch on market terms rather than substance: the role is in demand right now, and the poster should take it while it is.
Notice what the skeptics are not saying. Nobody argues the work is easy, or that the demand is imaginary. They argue that embedding a technical person with a customer to build software in the customer’s environment is a description of implementation consulting, and that the ecosystem has renamed it. On the plain meaning of the words, they have a point.
Salesforce builds its forward deployed engineer team partly from its own professional services organization
Here is the evidence that most supports the skeptics, and it comes from Salesforce rather than from critics.
Salesforce reported in March 2026 that it had tripled its forward deployed engineer team in six months, and that the team was built from three existing internal groups: engineering, professional services, and customer success. Salesforce headlined the same report with the phrase curiosity over credentials.
Read that plainly. Salesforce did not scale the role by recruiting a scarce new kind of engineer. It scaled by moving people across from adjacent internal organizations, one of which is professional services, and it says openly that aptitude mattered more than formal qualification. If forward deployed engineering required a fundamentally different human being, tripling a team that way in six months would not be possible.
So the honest position is this. The people are substantially the same population. The claim that FDE is a new species of engineer does not survive contact with Salesforce’s own staffing data.
What changed is not the person. What changed is the commercial and operational structure the person works inside, and that change is measurable.
Billable utilization fell to 66.4 percent and broke the engine traditional consulting runs on
Traditional Salesforce consulting is not primarily a methodology. It is a business model, and the model has one engine: billable hours multiplied by utilization multiplied by the ratio of junior staff to senior staff.
That engine is running at its weakest measured point. The 2026 SPI Research Professional Services Maturity Benchmark, which SPI describes as drawing on input from more than 8,000 project and services-based organizations, records average billable utilization falling to 66.4 percent in 2025, down from 68.9 percent the year before and the lowest figure in the nineteen years SPI has run the study. That is a fourth consecutive annual decline, and it sits below the 70 percent floor SPI treats as the minimum for a healthy firm. Level 5 firms exceeded 80 percent, and SPI reports those firms carry 42 percent more billable utilization than Level 2 peers alongside 250 percent better project margins.
Three consequences follow, and each one explains a behavior buyers already recognize.
Utilization pressure creates staffing pressure. When a third of paid capacity is not billing, the fastest correction is to bill more of the bench, which means placing whoever is available rather than whoever is right.
The pyramid exists to protect margin, not outcomes. Consulting economics depend on a small number of senior people supervising a large number of junior people. That structure is efficient at converting hours into revenue. It is not efficient at converting decisions into working software, because the people making the decisions are spread thinnest.
Time and materials rewards duration. A model paid by the hour is not neutral about how many hours a project takes, whatever the integrity of the individuals inside it.
None of this is an accusation of bad faith. It is arithmetic. And it is the arithmetic that the forward deployed model was constructed to avoid.
Four attributes separate FDE delivery from traditional Salesforce consulting
Strip away the branding and four structural differences remain. These are the ones worth testing in a procurement conversation, because each is observable in a contract rather than in a pitch.
| Attribute | Traditional Salesforce consulting | Forward deployed engineering |
|---|---|---|
| Unit of sale | Hours, days or accepted milestones | A working capability in production |
| Staffing shape | Pyramid, senior oversight over junior execution | Seniority first, decisions made in the room |
| Definition of done | Signed acceptance against a scope document | The system running and being used |
| Source of leverage | Junior headcount | Agents supervised by a senior engineer |
The fourth row is the one that is new. The first three have existed in outcome-based contracting for years and any capable firm could adopt them tomorrow. The fourth could not be answered before, because until recently the only way to multiply a senior engineer was to surround that engineer with junior people.
A consultant recommends and leaves, an FDE writes production code and stays
The clearest third-party articulation of the distinction comes from outside the vendor ecosystem. Illinois Institute of Technology, answering whether a forward deployed engineer is the same as a consultant, puts it this way: a consultant typically makes recommendations and leaves, while an FDE embeds with a customer for the long term, writes production code in the customer’s own systems, and contributes improvements back to the vendor’s core product.
That last clause is easy to skip and it carries most of the weight. The feedback loop back to the product is what makes the role structurally different from staff augmentation. A consultant who finds a platform limitation writes a workaround and moves on, and the workaround becomes the customer’s technical debt forever. An engineer whose findings reach the product roadmap can get the limitation removed.
Apply the test honestly and most Salesforce engagements sold as forward deployed engineering fail it. Recommending, documenting and handing over is consulting. Building in the customer’s org, staying through production, and carrying findings upstream is something else. The label is available to anybody. The behavior is not.
Agents replace the junior tier that traditional consulting multiplied margin with
This is where the two models stop converging.
Traditional consulting multiplies senior capacity with people. One architect designs, and four to six less experienced consultants build, configure, document and test. The margin comes from the gap between what the junior tier costs and what it bills. The quality risk comes from the same place, because the people furthest from the business context are producing most of the artifacts.
Agents change what the junior tier was for. Requirement capture, solution documentation, configuration, test case generation, and the documentation nobody writes are all artifact production. They were never the reason a senior consultant was in the room. Assigning them to agents removes the junior tier without removing the multiplier. The same SPI benchmark records generative AI use on client projects rising 40 percent in a single year to 27.1 percent of projects, so the substitution is already underway across the sector rather than being a claim unique to one vendor.
GetGenerative.ai is built on that specific substitution. Its platform runs six named agents covering discovery, metadata, design, build, testing and support, and every pod is led by a Forward Deployed Engineer who owns architecture, judgment and stakeholder alignment. The engineer reviews what the agents produce rather than supervising people who produce it. Delivery is explicitly AI-first and human-reviewed, which is a statement about where accountability sits rather than a claim that the agents are autonomous.
The economic consequence is the interesting part. When the multiplier is agents rather than headcount, utilization stops being the constraint on margin, and the firm no longer needs long projects to stay solvent. That removes the incentive conflict described earlier at its source rather than papering over it with a fixed-price wrapper. A fuller account of the model sits in the forward deployed engineer model in full.
Traditional Salesforce consulting still wins where scope is stable and knowledge transfer is the point
A comparison that concludes one side wins everything is marketing rather than analysis. Three situations favor the conventional model, and buyers should not be talked out of it.
Well-understood, stable scope. A standard Sales Cloud rollout on clean data with no unusual integration is a solved problem. Embedded engineering buys adaptability, and paying for adaptability you will not use is waste.
Knowledge transfer as the primary goal. If the objective is to build an internal team’s capability, a partner whose commercial model rewards teaching rather than shipping is better aligned. Embedded delivery optimizes for the system working, not for your admins learning.
Procurement environments that require conventional structures. Public sector and regulated buyers frequently need fixed scope, fixed price and defined acceptance criteria for reasons that have nothing to do with delivery quality. Outcome-linked contracting is often impossible to get through those gates.
The choice across every available model, including in-house and offshore, is set out in every delivery model compared.
Five questions separate a real FDE engagement from a relabeled one
Because the term is unprotected, the burden of verification sits with the buyer. These five questions are answerable in a first conversation and cannot be passed by a firm that has only changed its job titles.
- What does the contract pay for? If the answer is hours, days or accepted milestones, the commercial model is conventional regardless of the title on the CV.
- Who is in the room on day one, and what can they decide without escalating? An engagement where architecture decisions leave the room is a pyramid with new labels.
- How many people are on the team, and what is the experience distribution? Four juniors and one architect is the traditional shape. Ask directly.
- What happens to a platform limitation you discover? A workaround that becomes our technical debt is consulting. A finding that reaches the vendor’s product roadmap is forward deployed engineering.
- What are your agents responsible for, and who reviews their output? A firm claiming AI capacity should name the work agents do and the human accountable for it. Vagueness here means the multiplier is still junior headcount.
For practitioners considering the move themselves rather than buying the service, the skills and progression are covered in the consultant to FDE career path.
The verdict on Salesforce FDE versus traditional consulting
The skeptics are right about the people and wrong about the model.
Forward deployed engineers are drawn from the same population as senior implementation consultants, and Salesforce’s own redeployment data proves it. Anyone claiming a new species of engineer is selling something. But the commercial structure, the staffing shape, the definition of done, and above all the source of leverage are materially different, and those differences change what a buyer receives.
The word that most reliably separates the two is not engineer. It is production. Traditional consulting is paid when the work is accepted. Forward deployed engineering is paid when the work is running. Everything else follows from that.
Teams that want the model rather than the label can meet our Forward Deployed Engineers.
Questions teams ask about Salesforce FDE versus traditional consulting
Is a Salesforce forward deployed engineer just a consultant with a new title?
Partly. The people are drawn from the same population, and Salesforce tripled its FDE team in six months by building it from its own engineering, professional services and customer success organizations. What differs is the structure: the unit of sale is a capability in production rather than hours, staffing is seniority-first rather than pyramid-shaped, and leverage comes from agents rather than junior headcount.
How does FDE pricing differ from traditional Salesforce consulting pricing?
Traditional consulting sells time and materials or fixed price against a scope document, and revenue is a function of hours and utilization. Forward deployed engagements tie payment to a working capability, which removes the incentive for a project to take longer. Ask what the contract pays for rather than what the proposal is called.
Why is billable utilization relevant to choosing a Salesforce partner?
Because it drives staffing behavior. The 2026 SPI Research Professional Services Maturity Benchmark records average billable utilization at 66.4 percent in 2025, down from 68.9 percent the year before and the lowest in the nineteen years of the study. When a third of paid capacity is not billing, firms are pushed to place available people rather than ideal people, and buyers absorb the difference.
When is traditional Salesforce consulting the better choice?
When scope is stable and well understood, when the primary objective is transferring knowledge to an internal team, or when procurement requires fixed scope, fixed price and formal acceptance criteria. Embedded engineering buys adaptability, and paying for adaptability that a project does not need is waste.
What should a Salesforce buyer ask to verify an FDE engagement is real?
Ask what the contract pays for, who is in the room on day one and what they can decide without escalating, the experience distribution across the team, what happens to a platform limitation the team discovers, and what the firm’s agents are responsible for and who reviews their output.
Do AI agents replace Salesforce consultants in the FDE model?
They replace the junior tier’s output rather than the consulting judgment. Requirement capture, solution documentation, configuration, test case generation and delivery documentation are artifact production, which agents handle. Architecture, prioritization, stakeholder alignment and accountability stay with the Forward Deployed Engineer who reviews the output.
Does the forward deployed engineer model apply to Agentforce projects specifically?
It applies most strongly there, because agent projects have unstable scope by nature. Requirements change as the first agents meet real conversations, which is the condition embedded delivery is designed for and the condition fixed-scope contracting handles worst.
