Today we begin the re-read of Team Topologies: Organizing Business And Technology Teams For Fast Flow by Matthew Skelton and Manuel Pais. The book contains front matter, including a foreword and preface (22 pages), 8 chapters, a conclusion (190 pages), and end matter (glossary, recommended reading, references, notes, index, acknowledgments, and about the authors).
The Foreword written by Ruth Malian sets the stage by calling out how the book addresses the design of software development organizations. One of the main points of the Foreword is that as the complexity of systems increases so do the cognitive demands they levy on the organizations around them. This is one of Lehman’s Laws of Software Evolution. Lehman’s nine laws were new to me; I have at last partially rectified the omission in my education (Wikipedia). As complexity increase,s the amount of physical and mental effort required to control the flow of work increases. It might sound like the prescription for complexity is mercilessly adopting simplicity. That, however, is too simple. The goal is always to keep teams and processes as simple as possible. In practical application, the phrase, “simple as possible” is ambiguous. For example, who’s simple are we shooting for? Lehman’s Laws fits with Conway’s Law which is referenced in both the Foreword and Preface. Conway’s Law states that organizations design systems that mirror their internal communication structure.
In the Preface, the authors explain the rationale for the book and the three major assumptions that underpin the book. The assumptions are:
- The organization represents an interaction of people and technology.
- Teams are central to getting work done.
- Conway’s Law is true.
I’d like to return to the second assumption for a bit of a deeper dive. The authors assume that teams are teams, not just assemblies of individuals. As we have noted in the past, this isn’t always true. Pushing aside that possibility for a moment, teams exist at all levels of an organization. A working group of board of directors members can be a team. A group of software developers can be a team. The day of the rugged individual toiling in their basement or garage to build the next big software application is gone, faded into the sunset. Look around your place of employment, how many individual contributors do you know? When I first started my career, I could point to many examples; now I am hard-pressed to bring any to mind. The solutions we build require people to coordinate and communicate with the solver. Not that pure individual contributors don’t exist, but even most janitors are a team working toward a common goal. I think that the understanding of team design and how that design impacts performance would be table stakes for a seat at the leadership table. Read along and let’s discuss whether my assumption is true.
Re-read Logistics: I am currently planning for this re-read to run 12 -14 weeks (including today) beginning April 1st and ending somewhere between June 17th and July 1st. The timeframe is premised on re-reading a chapter per week but with the possibility that a couple of chapters might require two weeks to consider. I have also inserted a week as a potential buffer.
As you are reading along, consider listening to Ben Woz’s discussion of the ideas in the Team Topologies released as part of SPaMCAST 683 http://bit.ly/3ZFuidq Also like Extraordinary Badass Agile Coaching (the re-read we just completed), I will reach out to the authors to see whether we can arrange an interview as the capstone for the re-read.
Buy a copy of Team Topologies and re-read along.
