B
Appendices
Templates
An engagement goes wrong in the blanks nobody filled in: the sponsor, the threshold, the owner after handoff. Here are the book's seventeen templates, blank and in chapter order, from the job check in Chapter 1 to the growth plan in Chapter 18. Each one is this book's proposal, not a standard. Copy it, cut what does not apply, and fill it in with names, dates and where each number came from.
B.1
Using these templates
The templates are in English in both editions on purpose, so the same sheet can go to a customer, a lead or a repository unchanged. Underscores mark a blank; fill it or say why it is empty, because a blank you cannot fill is usually the finding. Each section below says when to use the template, links to the chapter section that explains it, and describes the filled example there. Most examples come from the book's composite engagement, an insurer's auto claims triage, and carry ranges, not measured figures. No one has validated these forms against outcomes, so treat every line as advice (T4), cut what does not apply, and re-sign a template whenever its threshold, scope or authority changes.
Template
When
Chapter
Before the security questionnaire arrives
Before the build commits to a decision
After each engagement, with the self-assessment
B.2
Is this an FDE job?
Use it on a real posting before you apply, and again on the offer. It reads the post by stage and asks you to quote the text behind each answer: Y if the post says so, N if it says otherwise, ? if it is silent. A "?" is not a fail; it is a question for the first interview. Chapter 1, What an FDE Is, and Isn't, fills it in for a real posting chosen because it is hard to classify: Harvey's "Forward Deployed Finance Engineer, Buyout".
IS THIS AN FDE JOB? post: ____________ date: ______
Quote the post for every answer. Y = says so, N = says not, ? = silent
OWNERSHIP, DISCOVERY TO HANDOFF Y / N / ?
1 Discovery: does the role find the problem, or get it [ ]
handed over on a ticket? quote: ________________________
2 Scope: does it agree scope and success criteria with [ ]
the customer? quote: ________________________
3 Build: does it write production code itself, or [ ]
design for a partner to build? quote: __________________
4 Production: does it stay until the system runs on [ ]
real traffic? quote: ________________________
5 Handoff: is "the customer runs it without you" named [ ]
as the end state? quote: ________________________
6 Loop: does field work feed the product, by a named [ ]
channel? quote: ________________________
SIGNALS THAT SHIFT THE READING
7 Pay shape: base, or a base/variable split? ____________
8 Team or job family: product / R&D / GTM / sales? _______
9 Code: required, or "a plus"? __________________________
10 Who else is named alongside (AE, CSM, partner, PM)? ____
READING (take the first rule that matches)
Mostly ? ............................ ask lines 1, 3 and 5 first
N on 4-5 and a variable split ....... sales engineer, rebranded
N on 3, or line 9 says "a plus" ..... strategist or architect:
owns the problem, not the code
N on 1-2 (problem arrives decided) .. contractor or delivery engineer
N on 6 .............................. services; ask what happens to
what you learn in the field
1-6 all Y and code required ......... an FDE job, whatever the title
IF A LINE IS ?, ASK
1 "Who decided what to build on your last engagement?"
3 "Whose name is on the production commits?"
4 "Where were you when it went live, and for how long?"
5 "Who was running it three months after you left?"
6 "Name one product change that came from the field."
B.3
Skill self-assessment
Fill it in after each engagement, not once a year, then hand it to your lead and ask them to strike anything they would not sign. Chapter 3, The Skill Map, shows the composite insurer's mid-level FDE filling it in at month nine, scoring only what was done unaided, with an artefact and a witness. The growth plan in B.18 starts from this sheet.
SKILL SELF-ASSESSMENT date: ______________ Name / role: _______________________ Engagements so far: ______ Rule: score the highest level you have DONE unaided, twice or kept up across an engagement, with an artefact and a witness. Knowing how is not evidence. Anything done once goes in section 2. 1. LEVEL PER DOMAIN Domain Level Evidence (what, where, when) Witness technical _____ ____________________________ __________ customer _____ ____________________________ __________ product _____ ____________________________ __________ judgment _____ ____________________________ __________ 2. ONE-OFF DATA POINTS ABOVE THAT LEVEL (not yet a level) Domain/level What happened Witness ____________ _________________________________ __________ ____________ _________________________________ __________ 3. WHAT MY LEAD (OR SOMEONE ELSE) DID, NOT ME ________________________________________________________________ ________________________________________________________________ 4. SHAPE CHECK Strongest domain: _________ Weakest domain: _________ Gap of two or more levels? YES / NO If unchanged, I drift toward: services / AI engineering / n.a. 5. NEXT ENGAGEMENT: WHAT I WILL ASK TO OWN 1. __________________________________________________________ 2. __________________________________________________________ 3. __________________________________________________________ 6. REVIEW Lead struck or changed: ______________________________________ Lead: ______________ date: ________
B.4
Engagement brief and pilot terms
Fill it in before signature: the FDE, the lead and the account executive together, with the customer's sponsor reading it. A field you cannot fill is the finding, and the problem hypothesis stays labelled a hypothesis until discovery tests it. Chapter 4, Before the Engagement, shows it filled from the composite at the point the COO signed.
ENGAGEMENT BRIEF AND PILOT TERMS v__ / date ________
PARTIES
Customer sponsor (owns the KPI): ______________________
Decision-maker (signs the annual deal): ______________________
Budget owner (whose budget pays): ______________________
Vendor: FDE ____________ Lead ____________ AE ____________
PROBLEM HYPOTHESIS (to be tested in discovery, not built to)
As stated by the customer: ______________________
Business number it is meant to move: ______________________
THE ONE KPI
KPI: ______________________
Baseline source (system / report): ______________________
Baseline measured by (who, which week): ______________________
TERMS
Duration (30 days target; 90 max): ____ days, start ______
Price: ______ (or: FREE because ______;
investment owner: ______)
Credit on conversion: ___% if signed within ___ days
Annual contract shape agreed in advance: [ ] yes scope ______ value ______
DATES THAT STOP THE CLOCK IF MISSED
Production-like data access by: day ___ (target: day 5)
Security / model-risk review starts: day ___ (target: day 1)
CUSTOMER EXPERTS
Name / role hours per week from day
______________________ ____ ____
______________________ ____ ____
MILESTONES (2-3, owner on each side)
1. ______________________ vendor: ______ customer: ______ day ___
2. ______________________ vendor: ______ customer: ______ day ___
3. ______________________ vendor: ______ customer: ______ day ___
EXIT CRITERIA (either side may stop if)
- ________________________________________________
- ________________________________________________
ON SUCCESS
Success means: ______________________
What happens next (contract shape, date): ______________________
BLANK FIELDS AT SIGNATURE (list; each blank is a risk accepted by ______)
________________________________________________
B.5
Discovery interview guide
Use one guide per stakeholder group and merge them into the summary box at the end. Record ranges, not point figures, and mark every number with where it came from: said, counted or measured. Chapter 5, Discovery, shows the merged guide for the composite insurer's auto first-notice-of-loss (FNOL) work, across the COO, the claims director, adjusters, the contact-centre head, claims-platform IT and model risk.
DISCOVERY INTERVIEW GUIDE Engagement: ____________ Interviewer: ____________ Date: ________ Stakeholder (role, team): ______________________________________ 1. BUSINESS LEVER Which number would you most like to move this year? ____________ Who reports it, and to whom? _________________________________ Where do you think it is lost? (their hypothesis) ______________ 2. CURRENT WORKFLOW (observed, step by step) Trigger: ______________________________________________________ Steps (system touched / wait / handoff at each): ______________ Workarounds seen (side sheets, inboxes, "ask X"): ______________ 3. PEOPLE AND HANDOFFS Who does each step: ___________________________________________ Unofficial experts / routers: _________________________________ 4. VOLUMES AND TIME (ranges; source: said / counted / measured) Cases per day (slow day - bad day): ___________________________ Time per case (easy - hard): __________________________________ Share of cases that are hard: _________________________________ 5. DATA Where it lives (system, format): ______________________________ Owner who grants read access: _________________________________ Owner who approves changes to the workflow: ___________________ How to get access, and how long it usually takes: _____________ 6. WHAT "BETTER" MEANS TO THIS STAKEHOLDER ______________________________________________________________ 7. THE FEARED FAILURE Worst thing that could happen if a machine helped: ____________ SUMMARY BOX (complete once, across all interviews) Stated problem: ____________________________________________ Observed problem: ____________________________________________ Evidence: ____________________________________________ Lever it moves: ____________________________________________ Confirmed by sponsor (name, date): ___________________________
B.6
One-page scope
Write it after discovery. It carries the observed problem, the cut, the number and the names, on one page because nobody signs a longer one carefully. Keep it where the customer can edit it, and re-sign it whenever the threshold or the scope changes. Chapter 6, Scoping and the First Win, shows it filled for the composite's auto FNOL triage, where the stated problem was "a customer chatbot".
ONE-PAGE SCOPE version / date: ____ 1. PROBLEM (observed, from discovery) Stated problem: ______________________________________________ Observed problem: ______________________________________________ Business lever it moves: _______________________________________ 2. IN SCOPE (one workflow) Workflow / step: ______________________________________________ Slice: line of business / region / team / % traffic Agent authority: propose only | act with approval | act Workflow owner: ______________________________________________ 3. NOT NOW (each with a reason and a trigger) - item: ____________ reason: ____________ revisit when: ______ - item: ____________ reason: ____________ revisit when: ______ 4. SUCCESS METRICS Metric Baseline (how measured, when) Threshold Owner main: ______________________________ _________ _____ speed/cost: ______________________________ _________ _____ guardrail: ______________________________ never _____ Threshold in the sponsor's words: _____________________________ 5. HELD-OUT SET Source and size: _______________ Labelled by: ________________ Owner (customer): ______________ Vendor tunes on it: NO 6. FIRST DEMO Date: ________ Audience: threshold owner + users: ____________ Data: real / redacted (never synthetic only) 7. WEEK-BY-WEEK PLAN Week 1: __________________________________________________________ Week 2: __________________________________________________________ Week 3: __________________________________________________________ Week 4: __________________________________________________________ 8. TOP RISKS Earliest signal By when - ____________________________ _______________________ _______ - ____________________________ _______________________ _______ 9. SIGN-OFF Sponsor (metric matters): __________ date: ______ Threshold owner (good enough): __________ date: ______ Vendor lead (we can build it): __________ date: ______
B.7
Data-access request
Send it on day one to every approver, with each approver's question marked. It asks for the minimum, says what you will do while you wait, and names who owns the connector after you leave. Chapter 7, Data Access and Integration, shows it filled from the composite in ranges, including the agreed rule that the 30-day clock pauses if access is late.
DATA-ACCESS REQUEST version / date: ____ 1. PURPOSE Workflow served: ______________________________________________ Metric it serves: ______________________________________________ Needed by (date): ________ If late: ___________________________ 2. WHAT WE NEED (the minimum) System / store Objects (tables, folders) Access Rung ______________ _________________________ read ____ ______________ _________________________ read ____ Fields excluded: ______________________________________________ Personal data: categories: __________ minimised how: _______ 3. HOW WE CONNECT [security's questions] Environment: replica / reporting copy / live Network path: ______________________________________________ Identity: one service identity, read-only: ____________ Credentials: held in: ____________ never in code Write access: NONE in this phase | side store only: _____ 4. DATA HANDLING [privacy's questions] Leaves the customer's environment: yes / no what: __________ Residency: ______________________________________________ Retention: ______ Deletion on: pilot end / on request Model provider retention / training: __________________________ 5. LOAD AND STABILITY [system owner's questions] Query pattern: ______________ Peak volume: ______________ Scheduled runs: ______________ Kill switch: ______________ 6. WHILE ACCESS IS PENDING Fallback: sanitised fixtures / redacted export: _______ Export owner: ______________ Size: ______________________ Fixtures used for scoring: NEVER 7. AFTER THE PILOT Connector owner (customer): ____________________________________ Contract tests and freshness alarm run by: _____________________ Glossary and field map kept in: ________________________________ 8. APPROVALS name date System owner (load, change): ______________ ______ Security (identity, path): ______________ ______ Privacy / DPO (fields, use): ______________ ______ Requested by (vendor): ______________ ______
B.8
AI security-questionnaire answers
Write it before the customer's questionnaire arrives and send it with the data-flow diagram. It will not replace their form, but most of their AI questions can be answered by pointing to one of its sections. Version it, because every change to the agent's authority or data flow changes an answer. Chapter 8, Security, Governance and Model Risk, explains how to split their form into three piles and shows the sheet filled from the composite at week 3, for an agent with propose-only authority.
AI SECURITY ANSWERS version / date: ____ 1. SYSTEM What it does: ____________________________________________ Users: ____________________________________________ Agent authority: propose only | act with approval | act Tools that act: none | list: ________________________________ 2. DATA FLOW (attach diagram) Store / step Data held Region Retention ________________ ______________ _________ _______________ ________________ ______________ _________ _______________ Logs and traces: ______________ _________ _______________ 3. TRAINING Customer data used to train or improve any model: NO / YES Contract clause: ____________________________________________ 4. SUB-PROCESSORS Provider Role ZDR agreed Region ________________ ______________ YES / NO _______________ 5. IDENTITY AND ACCESS Agent runs as: ____________________________________________ Read scopes: ____________________________________________ Write scopes: none | ______________________________________ Credentials owner: ____________________________________________ 6. PROMPT INJECTION Untrusted input Written by Worst case if obeyed ________________ ______________ ___________________________ Control outside the model: ____________________________________ Seeded tests: ____________________________________________ Residual risk: _______________ Accepted by: ______________ 7. HUMAN OVERSIGHT Who decides: ____________________________________________ Rules enforced in code, not prompt: ___________________________ 8. AUDIT LOG (per suggestion or action) Inputs | output | model+prompt+code version | human decision | time | identity. Live from: ____________ Kept: ____________ 9. CHANGE CONTROL Model or prompt change triggers: re-run eval >= threshold Approver of changes: __________________________________________ 10. INCIDENT AND SWITCH-OFF Who can switch it off: ___________ How: _____________________ AI incident contact: ___________ Breach process: __________ 11. CONDITIONS OF APPROVAL Stage Condition Evidence Owner __________ _______________________ ______________ _______ 12. SIGN-OFF Security: ________ Privacy: ________ Model risk: ____________ Vendor lead: ________ date: __________________
B.9
Eval plan
It sits next to the one-page scope and makes its metrics runnable. Keep it where the customer can see it, and re-sign it whenever a set, a grader or the threshold changes. Chapter 9, Evals: Proving It Works, shows it filled from the composite at the week-4 readout.
EVAL PLAN version / date: ________ 1. CONTRACT (from the one-page scope) Threshold, precise: ___________________________________ Threshold, sponsor's words: ___________________________________ Ceiling (expert agreement): ___________________________________ Guardrail (never): ___________________________________ Threshold owner: ___________________________________ 2. SETS Source Size Owner Used for held-out _____________ ______ ________ readouts only development _____________ ______ ________ daily work regression fixed failures grows ________ every change Vendor tunes on or reads held-out failures: NO 3. LABELS Labelled by: ________________ Adjudicator: ________________ Label form: pass / fail per dimension, plus one-line reason Relabels: customer only; log case id, reason, date, initials 4. GRADERS (one per dimension) Dimension Grader: code / judge / human Calibrated (kappa) ______________ ____________________________ _________________ ______________ ____________________________ _________________ 5. CONSISTENCY Trials per held-out case (k): ____ Report: pass^k 6. CADENCE Regression suite runs on: every prompt / model / retrieval change Held-out measured on: ____________________ (agreed dates only) Stall rule: if ___ re-measures barely move, then ______________ 7. FAILURE LOG Share of misses Fix Owner ____________ _______________ _______________ ________ ____________ _______________ _______________ ________ 8. READOUT Date: ________ Threshold owner briefed first: ________ Re-measure date: ________ Decision asked for: ______________ 9. SIGN-OFF Threshold owner (cases and labels are right): _______ date: ____ Vendor lead (we will measure as written): _______ date: ____
B.10
Architecture decision record
Write one record per significant decision, before the build commits to it, signed by the people who will live with it: the customer's platform owner, model risk and the FDE lead. Keep it in the customer's repository, not the vendor's. Chapter 10, Building in Their Environment, shows a record filled from the composite for an agent hosted on the insurer's own container platform.
ARCHITECTURE DECISION RECORD ADR-__ date: ________ Status: proposed | accepted | superseded by ADR-__ 1. CONTEXT (their constraints, in writing from their platform team) Hosting: _______________________________________________ Model endpoint: ____________ region: ________ version: ______ Identity: _______________________________________________ Network/egress: _______________________________________________ Allowed stores: _______________________________________________ Change process: _______________________________________________ On-call owner: _______________________________________________ 2. DECISION (one paragraph) ______________________________________________________________ 3. RULES THAT MUST HOLD (never decided by the model) Rule Enforced where Test - ______________________ before | after ____________ - ______________________ before | after ____________ Rule tests must pass: 100%, on every change Model may move a case toward caution only: Y / N (which rules) 4. WHAT THE MODEL DECIDES Input: ______________ Output schema: ______________________ Allowed values: _______________________________________________ Authority: propose only | act with approval | act 5. OPTIONS CONSIDERED Option Rejected because - ______________________ ___________________________________ - ______________________ ___________________________________ 6. FAILURE BEHAVIOUR Endpoint down / bad output / rule rejects -> ________________ 7. VERSIONS PINNED AND LOGGED PER DECISION model | prompt | examples | rules | code 8. EVAL GATE Held-out set re-run on this stack: ______ matches pilot: Y / N Climb to a more complex design only if: _______________________ 9. REVERSIBILITY How to turn it off: ___________________ Who can: ____________ 10. SIGN-OFF Customer platform owner (fits our environment): ______ date: __ Model risk (rules where approved): ______ date: __ Vendor FDE lead (can clear the eval): ______ date: __
B.11
Handoff document and runbook
One document with two halves: the handoff (what the system does, who owns what, what was proved) and the runbook (how to deploy it, roll it back, stop it and fix it). Write it with the operators, not for them, and treat the drill as its test. Chapter 11, Production and Handoff, shows it filled from the composite for the auto FNOL triage handoff.
HANDOFF DOCUMENT AND RUNBOOK version / date: ____
1. THE SYSTEM
What it does: ____________________________________________
What it never does: ____________________________________________
Authority: propose only | act with approval | act
Rules enforced outside the model: ______________________________
2. OWNERS (customer side, by name)
Service (deploy, alerts, credentials): ________________________
Behaviour (threshold, eval set, changes): ______________________
Adoption (definition, review, training): _______________________
Vendor support: scope ________ channel ________ ends ________
3. WHAT WAS PROVED
Threshold met: metric ________ held-out set ________ date ____
Adoption definition: ___________________________________________
Adoption baseline (date): ______________________________________
4. RELEASES
A release contains: code / prompts / pinned model version /
rules / reference data snapshot
Deploy: ____________________ Who may deploy: ______________
Rollback: ____________________ Last rehearsed: ______________
Before every release: run ________ suite; block if ____________
5. HEALTH (what normal looks like)
Signal Normal Alert when Who
_________________ _________________ _____________ _______
_________________ _________________ _____________ _______
6. KNOWN FAILURES
Symptom First check Fix / workaround
_________________ _________________ ________________________
_________________ _________________ ________________________
7. KILL SWITCH
How to stop: _______________________________________________
What happens: _______________________________________________
Who to tell: _______________________________________________
8. ADOPTION REVIEW
Measures: shown / accepted / overridden / ignored / share of
eligible work; accepted-without-review rate
Overrides go to: ________ Reviewed by: ________ every ________
9. HANDOFF DRILL
Date: ______ Operators: ________________ FDE silent: yes / no
Pass condition: ________________________________________________
Scenarios: _____________________________________________________
Gaps found / closed: ___________________________________________
Re-run date and result: ________________________________________
10. SIGN-OFF
Service owner (we can run it): __________ date: ______
Behaviour owner (it is good enough): __________ date: ______
Sponsor (we accept the handoff): __________ date: ______
Vendor lead (we have handed over): __________ date: ______
B.12
Product-feedback brief
One finding per brief: a brief with five asks gets the easiest one done and the rest forgotten. Write it from the field log, have the lead check the customer line, and send it to a named person. Chapter 12, Feeding the Product, shows it filled from the composite in month five, for a triage pipeline that was built from parts and that the next insurer would need again.
PRODUCT-FEEDBACK BRIEF version / date: ____
1. FINDING (one line)
________________________________________________________________
Destination: product | research | playbook
2. FIELD EVIDENCE
Engagements where seen: ______________________________________
How it showed up: eval category | workaround | overrides
| built twice
Frequency / cost: ______________________________________
Evidence tier: measured here | observed | anecdote
3. WHAT WE BUILT IN THE FIELD
Description: __________________________________________________
Where it lives / who owns it now: ______________________________
4. THE LINE
Generalises (pattern): __________________________________
Stays with the customer: data, labelled sets, rules,
identifiers, contract-owned items:
__________________________________
Checked by lead / contract: __________ date: ______
5. THE ASK (smallest useful version)
________________________________________________________________
Not asking for: ________________________________________________
6. SECOND-CUSTOMER TEST
Next engagement that needs it: ________________ starts: _____
What it would reuse: ________________________________
7. COST OF NOT DOING IT
Rebuild time per engagement: ________ (range)
Risk if rebuilt each time: ________________________________
8. DECISION
Receiver (owns a roadmap): ______________ decide by: ________
Outcome: build | defer (until ____) | decline (reason: ______)
B.13
Engagement post-mortem
Run it when two signals appear, or after the engagement ends. Section 1 is copied from the signed documents, including the rule, so the rule is fixed before anyone fills in section 3. Chapter 13, When Engagements Fail, shows it filled from the composite for the stalled property expansion, run during the engagement with the vendor lead as facilitator.
ENGAGEMENT POST-MORTEM version / date: ____
Run: during | after the engagement Facilitator: ______________
1. WHAT WE AGREED (copy from the signed terms and scope)
Sponsor and KPI: _________________________________________
Scope and threshold: _________________________________________
Threshold owner: _________________________________________
Exit criteria: _________________________________________
Decision rule: continue if all five conditions hold;
reset if each missing one has a named
restorer + date; walk if any has none
2. WHAT HAPPENED (dated facts, no adjectives, no names to blame)
when: ______ ___________________________________________________
when: ______ ___________________________________________________
when: ______ ___________________________________________________
3. THE FIVE CONDITIONS At start Now Evidence
Problem still matters yes/no/? yes/no/? ______________
Data path working yes/no/? yes/no/? ______________
Owner for the result yes/no/? yes/no/? ______________
Sponsor owns the number yes/no/? yes/no/? ______________
Threshold agreed, owned yes/no/? yes/no/? ______________
4. MAIN CAUSE (one only: the one that explains the others)
wrong problem | no data | no owner | moving sponsor |
unagreed threshold | too hard for AI | other: _______________
5. WHAT STILL WORKS, AND WHO OWNS IT (a person, not a team)
- system / artefact: ______________ owner: ____________________
- system / artefact: ______________ owner: ____________________
6. DECISION: continue | reset | walk decided by: ________
If reset: condition: ________ restorer: ________ by: ________
re-check date: ________
If walk: billing stops: ________
handed over: ________________________________________
return trigger: _____________________________________
7. WHAT GOES BACK TO PRODUCT
- _______________________________________________________________
8. SIGN-OFF
Sponsor: __________ date: ______
Vendor lead: __________ date: ______
FDE: __________ date: ______
B.14
Say-no note
One request per note, sent within a day of the meeting to the person who asked, and copied to the owner of the commitment. Keep it to a page: a long refusal reads as a defence. Chapter 14, Judgment Under Pressure, shows it filled from the composite for the first of four requests, sent to the claims director.
SAY-NO NOTE date: _______________ To: ______________ (who asked) Cc: ______________ (who owns it) 1. THE REQUEST (in their words, as asked) ________________________________________________________________ 2. THE ANSWER: no | not now | yes, if ______________________ 3. THE COMMITMENT IT WOULD BREAK (tick one) [ ] threshold [ ] data path [ ] sponsor [ ] exit Where it is written: ___________________ (document, date) 4. WHAT IT WOULD COST YOU (their terms, not ours) ________________________________________________________________ 5. WHAT WE WILL DO INSTEAD (by when) - ______________________________________________ by: _________ - ______________________________________________ by: _________ 6. WHAT TURNS THIS INTO A YES (measurable trigger) ________________________________________________________________ 7. WHO CAN OVERRULE THIS, AND HOW Decider: ______________ How: in writing, amending ____________ 8. REVIEW DATE: ____________ Logged on "not now" list: yes / no Test before sending: would we refuse this if every hour were paid? yes: send it no: it is a price, not a no; quote it instead
B.15
Before you sign: the question sheet
Ask these of your future lead, after the offer if not before, and accept only answers that name a customer, a person or a date. Chapter 2's five questions read the employer's economics; this sheet reads the specific job, and its section 4 checks whether the job is a services trap. Chapter 15, Where FDEs Work, fills it in from what is public about one real offer type, a founding FDE at a lab-backed deployment company in the US, with every gap the post leaves marked ASK.
BEFORE YOU SIGN date: ____________ Employer: ______________________ Title: _________________________ Type (lean): lab / app startup / platform / deployment co / mixed 1. THE WORK Last 3 engagements this team ran (customer, length, outcome): ________________________________________________________________ Who agrees the success threshold with the customer? __________ One product or model change that started in the field: ________ On site ____% office ___ days/wk travel ____% 2. THE MONEY Band posted: ________ - ________ base / OTE level: ________ What the next level needs, and who decides: ___________________ Variable: none / bonus / OTE ___/___ paid on: _______________ Equity: type _______ vesting _______ basis of value: _______ Months paid per year (12 / 13 / 15 / 16): ___ annualised: ____ 3. THE MEASURE AND THE EXIT Team measured on: adoption / outcomes / utilisation / bookings Where did the last two FDEs who left go? ________ / __________ Path above this level: senior IC / management only / unclear 4. TRAP CHECK (answers that point to services, out of 5): ____ Decision: sign / negotiate ________________ / walk
B.16
Portfolio project brief
Use it to shape one portfolio project like an engagement, with a real user who is not you. Done once, it yields one-off data points at L2 at most, not levels, and saying so in the interview is itself judgment. Chapter 16, Getting Hired, fills it in for a worked example that is not a real project: issue triage for a mid-sized open-source library.
PORTFOLIO PROJECT BRIEF date: ____________ Project: ______________________ User (not you): __________________ Their role: ___________________ Will run it after: _______________ 1. PROBLEM As stated by the user: __________________________________________ As observed (what you watched, how long): _______________________ The number they care about: _____________________________________ User agreed the observed version? YES / NO date: ___________ 2. SCOPE First win: ______________________________________________________ Not now: ______________________________________________________ Never (rule enforced outside the model): ________________________ Success metric: __________________ baseline: ___________________ Threshold (set by the user): ____________________________________ 3. EVAL SET Source of cases: ________________ size: ______ held out: ___ Who labelled: ___________________ agreement between labellers: _ Failure categories found: _______________________________________ 4. THE BUILD Where it runs (theirs, not yours): ______________________________ Acts or proposes? ACTS / PROPOSES why: _______________________ Result vs threshold: ____________ date measured: ______________ The bad news, if any, and the plan you gave: ____________________ 5. HANDOFF README (what the user needs without you) How to run / stop it: ___________________________________________ How to tell it is wrong: ________________________________________ Who to ask when you are gone: ___________________________________ 6. EVIDENCE MAP (skill map, Ch 3; one-offs, not levels) Domain Level shown Artefact Witness technical ___________ _________________ _______________ customer ___________ _________________ _______________ product ___________ _________________ _______________ judgment ___________ _________________ _______________ Cannot show (and why): __________________________________________
B.17
Weekly account review
For the person who leads FDEs. Run it weekly, five minutes an account; anything longer becomes a decision with an owner. It puts every account's load-bearing commitments on one page, so the lead sees what no single FDE can: two engagements hit by the same product gap, one FDE carrying two heavy phases, a sales promise about to consume next month's capacity. It is this book's design, not a published one. Chapter 17, Leading FDEs, shows the composite lead's page in month eight.
WEEKLY ACCOUNT REVIEW week of: ____________
Manager: _______________ FDEs: ____ Live accounts: ____
Rules: five minutes per account. Any commitment not OK gets a
name and a date. Two signals inside four weeks: schedule the
post-mortem this week. Count phases, not accounts.
ACCOUNT: _________________ phase: _____________________________
Threshold written? Y/N owner: __________ status: ______
Commitments threshold __ data path __ sponsor __ exit __
(OK / AT RISK / GONE; for each not OK:
restorer ____________ by ________)
Signals, 4wk _________________________________________________
FDE load FDE: _________ phase weight: heavy/medium/light
other phases this FDE carries: _________________
Product loop field log? Y/N brief: _________ reuse: _______
Decision continue / reset / post-mortem / walk / staff
owner: ____________ by: ________
(repeat the block for each account)
PORTFOLIO
FDEs with more than one heavy phase: __________________________
Requests waiting for an FDE: ___________________________________
learn: product hypothesis / research / reuse / none
land: KPI owner / data by day 5 / end date / price Y/N each
Signal to product this week: ___________________________________
Decisions to take upward: ______________________________________
B.18
Growth plan
Start from the skill self-assessment (B.3) and add what it leaves out: the load you are carrying and the exits you are keeping. Fill it in after each engagement and take both to your lead. Section 2, what you hand to someone else, is the one people leave blank; section 3 asks for counts, not feelings. Chapter 18, Levels, Burnout and What Comes Next, shows the composite FDE's plan at month nine.
GROWTH PLAN date: ______________ Name / role: ______________________ Self-assessment dated: ______ 1. LEVEL: CURRENT, NEXT, AND THE ENGAGEMENT THAT WOULD SHOW IT (current level = section 1 of the self-assessment, not hopes) Domain Now Next Evidence that would count Where/when technical ___ ___ _________________________ __________ customer ___ ___ _________________________ __________ product ___ ___ _________________________ __________ judgment ___ ___ _________________________ __________ 2. LEVERAGE: WHAT I STOP DOING MYSELF TO GET THERE 1. _____________________________________ handed to: __________ 2. _____________________________________ handed to: __________ 3. LOAD CHECK (last 12 months, and the next engagement) Weeks on site, by phase: discovery ___ build ___ handoff ___ On-site weeks outside discovery/handoff: ____ why: __________ Systems I still answer for support window ends ____________________________ ___________ (none = no end) ____________________________ ___________ Engagements back to back with no gap: ____ Engagements at once (incl. support tails): ____ Gap before the next engagement: ____ weeks, used for: _________ Red line I will raise before crossing: ________________________ 4. EXITS I AM KEEPING OPEN (at least two) Exit Draws on My evidence now Keep-alive ______________ _____________ _______________ ___________ ______________ _____________ _______________ ___________ Exit I would drift into if nothing changes: ___________________ 5. WHAT I ASK MY LEAD FOR 1. ______________________________________________________________ 2. ______________________________________________________________ 6. REVIEW Lead agreed / changed: ________________________________________ Lead: ______________ next review: ________
What to do.
- Before you apply, run the FDE-job check on the posting; at the offer, bring the question sheet to your future lead.
- Fill in the engagement brief before signature, and treat every field you cannot fill as a finding, not a formality.
- Send the data-access request to every approver on day one, and write the security answers before the customer's questionnaire arrives.
- Keep the scope, the eval plan and the architecture records where the customer can see them, and re-sign them whenever a threshold, a set or a decision changes.
- After each engagement, fill in the self-assessment and the growth plan, and ask your lead to strike anything they would not sign.