The Problem
Architecture review meetings had become the organisation's primary bottleneck. Every technical decision required a cross-team meeting. Meetings were scheduled weeks out. Decisions were revisited because nothing was documented. The VP Engineering estimated that 30% of engineering capacity was lost to architecture debate that never reached resolution.
The company had grown from 15 to 80 engineers in 18 months, but the decision-making structure had not evolved. Every architect could block any decision. Nothing was delegated.
The Approach
We ran a 6-week architecture governance transformation:
Phase 1: Decision Audit (Week 1)
- Mapped every architecture decision made (or stuck) in the previous 3 months
- Identified 5 decision types with different velocity requirements
- Interviewed engineering leads to understand friction patterns — the same interviews kept surfacing decisions escalating to a full committee that a single domain owner should have been able to make alone
Phase 2: ADR Framework Design (Week 2-3)
- Introduced 5 ADR templates covering different decision contexts (strategic, tactical, operational, experimental, urgent)
- Defined a decision rights matrix mapping decision type → decider → consultation group → notification list, built on the same altitude-and-domain logic as the Technology Decision Domain Architecture model — enterprise, domain, team and individual altitude against investment, standards, platform, integration, implementation and security domains
- Created a lightweight ADR review process that replaced the weekly architecture forum
Phase 3: Embedding (Week 4-6)
- Ran 3 hands-on workshops with engineering teams to practice ADR writing
- Set up an ADR log with status tracking
- Coached the architecture team on delegation patterns
- Established a fortnightly architecture sync (down from weekly) focused only on decisions that genuinely required cross-team input
The Outcome
| Metric | Before | After |
|---|---|---|
| Decision cycle time | 2-4 weeks | 2-5 days |
| Blocked decisions | 12+ at any time | 2-3 at any time |
| Cross-team meetings | Weekly (3 hours) | Fortnightly (1 hour) |
| Documented rationale | None | Every ADR logged and searchable |
Architecture decision time dropped by 60% within the first month. The ADR log became a source of truth that new hires could read to understand past decisions. The VP Engineering described it as "the single highest-leverage process change we made in two years."
What Changed
The shift was not about more process — it was about the right process. Before, every decision went through the same heavy gate. After, the decision rights matrix ensured that tactical decisions were made in hours, strategic decisions got the right attention, and everyone knew which category they were in. The architecture team stopped being a bottleneck and became an enabler.
Where the ADR Log Goes From Here
The five ADR templates and the decision rights matrix built here are the artefacts described in general form in ADR Templates: 5 Variations for Different Contexts and the decision rights matrix behind the Technology Decision Domain Architecture model — this case study is what applying both looks like inside one 80-person SaaS company rather than in the abstract. The matrix itself generalizes the way Architecture Patterns That Travel Across Industries describes: swap SaaS for logistics, insurance, or manufacturing and the artefact does not change — a matrix, five templates, an ADR log. What changes is only the domain vocabulary in the consultation-group column. The fortnightly sync that replaced the weekly forum is the practical shape of what The Architecture Review Is Broken argues for: a review cadence sized to the decisions that actually need a room, not a calendar slot that exists because it always has.
The searchable ADR log the VP Engineering called the highest-leverage change in two years is also becoming useful for a reason the team did not build it for. Nobody Uses ADRs as an Agentic Decision Log. They Should. makes the case that the same log a new hire reads to understand why a boundary exists is exactly the context an AI coding agent needs before it proposes changing that boundary. A company with eighteen months of documented, searchable rationale is not starting from zero when it starts pointing agents at its codebase. Most companies are — because most companies never built the log in the first place.