Handbook
Team rollout patterns
Patterns for introducing Blueprints after one person has a working first-hour layout — not a full change-management program. Scale the formality to your org: a single team needs fewer artifacts than a platform…
What it is
Patterns for introducing Blueprints after one person has a working first-hour layout — not a full change-management program. Scale the formality to your org: a single team needs fewer artifacts than a platform coordinating many repos.
When to use it
Use this page when more than one repo or squad needs the same vocabulary (phases, ceremonies, discipline bridges).
Prerequisites
- Adopting Blueprints path B or C is a rough match.
- At least one repo has
blueprints/, projectsdlc/, and optionallyforge/in place (Project setup checklist).
Rollout by scale (chooser)
| Scale | Primary audience | Deep dive |
|---|---|---|
| Single team | Tech lead + ICs | Single-team rollout |
| Multi-team | Chapter or org with several products | Multi-team rollout |
| Platform / org | Enablement or architecture | Platform playbook for Blueprints across many repos |
| Governance | Phased rollout, office hours, risks | Governance cadence |
Rollout scale (visual)
Formality and coordination increase as you move from one team to many repos and platform governance — pick the row that matches your scope, then read that child page.
How to verify success
- Teams can explain where baseline text lives (
blueprints/) vs their interpretations (sdlc/,docs/). - New repos reach the same verify steps as Project setup checklist without one-off forks of upstream.
What to do next
- Troubleshooting and FAQ
- Advanced customization — safe extension points in the consumer repo