Start With the FDE Charter

Most orgs build the team before anyone agrees on what it's actually for.

Most Solutions leaders we’re talking to have already been asked to build an FDE function. What we’re hearing now is what happens next: the team gets built, and then it gets pulled apart by expectations that were never aligned before anyone was assigned to it.

One leader in a recent roundtable was blunt: “Our CRO wanted them. Nobody thought this was a great idea. FDE is a thing we’re hearing about, like AI is a thing we’re hearing about. So this team was formed.”

The directive arrives, the Solutions leader takes the seat, and the harder conversation gets skipped in the rush to build. Six months later, the team is deployed, the customer is confused, and the CFO is asking what the return actually looks like.

The question we’d put to every Solutions leader being asked to build this: has your executive team agreed on what you’re building it for? Most haven’t.

The last mile is the proof.

Solutions leaders often frame FDE as a response to declining trust in AI. That framing is true, but it stops short of the real strategic argument.

IDC research puts the number at 88 percent. That’s the share of enterprise AI proofs of concept that never reach production. For every 33 POCs a company launches, only four graduate.

What that stat means for the buying conversation is this: buyers want more proof. Buyers know their pilot is going to hit integration walls, security reviews, and data-readiness gaps that will kill or delay the production rollout. It’s not a test of whether the product works.They’re asking whether you can get it to production reliably enough to bet a career on renewing it.

The last mile is where that second question gets answered, and it’s where the traditional SE motion was not designed to work. Tech win, handoff, done. FDE exists because someone needs to own that last mile with skin in the game.

If your executive team believes FDE is about trust, they’ll build a team that gets demos closer to production. If they believe it’s about owning the last mile, they’ll build a team that carries the deal into it. Those are two different functions. We covered the placement question in our earlier piece on FDE. This is the prerequisite one: what did the executive team actually agree the function is for?

There is no single FDE function.

Before anyone gets assigned, there needs to be agreement on what the FDE function is solving for. Consider what “FDE” could mean:

Is the team meant to close the POC-to-production gap in AI deals? To hold strategic accounts through the next consolidation review? To defend renewals we’re already at risk of losing? To match the time-to-value that AI-native competitors are putting into the market? To close the field-to-Product feedback loop that Product keeps asking Solutions to own? Or to collapse the customer’s post-sale handoff chain into a single technical relationship, so they stop bouncing between an SC, an SA, an implementation consultant, a TAM, and a CSM?

Each of those is a legitimate answer, but none is the same function. An FDE built to defend renewals is not the same team as an FDE built to feed Product. The executive team that says yes to all of them is building something that will do none of them well.

FDE failure is not theoretical. One Head of Presales in EMEA described her org as living inside “FDE sprawl”: “We have a version of FDE, the post-sales team has a version of FDE, the CS team has a version of FDE.” Three teams, three definitions, three sets of unspoken expectations. The customer sees the confusion, and so does the CFO.

If your executive team can’t explain the FDE function in a single sentence, you have an alignment issue.

Two ways this goes wrong.

Two patterns show up over and over in the conversations we’ve been having, both avoidable and both compounding quickly once the team is live.

The first is the top down metric with no shared definition underneath it. One Head of FDE inside a global technology vendor inherited a mandate that 80 percent of entitled customers would adopt the platform within two quarters. Her first question to her leadership wasn’t about the number. It was about the definition. “What does adoption mean?” Nobody had done that work.

That’s a prime example of a top down number that doesn’t have a shared definition. It reads well in a board deck and fails in every business review afterward.

The second is the non-billable trap. FDE work is often positioned as non-billable. The intent is right: reduce friction, get skin in the game, prove the last mile. The effect is that customers with a non-billable resource will use it until it runs out. One Director of FDE at a no-code application platform is now retrofitting guardrails after her leadership told her not to timebox engagements: “The direction from ELT was ‘don’t timebox this, attach them wherever, however long.’ That never works. So I’m starting to timebox between 30 to 90 days.”

Retrofitting a time box is harder than starting with one. Customers feel it, sales feels it, and the CFO now has a team that is expensive and unpredictably scoped.

The strongest FDE functions start on paper.

The strongest FDE functions we’ve seen have one thing in common: there was executive level agreement on what the function is, what it isn’t, and how it interfaces with everything else, before anyone was assigned to it.

One practitioner charter shared inside our network puts it this way: a small, senior, builder-led team creates disproportionate leverage when it is chartered to turn lighthouse customer work into repeatable solution patterns, partner-ready delivery motions, and validated product insight, not to function as a general services bench.

That is a mission statement that will hold up in a business review, specific about what the team is for, what the output is, and what the team is not.

That same charter also includes a “does NOT do” list.

• Not a general pre-sales escalation path for standard deals.

• Not staff augmentation or rescue engineering for failing projects.

• Not an open-ended custom delivery function with no reuse path.

• Not a source of free pilots without a named owner, a measurable business goal, or a credible scale path.

• Not a permanent dependency after handoff.

That list is more valuable than any positive definition. It survives the sales team that wants FDE as a specialist SE, the customer who wants an unbounded non-billable resource, and the executive who wants the function to quietly fill a gap they haven’t funded.

Every executive team standing up FDE should write their own version, and attach an operating boundary to each line. Timebox every engagement, typically 30 to 90 days. No engagement starts without a named executive sponsor, a measurable success metric, and a credible production pathway. No build starts without the handoff path visible up front. Intake is centralized, not field-escalated.

None of this is exotic. All of it gets skipped by executive teams that build on a directive and hope for alignment later.

Sometimes the answer is a redefined mandate.

Not every version of this conversation ends with a new team. One RVP at a developer-focused security startup pushed back on the acronym: “There’s a little bit of cynicism as to whether it’s a rebranding. We’re already pretty technical, we’re already doing deployments into live.”

Sometimes the existing SE function has the depth to own the last mile, but not the mandate or the scope. Redefining what your current team is chartered to do is faster than building a new one, and doesn’t require you to compete with AI-native vendors for a $600,000 staff-level engineer. It’s the option most executive teams don’t consider because they’re already three job reqs deep.

Five questions belong on the table first.

Whether you’re building or redefining, five questions belong on the table before anyone gets assigned.

1. What is the executive team actually trying to solve for? Deployment success, renewal defense, product feedback, and customer simplification are not the same function. Pick one primary answer.

2. What does the team NOT do? Write it down, share it, and defend it in the first two business reviews after launch.

3. Where does the team sit, and what does it interface with? Solutions, Engineering, Product, Services, and CS all have opinions. If the executive team hasn’t resolved them, the team will absorb the conflict.

4. How will success be measured? A top-down number without a shared definition is not a metric. It is a trap.

5. What is the handoff path, and when does it engage? A team that can’t hand off will be permanently attached. A team that hands off badly will produce work customers don’t adopt.

If your team can’t answer those five questions in a single conversation, the function isn’t ready to be built. That is not a failure, it’s just the work.