coordinating-implementation-across-teams

What this skill does

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. Review 1–2 early PRs per team to catch issues before they multiply.
- **Share learnings across teams.** Post in Slack when one team solves a common problem. Update the FAQ as patterns emerge. Call out good examples: "Team X's PR #567 shows a clean way to handle this edge case."
- **Refine guidance when needed.** If teams consistently struggle, the guidance may need improvement. Update the architecture plan or create supplementary guides. Host ad-hoc working sessions if multiple teams hit the same issue.
- **Make judgment calls on acceptable variation.** Some variation is appropriate based on context (e.g., "Mobile apps use variation A because of platform constraints; web should use the standard pattern"). Some variation is drift that undermines consistency. Document the calls.

## Tracking and Reporting Progress

The funnel doc specifies multiple cadences:

### Weekly (Your Internal Tracking)

- Review Jira dashboard: completed, in progress, blocked.
- Check the Slack channel for unresolved questions or concerns.
- Note risks or trends (e.g., multiple teams reporting the same issue).

### Bi-Weekly Tech-Leads Sync

- 30–45 minute meeting with tech leads from all affected teams.
- Round-robin update: progress, blockers, questions.
- Coordinate on dependencies.
- Identify needs for Architecture Council input.

### Monthly Leadership Update

15-minute slot in a stakeholder sync. Cover:

- **Status:** on track / at risk / blocked.
- **Completion percentage** (stories done / total stories).
- **Revised timeline** if needed.
- **Escalations** or decisions needed.

Example phrasing from the funnel doc:

> "TypeScript migration 60% complete, 3 of 6 teams finished their epics. Vault team delayed 2 weeks due to higher priority security fix. Still on track for Q3 completion."

### Celebrating Milestones

- First team completes its epic — recognition in Slack / team meeting.
- 50% completion — update in company all-hands.
- Last PR merged — celebrate with everyone involved.

## Managing Documentation

Documentation should not wait until the end. Per the funnel doc:

- **Draft early.** Create documentation structure (outline / skeleton) as Implementation starts.
- **Add content progressively.** As patterns stabilize and teams produce real implementations, add to the docs.
- **Have teams contribute examples** from their own implementations.

Documentation lands in two homes per [Documentation Patterns](https://bitwarden.atlassian.net/wiki/spaces/EN/pages/1774977070). What goes where:

**Close-to-code (alongside the team's code, in the repository):**

- **Framework / pattern `README.md`** updates as the pattern stabilizes across teams. The PoC's initial framework README evolves with what teams discover during rollout.
- **Folder-level notes** in each team's adopted area pointing to the framework README and the ADR.
- **Inline docs** (JSDoc/XML comments for TypeScript/Angular/.NET; `rustdoc` for Rust) per the per-stack rubric in Documentation Patterns.
- **CLAUDE.md updates** at the root and folder levels where the new pattern changes how engineers (and Claude tooling) should work. Use `@` syntax to link the `README.md` files that carry the canonical pattern.

**Centraliz