Team Topologies
Recap of the 2019 book "Team Topologies: Organizing Business and Technology Teams for Fast Flow".
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
Creators and Guests
