curating-the-strategy-ideas-backlog

Playbook pour pair-revieweur et curateur de portfolio pour le backlog Technical Strategy Ideas (TSI) de Bitwarden — le système en phase idée en amont qui alimente le Software Initiative Funnel à Identification. Couvre le rôle de fonction de challenge constructif pour l'idée de quelqu'un d'autre, la gestion du backlog (triage hebdomadaire, mises à jour RICE mensuelles, positionnement Now/Next/Later), l'examen trimestriel de priorisation avec le leadership engineering, et le transfert des idées approuvées au funnel.

Les deux rôles par idée active

Chaque TSI en statut actif (Research à Implementation) a deux membres Architecture assignés. La page TSI est explicite à ce sujet :

• Primary owner. Pilote l'idée à travers le pipeline : rédige l'énoncé du problème, mène la recherche, présente au Architecture Council, gère la transition vers le funnel. Responsable du progrès. Le playbook du Primary Owner est Skill(championing-a-strategy-idea).
• Peer reviewer. Un deuxième ingénieur Architecture qui agit comme sounding board, reste informé, et fournit une fonction de challenge constructif. Pas un co-owner. Son rôle est de poser les questions difficiles, de détecter les conflits entre initiatives, de s'assurer que l'engagement des stakeholders est approfondi. C'est votre rôle lors de l'invocation de cette skill — aux côtés de la pratique plus large de curateur de portfolio couverte dans le reste de la skill.

Comment fonctionne la peer review

Selon la page TSI :

• Les peer reviewers sont assignés par idée. À mesure que les idées progressent dans le lifecycle et que de nouvelles entrent, les pairages changent pour que l'équipe gagne en largeur sur le portfolio.
• Le primary owner partage les progrès et les points de décision avec le peer reviewer sur une base continue. La session de travail architecture bihebdomadaire est le lieu principal ; les check-ins ad-hoc sont attendus pour les décisions sensibles au temps.
• Avant qu'une idée ne passe de Backlog à Research, le primary owner et le peer reviewer complètent conjointement la section Stakeholder & Engagement Map du template. C'est un gate.
• Quand l'idée est présentée au Architecture Council, le peer reviewer y assiste en tant qu'allié informé qui peut aider à répondre aux questions et soutenir la discussion.
• Aucun ingénieur ne doit avoir plus de deux assignations de reviewer actives à la fois, primary ou peer. Surcharger la review en défait l'objet.

La Stakeholder & Engagement Map comme gate

La map est le gate que les idées doivent franchir avant d'avancer de Backlog à Research. Ses cinq champs — Decision makers, Must consult, Must inform, Known friction points, Engagement approach — sont détaillés dans Skill(championing-a-strategy-idea), la source canonique pour les mécaniques de la map du côté Primary-Owner. La map est complétée collaborativement par Primary Owner et Peer Reviewer ; les idées n'entrent pas en Research sans elle.

En tant que Peer Reviewer, votre job spécifique est de challenger la map — particulièrement Known friction points, le champ où les idées sont le plus souvent édulcorées et que la page TSI nomme explicitement comme là où « les propositions techniquement solides stagnent à l'adoption ». Lors du triage d'une idée prête à avancer de Backlog → Research, la question est : la map est-elle complète et honnête ? Faites une objection si la friction est éludée, si les décideurs sont vagues (« l'équipe Vault » plutôt qu'un rôle nommé avec autorité déclarée), ou si l'approche d'engagement ne correspond pas au style de communication du stakeholder.

Discipline de scoring RICE

Chaque idée porte un score RICE : Reach × Impact × Confidence / Effort. Selon la page TSI, la guidance de scoring se trouve dans Idea RICE Scoring.

Pratique de curation :

• Mettez à jour les scores mensuellement. À mesure qu'on en apprend davantage sur une idée — via la peer review, les conversations avec stakeholders, ou les initiatives connexes qui avancent — le score est affiné.
• Le triage hebdomadaire des nouvelles idées garantit que le backlog reste à jour ; la gestion du backlog en milieu de trimestre revissite les scores en comparaison du portfolio actuel.
• Résistez à l'inflation de score. Reach est ce qu'il est ; Confidence reflète l'état réel des connaissances. Un score RICE honnête qui dit « Confidence est basse » est plus précieux qu'un inflé qui cache la question qu'une PoC répondrait.

Theme, Roadmap Placement, Customer Segments

Selon la page TSI, les idées portent des champs de priorisation standardisés au-delà de RICE :

• Theme. Architecture / Operations / SDLC / Products / Application Security. Détermine quelle vue de portfolio l'idée apparaît dans.
• Roadmap placement. Now / Next / Later. Selon l'Architecture / Engineering Operating Model, ce sont les lanes utilisées dans le portfolio Now/Next/Later communiqué au leadership engineering.
• Customer segments. Individuals / Teams / Enterprises / Self-Hosted / Internal. Capture qui bénéficie.

L'Operating Model est explicite sur la distinction entre Now, Next, et Later — particulièrement que Later est un signal directionnel, pas un engagement. Conservez ce cadrage dans les conversations avec le leadership engineering ; les engagement de dates trimestriels au stade Later créent une fausse précision.

Le cycle de priorisation trimestriel

Selon la page TSI :

L'examen de priorisation trimestriel est le moment où Architecture amène les meilleurs candidats au leadership engineering pour approbation d'entrée au funnel. L'Operating Model le décrit comme l'examen approfondi trimestriel de 60 minutes, avec une mise à jour légère mensuelle de 15–20 minutes entre les deux via des syncs stakeholder.

Pratique de curation pour l'examen trimestriel :

• Parcourez le portfolio Now / Next / Later. Mettez en évidence ce qui a bougé depuis le dernier examen et pourquoi.
• Approfondissement sur les éléments « Now » : phase funnel actuelle, quelles équipes sont ou seront impliquées, ce qu'Architecture a besoin de ces équipes, timeline attendue pour l'engagement. C'est là où les équipes reçoivent un avis préalable de travail qui va vers eux.
• Discutez des éléments « Next » : invitez les contributions sur le séquençage et la priorité. Qu'est-ce qui devrait monter ou descendre ? Quelles dépendances ne se montrent pas dans les données ? Quelles idées d'origine équipe appartiennent au pipeline ?
• Ouvrez la parole aux équipes engineering pour soulever des sujets, poser des questions, ou signaler des préoccupations concernant la direction architecturale.

Transition d'une idée approuvée au funnel

Quand le leadership approuve une idée pour l'entrée au funnel (typiquement à l'examen trimestriel), elle transite vers une BW Initiative à Phase 1 Identification. Selon la page TSI, cela implique :

• Create Initiative. Une nouvelle Jira Initiative sous le projet BW.
• Link to idea. Lien work-item de l'initiative BW vers l'idée ARCH (dans JPD). C'est le lien de traçabilité fondamental.
• Assign shepherd. Un ingénieur Staff+ identifié pour mener l'initiative à travers le funnel. Souvent le primary owner ; parfois un ingénieur Staff+ différent avec l'expertise domaine appropriée.
• Assign peer reviewer. Un deuxième ingénieur Architecture comme sounding board et fonction de challenge pour le travail au funnel (souvent le même peer reviewer qui était sur l'idée, parfois roté).
• Complete Stakeholder & Engagement Map. Si pas déjà complète, le shepherd et le peer reviewer la finalisent conjointement avant d'entrer en Research.
• Enter Identification. L'initiative démarre Phase 1 du funnel.
• Update ARCH idea status à « 1️⃣ Identification » dans JPD.

À partir de là, le shepherd utilise Skill(shepherding-an-initiative) et les skills d'approfondissement par phase pour pilote l'initiative vers l'avant. Le peer reviewer continue à être informé et fournit la fonction de challenge.

Idées qui ne procèdent pas

Selon la page TSI, les raisons de déclin incluent :

• Not aligned with strategy.
• Insufficient value — le coût dépasse le bénéfice, même en considérant des approches différentes.
• Better handled elsewhere — travail au niveau équipe, processus produit, autres canaux.
• Timing — les facteurs externes ou dépendances la rendent impraticable pour le futur prévisible.
• Superseded par une idée connexe ou une initiative existante.
• Resolved par d'autres moyens (travail équipe, changements externes).

Les idées déclinées restent visibles dans JPD avec la rationale enregistrée. La discipline côté curation : toujours enregistrer la rationale, toujours préserver la mémoire institutionnelle. Sans une raison enregistrée, la même idée est re-évaluée 6 mois plus tard à partir de zéro.

La retrospective d'adoption (au transfert du funnel)

Selon la page TSI, quand une initiative atteint Implementation et commence le transfert du Work Transition Playbook, le Primary Owner et Peer Reviewer exécutent une brève retrospective focalisée sur l'effectivité de l'influence — quel engagement a marché, où le mandat manquait, où les désaccords sont apparus tard, quoi faire différemment la prochaine fois.

Quand vous êtes le Peer Reviewer sur l'idée, participez. Le playbook retrospective canonique — les quatre questions, quoi chercher, où vont les findings — se trouve dans Skill(championing-a-strategy-idea), la skill du Primary Owner. La retrospective est Architecture-interne (Primary Owner + Peer Reviewer), focalisée sur comment Architecture a utilisé son influence, et est distincte de la retrospective de fin-Implementation du funnel (shepherd + tech leads récepteurs, focalisée sur l'exécution).

Pratiques de curation lors de la review d'une nouvelle idée

Quand un tech lead ou ingénieur Staff+ dépose une nouvelle idée, le triage côté curation inclut typiquement :

• Le problème est-il réellement cross-cutting ? S'il est contenu dans le codebase d'une seule équipe, déclinez avec rationale (« stays in-team — voir Skill(contributing-to-technical-strategy) pour quand ne pas déposer »). Ne tirez pas le travail à scope équipe dans le portfolio Architecture.
• L'énoncé du problème / opportunité est-il spécifique ? « Error handling est inconsistant » → objectez avec : « spécifiez les variations de pattern et l'impact ». Référencez la guidance du TSI page sur la spécificité.
• La friction est-elle nommée ? Si la Stakeholder & Engagement Map manque ou élude le champ « Known friction points », renvoyez-la. Nommer la friction à l'avance est non-négociable pour l'avancement vers Research.
• Ceci est-il supplanté ? Cherchez le backlog ARCH pour les idées adjacentes ou dupliquées. Liez explicitement si connexes ; supplantz si dupliquées.
• Ceci lève-t-il assez de signification architecturale pour amener au Architecture Council ? Certaines idées — nouveaux patterns, choix tech majeurs, sécurité cross-cutting — méritent l'input du Council avant d'entrer au funnel.

Erreurs courantes

• Laisser la Stakeholder & Engagement Map s'effondrer. Le gate existe pour une raison. Les idées qui avancent à Research sans nommage honnête de friction stagnent à l'adoption.
• Inflation de score. Les numéros de Confidence fabriqués et les valeurs de Reach gonflées produisent un backlog qui ne représente réellement pas la réalité. L'examen trimestriel dépend des scores étant honnêtes.
• Sur-assigner la peer review. Plus de 2 assignations actives par ingénieur Architecture dilue la fonction de challenge. La règle « pas plus de deux » de la page TSI porte charge.
• Traiter le déclin comme un échec. Les idées déclinées avec rationale enregistrée sont une connaissance institutionnelle précieuse. Les abandons silencieux, pas les déclines, sont le problème.
• Sauter la retrospective d'adoption au transfert. L'effectivité d'influence d'Architecture s'améliore seulement si ses patterns opérationnels sont examinés. Participez — le playbook pour la rouler est dans Skill(championing-a-strategy-idea).
• Curer en isolation de l'Operating Model. Le portfolio Now/Next/Later est communiqué au leadership engineering à l'examen trimestriel et à Platform au sync mensuel — curez avec ce public en tête.

Référence

• Technical Strategy Ideas — template TSI canonique, modèle peer-review, cycle de priorisation, gouvernance.
• Architecture / Engineering Operating Model — communication du portfolio Now/Next/Later, Architecture Initiative Review, sync Architecture/Platform.
• Idea-Based Initiatives — ce que l'idée ARCH devient quand elle transite au funnel.
• Software Initiative Funnel — où vont les idées approuvées à Phase 1 Identification.
• Idea RICE Scoring — guidelines de scoring de référence.
• Related: Skill(championing-a-strategy-idea) pour le côté Primary-Owner du même Shepherding Model (piloter une idée spécifique dont vous tenez l'accountability) ; Skill(contributing-to-technical-strategy) (dans bitwarden-tech-lead) pour le côté team-tech-lead-as-contributor de dépôt ; Skill(shepherding-an-initiative) pour ce qui arrive une fois qu'une idée est approuvée et entre au funnel.