# After the FDE leaves, who owns the outcome? Canonical URL: https://theunclej.com/blog/after-the-fde-leaves-who-owns-the-outcome Markdown URL: https://theunclej.com/blog/after-the-fde-leaves-who-owns-the-outcome.md Description: Last month a manufacturing owner showed me his company's FDE acceptance sheet. The acceptance criteria read: system live, full process verified, two training sessions delivered. He signed, paid the fi Category: ai-organization-os Tags: ai-organization-os, piece-00000146 Published: 2026-10-25T10:37:26.166Z Updated: 2026-10-25T10:37:27.348Z --- ![og-cover](https://assets.theunclej.com/uploads/214c4a7ca83882c2e12821fd958c7300.png) # After the FDE leaves, who owns the outcome? Last month a manufacturing owner showed me his company's FDE acceptance sheet. The acceptance criteria read: system live, full process verified, two training sessions delivered. He signed, paid the final invoice, shook hands. The day the vendor's people packed up, he posted a photo on WeChat Moments: "The efficiency revolution officially begins." Forty days later he was sitting across from me. His exact words: "The system is still running. But somehow nobody in the company knows what it is actually doing anymore." Translated: when the FDE left, the responsibility for the road between model capability and business result left with him. Nobody picked it up, because nobody was assigned to pick it up. This is not one owner's problem. It is the least-read page of the entire FDE wave. ## Fairness first: what the role actually is An FDE — Forward Deployed Engineer — is a person a model company stations at the customer's site. They understand the models and they understand the business; they can translate "we want an AI customer service agent" into a system that actually runs. The role is good. OpenAI's own job description lists the parts: customer-specific benchmarks, acceptance criteria, human review, exception escalation, launch conditions. My own client work uses a similar configuration. Talk about FDEs is everywhere this week — how to hire them, how to use them. The failure mode nobody names: an FDE done badly becomes one expensive go-between, absorbing everything the organization cannot articulate. And the sharpest observation: everyone completed their own task, yet the whole thing was never finished. The public discussion mainly answers how an FDE should enter: translating business outcomes, setting acceptance criteria, watching frontline adoption. I want to pick up the question it leaves open: when the FDE leaves, who owns the outcome? ## Why this question, why now Two sets of numbers. McKinsey's 2026 survey: about ninety percent of companies use AI, eighty percent of employees report personal productivity gains — but only 37 percent of respondents report a positive contribution to EBIT. Read the wording carefully: thirty-seven percent of respondents reporting contribution, not profits rising 37 percent. Individuals got faster. The organization's ledger went largely silent. BCG's split is blunter: of what it takes for AI to pay off, roughly 10 percent is algorithms, 20 percent technology and data, and 70 percent people and process. Both point to the same place. The model part, the vendor's people will see you through — that 10 and 20 percent is the FDE's battlefield. The remaining 70 percent, the people and the process, live inside your organization. The FDE's badge does not open those doors. The expensive person you hired, it turns out, is precisely unable to touch the part you most need changed. ## How the 70 percent actually fails I have watched this up close, in that manufacturing case. The FDE spent three months on site rewiring the quality-inspection flow: defect judgment moved from humans reading images to a model doing first-pass screening with human review on top. The system was good — steadier than the veteran inspectors. Before leaving, he wrote documentation and ran training. Every line of the contract, honored. Month one, nothing. Month two, the production line started seeing a new family of defects — scratch patterns unlike anything in the training data, and the model began missing them. The veteran inspector noticed. He said nothing. His reasoning, verbatim: "If the system says it's fine and I say it isn't — whose head rolls if I'm wrong?" Sit with that sentence. The technology is in place; the judgment is missing — because the responsibility that follows a judgment was claimed by no one in the process. While the FDE was on site, that judgment was his to make; he had the authority and therefore the nerve. When he left, the authority was never handed over, because the contract never mentioned it. So the whole system drifted, quietly, toward "whatever the model says" — not because the model was right, but because nobody felt entitled to be responsibly wrong. By month three, when the owner noticed the rising miss rate, the original human judgment capability had half-rusted. Walking it back was no longer available at any price. **Plenty of companies are not buying a capability. They are buying an expensive demonstration — one that runs for three months, priced high enough to feel real.** ## The reflex answer, and why it fails So keep the FDE forever? You can't afford it, and it wouldn't work. An external consultant kept as organizational capability drowns in your meetings first, then gets ground smooth by your processes, and ends as a well-paid go-between lodged inside your processes. You pay top rates to institutionalize the org chart equivalent of "let me ask the consultant." The thing to fix is not the staffing. It is the page of the contract that gets written before delivery even starts: **designing the handover comes before designing the delivery.** Concretely, the structure I describe in my book collapses into three questions to put next to the acceptance criteria, before you sign. First: who owns the process changes? The FDE rewired your inspection flow, your approval chain. When he leaves, who maintains it, and who has the authority to keep changing it? No answer means that flow becomes a fossil no one dares touch within a quarter. Second: who owns daily operations? The system runs every day; it throws exceptions every day. Has the person catching them been trained — not shown a demo, but actually left alone to handle one missed detection and one false kill? Operations that has never handled an exception is not operations. Third: who carries the outcome? Six months out, when the effect decays — is that model drift, usage decay, or organizational deformation? Who is assigned to answer? Unassigned, the day the numbers sag is the day the blame congress convenes. **If you cannot answer all three, do not sign acceptance.** ## What the acceptance sheet should have said Rewind the manufacturing case to signing day. The acceptance sheet read: system live, full process verified, two training sessions. Every line describable in a sentence; every line about the FDE's side of the table. Here is what the same sheet reads like after the three questions are written into it. System live, full process verified — same as before. Then: the process-as-changed is documented as the organization's own process document, version-controlled, with a named owner recorded on each change made during the engagement. The two training sessions produce at least two internal operators who have each independently resolved one missed detection and one false kill, logged. The exception-escalation path is written down — for each failure class, a name, a backup name, and a decision deadline. And the commercial tail: twenty percent of the engagement fee payable against business results measured ninety days after departure. Notice what changed. Nothing here distrusts the FDE. Every line simply forces the engagement to build the thing it would otherwise skip: the organization's own capacity to run what was sold. Vendors who are confident in their delivery welcome these lines; the ones who resist are telling you which half of their margin comes from never being measured after departure. ## The vendor's side of the table A word to the people who sell FDE capacity, because this cuts both ways. The super-contractor trap is not only the client's failure. It is also a pricing model. Time-and-materials billing rewards the vendor for staying; outcome-tied handover rewards the vendor for leaving behind an organization that runs without them. If your revenue depends on being the human interface, you will — structurally, without any bad intent — keep being one. The FDE teams that scale are the ones that productize the handover: a standard process-document format the client keeps; a train-the-operator program with a signed skills checklist; an acceptance suite the client's own people run, not the vendor's. None of this is charity. It is how you sell the next engagement — because the client that learned to run your system buys the next system, and the client that learned to need you buys nothing twice. ## Thirty days, in the client's calendar For the owner who wants dates and not doctrines, here is the handover month, run from the client's side. Days one to five: inventory. List every decision the FDE is currently authorized to make — approve, override, escalate, spend. Most owners doing this for the first time find the list longer than expected, and that surprise is the point. Days six to fifteen: pairing. Each recurring decision on the list gets an internal shadow who makes the call with the FDE watching — reversing the usual direction of supervision. The FDE corrects the system, not the person. Days sixteen to twenty-five: inversion. The internal operators run the process alone; the FDE attends only exceptions. The process document gets its first internal revision — written by the client, not the vendor — and the difference between the vendor's version and the client's version is itself diagnostic: it shows exactly where the organization's understanding has not caught up. Days twenty-six to thirty: the rehearsal of failure. The team runs one scripted anomaly end to end — a missed detection, a false kill, a rollback — with the acceptance sheet open, ticking the three questions. If any question still has no name next to it, the departure date moves. That is the clause worth negotiating before signing, not after. ## Capability is not headcount The next reflex: fine, stop hiring FDEs, build it all in-house. That is not the lesson either. The confusion is between capability and headcount. The FDE is a capability, and a capability enters your organization through three doors, each with its own conditions. Shadowing: your own business lead works alongside the FDE for three months and walks away with the method. Condition: the person genuinely works alongside — not nominal attendance. Fits small-scope, simple-logic process changes. A temporary squad: two or three people assembled for the project, disbanded when it ends, with the method written down as your organization's process document. Condition: someone owns turning the method into text before the disband. Fits one-off overhauls. A permanent role: an actual position. The condition is the hardest — you have confirmed this is a continuously delivered business result, not a project. Most companies, reaching this door, discover they wanted one of the first two. All three doors share one requirement: on departure day, someone inside your organization can answer the three questions. Hold that line: the first success is a project; running it faster the second time, without the outside brain, is a capability. Half a step further — **win it, and it is organizational capability. Until then it is a feature people came to look at.** ## The last trap One more failure mode: delegating everything to the FDE. Before you delegate, ask — is there truly no one inside who can change the process, move resources, sign off acceptance? If the answer is no, the thing to fear is not how strong the FDE is. It is how much your organization has already handed away. The stronger the outside, the sharper the shadow it casts on the inside. --- The FDE model is a good one. But run the accounting all the way: the expensive part is not bringing the FDE in. It is the seventy percent — people and process — after he leaves, and that line of the contract is worth more than all the others. Write the words "after departure" into it. Back to the manufacturing owner. He did three things. He made the veteran inspector the named owner of the review process — legitimate, on the org chart. He wrote an exception-escalation path into the process document, every step carrying a name. And he renegotiated the renewal as installment payments tied to business results six months after departure. He says it still hurts. But this time, the money went into the organization. I'm Uncle J. I spent 18 years in HR — the valuable part was never the résumés, it was the judgment about reading people, splitting work, and assigning accountability. Then I engineered that judgment into an AI system, solo. I don't talk model specs. I work out what they actually change. More at [theunclej.com](https://theunclej.com).