I had been hearing about this book frequently a few months ago and kept meaning to get around to reading it. Having only ever worked full-time in one team – albeit one that has rotated through several lifecycles – I’ve always been curious about effective team performance. I’ve wondered if there are ways we can collectively improve our ability to deliver what we need to build.

Team Topologies promises to offer practical advice, which made me keen to give it a read and break down what I took away from it. Initially, I intended to create a single comprehensive book summary post. However, as I put together my notes for Part 1, it became clear that a single post would be excessively long. Instead, I’ve opted for separate, more in-depth summaries for each core section of the book – so let’s start with Part 1!

Systems in Our Modern Life

The first part of the book explores Conway’s law, examining how organisational interrelationships profoundly impact the design of systems, and highlighting the value of effective teams.

In today’s world, it is crucial to recognise the significance of well-designed systems in our day-to-day lives. Consider, for instance, how reliance on taxi-hailing apps can leave people stranded when they fail, or how internet banking systems have become critical in our increasingly cashless society. These systems don’t just need to exist – they need to be developed and maintained quickly and safely. To stay competitive in this landscape, organisations developing such systems require teams and individuals who can context-switch and adapt effectively to changing demands.

Beyond Static Org Charts

When diving into the opening chapters, I was particularly interested by the way in which Team Topologies challenges the traditional approach of static org charts for establishing structure. While these charts serve a purpose in regulatory and legal compliance contexts, a case is made for preferring decoupled and long-lived teams instead. This shift away from highly structured approaches means that problem-solving shouldn’t be confined to the top-down/bottom-up communication lines that traditional org charts enforce.

Instead, Team Topologies pushes for establishing dynamic teams and interaction modes that help teams adapt to new situations and deliver software quickly and safely. What resonated with me was the book’s argument that communication paths inherently restrict the kinds of solutions an organisation can produce – and how reshaping these paths can lead us toward better system designs.

To illustrate this concept, the authors provide an insightful example of how team structure influences architecture: if there is a reliance on a single database expert or team, multiple teams will inevitably depend on that shared database resource. This dependency can lead to a deeply coupled system where applications lack proper separation of concerns. By contrast, having database developers within each team encourages independence and proper separation of data stores, leading to a much more flexible microservice-styled architecture.

The book also explores an interesting historical perspective on software development. It traces the evolution from the traditional “manufacturing” approach – with its emphasis on planning large projects upfront and executing them through individuals grouped by specialty domains – to more modern “Agile, Lean IT, and DevOps” methodologies. These newer approaches favour smaller, more autonomous teams working in iterative cycles and developing based on continuous user feedback.

What struck me was the observation that many large, traditional organisations have struggled to benefit from these more adaptive approaches, primarily because their organisational models remain stuck in outdated paradigms – creating a disconnect between their ideal development practices and the reality of their organisational structure.

Conway’s Law in Practice

In the context of this book, Conway’s Law takes centre stage with its observation that:

“Organisations which design systems… are constrained to produce designs which are copies of the communication structures of these organisations.“

– Conway’s Law

This leads to a critical insight: “if the desired theoretical system architecture doesn’t fit the organisational model, then one of the two will need to change.” The authors reinforce this with Ruth Malan’s powerful quote: “If the architecture of the system and the architecture of the organisation are at odds, the architecture of the organisation wins“. The book even emphasises that technical leaders must provide input to decide responsibilities, boundaries, and the shape of teams.

Digging deeper into Conway’s law reveals another counterintuitive truth: not all communication and collaboration adds value (interestingly, this made me reflect on the naive view of information that Yuval Noah Harari explored in Nexus, where we often assume more information is better when reality suggests otherwise). The book makes a case for focused communication, arguing that interactions between teams should be intentionally low-bandwidth to avoid the common trap of believing everyone needs to communicate with everyone else to get things done. In fact, Team Topologies goes as far as to say that when organisations promote excessive communication, they often produce monolithic, highly coupled, and interdependent systems that undermine the safe and rapid development they are trying to achieve. As the authors succinctly put it: “more communication is not necessarily a good thing.”

Key Considerations When Applying Conway’s Law

When putting Conway’s Law into practice, the book highlights several important considerations:

1. Tool choices matter significantly – separate tools work best for independent teams, while shared tools better serve collaborative teams
2. We should avoid unnecessary re-organisations done merely for management convenience, as these can severely hamper an organisation’s ability to iterate effectively on software development

One passage I found particularly insightful in this section was: “Team collaboration is important for gray areas of development, where discovery and expertise is needed to make progress. But in areas where execution prevails – not discovery – communication becomes an unnecessary overhead”. This distinction between discovery and execution contexts helped clarify when to promote collaboration versus when to minimise it.

Defining Effective Teams

Building on these organisational insights, the book then establishes what constitutes an effective team, why teams are needed in the first place, and how they can achieve peak effectiveness. A team is best defined as a “stable grouping of five to nine people who work toward a shared goal as a unit”, and such teams form the fundamental operational unit in any organisation. This approach recognises that expecting individuals to comprehend the sheer volume of information needed to build and maintain complex software systems simply isn’t realistic.

What I found particularly interesting was the emphasis placed on team size. The argument is that trust breaks down beyond certain size limits resonates, so the recommendation is to apply “Dunbar’s number” to organisational groupings – suggesting 5 to 8 people for software teams, fifteen for the next hierarchical level, then 50, 150, 500, and so on as you move up the organisational ladder.

Team Stability and Development Stages

Another crucial insight is how teams need sufficient time to become truly effective. It is stressed that providing stability is essential for teams to reach high performance levels. Reference is made to the “Tuckman model” of team development stages, which provides a useful framework:

1. Forming: The initial assembly phase when the team first comes together
2. Storming: Working through inevitable differences in personality and working styles
3. Norming: Gradually evolving standardised approaches to working together
4. Performing: Finally reaching that coveted state of high effectiveness

The book also emphasises that ownership is critical to team success. When multiple teams apply changes to a single system, we risk having no real ownership of those changes – often resulting in a disorganised mess. However, I appreciated the emphasis that ownership should be thought of as “gardening, not policing” – suggesting a nurturing rather than restrictive approach.

Fundamentally, a team-first mindset is essential, with members consciously placing the team’s needs above their individual priorities.

Managing Cognitive Load

Perhaps one of the most valuable frameworks the book introduces is the concept of “cognitive load” as it applies to teams. Making reference to John Sweller’s work, the authors break this down into three distinct types:

1. Intrinsic cognitive load comes from aspects of the task fundamental to the problem space. This should be minimised through training, strategic hiring, pair programming, and similar approaches.
2. Extraneous cognitive load stems from the environment in which the task is performed. Ideally, this should be eliminated altogether, often through automation.
3. Germane cognitive load relates to aspects of the task that need special attention for learning or high performance. This type needs to be given the most space and attention.

The core argument here is that a “teams-first” approach to cognitive load means deliberately limiting the size of the system that any team works with. When a team gets pushed beyond its cognitive load capacity, it typically breaks down into a collection of individuals focused solely on completing their personal tasks without considering the team’s broader interests or goals.

To illustrate these principles in action, the book presents a case study where a team recognised its lack of domain knowledge but couldn’t find the time, space, or bandwidth to acquire it – a situation I can definitely sympathise with. The solution involved splitting the overloaded team into smaller microteams, which led to increased motivation as each microteam could focus deeply on a single domain.

From this experience, Team Topologies offers a practical approach to classifying the domains a team might handle:

1. Simple domains have a clear plan of action, and a single team can reasonably handle up to three of these simultaneously
2. Complicated domains require iterations to get right, and a single team should avoid taking responsibility for more than one complicated domain at a time
3. Complex domains demand experimentation and discovery – if a team is responsible for a complex domain, it shouldn’t be assigned others, as the cost of disrupting flow and prioritisation becomes too high

The key insight here is that we must design the system and its software boundaries to fit the available cognitive load within delivery teams – not the other way around.

Maximising Team Effectiveness

Among the recommendations for maximising cognitive capacity by reducing intrinsic and extraneous load, I found several particularly valuable:

• Deliberately minimising distractions by limiting meetings and emails, and designating a dedicated person to handle support queries
• Communicating goals and desired outcomes rather than prescribing how to achieve them
• Improving the developer experience (DevEx) through comprehensive documentation, consistent patterns, and well-designed APIs

Central to all these approaches is creating space for individuals to come together, learn collaboratively, and develop their capabilities as a coherent team. The book emphasises two key methods for achieving this:

1. Thoughtfully designing both physical and virtual environments to support team cohesion
2. Actively encouraging time away from desks through participation in guilds, conferences, and other knowledge-sharing communities where cross-pollination of ideas can occur

Motivation

The authors also reference Dan Pink’s three critical elements of intrinsic motivation, which I’ve found extremely relevant in my own work:

1. Autonomy – freedom from the constant juggling of competing requests and priorities from too many stakeholders
2. Mastery – the ability to develop deep expertise instead of becoming a “jack of all trades, master of none”
3. Purpose – maintaining focus rather than spreading attention across too many domains of responsibility

Reflections: Intentional Team Design

Looking back across Part 1 of Team Topologies, the central idea is that organisational design directly shapes system architecture through Conway’s Law, and we should leverage this reality rather than fight against it. The book makes a compelling case for intentionally structuring teams to produce the system designs we desire.

What I found most valuable were the practical frameworks provided for optimising team performance:

• The emphasis on stable, right-sized teams (5-9 people) that follow the Tuckman model of development
• The cognitive load classification system that helps teams avoid taking on more than they can effectively handle
• The distinction between simple, complicated, and complex domains and how they should be distributed
• The focus on a “team-first” approach and creating environments that reduce distractions and unnecessary cognitive burdens, and allow a team to grow together

Throughout these chapters, Team Topologies consistently return to another core idea: that we should prioritise team effectiveness above all else when designing organisations that build software. By acknowledging the fundamental connection between organisational communication structures and system design, we can create teams that are not only more effective and satisfied but that naturally produce better-architected, more maintainable software systems.

As I reflect on my own experiences and observations, these insights certainly align with what I have observed. Teams that were consistently overloaded with cognitive burden struggled to find the time and space to develop the necessary domain knowledge to produce elegant solutions. By contrast, when I’ve seen teams given appropriate autonomy, stable membership, and manageable cognitive loads, they’ve consistently delivered more robust and adaptable systems, in addition to quick and safe delivery.

This post is part of a series. Other posts in this series are:

• Team Topologies (Part 2)
• Team Topologies (Part 3) – Coming Soon!