navigating-the-initiative-funnel

Bitwarden exécute les travaux transversaux techniques via le Software Initiative Funnel. Un ingénieur senior — généralement Staff+ pour les initiatives inter-équipes, parfois un tech lead pour des travaux à périmètre réduit contenus largement dans le domaine d'une seule équipe — pilote chaque initiative à travers cinq phases : Identification, Research, Proof of Concept, Scoping & Commitment, et Implementation. Le tech lead participe tout au long du processus, mais de manière plus intensive lors des phases Scoping & Commitment et Implementation. Cette compétence est le guide pratique pour cette participation, écrit du point de vue d'un tech lead travaillant aux côtés d'un shepherd distinct ; quand le tech lead pilote également l'initiative, lisez les descriptions de phase des deux rôles et exercez les deux. Quand une référence canonique est nécessaire, récupérez la page funnel via l'outil MCP get_confluence_page ; ce document en est le résumé opérationnel.

La Règle de Propriété

Chaque phase a une phrase à retenir : le shepherd possède l'initiative ; le tech lead possède la façon dont son équipe exécute sa part. Au moment où cette ligne s'estompe, l'un de deux modes de défaillance apparaît — soit le shepherd commence à écrire les stories de l'équipe (et l'équipe ne possède pas le travail), soit le tech lead commence à prendre des décisions inter-équipes qui ne sont pas les siennes (et l'initiative dérape).

Phase par Phase : Qui Fait Quoi

Phase 1 — Identification

Le shepherd crée un problème BW Initiative, documente le problème, et obtient un go/no-go du leadership technique.

Le rôle du tech lead est léger ici. Si le shepherd vous contacte parce que le domaine de l'équipe est affecté, fournissez le contexte, l'historique connu et les parties prenantes. Signalez les tentatives antérieures. Ne pré-scopez pas — la recherche n'a pas encore eu lieu.

Phase 2 — Research

Le shepherd interroge les parties prenantes (le tech lead en est une probable), examine le codebase, et produit une Architectural Assessment avec 2–4 options de solution.

Le rôle du tech lead : être bien interviewé. Partagez les points de douleur de l'équipe, les contournements, et les contraintes que le shepherd ne verra pas de l'extérieur. Quantifiez où possible (« cela provoque ~3 bugs par sprint »). Si le shepherd propose une direction qui entrerait en conflit avec un travail déjà sur la feuille de route de l'équipe, signalez-le maintenant — pas après l'engagement.

Phase 3 — Proof of Concept

Le shepherd choisit une zone PoC (parfois dans le codebase de l'équipe), construit un framework ou un exemple, présente à l'Architecture Council, et brouille une ADR.

Le rôle du tech lead si le PoC s'inscrit dans le codebase de l'équipe : désignez un point de contact dans l'équipe pour se jumeler avec le shepherd ou examiner ses PRs. Soyez un collaborateur, pas une barrière. Le PoC est destiné à tester la faisabilité dans du vrai code — si cela coupe les coins ronds, c'est un signal qui vaut la peine d'être soulevé, mais ne traitez pas la PR PoC comme un examen de production. Soulevez les préoccupations concernant l'approche directement auprès du shepherd ; n'expédiez pas silencieusement des contournements.

Phase 4 — Scoping & Commitment

C'est la phase où la participation du tech lead a le plus d'impact. Le shepherd crée des épics enfants sous l'initiative BW (généralement un par équipe ou module majeur), écrit les descriptions épic, et programme les réunions de transmission. Ensuite, l'équipe possède la décomposition.

Le shepherd apporte à la transmission : les résultats du PoC, la section du plan d'architecture pertinente pour l'équipe, les critères de succès, et du temps pour les Q&A. Le tech lead apporte : des questions, une lecture réaliste de la façon dont cela s'inscrit dans la feuille de route existante de l'équipe, et une date d'engagement pour la décomposition elle-même.

Après la transmission, menez une session de décomposition d'équipe. L'équipe crée les stories — pas le shepherd. Appliquez les règles de qualité des stories du funnel :

• Soyez spécifique. « Migrer la gestion des erreurs du user-service vers le nouveau pattern » bat « mettre à jour la gestion des erreurs ».
• Écrivez les critères d'acceptation qui définissent la fin. Référencez la PR PoC ou le plan d'architecture pour l'approche technique.
• Notez les dépendances — en particulier les inter-équipes. Celles-ci se retrouvent auprès du shepherd pour la coordination.
• Assignez à l'équipe, pas à des individus. Les individus arrivent lors de la planification de sprint.
• Étiquetez pour le filtrage (par ex. initiative-typescript-migration) de sorte que le tableau de bord du shepherd puisse suivre la progression.
• Dimensionnez avec le processus normal de l'équipe. N'inventez pas une nouvelle méthode d'estimation pour le travail d'initiative.

Quand la décomposition est faite, partagez-la avec le shepherd. Il examine la cohérence avec la vision de l'initiative, et non pour réécrire les stories ou micromanager. Attendez-vous à des questions comme « cela a l'air bien mais utilise des callbacks au lieu du pattern async/await du PoC — était-ce intentionnel ? » C'est le shepherd qui fait son travail. Le rôle du tech lead est d'avoir une bonne réponse.

Avant que l'initiative ne progresse vers Implementation, le leadership technique doit s'engager explicitement sur la capacité — une allocation spécifique pour des sprints spécifiques. N'acceptez pas une épic dans un backlog sans cet engagement. L'engagement exécutif sans priorisation opérationnelle est le mode de défaillance où les épics s'assoient dans les backlogs et ne sont jamais extraites des sprints.

Phase 5 — Implementation

L'équipe exécute. Le shepherd coordonne entre les équipes, répond aux questions d'approche, examine 1–2 PRs précoces pour l'alignement (pas un examen détaillé du code), et rapporte la progression au leadership.

Responsabilités continues du tech lead :

• Sync bi-hebdomadaire des tech-leads avec le shepherd et les autres équipes affectées. Rotation sur la progression, les blocages, les dépendances inter-équipes et les questions émergentes. 30–45 minutes.
• Surveillez la dérive à l'intérieur de l'équipe. Si les ingénieurs interprètent le pattern différemment entre les PRs, resserrez les directives — n'attendez pas que le shepherd l'attrape.
• Signalez les problèmes émergents. Si l'équipe rencontre un problème qui suggère que le PoC n'a pas couvert la véritable forme du problème en production, levez-le. Le shepherd peut escalader vers l'Architecture Council et coordonner une pause ou un pivot. Le pire résultat est trois équipes qui implémentent silencieusement trois contournements différents.
• Utilisez le doc FAQ. S'il y a un canal Slack #initiative-foo ou une page FAQ Confluence que le shepherd maintient, postez les réponses que l'équipe comprend — les autres équipes poseront la même question.
• N'arrêtez pas de examiner le code. Le shepherd n'est pas un relecteur pour les PRs de l'équipe. L'examen détaillé du code de l'équipe se produit toujours à l'intérieur de l'équipe.

Quand l'épic de l'équipe est fait, marquez-le comme fait, participez à la rétrospective que le shepherd exécute, et rendez-vous à la cadence régulière de l'équipe.

Les Deux Listes à Retenir

Ce que le tech lead possède et le shepherd ne possède pas :

• Décomposition des stories, critères d'acceptation, estimations.
• Examen détaillé du code à l'intérieur de l'équipe.
• La cadence de merge PR de l'équipe.
• Planification de sprint et assignation aux individus.
• Décisions qui sont purement à l'intérieur de la limite du codebase de l'équipe.

Ce que le shepherd possède et le tech lead ne possède pas :

• L'ADR de l'initiative et le plan d'architecture.
• La cohérence inter-équipes et la décision de pause/pivot.
• La représentation au Architecture Council.
• Le narrative de progression face au leadership.
• La communication avec les autres leads d'équipes sur les dépendances partagées.

Quand quelque chose ne figure dans aucune des deux listes, c'est généralement une dépendance inter-équipes — ce qui signifie qu'elle appartient au shepherd jusqu'à ce qu'il la repousse à l'équipe avec le périmètre et le contexte.

Chemins d'Escalade

• Conflit de capacité (l'équipe ne peut pas absorber l'épic sur le calendrier proposé) : escalade vers l'EM de l'équipe et le shepherd. La phase Scoping & Commitment du funnel est explicitement où la capacité est négociée — c'est le bon lieu, pas au milieu d'Implementation.
• L'approche PoC ne fonctionne pas dans le contexte de l'équipe : levez-le auprès du shepherd. Si c'est un problème fondamental, le shepherd l'porte à l'Architecture Council.
• Une autre équipe s'éloigne du pattern d'une façon qui nuira aux travaux de l'équipe : levez-le auprès du shepherd. La cohérence inter-équipes est leur travail ; les tech leads ne négocient pas directement avec l'implémentation d'une autre équipe.
• Le shepherd est absent ou sans réponse : le funnel stipule que les shepherds doivent désigner un relais pour les absences prolongées. S'il n'y en a pas, escaladez vers le leadership technique — ne combler pas silencieusement le vide.

Erreurs Courantes

• Accepter les stories du shepherd comme écrites. Si l'équipe n'a pas exécuté sa session de décomposition, l'équipe ne possède pas le travail. Réexécutez-la, même si cela semble être un travail redondant.
• Traiter la transmission comme cérémonielle. La réunion de transmission est le moment de poser les questions inconfortables. Si quelque chose semble mal dans le pattern PoC, la transmission est peu coûteuse ; post-merge coûte cher.
• Laisser la dérive se cumuler. Les petites variations se multiplient. Attrapez-les dans les 1–2 premières PRs, pas les 10 dernières.
• Commencer le travail avant que la capacité soit allouée. Les épics qui atterrissent dans les backlogs sans allocation de sprint claires y meurent. C'est une conversation de leadership, pas une conversation d'héroïsme.
• Sur-indexer sur le shepherd. Il coordonne 5+ équipes. La qualité détaillée du code, la discipline de sprint et les décisions internes à l'équipe sont toujours celles de l'équipe.

Référence

• Software Initiative Funnel — le document canonique phase par phase. Récupérez via get_confluence_page quand le modèle complet, les critères go/no-go ou le tableau chronologique d'exemple est nécessaire.
• Connexe : Skill(running-work-transitions) pour les mécaniques de transition Phase 4→5 de chaque côté de la transmission, Skill(architecting-solutions) pour le jugement architectural à apporter à la décomposition.