Team Topologies

Today I’m covering the 2019 book "Team Topologies: Organizing
Business & Technology Teams for Fast Flow" written by Matthew
Skelton & Manuel Pais.



Let me read off their official bio:
Matthew Skelton and Manuel Pais - co-authors of the book Team
Topologies - have worked together on organisation design for modern
software systems with many clients around the world. Their training
sessions on Organisation Design for Modern Software Systems have
helped numerous organizations to re-think their approach to team
intercommunication and software architecture, improving flow and
the effectiveness of software delivery.


So I’m stoked to finally discuss Team Topologies on Small
Batches. This book has come up so many times in my work as an SRE
at Skillshare and tangentially related to everything I’ve
discussed on Small Batches to date. This is because team
architecture and software architecture are directly related to
software delivery performance.



That’s particularly why I enjoyed Team Topologies so much because
it’s truly a book about high velocity software delivery. In fact
it’s right there smack in the title. Plus it provides a language
to discuss this facet of software delivery.



You’ve likely encountered some of these concepts before, so this
time around it may just be a new language.



I’ll share a personal anecdote from earlier in my career to set
the stage for this episode. 



Roughly fives years ago I lead the platform team through a
complete ground up rewrite at a previous company. We were divided
into technology teams: The web, mobile, and platform team. Given
these boundaries each of respective team lead set out to create
their internal architecture. Nothing to see here: just Conway’s
law in action. It worked well here because we had isomorphic
technology and team architecture. 



Then something happened out of the blue shortly after the rewrite
completed. 



The organization went through a total re-org that changed the
team structure, their responsibilities and how they interacted
without doing anything to address the underlying technical
architecture. This created confusing boundaries, ownership
responsibilities, and left so called "independent feature teams"
at the mercy of the small number of capable backend engineers
capable of working across the various internal services. 



These problems could have been avoided with some foresight and
planning. Plus it’s especially bothersome because the entire
engineering team had just finished a ground up rewrite that
architected a system to support an entirely different team
topology! If there was ever a time for a reverse Conway maneuver
that was not it.



This example speaks to the importance of Conway’s law and how
team and software architecture fit together to create fast flow
or on the other hand just inhibit it.



Team Topologies provides a framework that avoids this problem
from the outset by optimizing for fast flow.


Links


Small Batches #34: Team Topologies with Matthew Skelton

@Manuelpaisable

@MatthewPSkelton

Buy Team Topologies

Monoliths vs Microservices is Missing the Point—Start with
Team Cognitive Load @ DOES Europe 2019

Team Topologies Posters

Team Topologies on Mik Plus One

Team Topologies at Parts Unlimited w/Manuel Pais

The Idealcast # 5: The Pursuit of Perfection: Dominant
Architectures, Structure, and Dynamics: A Conversation With Dr.
Steve Spear




Support this podcast on Patreon