/coordinating-implementation-across-teams

name: coordinating-implementation-across-teams
description: Phase 5 (Implementation) deep-dive playbook — shepherd coordinates teams executing the initiative across the support period, pulse check, retrospective, and closure.
when_to_use: Use when an initiative is in active execution and the shepherd is coordinating, not implementing. Triggers — "support period", "early PR review for drift", "monthly stakeholder update", "Adoption Retrospective", "closing out the initiative". Not for Phase 4 scoping (use `scoping-and-handing-off-to-teams`).
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

Phase 5 (Implementation) deep-dive playbook for an initiative shepherd. **You are not doing the implementation.** You enable teams, maintain consistency, ensure the initiative completes, and step back when it does. Time budget: 2–6 months wall clock, 10–20 hours/month of shepherd time. Composes `Skill(running-work-transitions)` in `bitwarden-delivery-tools` for the originating-side Support Period, Pulse Check, Retrospective, and Closure phases of the [Work Transition Playbook](https://bitwarden.atlassian.net/wiki/spaces/EN/pages/2521038855).

The funnel doc's mental model:

> **Think of the shepherd as:** > > - A guide ensuring teams stay aligned with the initiative's vision > - A coordinator managing cross-team dependencies and communication > - A subject matter expert available for questions about the approach > - A reporter keeping leadership informed of progress > - _Not_ a project manager micromanaging day-to-day work > - _Not_ doing code reviews on every PR (unless specifically needed for approach validation)

Establishing Communication Channels (Before Implementation Starts)

Set up the coordination mechanisms before teams begin. The funnel doc specifies:

• **Optional dedicated Slack channel** (e.g., `#initiative-typescript-migration`). Pin links to: PoC PR, ADR, architecture plan, Jira dashboard. Use for questions, blockers, and learnings across teams.
• **Bi-weekly tech-leads sync** with all affected tech leads. 30–45 minutes. Round-robin: progress, blockers, questions, cross-team dependencies.
• **Optional office hours** (1–2 hours per week for drop-in questions) or use the company-wide office hours.
• **Monthly stakeholder-sync update** for engineering and architecture leadership — 15 min, status / completion percentage / risks / decisions needed.

Set response-time expectations explicitly when you announce the channel: "Questions in Slack — aim for 1 business day response. Architecture concerns — same day."

Kickoff Meeting

When teams are ready to begin (capacity allocated, stories in sprint planning), host a 1-hour kickoff with all teams. Per the funnel doc:

• **Recap the initiative.** Problem, solution, PoC results — for engineers who weren't in handoff meetings.
• **Walk through the approach** and key patterns. The PoC PR is the best teaching artifact you have.
• **Review cross-team dependencies.** Make them visible so teams know who they wait on and who waits on them.
• **Introduce communication channels and cadence.** What to use where; what response time to expect.
• **Answer questions and address concerns.**
• **Celebrate the start.**

Share a resources package in the Slack channel: PoC PR, ADR, architecture plan, FAQ (start empty), your availability and response time.

Supporting Teams During Execution

Four activities, per the funnel doc:

1. Answer Questions

• Respond in the Slack channel within ~1 business day.
• Jump on Meets when text doesn't suffice.
• Clarify edge cases or scenarios the PoC didn't cover.
• Provide examples or references to similar implementations.

2. Review for Consistency (Not Detailed Code Review)

This is the most-violated rule of Phase 5. The funnel doc is unambiguous: **"Trust teams for detailed code review – only intervene for approach issues."**

• Monitor PRs related to the initiative.
• Review **the approach in early PRs from each team** to ensure alignment with the PoC pattern.
• Provide feedback only on approach deviation, not on style, naming, test coverage, or anything else the team's own reviewers handle.
• The funnel doc's example pattern: "This looks good but uses callbacks instead of the async/await pattern from the PoC — was that intentional?"

The "Not a reviewer for the team's PRs" line from `navigating-the-initiative-funnel` applies symmetrically here: tech leads expect you not to be their team's code reviewer. Respect it.

3. Troubleshoot Unexpected Issues

When teams hit problems the planning didn't anticipate:

• Help diagnose: implementation issue, or approach issue?
• For approach issues, escalate to Architecture Council if fundamental adjustment is needed.
• Document solutions in the FAQ so other teams can learn.

4. Unblock Dependencies

• Track which teams are waiting on others (via the dashboard and the bi-weekly sync).
• Coordinate communication between dependent teams.
• Escalate to engineering leadership when blockers can't be resolved at the team level.
• Adjust sequencing if the original plan proves problematic.

Maintaining Cross-Team Consistency

The funnel doc calls this "one of the shepherd's most critical responsibilities." Four sub-activities:

• **Early detection of divergence.** Notice when teams interpret the pattern differently. Spot legitimate variation vs. misunderstanding. Rev