Before we start — the one thing to hold onto

Most leaders think their delivery problems are people problems. The wrong engineers. Not enough of them. Low motivation. They hire more, reorganise, and six months later the same friction is back in a different shape. The people weren't the problem.

Your teams will build a system that looks like your organisation. That's not a metaphor — it's a law. If you want a different architecture, you need a different team structure first.

That one idea changes everything. It turns delivery friction from a performance problem into a design problem — and design problems have solutions.

Keep it in mind.

Purpose

The goal of this workshop is concrete: redesign how your engineering organisation is structured so that team boundaries accelerate delivery instead of creating the friction you're currently managing around.

I've worked with organisations that had spent a year trying to build independent microservices with teams that still shared a database, a release process, and a weekly coordination meeting. The architecture said independent. The org structure said otherwise. The architecture lost.

You'll leave with a team topology that matches the system you're trying to build, an interaction model that reduces unnecessary coordination, and a clear charter for the platform capability your stream teams actually need.

Who Should Attend

This workshop is designed for the people who decide how teams are formed — and who feel the delivery consequences when they're formed wrong.

CTO, VP Engineering, Engineering Directors
Principal Engineers and Architects (who understand the system the teams are building)
HR or People Leaders responsible for org design (if involved in team structuring)

Typical team size: 6-10 participants
Format: In-person strongly preferred — org design requires physical space to map and move

Try it yourself — The coordination cost audit

Count the number of recurring cross-team meetings your engineering organisation runs every week. Now ask: how many of those meetings exist because two teams need to coordinate on something that should have been one team's decision alone?

Every meeting that exists to compensate for a structural gap is a tax on delivery speed. This workshop eliminates the structural gaps.

What You'll Achieve

By the end of this workshop, you will have:

A team topology map — stream-aligned, platform, enabling, and complicated-subsystem teams identified and placed
Cognitive load assessment per team — where teams are carrying more than they can sustainably own
Interaction model — which teams collaborate, which facilitate, and which operate as X-as-a-Service
Platform team charter — what the internal platform exists to do, and what it doesn't
Identified team anti-patterns currently creating your delivery bottlenecks
A phased transition plan from current structure to target topology

These aren't org chart changes. They're structural decisions that will determine how fast you can ship in twelve months.

Typical Outcomes

Immediate outcomes (within 1 week):

Team topology map shared with leadership and engineering leads
Top 3 cognitive load violations identified and owners assigned to resolve them
Platform team scope agreed — what it owns, what it doesn't

Short-term outcomes (within 1 month):

Team interaction modes clarified — collaboration, facilitating, X-as-a-Service
New features being scoped within stream team boundaries rather than across them
Reduction in cross-team dependency surprises in sprint planning

Long-term outcomes (3-6 months):

Measurable reduction in cross-team coordination overhead
Architecture evolving to match team boundaries, not fighting them
Faster onboarding — new engineers understand ownership through team boundaries, not org charts

Workshop Structure

Morning (3 hours): Topology Diagnosis

Map the current team structure against the system being built
Identify where Conway's Law is working against you — where the org is producing the wrong architecture
Cognitive load assessment — which teams are overloaded, under-bounded, or carrying the wrong things

Afternoon (3 hours): Topology Design

Design the target team topology — stream-aligned, platform, enabling, complicated-subsystem
Define interaction modes between teams — not just who talks to whom, but how and why
Draft the platform team charter — scope, mandate, and the line between enabling and controlling
Build the phased transition plan

Total duration: 1 day
Adjustable: Yes — can extend to a second half-day for platform team deep-dive or transition planning with a wider group

Try it yourself — The Conway's Law check

Draw your current team structure. Now draw your system architecture. Hold them side by side.

Do the boundaries match? If your architecture has five services but your teams are organised by technical layer — frontend, backend, data — your teams are producing integration meetings, not independent deployments. That gap is what this workshop closes.

Prerequisites & Preparation

Before the workshop:

Current org chart and team responsibilities documented
System architecture diagram (even a rough one) of what the teams are building and maintaining
List of recurring cross-team dependencies and coordination points

Recommended team composition:

1-2 Engineering leadership (VP, Director level)
2-3 Principal Engineers or Architects who understand the system topology
1-2 Engineering Managers closest to the delivery friction
1 Product or Delivery lead (to represent business flow, not just technical boundaries)

How to know if this landed

You'll know this has landed when someone proposes a new feature and the first question is "which team owns this end to end?" — and there's an answer. When a team can release independently because nothing in their boundary requires coordination with another team's release cycle. When the platform team is measured by how rarely stream teams need to ask it for help. When the org chart and the architecture diagram finally look like they were designed by the same people.

What changes when the mental model clicks

I've run this session with engineering leaders who were convinced their delivery problems were down to technical debt, bad tooling, or underperforming engineers. The moment they see their org structure mapped against their system architecture — and see exactly where the coordination overhead is being generated — the conversation changes completely.

What changes after this workshop:

Leaders stop reorganising in response to delivery pain and start designing team structure as a first-class architectural decision. The cognitive load assessment tends to be the moment things click — teams that everyone assumed were high-performing turn out to be carrying three times what they can sustainably own, and the delivery drag finally has a structural explanation rather than a people one.

The interaction model design tends to immediately change how teams plan. They stop treating cross-team dependencies as inevitable and start treating them as design failures to be eliminated. Their planning gets more honest. Their commitments get more reliable. They stop blaming "poor communication" when the real problem was that the structure forced communication to compensate for boundaries that were never clearly drawn.

Book a Workshop

Ready to give your engineering organisation the structural clarity that turns delivery friction into predictable flow?

→ Book a Workshop

→ Contact me directly

1-day intensive workshop includes topology diagnosis, Conway's Law mapping, cognitive load assessment, team topology design, interaction model definition, platform team charter, and a phased transition plan.

Team Topologies & Organisational Design Workshop