
Something in how your organisation makes technology decisions isn't working. Maybe architecture reviews slow everything down. Maybe AI adoption is stuck in pilot purgatory. Maybe your teams are shipping but the wrong things are breaking. Maybe you need senior technology leadership but can't justify a full-time hire yet.

This page is your map — it connects every framework, training, workshop, and engagement model on this site to the problem you're actually trying to solve. Whether you need a focused workshop, a training program, a full consulting engagement, or an embedded fractional executive — the right starting point is here.

**Not sure which problem is yours?** Ask yourself: where is the slowdown most visible — in decisions, in delivery, in your AI initiatives, or in your leadership capacity? Find that answer below and start there.

---

```mermaid
flowchart TD
    A[Start Here] --> B{What is your<br/>problem?}
    B --> C[Architecture Friction]
    B --> D[Adopting AI]
    B --> E[Delivery Bottlenecks]
    B --> F[Scaling Leadership]
    C --> C1[Decision Rights]
    C1 --> C2[Team Topology]
    C2 --> C3[Architecture Clarity]
    D --> D1[Operating Model]
    D1 --> D2[Decision Rights]
    D2 --> D3[Responsible AI]
    E --> E1[Team Topology]
    E1 --> E2[Decision Rights]
    E2 --> E3[Delivery Excellence]
    F --> F1[Decision Rights]
    F1 --> F2[Distributed Models]
    F2 --> F3[Fractional Leadership]
```

## Navigate by Problem

### "We have architecture friction"
Decisions are being escalated that shouldn't be. Teams are blocked waiting for approval, or worse — making decisions nobody sanctioned and creating drift. The architecture is real but invisible.

Start with **Decision Rights** → **Team Topology** → **Architecture Clarity**

- [Decision Rights for Technology](/blogs/decision-rights-for-technology-who-decides-what-in-a-modern-enterprise) — Define who decides what, at which altitude
- [The TDDA Framework](/blogs/architectural-decision-rights-matrix-governing-enterprise-solution-and-technical-architecture) — Make authority explicit across enterprise, domain, and team layers
- [Your Git History Is an Architecture Health Report](/blogs/your-git-history-is-an-architecture-health-report-nobody-is-reading-it) — Measure the architecture you actually have, not the one you intended

### "We're adopting AI"
Pilots are working but nothing is scaling. There's excitement without governance. You're not sure where AI decisions should be made or who owns them when they go wrong.

Start with **Operating Model** → **Decision Rights** → **Responsible AI**

- [The Enterprise AI Operating Model](/blogs/the-enterprise-ai-operating-model-from-experimentation-to-institutional-capability) — Move from experiments to institutional capability
- [AI Agents and Agentic Systems](/trainings/ai/ai-agents-automation) — Understand what autonomous AI decisions actually mean for governance
- [Responsible AI Workshop](/workshops/ai/responsible-ai) — Safety, bias, and compliance without slowing delivery

### "We have delivery bottlenecks"
You're shipping, but slowly. Handoffs are costly. Architecture reviews are a queue, not a conversation. Teams are waiting on each other in ways nobody designed.

Start with **Team Topology** → **Decision Rights** → **Delivery Excellence**

- [Team Topologies & Organisational Design](/workshops/leadership/team-topologies-and-org-design) — Structure follows architecture; fix the structure first
- [Delivery Excellence Workshop](/workshops/leadership/delivery-excellence) — Guardrails and flows that actually unblock teams
- [Architecture Decision Clarity](/workshops/architecture/architecture-decisions-clarity) — Stop relitigating decisions; start making them stick

### "We're scaling leadership"
You need senior technology leadership capacity your headcount doesn't support. Decision-making is centralised on people who are already stretched. The organisation is ready to scale but the leadership model isn't. A full-time executive hire isn't justified yet — but the gap is costing you.

Start with **Decision Rights** → **Distributed Models** → **Fractional Leadership**

- [Fractional CTO / VP Engineering / Chief Architect](/services) — Embedded senior leadership at 1-3 days/week, fraction of the cost of a full-time hire
- [Distributed Leadership Workshop](/workshops/leadership/distributed-leadership) — Decentralise decision-making without losing coherence
- [Technology Leadership Fundamentals](/trainings/leadership/technology-leadership-fundamentals) — Build the leadership layer your organisation needs
- [Fractional Leadership Case Studies](/case-studies/saas-adr-implementation) — Real engagements with measurable outcomes

---

## The Core Frameworks

These three frameworks underpin everything on this site. They're not academic — each one came from working through a real organisational problem.

### 1. Technology Decision Domain Architecture (TDDA)

Most architecture friction isn't caused by bad decisions. It's caused by decisions happening at the wrong altitude — enterprise-level calls being made by individual teams, or team-level decisions being escalated to governance committees that have no business being involved.

TDDA maps every technology decision across two axes:
- **Altitude**: Enterprise / Domain / Team / Individual
- **Domain**: Investment / Standards / Platform / Integration / Implementation / Security

The matrix makes authority visible, prevents unnecessary escalation, and ensures the decisions that need scrutiny actually get it. It's the fastest intervention for organisations where "who decides this?" is a recurring, expensive question.

→ [Read the full TDDA framework](/blogs/architectural-decision-rights-matrix-governing-enterprise-solution-and-technical-architecture)

### 2. Team Topology and Conway's Law

Your architecture will mirror your team structure whether you design it to or not. Conway's Law isn't a warning — it's a design tool. If you want loosely coupled services, you need loosely coupled teams. If you want platform thinking, you need teams that think like platform owners.

The four team types that produce functional sociotechnical systems:
- **Stream-aligned teams** own customer outcomes end-to-end
- **Platform teams** provide self-service capabilities that remove cognitive load
- **Enabling teams** unblock adoption of new practices and technologies
- **Complicated-subsystem teams** manage components that require specialised knowledge

Fix the team structure and the architecture often fixes itself. Ignore it and no amount of architectural documentation will compensate.

→ [Team Topologies Workshop](/workshops/leadership/team-topologies-and-org-design)

### 3. AI Operating Model

Most organisations are sitting on a collection of AI experiments that individually work and collectively don't add up to capability. The gap between "we have AI pilots" and "AI is how we operate" is an operating model problem, not a technology problem.

The AI Operating Model defines:
- **Ownership**: Centralised, federated, or hybrid — and why it depends on your risk profile
- **Decision rights**: What AI decisions happen at the team level versus governance level
- **Risk gates**: Checkpoints that protect without becoming bottlenecks
- **Capability inventory**: What you can do today versus what your strategy requires

The goal isn't AI maturity for its own sake. It's turning AI investment into repeatable, governable business outcomes.

→ [The Enterprise AI Operating Model](/blogs/the-enterprise-ai-operating-model-from-experimentation-to-institutional-capability) — [AI Operating Model Workshop](/workshops/ai/ai-operating-model)

---

## Progression Paths

If you're planning a structured engagement rather than solving a specific problem, these paths build on each other in the right order.

### Path A: Architecture Leader
Build the decision frameworks and governance structures that make architecture a delivery accelerator, not a gate.

1. [Architecture Decisions Clarity Workshop](/workshops/architecture/architecture-decisions-clarity) — Start with the decision layer
2. [Technology Leadership Fundamentals](/trainings/leadership/technology-leadership-fundamentals) — Build the leadership context around it
3. [Enterprise Architecture Strategy Workshop](/workshops/architecture/enterprise-architecture-strategy) — Connect architecture to business trajectory

### Path B: AI Leader
Move from AI experimentation to enterprise-grade AI capability with governance that doesn't slow innovation.

1. [AI Operating Model Workshop](/workshops/ai/ai-operating-model) — Set the foundation
2. [Agentic Systems Training](/trainings/ai/ai-agents-automation) — Understand what autonomous AI changes about governance
3. [Responsible AI Workshop](/workshops/ai/responsible-ai) — Embed safety and compliance from the start

### Path C: Engineering Leader
Build the organisational structures and delivery systems that let engineering teams actually deliver.

1. [Team Topologies Workshop](/workshops/leadership/team-topologies-and-org-design) — Fix team structure first
2. [Delivery Excellence Workshop](/workshops/leadership/delivery-excellence) — Remove the delivery bottlenecks
3. [Platform Engineering Workshop](/workshops/leadership/platform-engineering) — Build the internal platform that scales the rest

### Path D: Fractional Leadership
You need senior technology leadership but aren't ready for a full-time executive. Get the decisions, direction, and accountability you need without the overhead.

1. [Fractional CTO, VP Engineering, or Chief Architect](/services) — 1-3 days/week embedded, decisions and outcomes included
2. [Distributed Leadership Workshop](/workshops/leadership/distributed-leadership) — Decentralise decision rights so the organisation scales without you
3. [Fractional Leadership Case Studies](/case-studies/saas-adr-implementation) — How this model works in practice

---

## See It In Practice

Sometimes the fastest way to understand whether this approach fits your situation is to look at how it played out for someone else.

- [FinTech: From 15 AI pilots to 6 prioritised initiatives in 12 weeks](/case-studies/fintech-ai-strategy) — AI operating model and governance
- [SaaS: 60% faster architecture decisions with ADRs](/case-studies/saas-adr-implementation) — Decision rights and architecture clarity
- [HealthTech: HIPAA-compliant architecture with zero delivery slowdown](/case-studies/healthtech-governance) — Governance without bureaucracy

---

## Quick Actions

If you're not ready to commit to a path yet, start here this week.

**This Week:**
- List your top 5 recurring technology decisions. For each one: who is currently making it? Who should be?
- Identify one decision that is consistently happening at the wrong altitude — too high or too low
- Draw your current team structure and ask: does this map produce the architecture you want?

**Next 30 Days:**
- Implement decision rights for one active deliverable and measure escalation frequency before and after
- Run a Conway's Law audit — compare your org chart to your system architecture diagram
- Establish a baseline for one DORA metric (deployment frequency is the easiest starting point)
- [Read how other leaders solved the same problems](/case-studies) — bookmark for reference


A strategic guide to Enterprise Architecture, AI Strategy, Engineering Delivery, and Fractional Technology Leadership. Navigate complexity with clarity through decision frameworks, operating models, and hands-on execution support.

Start Here

Not sure which path applies?