running-work-transitions

What this skill does

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 session — ideally a few business days in advance. In the session: understand the problem being solved, why this approach was chosen, walk the PoC or framework, understand how the work fits into the broader initiative. Open Q&A. This session is mostly listening.
- **Session 2 (hands-on and planning).** By now the receiving team should have spent time with the code or tooling. Bring the questions that only emerge from reading the actual implementation. Discuss how the team will integrate, extend, or schedule the work. Surface gaps in the documentation. Agree on what the support period looks like.

Additional sessions are warranted for complex or high-stakes transitions. Both sides decide at the end of Session 2 whether more are needed.

### Phase 3 — Support Period

After the sessions, the originating team stays available — but shifts from leading to supporting. Typical duration: 4–8 weeks, proportional to complexity.

What to use the originating team for:

- Approach questions, intent, and edge cases that documentation doesn't cover.
- Early-PR alignment review — they catch misalignment with the intended pattern while it's cheap to correct.
- Evaluating options if a production reality suggests the original approach needs adjustment.

What not to use them for:

- Gatekeeping the receiving team's work. They're advisors, not approvers.
- Doing the work for the receiving team. A transition is a transfer, not a loaner.

A critical framing from the playbook: **a completed transition does not mean the receiving team will begin work immediately**. The transferred work competes with the team's existing priorities — product roadmap commitments, other initiatives, bugs, tech debt. A delay between handoff and active work is normal and expected.

**What is not normal:** the originating team quietly resuming the work because the receiving team hasn't prioritized it. That's a leadership conversation — between both teams and engineering leadership — not a workaround. The funnel's Scoping & Commitment phase is where executive capacity is allocated; if that commitment isn't translating into prioritized work, escalate rather than let the originating team fill the gap.

### Phase 4 — Pulse Check (~30 days after transition)

A 15–30 minute conversation, or an async thread. This is the load-bearing checkpoint — it's where "we handed it off" gets prevented from becoming "it was never picked up."

Questions to cover:

- Has the receiving team begun working with the transferred material? If not, what's blocking the team?
- Are there unanswered questions, or areas where documentation proved insufficient?
- Is the team comfortable with the approach, or working around it in ways that suggest a mismatch?
- Does the support period need adjustment — extended or shortened?

If the team hasn't started at all, escalate — not punitively. Understand whether it's capacity, priority conflict, or a real gap in the transition. Unaddressed, this is where initiative work dies.

### Phase 5 — Retrospective (~90 days after transition)

A real meeting, 45–60 minutes, with both teams. Goals: assess adoption, give feedback on the transition process, capture lessons for future transitions.

Topics:

- **Adoption assessment.** Is the work being used as intended? Has the receiving team extended it? Are there areas of drift or no