shepherding-an-initiative

What this skill does

End-to-end umbrella playbook for an initiative shepherd, covering all five phases of the [Software Initiative Funnel](https://bitwarden.atlassian.net/wiki/spaces/EN/pages/584515614): Identification → Research → Proof of Concept → Scoping & Commitment → Implementation. Maps each phase's effort, deliverables, and decision gate; holds the line on what the shepherd produces vs. what gets handed to teams. Fetch the canonical funnel page via `get_confluence_page` when entry/exit criteria or full template detail is needed.

## The Rule of Ownership (Hold Throughout)

**You own the initiative. Each receiving team owns how it executes its part.**

Every phase has a single sentence to remember: when you start writing the team's stories, the team won't own the work. When you stop coordinating across teams, the initiative drifts. Both failures are yours to prevent.

For the agent-neutral, team-side view of the same boundary (the version tech leads read), invoke `Skill(navigating-the-initiative-funnel)` in `bitwarden-delivery-tools`. Reading both perspectives keeps you honest about where the line actually sits.

## Time and Effort Expectations

The funnel page sets these benchmarks. They're not aspirational — they're the basis for capacity planning when leadership asks "what does it cost to shepherd this?"

| Phase                    | Duration   | Shepherd Effort   | Decision Maker                        |
| ------------------------ | ---------- | ----------------- | ------------------------------------- |
| 1 — Identification       | ~1 week    | 4–8 hours         | Holistic engineering leadership       |
| 2 — Research             | 3–5 weeks  | 40–80 hours       | Eng leadership + Architecture Council |
| 3 — Proof of Concept     | 2–4 weeks  | 40–80 hours       | Eng leadership + Architecture Council |
| 4 — Scoping & Commitment | 2–4 weeks  | 30–50 hours       | Engineering leadership (Director+)    |
| 5 — Implementation       | 2–6 months | 10–20 hours/month | Teams execute; shepherd coordinates   |

Total: 150–300 hours of shepherd time over 4–9 months for a medium initiative — roughly 5–10% of one person's time with higher concentration in Research and PoC.

## Phase-by-Phase: What the Shepherd Does

### Phase 1 — Identification

**Purpose:** Capture enough context for meaningful evaluation without premature commitment of resources.

**You produce:**

- A BW Initiative issue under the Bitwarden Company (BW) project. Type: Initiative. Assignee: you (the proposed shepherd). Reporter: whoever surfaced the problem. Priority: a placeholder ("TBD - Awaiting Research" or Medium).
- A description distilled from the upstream ARCH idea (if one exists) into an executive-readable summary — not a copy of the full TSI template. Pattern, link inventory, and field-by-field guidance live in [Idea-Based Initiatives](https://bitwarden.atlassian.net/wiki/spaces/EN/pages/2785181779).
- A **work item link** from the ARCH idea (in Jira Product Discovery) to the BW initiative. This is the foundational traceability link — every idea-based initiative must have one.
- Initial "Relates to" links: prior attempts, adjacent SRE/BRE/TSD/PM tickets, anything the ARCH idea's own research surfaced.
- An ARCH idea status update to "1️⃣ Identification" in JPD.

**Decision gate:** Holistic engineering leadership decides Proceed / Hold / Decline.

**What you do NOT do:** Pre-scope the solution. Research hasn't happened yet. Resist the urge to come in with an answer.

### Phase 2 — Research

**Purpose:** Deeply understand the problem space and explore potential solutions before committing to direction.

**You produce:**

- 3–5 stakeholder interviews (the affected teams' tech leads are likely subjects).
- A current-state analysis surveying existing implementations across the codebase — inconsistencies, workarounds, technical debt — with impact quantified where possible.
- 2–4 documented solution approaches with explicit trade-offs.
- An **Architectural Assessment** in Confluence under the EN-space assessments folder, refined through stakeholder review.
- Optional preview at Architecture Council for major initiatives.
- ARCH idea status updated to "2️⃣ Research".

**Decision gate:** Engineering leadership with Architecture Council input. Proceed to PoC / Continue Research / Hold / Decline.

**Deep skill:** `Skill(running-an-architectural-assessment)` for stakeholder interview structure, current-state analysis, options generation, and the Architectural Assessment template.

### Phase 3 — Proof of Concept

**Purpose:** Validate the recommended solution works in practice within Bitwarden's codebase before committing to full implementation. Reduce risk through hands-on experimentation.

**You produce:**

- A PoC area chosen in coordination with the owning team's tech lead — representative but contained (~1–5 files or one module).
- The framework or foundation that broader rollout will reuse, plus 1–3 production-quality example implementations.
- One or more PRs (may or may not be merged; mark "PoC" in title if not).
- An Architecture Council walkthrough — 15–30 minutes, with the PoC PR, the findings (what worked, what didn't, what would need to change), and the proposed direction.
- A **draft ADR** (status: Proposed) following the [Bitwarden ADR template](https://contributing.bitwarden.com/architecture/adr/). ADRs live in the centralized [`bitwarden/contributing-docs`](https://github.com/bitwarden/contributing-docs) repository under `docs/architecture/adr/` — there is no per-repo ADR directory.
- **Close-to-code documentation** for the framework and example implementations (per [Documentation Patterns](https://bitwarden.atlassian.net/wiki/spaces/EN/pages/1774977070)) — a `README.md` alongside the framework code, folder-level notes near examples, and CLAUDE.md updates where new patterns are introduced. The deep skill covers what each home (close-to-code vs. centralized `contributing-docs`) is for.
- ARCH idea status updated to "3️⃣ Proof of Concept".

**Decision gate:** Engineering leadership with Architecture Council recommendation. Proceed to Scoping / Revise PoC / Return to Research / Decline.

**Deep skill:** `Skill(running-a-proof-of-concept)` for PoC area selection, building the framework, Architecture Council prep, and ADR drafting.

### Phase 4 — Scoping & Commitment

**Purpose:** Transform a validated PoC into a concrete implementation plan with effort estimates, team assignments, and executive commitment.

**You produce:**

- A **High-Level Architecture Plan** in Confluence under the EN-space planning folder: scope, approach (phasing, migration path), team alignment, dependencies, risk mitigation, success metrics, documentation plan.
- Child epics under the BW initiative — typically one per team or major module. Each epic carries its area of the codebase, the PoC PR reference, expected outcomes, and success criteria.
- A scheduled **handoff meeting** with each receiving team (1 hour per team, structured 20/15/15/10): 20 min present, 15 min Q&A, 15 min team's initial breakdown thinking, 10 min commit to a breakdown date.
- A cost/benefit analysis documented in the architecture plan.
- An initiative priority (Critical / High / Medium / Low) updated on the BW initiative.
- A leadership presentation seeking explicit go/no-go with capacity commitment.
- **Operational prioritization** with engineering leadership: target start date, quarter, relative priority against teams' other commitments, sprint capacity allocation.
- A finalized ADR (status: Accepted) with timeline.
- ARCH idea status updated to "4️⃣ Scoping & Commitment".

**Decision gate:** VP of Engineering / CTO. Proceed to Implementation / Rescope / Defer / Decline.

**Critical anti-pattern:** You writing the team's stories. The team does the breakdown — not you. You review breakdowns for consistency with the initiative's vision, not to rewrite stories.

**Deep skill:** `Skill(scoping-and-handing-off-to-teams)`. The Phase 4→5 handoff