# Archetype 63 — Idée d'un grand patron ## Source Template communautaire « Idée grand patron » (source.md #37). ## Définition Reprendre **une idée précise d'un dirigeant d'entreprise reconnu** (Jeff Bezos, Reed Hastings, Satya Nadella, Marc Benioff, etc.) et la **discuter** — pas l'admirer. Le grand-patron sert de **prétexte à un débat de management** que tu veux ouvrir. ⚠ Variante de `26_argument_autorite` spécialisée. Différence : `26` discute *l'argument*, le grand-patron étant le porteur. **63** centre le post sur **la pratique managériale précise** documentée publiquement (la "two-pizza rule" de Bezos, le "keeper test" de Hastings, etc.) — l'idée est plus circonscrite, plus opérationnelle. ## Pattern syntaxique ``` [Nom + entreprise + pratique précise, 1-2 lignes] [Comment cette pratique a été documentée — source primaire, contexte, 2-3 lignes] [Pourquoi elle marche dans son contexte original : conditions de validité, 4-6 lignes] [Ce qui se casse quand tu la transposes mécaniquement : conditions de non-validité, 4-6 lignes] [Ce que tu garderais et ce que tu adapterais dans ton contexte, 2-3 lignes] [Source primaire (livre, lettre, interview) en first-comment] ``` ## Exemples - ***Jeff Bezos — Amazon : la "two-pizza rule" (1998).*** *Documentée dans plusieurs lettres annuelles aux actionnaires Amazon, et dans le livre de Brad Stone "The Everything Store". La règle : aucune équipe Amazon ne doit avoir plus de membres que ce que peuvent nourrir 2 pizzas (~6-8 personnes).* *Pourquoi ça a marché chez Amazon : l'entreprise a explosé en taille pendant 25 ans (1998 → 2023, de 600 à 1.5M d'employés). À cette échelle, **la coordination devient un coût plus important que la production**. La two-pizza rule rend la frontière "qui fait quoi" lisible et stable. Elle marche aussi parce que chaque équipe a un mandat **owner-end-to-end** (pas une dépendance à 5 autres équipes pour livrer).* *Ce qui se casse quand on transpose mécaniquement la règle dans une PME de 60 personnes : la taille n'est pas le coût dominant. Le coût dominant en PME, c'est souvent l'isolement des fonctions (1 dev qui porte tout, 1 designer qui porte tout). Faire des équipes de 6 personnes dans une PME de 60 = recréer artificiellement des frontières qui n'avaient pas lieu d'être. C'est appliquer le médicament d'une autre maladie.* *Ce que je garderais : le principe que la frontière d'équipe doit être **observable** et **respectée par le management** — pas une frontière qui bouge tous les 6 mois sur Excel. Ce que j'adapterais : la taille (4-12 selon contexte), et surtout le mandat owner-end-to-end qui est la vraie clé, pas le nombre.* *Source primaire : Brad Stone, "The Everything Store", chapitre 7. Lettres aux actionnaires Amazon 1999-2002.* - ***Reed Hastings — Netflix : le "keeper test" (2009).*** *Documenté dans la "Culture Deck" de Netflix (2009, disponible publiquement) et le livre de Hastings & Meyer "No Rules Rules" (2020). La règle : un manager Netflix se pose chaque trimestre la question — *« Si X démissionnait demain, ferais-je tout pour le retenir ? »* Si la réponse est non, l'employé est à laisser partir avec un package.* *Pourquoi ça a marché chez Netflix : société de produit où **la médiocrité d'un seul ingénieur** sur un module critique (recommandation, CDN, encoding) coûte 50× plus que ses 6 mois de salaire en bugs, dette, coût d'opportunité. Le keeper test rend explicite ce que les managers font implicitement de façon retardée.* *Ce qui se casse quand on transpose : Netflix peut se le permettre parce que ses packages de départ sont **généreux et publics**. Sans ça, la règle devient une menace permanente qui détruit la sécurité psychologique. Dans une PME française avec 14j de licenciement par année et 0 culture du package, le keeper test devient juste de la culture de peur.* *Ce que je garderais : la question elle-même est utile (chaque manager devrait pouvoir y répondre honnêtement). Ce que j'adapterais : ne pas la transformer en **règle de licenciement**, mais en **question de coaching** — si la réponse est non, qu'est-ce qui manquerait pour qu'elle devienne oui ?* ## Anti-patterns - ❌ **Idée grand-patron + admiration creuse** — devient hagiographie. La discussion est obligatoire. - ❌ **Transposition mécanique** sans nommer les conditions de validité — c'est ce qui rend les conseils de management dangereux. - ❌ **Citation seconde main** (du résumé Twitter, du résumé Medium). Le grand-patron a écrit la lettre annuelle ; lis-la. - ❌ **Grand-patron déjà sur-cité** (Steve Jobs surtout) — saturation, le post se noie dans le bruit. - ❌ **Idée du grand-patron qu'il n'a probablement pas eue** (la plupart des "citations Jobs" sont apocryphes). Vérifie deux fois. ## Combo piliers - ⭐ **Piliers "management / culture organisationnelle / gouvernance"** — c'est leur formule. - ⚠ **Piliers techniques** : la pratique de management ne se transpose pas naturellement. ## Combo analogies - ⚠ La pratique-grand-patron EST l'objet du post. Pas d'analogie supplémentaire. ## Cadence recommandée **≤ 1 par trimestre.** ## Source-discipline - **Source primaire impérative** — lettre annuelle, livre, interview enregistrée. Pas un fil Twitter. - **Date la pratique** — Bezos en 1998 ≠ Bezos en 2018. Les organisations changent. - **Nomme les conditions** où la pratique marche, sinon le post devient une généralisation dangereuse.