/running-work-transitions

name: running-work-transitions
description: Six-phase playbook for running ownership transitions in either direction — receiving work from another team (initiative handoffs from shepherds, frameworks from Platform, operational responsibilities from SRE), or originating a transition (handing off a built framework, transitioning a shepherded initiative, or moving operational responsibilities). Applies Bitwarden's Work Transition Playbook from whichever side a team is on. Use when a team is about to take on or hand off transferred work, when preparing materials or sessions, when the support period is underway, or when running a pulse check or retrospective on a handoff.
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 uses a [Work Transition Playbook](https://bitwarden.atlassian.net/wiki/spaces/EN/pages/2521038855) to move ownership of logic, patterns, tooling, or processes between teams. The most common trigger is Phase 4 → 5 of an initiative: a shepherd has finished Scoping & Commitment and a team is about to own implementation. But the playbook is general — Platform might hand a framework to a product team, SRE might hand over a runbook, another product team might transfer an integration they no longer own. Same playbook applies in any direction.

This skill covers both sides of a transition. It complements `Skill(navigating-the-initiative-funnel)`, which covers the funnel mechanics more broadly.

What "Transition" Actually Means

Read this line from the playbook and make sure both teams act on it: **a successful transition is not the moment documentation is shared or a meeting is held — it is the moment the receiving team is confidently operating independently with the transferred work**.

Everything in the six phases below is in service of that outcome. Sessions, documentation, and pulse checks are instruments, not the goal.

Which Side?

• **Receiving side.** Another team is handing work over. The receiving team is typically represented by a named primary point of contact (the playbook calls this out explicitly — "typically a tech lead or senior engineer"). The job is to evaluate what's being handed over, prepare the team to absorb it, and make the support period efficient.
• **Originating side.** A team is handing work to another team. This is the case when a team built a framework or pattern intended for adoption by other teams, when it has shepherded a smaller-scope initiative through to implementation by another team, or when operational responsibilities are shifting. The job is to prepare materials that make the receiving team self-sufficient and to support — not lead — once they've taken over.

The phases are the same on both sides; the responsibilities differ. Read both sections when participants will be on both sides at different points in the same effort (common when shepherding a single-team-adjacent initiative).

The Six Phases, From the Receiving Side

Phase 1 — Preparation

Before any transition session is scheduled, the originating team prepares materials. The receiving team's job is to evaluate those materials before accepting the transition.

Things to confirm:

• **Documentation is adequate.** A competent engineer on the receiving team should be able to take the docs and work with the material independently. If the docs are thin, push back — don't accept a transition the team can't sustain.
• **Jira is legible.** Epics have descriptive summaries. Stories exist at a level of detail the receiving team can refine further — not so specific that the team is handed a pre-written sprint plan, not so vague that the team has to re-research the scope.
• **Stakeholders and points of contact are identified.** The receiving team knows who from the originating side carries context that may be needed during the support period. The receiving team also knows which adjacent stakeholders (leadership, PMs, other teams) will care about progress.
• **A named primary POC is in place on the receiving side** (usually the tech lead, sometimes a senior engineer). The EM is aware and supportive.
• **Post-handoff effort is evaluated honestly.** Transitions that only plan for "adopting the new thing" underestimate the true cost. Evaluate three axes explicitly:
• **Implementation and integration.** What effort is required to put the transferred work into practice in the receiving team's domain? Adapting patterns, wiring integrations, writing tests, updating workflows.
• **Phasing out old processes and code.** If the new work replaces something that already exists, decommissioning that thing is its own scope. The receiving team usually has the deepest knowledge of what the old approach actually does in practice — use it.
• **Ongoing maintenance and bug fixes.** Once the support period ends, who owns what? For most transitions, the receiving team owns everything it adopted. For shared frameworks or libraries, the originating team may retain some maintenance — confirm explicitly where the ownership boundary sits.

If any of those are unclear, name it now. The preparation phase is where gaps are cheapest to fill.

Phase 2 — Transition Sessions

At least two sessions, spaced 1–2 weeks apart. The receiving team's job is to show up prepared and come back with sharper questions the second time.

• **Session 1 (context and approach).** Review the documentation before the