Team Topologies: book review

A while ago I received a proof copy of the book Team Topologies, by Matthew Skelton and Manuel Pais, to comment on.  It’s due out at the beginning of September 2019.  The Amazon info on it says:

‘Effective software teams are essential for any organization to deliver value continuously and sustainably. But how do you build the best team organization for your specific goals, culture, and needs? Team Topologies is a practical, step-by-step, adaptive model for organizational design and team interaction based on four fundamental team types and three team interaction patterns. It is a model that treats teams as the fundamental means of delivery, where team structures and communication pathways are able to evolve with technological and organizational maturity.’

I got hooked into reviewing it for a few reasons a) it appealed to my vanity – the preface opens with a quote from me! And there are others of mine are dotted through the book  b)  Just looking at the contents page brought me new learning:  I had to look up what ‘topology’ meant, and a few minutes later find out more about Conway’s law, covered in detail in the main body of the book)  c)  I was curious about the authors’ offer of  ‘a dynamic and evolving approach to organizational design based on real scenarios from across different geographies and industries.’ And about their hope: ‘As you travel through this book, we hope you get inspired to chal­lenge how to think about teams, their structures, and how they function’ d) I enjoy books that combine theory, practice, and pragmatism which on first skim this book seemed to do.  And the authors say it’s ‘meant to be a functional book. … [with] content that is interactive and delivers as much learning as we are able to fit within these pages’ (236 pages in 8 chapters + Preface and Conclusion).   I’ll cover these four aspects now.

Appeal of the book: Ignoring the appeal to me (via my vanity), would the book appeal to others?  The authors say it is for ‘anyone who cares about the effectiveness of the deliv­ery and operations of software systems.   I take the view that everyone should care about how software systems are designed and operated.  There’s far too much ‘black box’ stuff around technology. (See the article, I mentioned in a previous blog, Inside the black box: Is technology becoming too complicated?)

But how many people in organisations actually do care about effective software systems apart from in the absence of them?  People notice when a system goes down, or when there’s a security breach, or when something goes wrong from their user perspective, and I’m not convinced that their interest goes beyond that.  This seems to imply that the book is for a predominantly digital/tech professional population which is a pity because much of it is applicable to a more general organisation design/leader/manager audience.

One of the aspects I noticed (which may or may not affect the appeal) is maleness of it – all of the (very good) cases studies are presented by men, and there are only a handful of women referenced.  This could reflect the stats around (UK) women in technology,  ‘Only one in six tech specialists in the UK are women, only one in ten are IT leaders and, worse still, despite significant growth in the number of women working in technology and IT roles, female representation in the technology sector has stalled over the last 10 years.’

New learning:  Skelton and Pais say, ‘Experts in organizational behaviour have known for decades that modern com­plex systems require effective team performance.’ In this book, ‘team has a very specific meaning. By team, we mean a stable grouping of between five and nine people who work toward a shared goal as a unit. We consider the team to be the smallest entity of delivery within the organization. Therefore, an organization should never assign work to individu­als, only to teams.’

This is a refreshing take on organisation design – it’s rare, in my experience, that design focuses at the team level and is considered in relation to the team members’ shared goal and appropriate communication structures.  Yet it makes good sense to ‘consider and nurture’ the multiple aspects of team, including ‘team size, team lifespan, team relationships, and team cognition.’

Another aspect the authors discuss in some depth is the cognitive load of teams.  Again, that’s not a focus traditionally born in mind in organisation design – but its one that is of high significance in terms of individual and group resilience.  (See Steven Forth’s blog) They say that ‘ With a team-first approach, we match the team’s responsibilities to the cognitive load that the team can handle. The positive ripple effect of this can change how teams are designed and how they interact with each other across an organization.’

Dynamic and evolving approach:  Part III of the book discusses why ‘organizations must anticipate the need for evolution of team patterns to meet business, orga­nizational, market, technological, and personnel needs’ offering  a variety of approaches for both anticipating and evolving team patterns, including making decisions on when/whether to collaborate with other teams or interact with them as a service provider, using domain driven design (explained in Chapter 6), and sensing.  On this last, the authors say ‘with well-defined and stable communication pathways between teams, organiza­tions can detect signals from across the organization and outside it, becoming something like an organism.’

I absolutely agree that this dynamic and evolving approach is critical, but there are tensions involved – in highly traditional and bureaucratic organisations e.g. many public sector ones, the traditional systems and processes inhibit the possibilities of being dynamic and involving. A point that the authors make – in relation to Conway’s law “Orga­nizations which design systems . . . are constrained to produce designs which are copies of the communication structures of these organizations.”  The ideas around team design are interdependent with the design of the existing organisation.  (There are no case studies of large, bureaucratic, traditional organisations in the book, though I see the Matthew Skelton has worked in some).

Theory, practice, pragmatism:   The book scores well on the linkages of theory, practice and pragmatism.  There’s a helpful section in the Preface, ‘Key Influences that Informed this Book’

‘First, we assume that an organization is a sociotechnical system or ecosystem that is shaped by the interaction of individuals and teams within it; the authors are firm that they take a humanistic approach

Second, we assume that “the team” is something that behaves differently from a mere collection of individuals – several notable academics and writers are mentioned as sources here.

Third, we assume that Conway’s law (or a variant of it) is a strong driver of software product shape and that organizations would benefit from explicitly addressing the implications of this law.

Finally, we draw on numerous sources that describe practical successes developing and running software systems at scale.’

Overall, I fully recommend the book.  It is clearly written, easy to navigate (with suggestions on how do to so), well-illustrated with figures and graphics, call out and note boxes, and clearly based in author experiences.

What’s your view on designing around teams and a shared team goal? Let me know.

Image: The adaptable form of pleated and folded textiles provides a real world view of the mathematical field of topology. Kate Scardifield