/navigating-the-initiative-funnel

name: navigating-the-initiative-funnel
description: Phase-by-phase guidance for participating in Bitwarden's Software Initiative Funnel. Covers shepherd vs tech-lead ownership, running an epic breakdown after Scoping & Commitment handoff, sizing, cross-team dependency tracking, and escalation paths that protect team autonomy. Use when receiving an initiative epic, participating in an Architectural Assessment or PoC, preparing the Scoping & Commitment breakdown, or surfacing concerns to the shepherd or engineering leadership.
allowed-tools: Read, Skill, Bash(git clone https://github.com/bitwarden/tech-breakdowns*), Bash(git clone git@github.com:bitwarden/tech-breakdowns*), mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue_comments, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue_remote_links, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__search_issues, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_confluence_page, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_confluence_page_comments, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__search_confluence, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__search_confluence_cql

Bitwarden runs cross-cutting technical work through the [Software Initiative Funnel](https://bitwarden.atlassian.net/wiki/spaces/EN/pages/584515614). A senior engineer — typically Staff+ for cross-team initiatives, sometimes a tech lead for smaller-scope work that lives largely inside one team's domain — shepherds each initiative through five phases: Identification, Research, Proof of Concept, Scoping & Commitment, and Implementation. The tech lead participates throughout, but most heavily in Scoping & Commitment and Implementation. This skill is the working playbook for that participation, written from the perspective of a tech lead working alongside a separate shepherd; when the tech lead is also shepherding the initiative, read the phase descriptions for both roles and run both. When the canonical reference is needed, fetch the funnel page via the `get_confluence_page` MCP tool; this document is the operating summary.

The Rule of Ownership

Every phase has a single sentence to remember: **the shepherd owns the initiative; the tech lead owns how their team executes its part**. The moment that line blurs, one of two failure modes shows up — either the shepherd starts writing the team's stories (and the team doesn't own the work), or the tech lead starts making cross-team decisions that aren't theirs to make (and the initiative drifts).

Phase-by-Phase: Who Does What

Phase 1 — Identification

The shepherd creates a BW Initiative issue, documents the problem, and gets a go/no-go from engineering leadership.

**The tech lead's role is light here.** If the shepherd reaches out because the team's domain is affected, provide context, known history, and stakeholders. Flag prior attempts. Don't pre-scope — the research hasn't happened yet.

Phase 2 — Research

The shepherd interviews stakeholders (the tech lead is a likely one), surveys the codebase, and produces an Architectural Assessment with 2–4 solution options.

**The tech lead's role:** be interviewed well. Share the team's pain points, workarounds, and the constraints the shepherd won't see from outside. Quantify where possible ("this causes ~3 bugs per sprint"). If the shepherd proposes a direction that would conflict with work already on the team's roadmap, surface it now — not after commitment.

Phase 3 — Proof of Concept

The shepherd picks a PoC area (sometimes in the team's codebase), builds a framework or example, presents to Architecture Council, and drafts an ADR.

**The tech lead's role if the PoC lands in the team's codebase:** assign a point-of-contact on the team to pair with the shepherd or review their PRs. Be a collaborator, not a gate. The PoC is meant to test feasibility in real code — if it's cutting corners, that's a signal worth surfacing, but don't treat the PoC PR like a production review. Surface concerns about the approach to the shepherd directly; don't quietly ship workarounds.

Phase 4 — Scoping & Commitment

This is the phase where the most rides on the tech lead's participation. The shepherd creates child epics under the BW initiative (typically one per team or major module), writes epic descriptions, and schedules handoff meetings. Then **the team owns the breakdown**.

The shepherd brings to the handoff: the PoC findings, the architecture plan section relevant to the team, the success criteria, and time for Q&A. The tech lead brings: questions, a realistic read on how this fits the team's existing roadmap, and a commitment date for the breakdown itself.

After the handoff, run a team breakdown session. The team creates the stories — not the shepherd. Apply the funnel's story-quality rules:

• **Be specific.** "Migrate user-service error handling to new pattern" beats "update error handling."
• **Write acceptance criteria** that define done. Reference the PoC PR or architecture plan for the technical approach.
• **Note dependencies** — especially cross-team ones. Those feed back to the shepherd for coordination.
• **Assign to the team, not to individuals.** Individuals come during sprint planning.
• **Label for filtering** (e.g. `initiative-typescript-migration`) so the shepherd's dashboard can track progress.
• **Size with the team's normal process.** Don't invent a new estimation method for initiative work.

When the breakdown is done, share it back with the shepherd. They review for consistency with the initiative's vision, not to rewrite stories or micromanage. Expect questions like "this looks good but uses callbacks instead of the async/await pattern from the PoC — was that intentional?" That's the shepherd doing their job. The tech lead's job is to have a good answer.

**The Te