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.