Scan barcode
makragic's review
3.0
Nice read, but far too wide in my opinion.
It discusses which team structures are optimal (4 groups - streamlined teams, enabling teams, complicated sub-systems teams, and platform teams), when to limit the team size (Dunbar groups), how Conway's Law affects the architecture, what are all the things you should worry about when aiming to reduce the team's cognitive load (e.g. breaking monoliths, etc.), how teams should interact with one another, etc.
There are some valuable insights in this book, but it also contains a considerable amount of unnecessary quotes that disrupt the flow of reading (which is ironic, considering they are talking about the cognitive load on almost every page). I also expected to read more on how to transition into correct topologies, although they cover that topic to a certain extent, I don't feel like it can be done seamlessly or at all in the majority of the organizations. Perhaps if the authors focused more on real-life examples, they could have clarified some of the questions that I had.
Short summary: https://www.linkedin.com/pulse/stream-align-me-brice-beard/
It discusses which team structures are optimal (4 groups - streamlined teams, enabling teams, complicated sub-systems teams, and platform teams), when to limit the team size (Dunbar groups), how Conway's Law affects the architecture, what are all the things you should worry about when aiming to reduce the team's cognitive load (e.g. breaking monoliths, etc.), how teams should interact with one another, etc.
There are some valuable insights in this book, but it also contains a considerable amount of unnecessary quotes that disrupt the flow of reading (which is ironic, considering they are talking about the cognitive load on almost every page). I also expected to read more on how to transition into correct topologies, although they cover that topic to a certain extent, I don't feel like it can be done seamlessly or at all in the majority of the organizations. Perhaps if the authors focused more on real-life examples, they could have clarified some of the questions that I had.
Short summary: https://www.linkedin.com/pulse/stream-align-me-brice-beard/
mauricereeves's review against another edition
3.0
One of my coworkers mentioned this book to me when discussing models for setting up software development teams. I am looking to get more into management and have seen some other organizations using this methodology as well so I grabbed the book.
While I think that it had some interesting things to say, I wasn’t overly impressed with it. A large chunk of the book centers on Conway’s Law (a company ships its org chart) and it doesn’t necessarily need 216 pages to explain it further. It also spoke in pretty glowing terms about the “tribes and guilds” model that Spotify set up, when it turns out that wasn’t really that successful at Spotify, and maybe shouldn’t be the linchpin of your theory for team organization.
I also didn’t find many of the case studies that compelling or even explanatory. They felt like extra material and I ended up skipping some because they weren’t really helping me.
All in all this felt like a really good academic paper that was upsized into a book, and by nature of being expanded and inflated it became overwrought.
I will still ruminate on it and see if I can take anything useful from it.
While I think that it had some interesting things to say, I wasn’t overly impressed with it. A large chunk of the book centers on Conway’s Law (a company ships its org chart) and it doesn’t necessarily need 216 pages to explain it further. It also spoke in pretty glowing terms about the “tribes and guilds” model that Spotify set up, when it turns out that wasn’t really that successful at Spotify, and maybe shouldn’t be the linchpin of your theory for team organization.
I also didn’t find many of the case studies that compelling or even explanatory. They felt like extra material and I ended up skipping some because they weren’t really helping me.
All in all this felt like a really good academic paper that was upsized into a book, and by nature of being expanded and inflated it became overwrought.
I will still ruminate on it and see if I can take anything useful from it.
bookanonjeff's review
informative
inspiring
lighthearted
reflective
medium-paced
5.0
Theory + Application And Hefty Respect For Those Who Came Before. One thing that sometimes gets lost in the world of computing - specifically among those of us who make a career specifically inside this field of software development - is an appreciation of the history of the field before us. As a student many moons ago (I finished my degree requirements just over 20 yrs ago as I type this, ugh!), one of my favorite professors, one I talk about to this day, was a guy who had gotten his PhD from Harvard in the 60s in Mathematics and had come up through the early days of computing. We could get him talking about those early eras and... magically, class time was up before his stories were. :D Fascinating, but yes, as students we absolutely had ulterior motives there. :D
Getting back to this book and the contents thereof, one of the things I like about it is that it so heavily references not just fairly cutting edge research (some apparently published as recently as 2017, compared to this text's 2019 release date), but also *far* earlier results that *still* drive this industry, including the Mythical Man Month - introduced to me by the professor I discussed above, and the connection to this text - and Conway's Law - which was *not* a topic we studied in my Computer Science classes in college, but which proves interesting and, according to these authors, still extremely relevant to how teams are organized within computing to this day.
This book, along with Mik Kersten's Project to Product, was recommended to me by my Group Manager as I begin to truly look into where I want the next half of my career to go, and like that book, thinking about computing and, in this case, how teams within computing are organized and communicate both within themselves and within the overall organization is a different level of thinking than I, a Senior Software Developer "crewdog" coder to this point, have ever really given any thought to... and yet is as fascinating a space as any I've encountered as a coder. Indeed, having read both of these texts just a couple of days apart at the end of 2023, I find myself truly intrigued by the possible problem sets at these higher levels - and how to bring my experience as a "crewdog" to bear in working within them within my organization.
Truly a thought provoking text, particularly for those who either start out wanting to go straight into IT Leadership or perhaps those similar to myself who find themselves at mid career with Leadership as one of the few remaining avenues of career progression. This is one I believe I'll be coming back to in text form and referencing for some time, having listened to the Audible version this time (and thus having no real sense of how extensive the bibliography for this book actually is). As this one is filled with both theory *and* application, it at least provides some insight into how the theory *can* work "in the real world", making its points all the stronger for having this blend.
Very much recommended.
Getting back to this book and the contents thereof, one of the things I like about it is that it so heavily references not just fairly cutting edge research (some apparently published as recently as 2017, compared to this text's 2019 release date), but also *far* earlier results that *still* drive this industry, including the Mythical Man Month - introduced to me by the professor I discussed above, and the connection to this text - and Conway's Law - which was *not* a topic we studied in my Computer Science classes in college, but which proves interesting and, according to these authors, still extremely relevant to how teams are organized within computing to this day.
This book, along with Mik Kersten's Project to Product, was recommended to me by my Group Manager as I begin to truly look into where I want the next half of my career to go, and like that book, thinking about computing and, in this case, how teams within computing are organized and communicate both within themselves and within the overall organization is a different level of thinking than I, a Senior Software Developer "crewdog" coder to this point, have ever really given any thought to... and yet is as fascinating a space as any I've encountered as a coder. Indeed, having read both of these texts just a couple of days apart at the end of 2023, I find myself truly intrigued by the possible problem sets at these higher levels - and how to bring my experience as a "crewdog" to bear in working within them within my organization.
Truly a thought provoking text, particularly for those who either start out wanting to go straight into IT Leadership or perhaps those similar to myself who find themselves at mid career with Leadership as one of the few remaining avenues of career progression. This is one I believe I'll be coming back to in text form and referencing for some time, having listened to the Audible version this time (and thus having no real sense of how extensive the bibliography for this book actually is). As this one is filled with both theory *and* application, it at least provides some insight into how the theory *can* work "in the real world", making its points all the stronger for having this blend.
Very much recommended.
erikars's review against another edition
5.0
Team Topologies is an excellent read. It reframes how we understand and design team structures for the efficient delivery of value. Grounded in the inescapable Conway's Law, the book encourages organizations to embrace this law and design their teams around the value they want to deliver, rather than fighting against it. The implication is that teams, not individuals or larger organizations, should be the fundamental unit of delivery.
The book introduces four fundamental team topologies: stream-aligned teams (the core unit of value delivery), platform teams, complicated subsystem teams, and enabling teams. These topologies provide a foundation for building teams that facilitate fast flow and reduce the load for stream-aligned teams. However, these are not one-size-fits-all structures. Organizations will need to determine what works best in their specific context.
Critical to this model is the acknowledgement is that organizations are sociotechnical structures. The book emphasizes the importance of understanding our systems as comprising both technical and human components. This perspective acknowledges that teams are more than collections of individuals and have cognitive load limits. As such, organizations should structure their work around small, stable, long-lived teams, respecting their cognitive load for maximum effectiveness.
The authors note the perhaps-surprising idea that not all communication between teams is beneficial. Problematic communication patterns can indicate a mismatch between our technical architecture and our organizational design. This makes the case for applying Conway's law to our advantage, ensuring that our organizational structures match the software architecture we want to deliver.
A key strength of the book is its practical approach. The authors don't just present theoretical concepts, but they offer a set of tools for designing effective team structures. They discuss the process of splitting systems and organizations into team-sized units along "fracture planes" for increased flow and autonomy. They also define interaction modes between teams, including a close collaborative relationship, X-as-a-Service, and facilitating. These insights act as a guide for identifying when structures need to be updated.
It's crucial to note that team structures aren't static. They will, and should, evolve over time. Sensing capabilities are needed to identify when changes are necessary, and organizations must foster close collaboration between system developers, operators, and supporters to make this possible.
Team Topologies is a compelling read that promotes a dynamic, value-focused approach to defining teams. I found that the principles in this book aligned well with my general philosophy, making it a highly recommended read for anyone involved in organizational design for software systems.
The book introduces four fundamental team topologies: stream-aligned teams (the core unit of value delivery), platform teams, complicated subsystem teams, and enabling teams. These topologies provide a foundation for building teams that facilitate fast flow and reduce the load for stream-aligned teams. However, these are not one-size-fits-all structures. Organizations will need to determine what works best in their specific context.
Critical to this model is the acknowledgement is that organizations are sociotechnical structures. The book emphasizes the importance of understanding our systems as comprising both technical and human components. This perspective acknowledges that teams are more than collections of individuals and have cognitive load limits. As such, organizations should structure their work around small, stable, long-lived teams, respecting their cognitive load for maximum effectiveness.
The authors note the perhaps-surprising idea that not all communication between teams is beneficial. Problematic communication patterns can indicate a mismatch between our technical architecture and our organizational design. This makes the case for applying Conway's law to our advantage, ensuring that our organizational structures match the software architecture we want to deliver.
A key strength of the book is its practical approach. The authors don't just present theoretical concepts, but they offer a set of tools for designing effective team structures. They discuss the process of splitting systems and organizations into team-sized units along "fracture planes" for increased flow and autonomy. They also define interaction modes between teams, including a close collaborative relationship, X-as-a-Service, and facilitating. These insights act as a guide for identifying when structures need to be updated.
It's crucial to note that team structures aren't static. They will, and should, evolve over time. Sensing capabilities are needed to identify when changes are necessary, and organizations must foster close collaboration between system developers, operators, and supporters to make this possible.
Team Topologies is a compelling read that promotes a dynamic, value-focused approach to defining teams. I found that the principles in this book aligned well with my general philosophy, making it a highly recommended read for anyone involved in organizational design for software systems.
tomcat0's review against another edition
3.0
The thoughts and ideas in this book seem very helpful and are described in good detail. However it really only helps if you are either in charge of multiple teams or in charge of a team that interacts a lot with other teams, which is usually not the case for me. It's not completely applicable to delivering distinct software projects for an external customer. I did skip a lot of pages describing problems that I don't really have.
I did still take away some bigger ideas on how teams should work, how to structure a team's work, etc. If I'm ever in a situation with multiple teams or a project with multiple systems, I will surely re-read it.
I did still take away some bigger ideas on how teams should work, how to structure a team's work, etc. If I'm ever in a situation with multiple teams or a project with multiple systems, I will surely re-read it.
teibrich's review against another edition
5.0
This book is excellent! It provides a clear, simple mental model to think about organizational structure and how teams might best interact and work with each other.
At its core, there are 4 different team types (stream aligned, platform, enabling, and complicated subsystem) and 3 modes of interaction (collaboration, facilitation, and providing a service through a clear interface). This alone is extremely helpful as it harmonizes terminology.
The other 3 take-aways for me were:
(1) Conway's Law which shows you tightly coupled and interconnected organizational structure and software architecture are
(2) Dunbar's number and the limits of scaling that come with it
(3) the thought that more communication is not necessarily better. The focus should rather be on consciously designing communication paths that account for cognitive load and enable flow.
Thanks a lot for sharing! I'm fairly sure I will continue working with these terms and visualizations for a while!
At its core, there are 4 different team types (stream aligned, platform, enabling, and complicated subsystem) and 3 modes of interaction (collaboration, facilitation, and providing a service through a clear interface). This alone is extremely helpful as it harmonizes terminology.
The other 3 take-aways for me were:
(1) Conway's Law which shows you tightly coupled and interconnected organizational structure and software architecture are
(2) Dunbar's number and the limits of scaling that come with it
(3) the thought that more communication is not necessarily better. The focus should rather be on consciously designing communication paths that account for cognitive load and enable flow.
Thanks a lot for sharing! I'm fairly sure I will continue working with these terms and visualizations for a while!
lischa3000's review against another edition
2.0
Knowledgeable, but really boring. Felt like reading course material at uni.
kepheus's review against another edition
3.0
This is a quintessential "should have been/stayed a blog post" book. If you want to read this, start with the conclusion and, if you have any questions, backtrack to the relevant section. You likely won't because it's fairly self-evident. For example, narrowing team types and communication styles to a minimal set. Just make sure you pay attention to the part about cognitive load because I've been on very few teams that didn't have this problem.
books_are_nice_and_enjoyable's review against another edition
4.75
Recommended.
I read this book after reading Sam Newman's Microservices book - he covered some of the ideas included in the book in his coverage, and those ideas seemed important enough for me to decide to read this book in full after I'd finished Newman's coverage.
This is an important book you'll probably want to read. The evidence the authors present in favor of their claims is limited and in my view somewhat inadequate, but there are some really important ideas included in this book. The ideas are important in part because people who really ought to know those things ...usually can not be expected to do so, and the fact that they do not have this knowledge will lead to suboptimal outcomes.
I read this book after reading Sam Newman's Microservices book - he covered some of the ideas included in the book in his coverage, and those ideas seemed important enough for me to decide to read this book in full after I'd finished Newman's coverage.
This is an important book you'll probably want to read. The evidence the authors present in favor of their claims is limited and in my view somewhat inadequate, but there are some really important ideas included in this book. The ideas are important in part because people who really ought to know those things ...usually can not be expected to do so, and the fact that they do not have this knowledge will lead to suboptimal outcomes.
meelik's review
3.0
A good book for falling asleep...
Essential things are written, unfortunately, in a highly complex tone. The book could benefit from removing bloat and repetitions and changing the language into less academic.
Essential things are written, unfortunately, in a highly complex tone. The book could benefit from removing bloat and repetitions and changing the language into less academic.