2 · The Internal Deliverer's Position, and Where This Method Comes From

Companion Templates

The Challenge. The business side gets your name wrong, and you cannot say clearly who you are either. You are not a vendor, yet to the claims department you are an outsider. You are one of their own, yet budget, schedule, and performance review sit nowhere near the person making the ask. This role has no name on the company's job ladder, and you quietly wonder whether what you are learning now will still be good for anything two years from now.

What You Will Be Able to Do. State the basic shape of internal delivery, three lines that are not held by one person. Use the table of four invisible mechanisms to find the four things a vendor settles by contract and you have to settle by something else, and which chapter of this book rebuilds each one. Use the inheritance matrix to say in a minute what this method inherited from five mature professions and what the AI era added. Spot which old slot you are being pressed into and correct it on the spot. Use a one-page role charter in week 1 to align with your sponsor and your manager on what you are accountable for and whom you do not replace.

Week 1, Four Names

The day after the Field MVP got its "continue," you notice something small. No two people at Anchor & Helm Insurance call you the same thing.

Grant Whitmore introduces you to the board secretary as "the AI expert the Group brought in." Kevin Doyle calls you "our colleague from the Digital Center" in the department chat, in a tone that means "here to take our requests." On the PMO's project approval form, the implementing party field reads "the Digital Center." Behind your back Linda Marsh calls you "another innovation type," which you picked up from a slip by a young reviewer on her team.

This is not a question of manners. Behind each name sits a complete set of expectations. The four sets contradict each other, and not one of them is right.

"The AI expert the Group brought in." Here to perform something impressive. Demo when executives visit, answer a few technical questions, give the board an endorsement that says "we have not fallen behind," then step aside once used.
"Here to take our requests." Here to execute requests. We state the ask, you build it, do not ask why.
"The implementing party." A cell on the project approval form. Launch is the finish line, the acceptance wording reads "development complete and training delivered," and everything after launch belongs to ops.
"Another innovation type." Does not understand the business, ships a system that makes a mess, then gets reassigned to the next project. That is Linda's summary of every system builder she has seen in twenty years, and it is probably accurate.

Here is the danger. How the business side names you is how it will use you. How this project dies three months from now depends on which name defines you.

Why This Is Hard: You Are Not the Vendor, and You Are Not in the Business Unit Either

The vendor-side FDE arrives in a clear position. The contract states scope and acceptance, the price tag puts a cost on "let us wait and see," payment milestones force decisions, and the exit date forces handoff. None of it is friendly, but all of it is there.

Your position is far blurrier. You sit in the Group's Digital Center, and claims operations sits in the subsidiary Anchor & Helm Insurance. To Linda you are an outsider who does not understand her claims. To finance you are one of their own, your salary paid out of the same system as the claims department's. Your schedule and your performance review belong to Owen Hartley, Head of the Digital Center, who could reassign you tomorrow. People and data are in Kevin's hands, and he owes you neither. The mandate is in Grant's hands, and what he gave was a sentence, not a document.

Take the first thing first. The three lines are not held by one person. That is the basic shape of internal delivery. Your manager runs your schedule and your review, the business side gives people and data, the sponsor gives the mandate. A vendor faces one client. You face three directions at once, and the annual goals of those three do not have to agree.

The second thing is that your calendar gets torn in half. A vendor's whole day is on the client's site. Half of your day is at a desk in the claims area, and half is in the Digital Center's own weekly meeting, OKR alignment, and reviews of other projects. That second half produces no production outcome and still requires your attendance (Chapter 3 covers how to make room for it).

So this chapter starts with something a vendor never has to do. Draw your position first, then explain where the method comes from. Fail to state your position and someone else will define it for you.

If your company has no group structure, read "the Group's Digital Center" as whichever technology or data department you sit in, and "the subsidiary" as another department. One boundary fewer, the same mechanisms.

Framework One: The Four Invisible Mechanisms

A vendor has four things that force out expectations, filtering, decisions, and handoff. Inside a company not one of the four exists, and not one of the functions they carry can be dropped. Each row of the table reads left to right, what the vendor uses, what it forces out, where that thing hides inside, and which chapter of this book rebuilds it.

Vendor Mechanism	What It Forces Out	Where It Hides Inside	Which Chapter Rebuilds It
Contract and acceptance clauses	Expectations in writing, acceptance at a fixed moment	The project approval form, an executive's one sentence, the OKR wording your predecessor left	Chapter 4, the four charter signatures. Chapter 11, launch release conditions
Price tag and quote	Asks get filtered, "let us wait and see" carries a cost	Attention and schedule. Your service carries no price	Chapter 7, the five-question elimination. Chapter 25, the intake gate and its non-monetary price
Payment milestones and the right to pause	Not deciding has a price, unmet commitments give you leverage	Budget cycles, renewed funding points, the PMO register	Chapter 14, the three resource gates. Chapter 4, the three tiers of resource reassessment
Exit date	Handoff has a deadline	Next year's headcount, your OKRs, the transfer ledger	Chapter 22, the three mandatory handoff mechanisms and the responsibility transfer agreement

The way to use this table is to read it backwards. When a project is stuck, ask which row it is stuck in. Nobody accountable for the goal, row one was never rebuilt. Asks arriving without end and you can push none of them back, row two. A pilot still "continuously optimizing" in its fourth month, row three. Still catching alerts at midnight a year after launch, row four.

Whether that boundary is a company wall or a department wall changes how visible the mechanisms are, not the mechanisms themselves. Put another way, the mechanisms are always there, and the only difference is whether they sit out in the open. To the finance department, you in the Digital Center are the vendor, one who happens to be paid by the same payroll system. The five gaps (Chapter 1) do not care who employs you. Data does not become trustworthy because you are one of their own, and a business unit does not change how it works because you are a colleague.

In a company with no PMO register, no OKRs, and no headcount review, this table still holds. Only the carrier changes. The project approval form becomes a one-pager at the sponsor's standing meeting, the PMO register becomes a status line on that page, your OKRs become quarterly goals agreed in writing with your manager, and the renewed funding point becomes a reassessment date fixed at that meeting. The carrier can change. The source of enforcement cannot go missing. It has to be someone else's budget, someone else's performance review, or an action that fires automatically when the date comes due. A mechanism held up by your own willpower is not a mechanism.

The internal reader has two things a vendor does not, and two traps a vendor does not.

Asset one, depth. You have been at this company for years. The last failed project's real cause of death, the personnel history, whose word actually counts among the team leads, you were there for all of it. The field archaeology (Chapter 6) a vendor has to dig from scratch on every arrival, you only do the increment. Asset two, presence. Judgment grows in a specific room, and you live in that room. You can walk to the desks any time, pull from the data warehouse any time, file an SOP revision directly, and put two departments' decision trail data in one table to look at.

Trap one, permanent ops. You cannot leave, so the handoff can always be put off a little longer. Project by project, your team turns into the whole company's ops department for AI systems, and capacity for new projects drops to zero. The way out is Chapter 22. Trap two, ask inflation. Your service carries no price, so ideas pour toward you at triple speed. The intake gate (the checkpoint where asks come in, Chapter 25) is not optional for an internal team. It is the first lifeline.

Prior Art: Where This Method Comes From

This book did not invent the method. The vendor-side FDE is the market's explicit version of staking "accountable from advice all the way to the production outcome" on one person, and the FDE itself is a reorganization of five mature professions under AI's constraints. This section is also the book's master list of sources. The classics later chapters borrow all trace back to these five lines (this book only paraphrases the ideas and names the source, with each chapter working out the detailed use).

Predecessor one, strategy consulting (the McKinsey tradition). The method comes from the tradition recorded in Ethan Rasiel's The McKinsey Way and The McKinsey Mind. A falsifiable hypothesis on day one (the day-one hypothesis), fact-based, structured decomposition, plus the answer-first way of reporting (Barbara Minto's The Pyramid Principle, worked out in Chapters 13 and 19). What is inherited here is problem discipline. State the hypothesis first, then let facts rule on it. In Chapter 0 you bet that "the real pain is in exception claims" and then took ten claims to test it, which is the field version of a day-one hypothesis. This tradition stops at advice and carries no implementation responsibility. When the consultant leaves, the report and the problem usually stay behind together.

Predecessor two, the Solutions Architect (the AWS and enterprise architecture tradition). The SA's core skill is trade-off thinking and teaching the other side to decide for themselves. There is no best architecture, only trade-offs under constraints, explained until the other side can make the call (AWS's Well-Architected (an architecture review framework) and working backwards (deriving the product from a press release) culture is this line's contemporary form, borrowed in Chapter 8 for system boundaries). The SA hands over the design and leaves, is not accountable for adoption, and nobody stands behind "did anyone end up using it."

Predecessor three, the pre-sales engineer (the SPIN and Solution Selling tradition). Neil Rackham proved in SPIN Selling that large sales run on questions, letting the other side state the cost of the problem themselves. Michael Bosworth's Solution Selling contributed qualification, judging whether a deal is worth the investment. What is inherited here is discovery skill. The five-question elimination in Chapter 7 and the intake rubric in Chapter 25 are both descendants of qualification. Pre-sales settles at signature, promise and delivery come apart, the demo is a weapon, and the incentive structure makes over-promising easy.

Predecessor four, the implementation consultant (the Flawless Consulting tradition). Peter Block's Flawless Consulting gives three things. Settle the engagement before diagnosing the problem (contracting before diagnosis, already borrowed in Chapter 0 and worked out head-on in Chapter 4), resistance is a signal and not an enemy (worked out in Chapter 20), and authentic behavior, telling the client the truth. This is the closest of the five predecessors to the last mile. It really shows up, and it really is accountable for landing. This tradition is short on technical depth, and its deliverable slides toward a report. Faced with "why did the model answer that way," it has no tool.

Predecessor five, the product engineer (the continuous delivery and product thinking tradition). What is inherited here is production responsibility. Code counts only once it is in production, with monitoring, rollback, and someone taking the alert at midnight (Chapters 16 and 18 work out the continuous delivery tradition). The product engineer is far from the field, the user is an abstract persona (a user profile), and he does not enter the user's organization. He optimizes for "usable by ten million people." The enterprise field wants "these eight people use it next Monday."

What did the AI era change, and why is the reorganization happening now? On the demand side, Chapter 1 covered it. Demo inflation packed the last mile with project corpses, and organizations need someone who stakes a professional identity on the production outcome. On the supply side, model capability is in surplus and landing capability is scarce, so all the valuable judgment moved to the field. The cost of a prototype collapsed too (Chapter 0), and one person with AI's help can cover the whole way from discovery (the stage after you take it on, finding out how things actually are and locking the scope, Part II of this book) to writing the code and shipping it. "Accountable from advice all the way to the production outcome" was four departments' work ten years ago. Today, for the first time, it is a workable one-person role. Palantir made the term FDE popular. What it named was this reorganization, not an invention. Inside a company you do not need the title. You need the reorganization.

One Question First, Does This Scene Need This Kind of Investment?

Being pressed into an old slot is one kind of mismatch. There is another that happens earlier, where the scene itself does not need this kind of investment. Several practitioners who have built FDE teams at AI companies converged on one judgment in 2026 (paraphrased). FDE-style investment belongs to one quadrant only, a complex system needing deep customization, handed to a user organization without the capability to absorb it on its own.

A simple, configurable product needs only standard tooling. A user organization made of engineers needs only good documentation plus technical support. Force this method onto either scene and the cost structure will not hold.

If what the claims department wants is off-the-shelf ticketing software, sending you in is a mismatch. Every method in this book assumes you should be there. Before assigning this kind of investment to a business unit, run this question first. The intake in Chapter 25 is its institutional version.

Framework Two: The Inheritance Matrix

Put the five lines into one table and you have this chapter's second piece of kit. Each row reads left to right, the predecessor first, then what is inherited, what that predecessor lacks, and what the AI era added.

Predecessor	What Is Inherited	What That Predecessor Lacks	What the AI Era Added
Strategy consulting (The McKinsey Way / The Pyramid Principle)	Problem discipline, hypothesis-driven, fact-based, answer first	Stops at advice, carries no implementation responsibility	A hypothesis can be falsified by a Field MVP within hours, and research and validation merge into one act
SA (AWS / enterprise architecture)	Trade-off thinking, choosing under constraints, teaching the other side to decide	Hands over the design and leaves, not accountable for adoption	The architecture has an uncertain component for the first time, and the eval (the evaluation set) plus human oversight become architectural elements
Pre-sales SE (SPIN / Solution Selling)	Discovery skill, question discipline, qualification	Settles at signature, promise separated from delivery	After demo inflation, "impressive" lost its signal value, and discovery's output becomes verifiable golden cases (sample cases with the correct answer settled in advance)
Implementation consultant (Flawless Consulting)	Landing discipline, contracting, treating resistance as a signal	Short on technical depth, deliverable slides toward a report	Contracting now covers model behavior too, red lines, oversight points, responsibility when it errs
Product engineer (continuous delivery)	Production responsibility, monitoring, rollback, iterating until someone uses it	Far from the field, the user is an abstract persona	AI coding agents compress the cost of writing code, so one person can carry the field full stack

One line of conclusion.

This method = consulting's problem discipline + the SA's trade-off thinking + pre-sales' discovery skill + implementation's landing discipline + the engineer's production responsibility. It adds exactly one skill of its own, AI uncertainty management, meaning eval, human oversight, and drift (data and rules quietly shifting after launch, worked out in Chapters 11, 12, and 18).

This Label Is Still Drifting

Do not expect the title FDE to settle down. A practitioner mapped its four generations in 2026 (paraphrased). Within Palantir alone the word has meant four different kinds of people. In order, around 2008 it was the DevOps firefighting squad, around 2012 the data integration engineer, around 2016 the custom solution builder, and after 2020 the platform enabler.

The skill stack turned over four times, and the four generations share exactly one thing, full accountability for the user's outcome. Another observation from the same mapping is that as code generation got cheap, the product engineer is increasingly user-facing too, and the two roles are converging (Chapter 26 returns to that trajectory).

So the answer to the question in the challenge box is this. Two years from now the label may hold different content or even carry a different name, and the matrix's five rows plus AI uncertainty management will not go out of date. What you are learning is the core, not the title. Your company having no such position does not stop you from doing all five rows. Section 3.9 of Template 3 in the appendix says it more directly. Internal cross-department delivery is this capability set's home ground.

The matrix has two uses. Outward, it is the draft of your one-minute self-introduction. The third column answers "why no old profession can replace you," and the second answers "how the project dies when you get pressed into one slot." Inward, it is a self-check sheet, and the brutal version is failure mode 4.

At Anchor & Helm: Four Hats on Thursday

Role positioning gets demonstrated in every interaction. Announcing it in a meeting does nothing. Here is the record of your Thursday in week 1 at Anchor & Helm.

9:30 a.m., Kevin's office (the consulting hat). The readout narrowed the scope to auto exception claims, and Kevin wants the dashboard back in. "Do the big screen while you are at it, the data is all there anyway." The request taker would say "sure." The innovation type would say "no problem." You push back with questions. What was the readout's evidence? Seven of ten claims stuck in exceptions. Whose next action does the big screen change, and which one? Kevin cannot answer the "whose." What you settle on is the exceptions queue first, the dashboard into the backlog, to be discussed once the queue produces real data (this thread comes to a head in Chapter 17). Hypothesis-driven, ruled on by facts. The hat you are wearing is the consulting hat.

12:40 p.m., answering Victor's security questionnaire (the SA hat). The pre-mortem drew Victor Reyes in, and he sent an 11-question questionnaire. A team from the Group entering a subsidiary's production system goes through the same gate he puts external suppliers through. The request taker would forward the questionnaire to the Digital Center's security group. The internal consultant would book a meeting. You answer it line by line yourself, giving trade-offs and not guarantees. De-identification option A is fast but coarse-grained, option B is two days slower and auditable end to end. You recommend B, with one line of reasoning. At the end you add one line, asking him to review the audit log design with you in week 3 (Chapter 12 continues this). Teach the other side to decide, do not decide for him. That is the SA hat.

3:00 p.m., the claims department desk area (the discovery hat). You booked fifteen minutes of tea with Linda and did not talk about the system. You brought three printed unsafe cases to ask about. "You said acting on these three would cause harm. I want to understand what 'harm' actually looks like." She talked for twenty minutes and finished with, "You system builders, this is the first time anyone asked me that." You take the opening and book half a day of shadowing next week (Chapter 6). What is used here is pre-sales' question discipline, and what it is after is something else, getting the owner of the tacit knowledge (the knowledge people hold but cannot state, learned only by watching it in the field) willing to speak.

6:00 p.m., at the laptop (the engineer hat). Three "days waiting" values in the queue prototype are computed wrong, and the root cause is the core system's status field lagging (one more line in the friction log, the list opened in Chapter 0 of the places where reality and paper do not match, the lead into Chapter 9). You have an AI agent draft the reconciliation script, change the judgment logic yourself, and wrap up in forty minutes.

Four hats in one day. Two things are worth saying. First, this is a normal day in this role, and each hat solves a problem the other hats cannot (how four hats become a manageable daily routine, Chapter 3 unfolds it as the four identities). Second, in every interaction you were quietly correcting a name. Kevin's session corrected "here to take our requests." Linda's corrected "here to push a system." On Friday you freeze these alignments into one page, the role charter (Template 2), and put it at the front of next week's deployment charter negotiation (Chapter 4). Before you send it to Grant, walk Owen through it. He signs fourth on the charter, and he needs to know first what you are accountable for and whom you do not replace.

Failure Modes

1. Treated as the POC demo squad. Every executive visit brings a call to "give us a demo," your calendar fills with demos, and nothing follows one. The company has only the "innovation showcase" slot, and you really are good at demos, so every time you cooperate the slot gets one notch stronger. The project will settle forever at L0 on the outcome ladder. The correction has to happen on the spot. "A demo is fine, but the people who should be seeing it this week are Linda's team. Their scores are what move the project."

2. Treated as the request taker. Asks arrive as tickets, your follow-up questions read as unprofessional, "this is all settled, you just build it." The project approval process assumes by design a split between the requesting side and the implementing party, the business unit states the ask and the technology unit builds it, and that split is written into policy, which is harder to argue with than a contract. Take the first ticket without a follow-up question and your right to discovery is gone. The ending is on-time delivery of the wrong ask, with not one of the five gaps checked. The response is to write "every ask must answer a workflow claim" into the role charter and enforce it from the first ticket.

3. Positioning yourself as internal consulting. "Recommendations, proposals, assessments" fill more and more of your output, and you touch production systems less and less. This is the only mold you impose on yourself. Advice has a short feedback cycle, low risk, and an air of seniority. Production systems page you at midnight. The slide is comfortable. Inside a company the slide is easier than it is for a vendor, because nobody withholds payment over an output of advice alone. The ending falls back to predecessor four's classic way to die, the report that dies on the shelf. Run a weekly self-check. Did one production outcome move up a rung on the outcome ladder this week because of me? Two weeks running with no answer, and you are already internal consulting.

4. Using "full stack" to cover "good at none of it." You introduce yourself as someone who does everything, and under an architect's questions on design choices or a consultant's on method you last three rounds. An intersection role carries this risk by nature, and every column of the matrix has an expert stronger than you. With no real depth in any column, key meetings will vote you down column by column, and the reorganization degrades into a mediocre mix. The response is to self-score the matrix row by row (Chapter 3 gives the self-assessment tool). At least one column has to reach the level of sitting across from an expert in that field and holding your own. The rest need you to know the boundary and know when to ask for help.

Next Monday

Write down what each key person on your current project actually calls you (listen for the words they use when introducing you to someone else). Check them against this chapter's four molds and judge which slot you are being pressed into.
Draw your three-line triangle, the three lines named earlier. Who runs your schedule and review, who gives people and data, who gives the mandate, one name each. If two of the three turn out to be the same person, congratulations, you have one line fewer. If one of the three is a name you cannot write, that line is the project's largest exposed surface right now.
Take stock of yourself with the inheritance matrix. Which of the five rows is your home row? Which is weakest? Write the answers from impression first. The next chapter gives the scale, and you come back then to check.
Use Template 2 to write your role charter, what I am accountable for, whom I do not replace, and what each side expects. Book 15 minutes each with your sponsor and your manager to walk it through.
The next time you are called the wrong thing ("come give us a demo," "just build this ask"), correct it on the spot in one sentence and watch the reaction. The reaction itself is stakeholder (a party with a stake in the outcome) information (useful in Chapter 5).

Want an agent to get you started? In the repo you set up following Start Here, paste this to your coding agent:

In the repo/ directory of the the-last-mile repository, help me with the Chapter 2 Next Monday actions. First copy
templates/role-charter/role-charter.md into the working directory I name, then follow templates/role-charter/prompt-role-charter.md
and put the three boundary questions to me one at a time, filling in the draft after I answer. The three names of the three-line
triangle and what each key person actually calls me are mine to say. Only record, do not guess names for me, mark anything
missing as [TBD]. When the draft is done do exactly one thing, flag every sentence that takes more than one breath to read
aloud so I can shorten it. This charter is meant to be read aloud to people. If any command errors, stop and show me the output.

Chapter Kit

Judgment frameworks. The three-line triangle (your manager / the business side / the sponsor, holding schedule and review, people and data, and the mandate); the table of four invisible mechanisms (contract and acceptance / price tag / payment milestones and the right to pause / exit date, where each hides inside and which chapter rebuilds it); the inheritance matrix (five predecessors × inherited / lacking / added), both a capability self-check and the draft of a one-minute self-introduction; the four hats (consulting / SA / discovery / engineer), the record of one day's role switching, used to check which hat you did not put on today
Templates. Template 2, the Deliverer Role Charter, what I am accountable for / whom I do not replace / the two-sided expectations table, aligned in week 1 with your sponsor and your manager
Key judgments
"The three lines are not held by one person. That is the basic shape of internal delivery."
"Whether that boundary is a company wall or a department wall changes how visible the mechanisms are, not the mechanisms themselves."
"The FDE invented nothing. It is a reorganization of old wisdom under new constraints."
"How the business side names you is how it will use you. Get the name wrong and correct it on the spot."
"Every column of the matrix has someone stronger than you. At least one column must let you sit across from an expert. The rest, know when to ask for help."