/contributing-to-technical-strategy

name: contributing-to-technical-strategy
description: How team-level patterns flow up into Bitwarden's Technical Strategy Ideas backlog and back down through BW Initiatives into team epics and stories. Covers recognizing which team-level patterns belong in the TSI backlog, framing an idea well enough for Architecture to evaluate it, the ARCH idea ↔ BW Initiative linkage, and defining epic-level and story-level work downward from an initiative. Use when noticing a cross-team pattern of pain that exceeds one team's scope, when surfacing ideas to the architecture group, when understanding how an initiative connects back to its originating idea, or when breaking epic-level work out of an initiative onto a team.
allowed-tools: Skill, 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's technical strategy has a vertical shape: ideas live at the top, initiatives in the middle, and team-level epics and stories at the bottom. The tech lead is the role that spans the vertical — noticing the patterns at the bottom that belong at the top, and translating the work at the top back down into stories the team ships.

This skill covers that full vertical:

• Recognizing an idea worth capturing.
• Framing it well enough for Architecture to evaluate.
• Understanding how an approved idea becomes a BW Initiative.
• Defining epic-level and story-level work downward from an initiative.

The canonical references are [Technical Strategy Ideas](https://bitwarden.atlassian.net/wiki/spaces/EN/pages/2344517656) and [Idea-Based Initiatives](https://bitwarden.atlassian.net/wiki/spaces/EN/pages/2785181779). Fetch them via `get_confluence_page` when the full templates or the complete field definitions are needed.

The Top of the Funnel: Technical Strategy Ideas

Technical Strategy Ideas (TSIs) are Bitwarden's **idea backlog** — the curated collection of technical improvement opportunities that Architecture maintains in Jira Product Discovery under the `ARCH` project. Ideas get RICE-scored, categorized by theme, and placed on a Now / Next / Later roadmap. The ones that get prioritized enter the Software Initiative Funnel at Identification.

Recognizing an Idea Worth Capturing

Create a TSI when these patterns appear:

• **A pattern of pain across multiple teams.** Five teams are each solving the same error-handling problem differently. That's not five team-level problems; it's one cross-team idea.
• **An architectural gap or tech debt with broad impact.** The debt exists in shared code, or its absence is blocking other teams.
• **An opportunity to improve developer experience or operational reliability** at a level that a single team can't own.
• **A technology trend Bitwarden should evaluate** — not "we should use GraphQL because it's modern," but "REST's round-trip cost is quantifiable here and here, and the alternatives warrant evaluation."
• **A security improvement that spans multiple systems.**

Stay in-team (and create nothing) when:

• The problem is contained to a single team's codebase and that team can solve it in normal work.
• The problem is urgent and requires immediate action — those bypass this process; talk to leadership directly.
• It's a product-driven feature request — that belongs in product backlogs, not TSIs.

Staff+ engineers are the primary contributors to TSIs, but tech leads absolutely can and should contribute ideas sourced from their teams' experience. The patterns surfacing across sprints are signal Architecture often doesn't have direct access to.

Framing an Idea Well

A TSI doesn't require a full architectural proposal. It does require enough context for Architecture to evaluate whether it's worth research. The TSI template has several sections — the ones that matter most:

• **Problem / Opportunity Statement.** Be specific about the current state, the pain points, and the opportunity if solved. "Error handling is inconsistent" is vague; "Five different error handling patterns exist across clients, causing debugging difficulty and user confusion" is actionable. Quantify where possible — "~3 bugs per quarter tied to this" or "~4 hours per sprint lost to this" makes impact concrete.
• **Strategic Alignment.** Which OKRs, strategic themes, or architectural principles does this support? What other initiatives does it depend on or enable?
• **Target Audience / Stakeholders.** Teams, users, or systems that benefit; others affected; teams with expertise to consult.
• **Stakeholder & Engagement Map.** This is where ideas frequently stall if done poorly. Identify decision makers by name or role (not just team names), must-consult stakeholders, must-inform stakeholders, and — this is the uncomfortable one — **known friction points**: where will disagreement or resistance come from, and why? Naming friction upfront is how good ideas avoid becoming technically sound proposals that stall at adoption. Ideas that acknowledge friction earn more trust than ones that present only the upside.
• **Proposed Direction.** High-level only — don't design the solution. That's for funnel research. Rough conceptual approach, technologies worth considering, build/buy/integrate thinking.
• **Operational & Quality Considerations.** Key metrics or SLIs, performance constraints, testability implications, self-hosted vs. cloud implications, compliance touchpoints (SOC 2, ISO 27001).
• **Validation Approach.** What a mini