Piloter une Technical Strategy Idea jusqu'au funnel

Manuel de jeu du Primary Owner pour piloter une Technical Strategy Idea (TSI) à travers l'évaluation pré-funnel d'Architecture. Couvre le dépôt de l'idée ARCH, l'appairage avec un relecteur pair, la complétion de la Stakeholder & Engagement Map (avec les Points de Friction Connus), la présentation au Architecture Council, la navigation dans la priorisation trimestrielle, et l'exécution de la Retrospective d'Adoption au moment de la transmission d'implémentation. Horizon temporel : piloté par la cadence de revue trimestrielle, pas une horloge fixe.

Pour le côté Peer Reviewer / portfolio-curator utilisez Skill(curating-the-strategy-ideas-backlog); pour le cadrage team-tech-lead-as-contributor (bien déposer, conduire les approbations vers un propriétaire Staff+) utilisez Skill(contributing-to-technical-strategy) dans bitwarden-tech-lead.

Le Modèle de Pilotage

Selon la page TSI, chaque idée en statut actif a deux rôles côté Architecture assignés :

Primary Owner. Pilote l'idée à travers le pipeline. Rédige la déclaration de problème, conduit la recherche, présente au Architecture Council, pilote la transition vers le funnel. Comptable du progrès. C'est vous quand vous invoquez cette compétence.
Peer Reviewer. Un deuxième ingénieur Architecture qui agit comme un sounding board, reste informé de la progression de l'idée, et fournit une fonction de défi constructif. Pas un copropriétaire — leur travail consiste à poser les questions difficiles, détecter les conflits interinitiatives, et s'assurer que l'engagement des stakeholders est approfondi.

L'appairage compte. La page TSI est explicite : « Aucun ingénieur ne devrait avoir plus de deux assignations d'examen actives à la fois, primary ou peer. » Si vous prenez un rôle de Primary Owner et que vous avez déjà deux assignations actives, soulevez-le — un examen surchargé défait son objectif et bloque les idées que vous avez nominalement prises en charge mais ne pouvez pas réellement piloter.

L'Arc : De la Thèse à l'Intake du Funnel

Grossièrement :

Capture. Déposez l'idée ARCH avec un premier passage léger — Déclaration de Problème / Opportunité, Alignement Stratégique, RICE approximatif, thème, segments clients, placement sur la feuille de route.
Appairage. Obtenez un relecteur pair assigné. Commencez à partager la progression avec lui à la session de travail architecture bihebdomadaire.
Affiner avec la revue pair. Ensemble, complétez la Stakeholder & Engagement Map avant que l'idée ne passe de Backlog à Research. C'est la porte.
Research. Affinez la Déclaration de Problème, menez des conversations avec les stakeholders en utilisant les approches d'engagement auxquelles vous vous êtes engagé, surfacez les résultats.
Présentez au Architecture Council. Le relecteur pair assiste en tant qu'allié informé.
Obtenez l'intake à la priorisation trimestrielle. Le leadership de l'ingénierie décide si cette idée entre dans le funnel — et sur quel timing de feuille de route.
Transition vers le funnel. Créez la BW Initiative, établissez un lien vers l'idée ARCH, mettez à jour les statuts, et transmettez à Skill(shepherding-an-initiative) pour l'arc funnel.

Après la fin de l'implémentation du côté funnel, vous et le relecteur pair exécutez une Retrospective d'Adoption centrée sur l'efficacité de l'influence. Cela revient ici, pas aux compétences funnel — voir le bas de cette compétence.

Dépôt de l'Idée (Capture)

Le template TSI se trouve dans JPD sous le projet ARCH. Les sections les plus importantes pour le Primary Owner sont :

Déclaration de Problème / Opportunité. Soyez précis sur l'état actuel, la douleur et l'opportunité. Le bar d'exemple de la page TSI : « Cinq motifs différents de gestion des erreurs existent dans les clients, causant des difficultés de débogage et de la confusion utilisateur » — pas « La gestion des erreurs est incohérente. » Quantifiez partout où c'est possible.
Alignement Stratégique. Quels OKRs, thèmes ou principes architecturaux cela soutient-il ? Quelles autres initiatives en dépendent ou qu'il active ?
Direction Proposée. Approche conceptuelle uniquement. Ne concevez pas la solution — cela vient pendant le Research du funnel. Build vs. buy vs. integrate au niveau approximatif.
Considérations Opérationnelles & Qualité. Métriques clés / SLIs, contraintes de performance, testabilité, auto-hébergé vs. cloud, points de conformité.
Approche de Validation. À quoi ressemblerait une PoC minimale, signaux de succès, hypothèses à tester.
Dimensionnement Approximatif. T-shirt, durée attendue, facteurs de complexité.
RICE. Honnête. La confiance est ce qu'elle est — l'inflater produit un backlog mensonger. La page TSI documente la rubrique RICE.

Vous pouvez déposer avec Skill(contributing-to-technical-strategy) dans bitwarden-tech-lead comme référence pour les mécaniques template. Cette compétence est le cadrage côté contributeur ; tout ce qui dépasse le dépôt — appairage, mapping, affinage, présentation, priorisation — est le territoire de cette compétence.

La Stakeholder & Engagement Map (la Porte de Research)

La chose la plus importante que cette compétence fait bien. Selon la page TSI, les idées n'avancent pas de Backlog à Research sans une map complète, complétée conjointement par le Primary Owner et le Peer Reviewer. La map a cinq champs :

Décideurs. Des personnes ou rôles spécifiques — pas juste des noms d'équipe — et l'aspect sur lequel chacun a autorité. « VP Ingénierie pour l'allocation des ressources ; SRE Lead pour la propriété opérationnelle. »
Doit consulter. Personnes avec expertise ou contexte qui affecteront matériellement la direction. Input cherché pendant le Research, pas après. Distinguer doit-consulter de doit-informer est ce qui empêche les idées d'être façonnées dans le vide.
Doit informer. Personnes affectées par le résultat qui doivent rester conscientes. Elles ne devraient pas être surprises quand l'initiative les atteint.
Points de friction connus. Où le désaccord, la résistance ou les priorités concurrentes viendront. Honnête. Nommé. Avant que le Research ne commence. La page TSI est explicite : « Nommer la friction à l'avance est comment les bonnes idées évitent de devenir des propositions techniquement saines qui stagnent à l'adoption. » C'est le champ où les Primary Owners sont les plus tentés d'adoucir. Résistez.
Approche d'engagement. Comment chaque groupe sera engagé. La page TSI liste le menu : conversations 1:1, revue RFC-style Confluence, présentation au Architecture Council, présence à une revue de sprint d'équipe, revue Confluence asynchrone. Appariez l'approche au style de communication du stakeholder et à la sensibilité du sujet.

Deux questions que le Peer Reviewer devrait pousser, et que vous devriez pousser en premier :

Avons-nous nommé la friction que nous connaissons déjà ? « Nous nous attendons à une résistance de l'Équipe X parce que Y » est une idée plus crédible qu'une qui ne présente que le côté positif.
L'approche d'engagement est-elle honnête sur l'influence ? Si la map dit « RFC pour l'équipe Platform » mais que vous avez réellement besoin d'un 1:1 avec le tech lead Platform avant que la RFC ait une chance d'être examinée, nommez-le.

La map est aussi un document vivant. À mesure que le Research surface de nouveaux stakeholders ou frictions, mettez-la à jour. La Retrospective d'Adoption à la fin de l'arc demandera si la map était exacte — rédigez-la pour être vérifiable plus tard.

Affinage par le Research (Pré-Funnel)

La phase TSI Research est plus légère que la phase Research du funnel — vous ne produisez pas encore une Architectural Assessment. Vous affinez la compréhension assez pour que l'idée soit prête à être présentée et priorisée.

Affinez la Déclaration de Problème / Opportunité. Mettez à jour à mesure que les preuves s'accumulent. La version qui va au Architecture Council devrait être plus affûtée que la version qui a été déposée.
Exécutez les approches d'engagement auxquelles vous vous êtes engagé. 1:1s, revues RFC, présence aux revues de sprint d'équipe. Chaque conversation surface généralement quelque chose que la map n'a pas prédit — mettez à jour la map.
Partagez la progression avec le relecteur pair à la session de travail architecture bihebdomadaire. Le travail du Peer Reviewer ici est de poser les questions que vous avez cessé de vous poser.
Mettez à jour RICE. À mesure que la Confiance s'affûte, le score devrait changer. Une Confiance décroissante honnête signale souvent « needs PoC before commitment » — ce qui est bien ; c'est ce que le Research, puis la PoC, sont pour.

Présentation au Architecture Council

Quand l'idée est prête — map complète, déclaration de problème affûtée, friction reconnue, approche d'engagement validée par quelques conversations initiales — amenez-la au Architecture Council.

Le Peer Reviewer assiste en tant qu'allié informé. Il peut aider à répondre aux questions et soutenir la discussion. La page TSI note que « le groupe Architecture s'aligne en interne avant la session par leur session de travail bihebdomadaire » — utilisez cela.
Structurez la présentation autour de la thèse. Commencez par le problème et l'alignement stratégique, pas par une solution proposée. Le travail du Council est de valider que cette idée mérite des ressources, pas de la concevoir.
Amenez la friction avec vous. Le Council demandera. Mieux vaut commencer avec la version honnête que d'être tiraillé par les questions.
Prenez l'input au sérieux. Si le Council surface un conflit interiniciatives ou un stakeholder que vous n'aviez pas mappé, cela revient dans la map.

Ce que le Architecture Council fournit à ce stade : conscience interiniciatives, validation de l'alignement stratégique, mise en surface des préoccupations concernant le timing ou les conflits, parfois une recommandation sur l'approche d'engagement.

Ce qu'il ne fournit pas : un feu vert indépendant de la priorisation du leadership de l'ingénierie qui suit. Le Council recommande ; le leadership priorise ; les deux informent si l'idée obtient l'intake funnel.

Obtenir l'Intake du Funnel à la Priorisation Trimestrielle

Selon le Architecture / Engineering Operating Model, Architecture apporte des idées priorisées au leadership de l'ingénierie trimestriellement (60 minutes, revue approfondie) avec des mises à jour légères mensuelles (15–20 min) entre.

Votre travail avant la revue trimestrielle :

Assurez-vous que l'idée est à l'ordre du jour. Architecture décide quelles idées présenter ; coordonnez avec le leader du groupe Architecture à la session de travail bihebdomadaire.
Soyez préparé à présenter un cas Now / Next / Later. Le Operating Model utilise ces couloirs. Où pensez-vous que cette idée devrait aller ? Pourquoi ? Qu'est-ce qui change si elle glisse d'un trimestre ?
Soyez honnête sur la demande de ressources. Si approuvée, qui la pilote (vous ou quelqu'un d'autre) ? Quelles équipes sont probablement affectées ? Quel est le timeline approximatif ?
Amenez la friction en avant. Le leadership est plus susceptible de s'engager envers une idée qui nomme où le désaccord émergera que vers une qui le cache.

Si approuvée, l'idée transition vers le funnel à Phase 1 Identification. Selon la page TSI et Idea-Based Initiatives :

Une nouvelle BW Initiative est créée dans le projet BW sous Jira.
Un work-item link est établi de l'initiative BW vers l'idée ARCH — le lien de traçabilité fondateur.
Un shepherd est assigné (souvent vous ; parfois un ingénieur Staff+ différent avec la bonne expertise de domaine — surfacez la préférence, ne supposez pas).
Un peer reviewer est assigné pour l'arc funnel (souvent le même relecteur pair, parfois roté pour la breadth).
La Stakeholder & Engagement Map est finalisée si pas déjà complète.
Le statut de l'idée ARCH est mis à jour à « 1️⃣ Identification » dans JPD.

À partir de là, transmettez à Skill(shepherding-an-initiative) pour le playbook parapluie de l'arc funnel. L'arc que vous venez de piloter devient le contexte amont pour ce travail.

Quand l'Idée Est Déclinée ou Retenue

Selon la page TSI, les raisons de déclin sont enregistrées explicitement :

Pas alignée avec la stratégie.
Valeur insuffisante (coût > bénéfice, même après avoir considéré des approches différentes).
Mieux gérée ailleurs (travail au niveau équipe, processus produit, autres canaux).
Timing (facteurs externes, dépendances).
Remplacée par une idée liée ou initiative existante.
Résolue par d'autres moyens.

Documentez la justification sur l'idée dans JPD avant de la déplacer à Declined. La mémoire institutionnelle compte — six mois plus tard, quelqu'un peut surfacer le même motif et bénéficier de savoir ce qui a été conclu.

Les idées Held sont différentes des idées déclinées. Si le timing est mauvais mais la thèse reste valide, poussez pour « Later » plutôt que Declined et revisitez à la prochaine revue trimestrielle.

La Retrospective d'Adoption (Après la Transmission d'Implémentation)

C'est la conclusion de l'arc de championing et elle vit ici, pas dans les compétences funnel. Selon la page TSI, quand l'initiative atteint l'Implémentation et commence sa transmission du Work Transition Playbook, le Primary Owner et le Peer Reviewer exécutent une brève retrospective centrée sur l'efficacité de l'influence — pas les mécaniques de livraison.

Quatre questions, toutes sur la façon dont Architecture a utilisé son influence pour ancrer cette thèse :

Quelles approches d'engagement ont fonctionné pour obtenir l'adoption ? Quels 1:1s ont changé les positions ? Quelles revues RFC ont réellement fait avancer le travail ? Quelles présentations du Council ont obtenu de l'engagement ?
Où nous a manqué le mandat, et comment l'avons-nous navigué ? Architecture n'a pas autorité pour assigner du travail aux équipes ; les approches d'engagement sont comment l'influence substitue au mandat. Quand cette substitution a fonctionné — et quand ce n'était pas le cas — informe l'idée suivante.
Où avons-nous découvert des désaccords tard qui auraient dû être surfacés plus tôt ? C'est la post-mortem du champ « Known Friction Points » de la Stakeholder & Engagement Map. La friction que nous avons surfacée tôt est la friction que nous avons navigée. La friction que nous avons découverte pendant l'Implémentation est la friction que la map a manquée.
Qu'est-ce que nous ferions différemment sur l'initiative suivante ? Leçons pratiques, transférables.

La page TSI ordonne que les résultats soient « partagés à la session de travail Architecture et capturés comme un commentaire sur l'idée originale pour la mémoire institutionnelle. » Les deux lieux comptent — la session de travail améliore la pratique collective d'Architecture ; le commentaire s'assure que la prochaine personne qui trouve cette idée a le contexte de la retrospective.

C'est distinct de la retrospective end-of-Implementation du funnel dans Skill(coordinating-implementation-across-teams) — celle-ci est shepherd + tech leads récepteurs, centrée sur l'exécution. La Retrospective d'Adoption est Architecture-interne (Primary Owner + Peer Reviewer), centrée sur l'influence.

Erreurs Courantes

Dépôt de l'idée, puis dérive. Le dépôt n'est pas le championing. Prenez l'assignation Primary Owner au sérieux : appairez, mappez, présentez, priorisez. Sinon l'idée stagne en Backlog.
Adoucissement des Points de Friction Connus. La map est où les idées deviennent crédibles ou restent théoriques. Le travail du Peer Reviewer est de pousser sur cela ; si vous trouvez que vous adoucissez leur pushback, c'est un signal.
Traiter le Architecture Council comme une porte à franchir. Le Council est un input. Amenez des vraies questions, pas un pitch. La plupart des idées fortes sortent du Council avec des changements de forme.
Sauter la Retrospective d'Adoption. La retrospective funnel couvre la livraison ; celle-ci couvre l'influence. Sans elle, la pratique collective d'Architecture ne s'améliore pas sur la chose qu'elle a le plus besoin d'être bonne.
Surcharger le Peer Reviewer. Règle de la page TSI : pas plus de deux assignations d'examen actives par ingénieur Architecture. Si votre relecteur est surchargé, sa fonction de défi décline. Surfacez-le.
Pré-scoping pendant le championing. La Direction Proposée est conceptuelle. La conception détaillée de la solution est le travail du Research du funnel, pas le vôtre encore. Le scoping prématuré ferme les options que le Council aurait pu ouvrir.

Référence

Technical Strategy Ideas — template TSI canonique, Shepherding Model (Primary Owner / Peer Reviewer), Stakeholder & Engagement Map, Adoption Retrospective.
Idea-Based Initiatives — comment une idée ARCH approuvée devient une BW Initiative à Phase 1 du funnel.
Architecture / Engineering Operating Model — la revue de priorisation trimestrielle et le portfolio Now/Next/Later qui décide quelles idées entrent dans le funnel.
Software Initiative Funnel — où les idées approuvées vont (Identification en avant).
Architecture Council — le lieu où vous présentez pendant le championing et à nouveau pendant le Research/PoC du funnel.
Lié : Skill(curating-the-strategy-ideas-backlog) pour le côté Peer-Reviewer / portfolio-curator du même Shepherding Model ; Skill(shepherding-an-initiative) pour ce qui arrive une fois que votre idée obtient l'intake funnel ; Skill(contributing-to-technical-strategy) (dans bitwarden-tech-lead) pour le côté team-tech-lead-as-contributor du dépôt.

championing-a-strategy-idea