Analogical grounding for delivery

Purpose: This document explains the analogical layer used throughout the delivery system. Analogies are used to teach the logic of the system more quickly, especially under pressure or during onboarding.

Policy remains literal. Analogies are scaffolding, not policy.


1. Why we use analogies

Elite operating systems in different domains tend to converge on similar structural truths:

  • preparation matters
  • ownership matters
  • review gates matter
  • escalation discipline matters
  • quality control before external exposure matters

Analogies help us name those truths quickly without turning the operating model into vague motivational language.


2. Guardrails

  • Policy stays literal. The source of truth lives in the actual delivery docs.
  • Use the strongest matching analogy, not all analogies at once.
  • Do not force analogy over clarity. If the literal explanation is enough, use the literal explanation.
  • Use analogies as teaching tools, not as the structure of the repo.

3. Michelin-star restaurants

What this analogy teaches

  • mise en place
  • station ownership
  • timing and coordination
  • quality gate before the output reaches the guest

Best fit in the delivery model

  • preparation before execution
  • CSO / SL / IC role coordination
  • review before client-visible output
  • re-gating when the dish changes materially

Why it fits

High-performing kitchens are not great because they “care a lot.” They are great because preparation, ownership, and the pass create control under pressure.


4. Elite consultancies

What this analogy teaches

  • structured thinking
  • preparation before discussion
  • defensibility under scrutiny
  • synthesis of complexity into decisions

Best fit in the delivery model

  • plan before promise
  • Project Review Meeting
  • distilling complexity into clear action
  • strong leadership and client communication

Why it fits

The best consulting environments reward not just insight, but the ability to present a coherent, defensible case under questioning.


5. Great agencies

What this analogy teaches

  • client-visible momentum
  • responsive communication
  • strong narrative discipline
  • progress that can be seen and felt by the client

Best fit in the delivery model

  • client weekly touchpoints
  • artifact habit
  • making delivery legible
  • framing progress in business language

Why it fits

The best agencies understand that good work must also be presented in a way that creates confidence and shared momentum.


6. Banks and other risk-managed institutions

What this analogy teaches

  • no surprises
  • review discipline
  • exactness
  • escalation before external damage

Best fit in the delivery model

  • escalation doctrine
  • portfolio-level leadership review
  • controlled communication on risk
  • explicit ownership and approval paths

Why it fits

In risk-managed environments, the cost of late truth is usually higher than the cost of early truth.


7. Mapping table

Delivery conceptStrongest analogyWhy it fits
Project Review MeetingThesis defense / consultancy review / investment committeeThe plan must survive scrutiny before commitment
Plan before promiseConsultancy / bankingCommitments should be pressure-tested
Story matches buildMichelin front-of-house + kitchen / great agenciesThe external narrative and the actual product cannot drift apart
No surprisesBanking / risk-managed operating systemsEarly escalation protects trust
Show up preparedMichelin mise en place / consultancy prepPreparation is part of quality, not a nice-to-have
Deliver tangible valueGreat agenciesProgress must be visible and meaningful
Close the loopBanking / strong service environmentsControl of the system shows up in follow-through

8. Limits

  • We are not an academic institution. The defense analogy is about review structure, not academia.
  • We are not a restaurant. The kitchen analogy is about roles, prep, timing, and quality gates.
  • We are not an agency or bank. We borrow structural lessons, not identity.
  • Analogies are optional. If they are helping, use them. If they are cluttering, drop them and stay literal.

9. Where these analogies should appear

The preferred pattern in major docs is:

  1. Literal statement
  2. Why it exists
  3. Analogy
  4. What good looks like

That pattern should be used lightly and intentionally across the delivery system.


Last updated: 2026-03-24