championing-a-strategy-idea

What this skill does

Primary-Owner playbook for shepherding a [Technical Strategy Idea](https://bitwarden.atlassian.net/wiki/spaces/EN/pages/2344517656) (TSI) through Architecture's pre-funnel evaluation. Spans filing the ARCH idea, pairing with a peer reviewer, completing the Stakeholder & Engagement Map (with Known Friction Points), presenting at Architecture Council, navigating quarterly prioritization, and running the Adoption Retrospective at Implementation handoff. Time horizon: driven by the quarterly review cadence, not a fixed clock.

For the Peer Reviewer / portfolio-curator side use `Skill(curating-the-strategy-ideas-backlog)`; for the team-tech-lead-as-contributor framing (filing well, driving passes to a Staff+ owner) use `Skill(contributing-to-technical-strategy)` in `bitwarden-tech-lead`.

## The Shepherding Model

Per the TSI page, every idea in active status has two Architecture-side roles assigned:

- **Primary Owner.** Drives the idea through the pipeline. Writes the problem statement, conducts research, presents at Architecture Council, shepherds the transition to the funnel. Accountable for progress. **This is you when invoking this skill.**
- **Peer Reviewer.** A second Architecture engineer who acts as a sounding board, stays informed on the idea's progress, and provides a constructive challenge function. Not a co-owner — their job is asking the hard questions, catching cross-initiative conflicts, and ensuring stakeholder engagement is thorough.

The pairing matters. The TSI page is explicit: "No single engineer should carry more than two active reviewer assignments at a time, primary or peer." If you are taking on a Primary Owner role and already have two active assignments, surface that — overloaded review defeats its purpose and stalls ideas you've nominally taken on but can't actually drive.

## The Arc: From Thesis to Funnel Intake

Roughly:

1. **Capture.** File the ARCH idea with a lightweight first pass — Problem / Opportunity Statement, Strategic Alignment, rough RICE, theme, customer segments, roadmap placement.
2. **Pair.** Get a peer reviewer assigned. Begin sharing progress with them at the biweekly architecture working session.
3. **Sharpen with peer review.** Together complete the **Stakeholder & Engagement Map** before the idea moves from Backlog to Research. This is the gate.
4. **Research.** Refine the Problem Statement, run stakeholder conversations using the engagement approaches you committed to, surface findings.
5. **Present at Architecture Council.** The peer reviewer attends as informed ally.
6. **Earn intake at quarterly prioritization.** Engineering leadership decides whether this idea enters the funnel — and on what roadmap timing.
7. **Transition to the funnel.** Create the BW Initiative, link it back to the ARCH idea, update statuses, and hand off to `Skill(shepherding-an-initiative)` for the funnel arc.

After implementation completes on the funnel side, you and the peer reviewer run an **Adoption Retrospective** focused on influence effectiveness. That comes back here, not to the funnel skills — see the bottom of this skill.

## Filing the Idea (Capture)

The TSI template lives in JPD under the `ARCH` project. The most-load-bearing sections for the Primary Owner are:

- **Problem / Opportunity Statement.** Be specific about current state, pain, and opportunity. The TSI page's example bar: "Five different error handling patterns exist across clients, causing debugging difficulty and user confusion" — not "Error handling is inconsistent." Quantify wherever possible.
- **Strategic Alignment.** Which OKRs, themes, or architectural principles does this support? Which other initiatives does it depend on or enable?
- **Proposed Direction.** Conceptual approach only. Don't design the solution — that comes during funnel Research. Build vs. buy vs. integrate at the rough level.
- **Operational & Quality Considerations.** Key metrics / SLIs, performance constraints, testability, self-hosted vs. cloud, compliance touchpoints.
- **Validation Approach.** What a minimal PoC would look like, success signals, assumptions to test.
- **Rough Sizing.** T-shirt, expected duration, complexity factors.
- **RICE.** Honest. Confidence is what it is — inflating it produces a backlog that lies. The TSI page's RICE scoring page documents the rubric.

You can file with `Skill(contributing-to-technical-strategy)` in `bitwarden-tech-lead` as a reference for template mechanics. That skill is the contributor-side framing; everything past filing — pairing, mapping, sharpening, presenting, prioritizing — is this skill's territory.

## The Stakeholder & Engagement Map (the Research Gate)

The single highest-leverage thing this skill does well. Per the TSI page, ideas do not advance from Backlog to Research without a complete map, jointly completed by Primary Owner and Peer Reviewer. The map has five fields:

- **Decision makers.** Specific people or roles — not just team names — and the aspect each has authority over. "VP Engineering for resource allocation; SRE Lead for operational ownership."
- **Must consult.** People with expertise or context that will _materially affect direction_. Input sought during Research, not after. Distinguishing must-consult from must-inform is what stops ideas from being shaped in a vacuum.
- **Must inform.** People affected by the outcome who need to stay aware. They shouldn't be surprised when the initiative reaches them.
- **Known friction points.** Where disagreement, resistance, or competing priorities will come from. Honest. Named. _Before_ Research starts. The TSI page is explicit: "Naming friction upfront is how good ideas avoid becoming technically sound proposals that stall at adoption." This is the field where Primary Owners are most tempted to soften. Resist.
- **Engagement approach.** How each group will be engaged. The TSI page lists the menu: 1:1 conversations, RFC-style Confluence review, Architecture Council presentation, attending a team sprint review, async Confluence review. Match the approach to the stakeholder's communication style and the sensitivity of the topic.

Two questions the Peer Reviewer should be pushing on, and you should be pushing yourself on first:

- **Have we named the friction we already know about?** "We expect resistance from Team X because Y" is a more credible idea than one that presents only the upside.
- **Is the engagement approach honest about influence?** If the map says "RFC for Platform team" but you actually need a 1:1 with the Platform tech lead before the RFC has any chance of getting reviewed, name that.

The map is also a living document. As Research surfaces new stakeholders or friction, update it. The Adoption Retrospective at the end of the arc will ask whether the map was accurate — write it to be checkable later.

## Refining Through Research (Pre-Funnel)

The TSI Research phase is lighter than the funnel's Research phase — you are _not_ yet producing an Architectural Assessment. You are sharpening understanding enough that the idea is ready to be presented and prioritized.

- **Refine the Problem / Opportunity Statement.** Update as evidence accumulates. The version that goes to Architecture Council should be sharper than the version that was filed.
- **Run the engagement approaches you committed to.** 1:1s, RFC reviews, attending team sprint reviews. Each conversation usually surfaces something the map didn't predict — update the map.
- **Share progress with the peer reviewer** at the biweekly architecture working session. The Peer Reviewer's job here is to ask the questions you've stopped asking yourself.
- **Update RICE.** As Confidence sharpens, the score should change. An honest dropping Confidence often signals "needs PoC before commitment" — which is fine; that's what Research, then PoC, are for.

## Presenting at Architecture Council

When the idea is ready — map complete, problem statement sharp, friction acknowledged, engagement approach validated