Is delivery keeping getting blocked or slowed down, with no clear reason why? In this lightning lesson, Giuseppe De Simone and Simon Sablowski presented a simple collaborative tool to visualise inter-team dependencies and build a shared understanding of the coordination cost attached to them. As an example, they mapped one feature request across five teams to show where coordination cost comes from, and what changes when team boundaries are redesigned around the outcome instead of technical layers or domains.

The recording covers how to:

  • Spot boundaries that create coordination cost. See where team boundaries generate unnecessary handoffs, delays and overhead in the current structure.
  • Make cross-team dependencies visible. Surface hidden dependencies before they show up as blockers in the delivery flow.
  • Choose the right coordination pattern. Evaluate which patterns fit the actual context, and which ones are quietly making things slower.

Watch the recording here

Key takeaways

1. Four questions to ask before touching the org chart

Before any organisational redesign, Giuseppe laid out four strategic decisions that shape everything downstream. They are not frameworks, just questions worth sitting with:

  • What is "our product"? A bank could call internet banking one product, or split it all the way down to iOS and Android credit card apps. Broader definitions mean fewer, more complex teams with a more holistic view of priorities, while narrower definitions are simpler to run but risk sub-optimisation.
  • Component teams or feature teams? Splitting by technical layer (frontend, backend, hardware) puts the most competent people on each part, but customers do not submit requirements that politely stay inside one layer, so dependencies are built in by design. Feature teams avoid this, but require investing in broader competence across the team.
  • Efficiency or effectiveness? Splitting by skill optimises for efficiency; cross-disciplinary teams with end-to-end ownership optimise for effectiveness.
  • One Product Owner per team, or per product? Per team is simpler day to day, but the more Product Owners there are, the more time each one spends coordinating backlogs with the others.

None of these choices is free: each comes with trade-offs that are signed up for, not avoided.

2. Making coordination cost visible: frequency × risk = cost

Simon introduced a simple dependency-mapping exercise to turn "coordination feels expensive" into an actual number. Take one realistic feature, trace it across every team it touches, and score each dependency on two axes from 1 to 3: frequency (how often the teams need to interact) and risk (how much could go wrong). Multiplying the two gives a cost per dependency. Dependencies come in three flavours: technical, approval, and knowledge-based (for example, one engineer being the only person who understands a legacy system).

3. What redesigning around outcomes looks like

The example was a feature that lets customers schedule a recurring usage report (CSV or PDF, emailed, limited to paying plans), simple from the customer's side. Mapped across a typical component structure (web frontend, auth and permissions, billing, data and reporting, notifications), it touched five teams with seven dependencies, for a total coordination cost of 38. And this applies to a well-run organisation, with no one being lazy or slow.

Merging frontend, data and reporting, and notifications into a single "Reporting and Insights" team cut the dependency count from seven to two. Those two remaining dependencies were formalised as published, self-serve APIs instead of ad hoc Slack threads and pull-request reviews, dropping the total cost from 38 to 2. Same scope, same work, just far less friction moving it through the system.

4. The fine print: what the numbers do not capture

The Q&A pushed back productively on the model, and the caveats matter as much as the tool:

  • It is a deliberate simplification: the value is in the conversation the scoring provokes, not the precision of the numbers themselves.
  • Redesigning around a single feature is a mistake. Run the mapping across four or five features and look for the structure that works in most cases (an "80% solution", not a perfect one).
  • Moving people and merging teams has social and behavioural consequences that the model does not touch at all.
  • It is a tool for placing informed bets, not for avoiding experimentation: what actually happens is only learned once the change is made.
  • Used carelessly, it can become an excuse for constant reorganisation, which has its own real cost.

Why this matters

Coordination cost is almost always hidden: it lives in people's heads as frustration, not as a number on a wall. As AI keeps raising how fast individuals and teams can produce, an operating model built around outdated boundaries just means hitting the same hidden dependencies sooner. Making them visible, even with a rough, imperfect score, turns a vague sense of friction into something a team can discuss, prioritise and act on.

Want to go deeper? Giuseppe and Simon are piloting a full course this November, Leading Coordination and Collaboration in AI-Accelerated Organisations, because faster teams need boundaries designed for the speed they are now capable of. Reach out to be part of the first cohort or to help shape it with feedback.

About the presenters

Giuseppe De Simone is a Certified Trainer and organisational coach with 25+ years in product development and transformations at enterprise scale. He has coached and trained leaders at organisations where the gap between individual performance and delivery throughput is not theoretical but the daily reality. He keeps seeing the same pattern: AI tools accelerate individual output, but the operating model was never designed for that speed, so the result is more friction, not less. His work focuses on the layer most skip: how decisions flow, how alignment breaks down, and how teams coordinate under pressure. He is the founder and CEO of his consulting and training business and a Fellow Coach at Better Change.

Simon Sablowski is a coordination and organisational design consultant who helps companies redesign the layer between their people and their delivery: the structures, boundaries and patterns that determine how fast decisions move, how dependencies are managed, and how teams actually coordinate in practice. He works with engineering-led organisations navigating the gap between individual performance and delivery throughput, focusing on the structural root causes most interventions skip: where team boundaries are drawn, how dependencies are made visible, and which coordination patterns fit the actual work, not just the org chart.