Catalog

You Build It, You Run it

Description: “You build it, you run it” assigns ownership of both building and operating a service to the same team: developers are responsible for code, deployments, incident response, monitoring, and ongoing reliability. The pattern encourages teams to design for operability (observability, automation, runbooks, feature flags) and to treat production as part of the development lifecycle, which speeds feedback, improves quality, and reduces handoffs between dev and ops.

Positioning: This pattern sits between governance and automation but leans toward governance-driven ownership with strong automation enablers. It aligns teams by creating clear accountability for service health and shared operational standards (SLIs/SLOs, on-call responsibilities, postmortems), while automation (CI/CD, deployment tooling, alerting, auto-remediation) reduces toil and enforces practices at scale. It gives teams high freedom to choose implementation details but expects them to meet organizational reliability and support requirements; good implementations combine platform automation with clear governance and measurable operational targets.

Architecture Record

Description: An Architecture Record captures the key design decisions for a system — what was decided, why, alternatives considered, consequences, and who made the decision. It’s a short, living document (decision log or ADR) linked to code and tickets so teams understand architectural intent, reasoning, and constraints when making changes or integrating systems.

Positioning: Architecture Record sits on the governance side but leans toward lightweight process: it supports alignment by making decisions visible, reproducible, and discoverable, so teams avoid repeating debates or drifting from agreed constraints, while leaving teams freedom to propose new options if they document and agree them. Tooling (templates, ADR generators, links in repos) can automate creation and discovery, but human discussion and approval remain central to its value.

Tech Radar

Description: Tech Radar is a lightweight tool for tracking and communicating the organization’s stance on technologies, tools, and practices. It classifies items (e.g., Adopt, Trial, Assess, Hold), explains the reasoning, and highlights who owns decisions and next steps. By keeping a visible, regularly updated radar, teams can see what’s recommended, what’s experimental, and what to avoid, making technology choices faster and more consistent.

Positioning: Tech Radar sits on the governance side but leans toward guidance and transparency rather than enforcement. It supports alignment by creating a shared, evolving view of technology direction and risk, while preserving team freedom to experiment within the stated categories; automation (dashboards, publication pipelines) can keep the radar up to date, but the real value is in the people who review, debate, and update the recommendations.

Standard Stack

Description: Standard Stack defines a common, supported set of technologies, libraries, and configurations (frameworks, runtimes, CI templates, logging/metrics setup, deployment patterns) that teams are encouraged—or required—to use. It provides ready-made boilerplates, shared components, and clear upgrade/compatibility rules so teams start faster, avoid duplicated work, and produce systems that are easier to operate and integrate.

Positioning: Standard Stack sits between governance and automation and leans toward governance when mandated, toward automation when provided as self-service. As a governance tool it strongly aligns teams by reducing variability and simplifying cross-team work; as an automated offering (templates, SDKs, platform integration) it enforces patterns with minimal friction. The trade-off is less freedom for teams that need unusual tech—mitigate this by allowing extension points, approved exceptions, or a fast process to evolve the stack.

Advice is Enough

Description: Advice Is Enough is a decision-making pattern in which higher authorities, experts, or governance bodies provide guidance, considerations, or risks to watch for — but do not grant formal approval or take ownership of the decision. Instead of escalating choices upward, teams seek advice that highlights what is important to consider, then make the decision themselves. This shifts focus from permission to informed judgment: as long as teams meaningfully address the advisory points, their decision is considered valid. The pattern accelerates progress, reduces bottlenecks, and empowers teams while still ensuring they benefit from broader organizational experience and insight.

Positioning: Advice Is Enough leans strongly toward autonomy on the control–autonomy axis by decentralizing decision ownership and pushing accountability to the teams closest to the work. It still maintains a light form of governance by making expert advice an expected input, ensuring that decisions don’t ignore critical risks, constraints, or strategic context. There is little role for automation beyond surfacing advisors or capturing their input; the value is primarily human judgment and dialogue. The pattern’s strength lies in replacing gatekeeping with informed empowerment — ensuring alignment and quality through shared wisdom rather than approval authority.

Plattform-as-a-Service

Description: Platform-as-a-Service (PaaS) gives teams a ready-made, self-service platform that hides common infrastructure and operations (deployments, logging, metrics, secrets, runtimes). It provides opinionated templates, libraries, and APIs plus clear guardrails (quotas, supported runtimes, CI/CD patterns) so teams can build and run services reliably without managing every detail themselves.

Positioning: PaaS sits between governance and automation but leans toward automation: the platform enforces standards automatically (provisioning, policy-as-code, telemetry) so teams meet reliability and security requirements with little extra effort. That makes it strong at aligning teams, but it reduces freedom by restricting tools and runtimes. Good PaaS balances this by offering extension points, configurable tiers, or a simple exception process so teams can keep flexibility where they need it.

Shift-left

Description: Shift-left moves quality, security, and operational checks earlier in development — into design, coding, and CI — so issues are found and fixed sooner. It uses practices like unit tests, static analysis, threat modeling, feature flags, and short feedback loops so teams deliver more reliable software with lower cost of change.

Positioning: Shift-left sits between governance and automation but leans toward automation: CI pipelines, linters, SAST/DAST, and automated tests do most of the enforcement and fast feedback, while governance defines the standards and exception rules. That makes it effective at aligning teams around quality and security, yet it still leaves teams freedom in implementation choices as long as they meet the automated checks and policies.

Experimentation Budget

Description: Experimentation Budget sets aside time, money, or engineering cycles for pilots and learning (e.g., 10% time, hackweeks, or a small fund). It defines light rules — who can propose, size limits, hypotheses and success criteria, and how results are shared — so experiments produce usable learnings without disrupting delivery.

Positioning: Experimentation Budget is mainly a governance pattern with helpful automation: approvals, registries, and trackers can be automated, but alignment comes from rules and review practices. It supports team freedom to explore while keeping experiments visible and bounded so discoveries feed back into shared strategy.

Architecture Board

Description: An Architecture Board is a group of cross-functional senior engineers, architects, and stakeholders who review, advise on, and approve significant architectural decisions and cross-team initiatives. The board meets regularly (or on demand), evaluates proposals against system-wide concerns (scalability, security, interoperability, cost), records outcomes, and helps resolve disputes or conflicting roadmaps so architecture choices are visible and coordinated across the organization.

Positioning: The Architecture Board sits on the governance side and leans toward centralized coordination: it strengthens alignment by providing a single forum for system-wide decisions, preventing fragmentation and duplicate work, and ensuring shared constraints are respected. That centralization reduces team freedom where the board’s approvals are required, so effective boards keep processes lightweight (clear thresholds for when review is needed, fast turnarounds, and published criteria) and rely on advisory roles for lower-impact changes to preserve local autonomy.

KPI Dashboard

Description: A KPI Dashboard is a shared, visual display of the key metrics that matter for product, reliability, and business outcomes (usage, conversion, error rates, latency, SLOs, lead time, deployment frequency, churn, etc.). It aggregates data from monitoring, analytics, and CI/CD systems into clear, up-to-date panels and alerts so teams and stakeholders can quickly see health, trends, and the impact of changes. Dashboards make metrics actionable by linking to ownership, runbooks, and follow-up tasks.

Positioning: KPI Dashboards sit between governance and automation but lean toward automation: tooling collects and presents measurements automatically, enforcing a common view of success and surfacing misalignment fast. That strong automation supports alignment—everyone measures against the same numbers—but teams retain freedom in how they reach those targets. Governance defines which KPIs are required, their definitions, and reporting cadence; automation keeps the data current and visible, while culture and review processes drive interpretation and follow-up.

Product Teams

Description: A Product Team is a small, cross-functional group that owns a product or service end-to-end — product management, design, development, QA, and ops work together toward clear customer outcomes. The team is empowered to prioritize the backlog, deliver features, measure impact, and iterate quickly, reducing handoffs and improving focus on user value.

Positioning: Product Teams sit between governance and automation but lean toward governance-driven autonomy: they align by owning goals, KPIs, and responsibilities set by product strategy and organizational guardrails, while having freedom to choose how to achieve those goals. Automation (CI/CD, telemetry, templates) supports their work and enforces technical standards, but alignment comes from shared objectives, role clarity, and regular reviews rather than heavy technical enforcement.

System Teams

Description: A System/Toolsmith Team is a dedicated group that builds and maintains the internal platforms, developer tools, shared libraries, and operational automation other teams use (CI/CD pipelines, deployment tooling, observability components, internal SDKs, and self-service portals). They focus on reducing toil, standardizing repeatable work, and delivering reliable, well-documented tools so product teams can move faster without reinventing infrastructure.

Positioning: This pattern sits between governance and automation but leans strongly toward automation: the team produces automated capabilities that enforce standards and make compliance low-friction. It supports alignment by providing common, battle-tested implementations and clear contracts teams can rely on, while preserving product-team freedom by exposing flexible APIs, extension points, and clear escalation paths for new needs. Governance guides priorities, quality expectations, and support levels, but the toolsmith’s automation is what scales alignment in practice.

Shared Vision

Description: Shared Vision is a clear, communicated statement of the long-term goals, values, and success criteria that guides teams across the organization. It translates strategy into a few concrete outcomes and priorities (customer problems to solve, quality goals, market direction) so teams understand why they work on certain things and can make consistent trade-offs without constant coordination.

Positioning: Shared Vision sits on the governance side and leans toward guidance rather than enforcement: it strongly supports alignment by giving teams a common north star and decision filter, while preserving team freedom in how to achieve those goals. Automation can help distribute and track engagement (dashboards, OKR tools, newsletters), but the pattern’s power comes from leadership communication, storytelling, and regular reviews that keep the vision shared and actionable.

Exception Approval

Description: Exception Approval is the decision step and authorization that follows an Exception to Policy request — a formal, documented yes/no (often with conditions) that allows a team to temporarily deviate from a standard. It records who approved it, why, what compensating controls must be in place, the expiration or review date, and any monitoring or reporting required so the exception is visible, enforced, and revisited.

Positioning: Exception Approval sits squarely on the governance side and leans toward controlled coordination: it strengthens alignment by making deviations explicit and accountable, preventing hidden variance that undermines standards, while still allowing teams some freedom under defined conditions. Automation can help route requests, store approvals, and trigger renewals or audits, but human judgment is needed to assess risk, attach appropriate controls, and decide when an exception should be granted or revoked.

Team Rituals

Description: Team Rituals are regular, lightweight practices teams use to coordinate and improve—daily standups, sprint planning, retrospectives, backlog grooming, demos, and ad-hoc syncs. These rituals create predictable cadences for sharing progress, surfacing risks, aligning priorities, and learning together, keeping work visible and reducing miscommunication.

Positioning: Team Rituals sit on the governance side but lean toward guidance and culture rather than strict control: they support alignment by creating shared habits and expectations that keep teams coordinated, yet they preserve freedom because teams can choose formats, frequency, and detail that fit their context. Simple automation (calendar templates, status boards, meeting notes tooling) can reduce overhead, but the real value comes from consistent human participation and follow-through.

Checklist

Description: A Checklist is a simple, explicit list of steps or checkpoints teams must consider or complete for recurring activities (deployments, release readiness, security reviews, incident handoffs, on‑boarding). Checklists capture proven practices, reduce human error, and make expectations visible so teams consistently follow critical steps without relying on memory.

Positioning: Checklists sit between governance and automation but lean toward governance: they align teams by standardizing required actions and decision points, while leaving teams freedom in how they implement each step. Automation (templated forms, checklist integrations in CI/CD, reminders) can enforce or track completion, but the pattern’s core value is the human discipline of verifying essentials before proceeding.

Guidelines

Description: Guidelines are recommended practices, patterns, and explanations that help teams make better technical and process choices without imposing mandatory rules. They provide context, examples, pros/cons, and suggested defaults (for design, coding, security, testing, or operations) so teams can move faster and more consistently while adapting guidance to their situation.

Positioning: Guidelines sit on the governance side and lean toward advice and autonomy: they support alignment by offering a common reference and reducing needless debate, but they preserve team freedom because adherence is voluntary. Tooling (docs portals, linters with non-blocking warnings, searchable examples) can make guidelines easy to find and follow, yet human coaching and culture are what drive adoption.

Template

Description: A Template provides a structured, repeatable format for teams to capture information consistently — what to include, what not to include, and how to present it. By defining the key fields and expected scope for a given artifact (design doc, incident review, strategy note, etc.), templates reduce ambiguity, speed up writing, and help readers quickly orient themselves. They create a shared understanding of what “good” looks like while keeping focus on content rather than format, enabling lightweight alignment without prescribing the details of the solution.

Positioning: Template sits toward the governance side by establishing a common structure that guides how teams communicate and document their work, reducing variability and ensuring essential elements are always covered. Yet it supports autonomy because teams can adapt how they fill the template, expand fields when needed, or evolve the template through feedback loops. Automation can assist by providing pre-generated templates in tools, integrating them into workflows, or validating required sections, but the value remains largely human-driven — using structure to improve clarity, shared understanding, and decision quality without enforcing strict control.

Shared Cadence

Description: A Shared Cadence establishes a common rhythm for recurring events — such as planning sessions, demos, retrospectives, backlog refinements, or cross-team checkpoints. By anchoring ceremonies to a predictable schedule (e.g., every two weeks, monthly, or aligned to release cycles), it provides regular synchronization points that help teams coordinate dependencies, surface issues early, and maintain momentum. This shared tempo reduces friction caused by unsynchronized workflows, ensures information flows at consistent intervals, and gives teams a stable backdrop for planning and collaboration without mandating uniform execution.

Positioning: Shared Cadence leans toward governance by defining when alignment happens, creating predictable touchpoints that reduce coordination overhead and prevent teams from drifting apart in timing or priorities. At the same time, it preserves autonomy: while the cadence sets when teams sync, it doesn’t prescribe how they run their ceremonies or make decisions within them. Automation can support the cadence through calendar tooling, reminders, and integrated workflow triggers, but the heart of the pattern is human alignment — using regular, lightweight synchronization points to keep teams moving in the same direction while allowing flexibility in local practices.

Transparency is Enough

Description: Transparency Is Enough is the practice of making work, decisions, services, and assets openly visible and understandable so that alignment emerges organically rather than being imposed. Teams publish what they build, document intent and constraints, expose interfaces and metadata, and make artifacts easy to browse or search. Inconsistencies, overlaps, or redundancies are tolerated as a natural consequence of autonomy; what matters is that these divergences are visible. With transparency in place, people discover related efforts, raise questions, and initiate conversations that naturally lead to consolidation or refinement over time. The system relies on openness as the minimal guaranteed condition for coherent evolution in a heterogeneous environment.

Positioning: Transparency Is Enough sits firmly on the autonomy side: teams can choose independently how they solve problems, even if their approaches differ or conflict, as long as their work is exposed and accessible to others. It leans toward the automation axis because automated catalogs, metadata extraction, indexing, service registries, and code search tools help surface what exists without manual coordination. Governance plays only a light role — not to enforce consistency, but to require visibility. Instead of mandating alignment up front, the pattern trusts that transparency enables self-correction, emergent convergence, and informed decision-making across decentralized teams.