Before we start — the one thing to hold onto
Most teams think they have a documentation problem. They don't. They have a decision problem. I've sat in rooms with architects who could show me fifty Slack threads debating technology choices — and zero records of what was actually decided, why, and by whom.
An architecture decision isn't a conversation. It's a record — who decided what, when, why, and what alternatives were considered. Without that record, every new engineer reopens the same debate.
That one idea changes everything. It turns endless architecture debates into traceable decisions.
Keep it in mind.
Purpose
The goal of this workshop is concrete: eliminate architectural ambiguity and technical decision bottlenecks through clear decision frameworks and accountability patterns for both human and autonomous systems.
I've seen teams spend three weeks debating a technology choice that was already decided six months ago — because nobody documented it. The cost isn't just time. It's trust. When decisions disappear, debates repeat. This workshop fixes that.
You'll leave with ADR templates customised for your organisation, a decision backlog, and a governance framework that scales.
Who Should Attend
This workshop is designed for the people who actually make and live with architecture decisions.
- Enterprise & Solution Architects
- Principal Engineers, Tech Leads
- Platform & Engineering Leads
Typical team size: 6-10 participants
Format: In-person or virtual (hybrid available)
Try it yourself — The decision archaeology exercise
Before the workshop, pick one technology choice your team made recently. Can you answer: who decided it? What alternatives were considered? Why was this choice made? When was it decided?
If you can't answer all four, that's exactly why this workshop exists.
What You'll Achieve
By the end of this workshop, you will have:
- Identification of undocumented or conflicting decisions
- Architecture Decision Records (ADR) implementation for team decisions
- Agentic Decision Log (ADL) patterns for AI agent autonomy
- Clear system boundaries, ownership, and decision rights
- Technical debt visibility and prioritisation
- Decision governance for both traditional and agentic systems
These aren't templates you'll file away. They're frameworks your team will use in next week's architecture review.
Typical Outcomes
Immediate outcomes (within 1 week):
- Inventory of current architecture decisions and gaps
- ADR template customised for your organisation
- Decision backlog with initial prioritisation
Short-term outcomes (within 1 month):
- ADR process adopted by key teams
- Decision rights matrix documented and shared
- Reduced decision latency and rework
Long-term outcomes (3-6 months):
- Consistent decision-making across teams
- Onboarding acceleration through documented decisions
- Reduced architectural technical debt
Workshop Structure
Day 1 (Full):
- Morning (3 hours): Decision archaeology — uncovering existing decisions & patterns
- Afternoon (3 hours): ADR/ADL framework design & template creation
- End of day: Prioritising decisions to document first
Optional Day 2 (Half day):
- ADR writing clinic (hands-on)
- Governance model rollout plan
Total duration: 1 day (with optional half-day follow-up)
Adjustable: Yes — can be tailored to decision-making maturity
Try it yourself — The bottleneck audit
Look at your last three architecture debates. How long did each take? How many people were involved? Was the final decision documented somewhere a new engineer could find it?
Most teams I work with find that their longest debates are about decisions that were already made — just never recorded.
Prerequisites & Preparation
Before the workshop:
- Participants bring 2-3 examples of recent decisions (good and bad)
- Review of existing documentation (ADR templates, wikis, decision logs if any)
- List of known decision bottlenecks or recurring debates
Recommended team composition:
- 2-3 Enterprise/Solution Architects
- 2-3 Principal Engineers/Tech Leads
- 1-2 Platform or Engineering Managers
- 1 Product Manager (to provide business context)
How to know if this landed
You'll know this has landed when someone stops starting a new architecture debate and starts by checking if one already exists. They can write an ADR in under thirty minutes. They understand the difference between a decision that needs a record and a decision that needs a conversation. They catch undocumented decisions before they become tribal knowledge.
What changes when the mental model clicks
I've run this session with teams ranging from startups with zero documentation to enterprises with wikis full of debates and zero decisions. The gap at the start is usually not about discipline — everyone wants clarity — it's about not having a lightweight process that actually gets used.
What changes after this workshop:
Teams stop treating architecture decisions as conversations and start treating them as records. The decision archaeology exercise tends to be the moment things click — people realise they've had the same debate three times in eighteen months, and that realisation changes how they think about documentation.
The ADR template creation tends to immediately change how people write decisions. They start including alternatives considered and consequences. Their decisions get better. Their debates get shorter. They stop blaming "lack of time" when the real problem was that nobody made it easy.
Book a Workshop
Ready to give your architecture team the decision framework they need?
or
1-day intensive workshop includes decision archaeology, ADR/ADL framework design, template customisation, decision backlog creation, and governance model planning.