Book Cover
Rate this book
5 stars
1,676 (43%)
4 stars
1,474 (38%)
3 stars
538 (14%)
2 stars
110 (2%)
1 star
20 (<1%)
Displaying 1 - 30 of 353 reviews
Profile Image for Vlad Ardelean.
135 reviews25 followers
September 9, 2020
Far too bloated, but very nice references!

This video here: has one of the authors explaining what's in this book.

I made 135 highlights on kindle, so there has to be some value in it, but the book could easily have been made 5 times shorter.

Bits of information I remember and found interesting:
* Decisions should be taken by people who have the most information in order to make the decision.
* Reverse Conway maneuver: ensure teams can't communicate well, and the software they produce will have very clear boundaries
* Dunbar's number 7+-2: the optimal number of individuals on a team. Some teams could stretch this number to 15. Here "optimal" refers to social interactions. Above that number, people won't "trust" other people enough to work effectively with them.
* Dan Pink's 3 elements of intrinsic motivation: autonomy, mastery and purpose
* If we have managers deciding which services will be built by which team, we implicitly have managers deciding on the system architecture.
* If you don't want teams to communicate, give them separate tools (slack vs email vs JIRA, trello, hipchat, etc :P)
* 3 types of cognitive load: intrinsic (language syntax), extrinsic (deployment and how systems communicate) and germaine (business knowledge). Need to minimize the intrinsic and extrinsic and maximise the germaine kinds of knowledge, as business knowledge is what actully brings $
* 3 levels of system complexity: simple, complicated and complex. Simple = can fit inside one person's head and leave room; Complicated = can't fit inside one person's head, but they're traceable by a human mind; Complex = has non-intuitive/ non-deterministic behaviours and can't fit inside a single person's mind
* One team can support 2-3 simple domains OR 1 complicated+1 simple one OR 1 complex domain (rules of thumb)
* If a team has a complex domain, and a simple one, they might just end up solving the simpler problems and postponing the harder ones forever
* Team API: have a place that describes what the team does and how to interact with them
* put teams that naturally have a need to communicate, in the same space
* The ration between stream aligned and other types of teams should be between 6:1 and 9:1. Wow, lots of stream teams there!
* Monolith types: joint-at-the-db, monolithic build, monolithic release, monolithic model, monolithic workspace (come on, this one's stretching it!)
* Ways to break up a monolith: by business domain, change cadence, team location, risk profile, performance isolation (services supporting 3RPS on average, constantly vs services who stay down most of the year, but then need to process big data for Christmas), technology, user personas; And the test for the monolith split: does the new team architecture support more independent teams?
* Hand-offs between teams are bad
* Having teams that maintain systems and teams which build new systems seems to be an anti pattern; The team that built a system should operate it

4 Team types:
* Stream-aligned (the authors refuse to call them "feature teams" for some reason). These ship features. They're aligned to make changes where the business most requires them
* Complicated-subsystem teams: teams created from people who are basically all PHDs or work on very specialized things (image processing, NLP, etc). They probably act like platform teams.
* Platform teams: they create services that the stream-aligned teams will use
* Enabling teams: teams experienced professionals, going around and helping other teams in specific areas (for instance, specialized could infrastructure people, going around and helping other teams move to the cloud. Same for setting up CI/CD etc.)

3 Interaction modes:
* Collaboration: in this interaction mode, team boundaries are broken, the teams become one for a period of time. Like this, they can spot problems/innovate faster, but communication overhead is high.
* Facilitation: one team teaches the other some kind of technique, or helps the other team in some way.
* X-as-a-service: The teams are extremely separated, and communicate through clear interfaces (web services for example). This interaction mode optimizes for predictability of delivery, and it's the opposite to "collaboration" (so not optimal for innovation)

... so some interesting insights, probably backed by research done by other authors, reported in other books. This book is a good starting place and conversation-starter about team design. It's however too repetitive, and the case studies must be taken with a grain of salt, because it's kind of hard to support a model with just one anecdote.

The number of references quoted by this book is high, and at least the articles that I read are very qualitative. If you read this book, I think that the references should be mandatory read as well.

In the end though, I got left with the feeling that there's far more about team design out there than this book is addressing. For instance in "Leading the unleadable" a lot of personality quirks of team members get discussed. This book does not consider human beings as individuals. There's no mention even of seniority level in a book about team design, which I find kind of weird. Should we put 5 juniors together and call it a team? How about 5 seniors? The book presents some mental models about teams and how they collaborate, which is good, but a little too simplistic. What happens if you have introverts on the team, do you make them work in an x-as-a-service interaction mode, because they don't know/like to communicate with people? What do you do when you have a bunch of bored seniors, do you put them in enabling teams and let them walk around and be pedantic to other people? :D Does this book cover interactions with the marketing, sales, and account management teams as well? I get it that these topics are very complex, but would have been great if instead of being so repetitive, the authors would have acknowledged these topics, and declared them out of scope. The book explains too much what the book's purpose is, doesn't deliver enough information to reach that purpose, and leaves all other related topics completely out.
Profile Image for Sebastian Gebski.
981 reviews896 followers
October 14, 2019
I've openly criticized recent MS's book (the one about sketching) - as half-arsed, rushed & shallow.
I've speculated that one of the reasons could be that he was working (in parallel) on something else - "Team Topologies" - and TBH after reading it ... I feel like my guesses were correct.

Just because TT is so much better.

Good points. Good conceptual model (that appears comprehensive enough). Some very good remarks & references (e.g. to McChrystal or theory of org. structures). This books ain't long either (appendixes bloat it up a bit), but it's definitely "meaty". Don't get me wrong - one can easily "expand" the list of topologies presented here, but IMHO without adding much value.

I liked it. It provided a common way of thinking about team organization - one that IMHO will be very useful in my work. Again - it's not about revealing some hidden truth - MS is not a prophet, but the framing he does really helps with harnessing the topic. 4.2-4.5 stars, but rounded up to 5, because I already have a list of people I'd like to recommend it to.
Profile Image for Doc Norton.
Author 1 book22 followers
February 7, 2021
Good, but stretched into a bigger book. There are very valuable nuggets in here and many references to related and supporting books. But it felt stretched. I'd have preferred something half the length and believe the value wouldn't have been compromised.
Profile Image for Brice Beard.
1 review4 followers
November 12, 2019
Formatted review at

Team Topologies provides deep insight into organizing IT teams for high performance. It demonstrates why a team centric approach is critical to DevOps and Agile success.

For anyone leading team(s) or simply working in a team, you’re bound to learn a lot through the case studies and synthetic approach presented. You will acquire a new frame of reference to help evolve your team(s) or organization and improve Teamwork !

Software Architecture & Conway’s Law
“organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations” - M. Conway [1]

The book starts with a detailed analysis of Conway’s law and how it should inform team organization. The authors demonstrate that system architectures form, live and die with the teams implementing them through their interactions.

Teams effective delivery needs a compatible architecture driven by its ability to sustain Flow for the teams involved through scaling, change of focus, new features, ..

In effect, Team organization and Software Architecture are interdependent and they evolve in a symbiotic relationship. Check codescene that measures how your team organization and architecture align based on code commits.

Team First approach
The authors then analyze what makes teams efficient. They go in details on appropriate team size and also how to engage people and teams through empowerment alongside the dimensions of Autonomy, Mastery and (shared) Purpose [2].

A fundamental aspect explained is Team Cognitive Load, not quite the sum of team members ability, but a limit to take into account to ensure teams are not overwhelmed by the complexity of the software they own (guidance of one major and two minors systems per team).

Another way to control demand is to define a team API in term of SLA, error budget, documentation or any other way to interact with the team. This includes making independent technology choices as needed but normally rely on standard tools and process to make it easy to own part of a software stack.

Finally, a strong argument is made against cubicles and open space offices which actually reduce communication. Instead Office space should foster team efficiency by letting teams achieve some level of isolation (flexible partitions) as well as on-demand collaboration through pair programming/designing, whiteboards, writable walls or event spaces.

Breaking the Monolith to unleash Flow
“At a conceptual level, software architectures should resemble the flows of change they enable [ in business streams] (because a stream flows).” - Team Topologies

With the team first approach as a guiding principle and the need to align teams to your evolving architecture, the authors explain that a loosely coupled architecture based on highly cohesive components that are easy to test together is how teams achieve Flow.

They go in details on how to break monolithic aspects of your system along fracture planes to reach this architecture type. A strong case is made that while there are many ways to split your architecture ( Business Domain Bounded Context, Risk, Change Cadence, Team Location, User Personas, Technology, .. ), they are context dependent and definitely not equal in achieving Flow.

Microservices are often presented as an example of architecture that can decompose well with its independent services, provisioning model, monitoring and rapid deployment. But the authors warn that Flow is reached only with a Team centric approach that guarantees team ownership of components that are deployed independently with enforced APIs and often based on separate data models, storage and optimistic/resilient consistency.

Fundamental Team Topologies
With the argument built so far about autonomous teams, aligned to business and able to flow work as independently as possible, the fundamental team is not surprisingly described as a generalization of the classic Agile product/feature team.

These stream-aligned teams own their codebase and optimize their collaboration with other teams (great take on Lean Value Streams and Value Stream Mapping [3]. As one of the practical Tips enriching the book, you are advised to target a ratio between 7 and 10 to 1 between stream-aligned and other teams.

The other fundamental team types support the stream-aligned teams ability to flow changes.

Enabling teams help other teams to improve their capabilities from expertise and tooling to process and practice. The focus of Enabling teams is to grow the other teams and serve their journey towards autonomy, mastery and purpose [2].

Complicated sub-system teams should be an exception as they help take care of particularly complex part of the codebase, components that need the undivided attention of specialists. They help avoid the extreme cognitive tax that these complicated components would levy if owned by stream-aligned teams.

Finally, Platform teams deliver platform as a product to the stream-aligned teams, including the definition of pattern and common concepts [4]. They can have more focus on Tech aspects but need to understand product development as their role is to help optimize stream aligned teams delivery with a strong focus on DevEx.

These fundamental team types serve as role models other teams should move towards to optimize delivery. These types scale to the organization level as a self-similar or fractal model where say a platform team decomposes as a set of stream aligned teams delivering a platform product itself relying on a lower level platform team.

Note the absence of support or operation teams in the topologies, the analysis on why you don’t need them (while learning about Operation as a sensory mechanism) warrants to read the book on its own.

Team Interaction Modes
Considering how teams should interact is where the book starts to resonate into a powerful toolset to optimize delivery. The figure below shows team interaction modes in action.

The critical argument is that interactions need to be controlled. Collaboration (in red) has high (potential) value / high cost whereas X-asAService (chains) provides predictable delivery but with limited innovation opportunity.

Facilitating is the third and last interaction mode presented, referring essentially to how Enabling teams support the other teams with well described patterns and anti-patterns.

The figure below shows how collaboration can help define and put in place a Platform-as-a-Service relationship between a stream-aligned team and a platform team, a good way to ensure your platform evolves to purpose and focus on DevEx.

No alt text provided for this image
With the added insight that efficient interactions are focused, well bounded and intermittent [5], the interdependence between system architecture, teams and their interactions is now fully formed.

How to evolve Team organization
“Disbanding high-performing teams is worse than vandalism: it is corporate psychopathy.” - Alan Kelly, Project Myopia

Beyond building long lived performant teams who you move work to, an important point made here is the role of architects (not team of architects!) in helping shape and evolve team boundaries, interactions and system architecture in unison.

Another practical tip recommends to evolve different team topologies for different parts of the organization at different times to match the team purpose and events ( and avoid just another Re-Org ! ).

The book provides examples of successful changes in the small but the focus is on helping define and evolve a target. Beyond Teams APIs, Promise Theory [6] is mentioned several times as a way to improve interactions without enough details, a dedicated chapter would have been welcome.

Similarly, interaction with Business (teams) is not explained much and references to Inner/Open source are limited. This is a significant gap as the focus existing in Inner/Open source on architecture for participation resonates strongly with many aspects of the book. For instance an inner-sourced platform seems a good option to increase innovation in parallel to an X-as-a-Service interaction.

High trust organizations would also have deserved a separate chapter to explain how elements of the book apply to them and where they open up further options to reach the next level of Flow.

Finally, the authors could help refine a diagram type to represent teams and their interactions showing Value Streams at team level (maybe with help from Promise Theory ?). As an example, the team relationships should be directed. Also collaborations with hand off (say to an Ops team for release) could show differently given their Flow impact ..

Team Topologies brings together novel ideas and learnings complementing each other to demonstrate that a Team First approach to software delivery is critical to successful System Architecture and Team efficiency.

By defining Four Fundamental Team Types and Three Interaction Modes, the book provides a well thought toolset to help build an agile organization that supports stream-aligned teams to reach and sustain a faster flow of delivery.

So start thinking how you can Stream Align Me and help realize the full potential of your Team(s) and System(s) by reading and using Team Topologies !

Profile Image for Toni Tassani.
165 reviews11 followers
September 15, 2020
The authors evolve the idea behind DevOps Topologies into a model for or organisational design. They suggest four essential team types and three interaction models, and present multiple real cases where their approach was used. From that perspective, they try to cover aspects like finance, diversity, culture, maturity, support, office layout, or quality, with a clear focus on architecture, and Conway's Law.
Considering the team as the essential unit they pitch for team stability and cross-functionality, providing appropriate coaching and giving a clear and independent mission.

They provide a lot of statements as pieces of advice but let a lot of aspects uncovered, like management, team coaching, or external teams.

I didn't like that they quote a lot of books without context, finding a sentence that may cover their particular idea, even though the book being referenced defends a different position.
I didn't like the way they interpret Dumbar's number: 15, according to them.

Team Topologies approach is a simplification and some simplifications are useful. It may provide a vocabulary to discuss the organisation.
Profile Image for alper.
186 reviews44 followers
May 17, 2023
Çok hakim olmadığım bir konu, okurken zorlandım. Ama cehalet haritamda çok genişçe bir alanı doldurdu; anladığım kadarı bile. :) Çok şey öğrendim. Çok şeye hayret ettim. “Bizde şöyle” diye bir topa girmiyorum; odağımızı kaydırmayalım. Ekip kavramını ele alışı, otonomisi, sınıflandırması ve bunların birbiriyle etkileşiminin nasıl olması gerektiği, süreç içinde bu yapının dinamikliği işlenmiş. Çok sayıda örnek vaka ile somutlaştırılmış. Tabii bunlar içinde bulunduğu organizasyondan ve sistemden bağımsız ele alınmıyor. O açıdan çok başarılı buldum. "Accelerate" ve "The DevOps Handbook" (benim okuma serimde "Continuous Delivery" vardı, sıra bu kitaba da gelecek) kitaplarından çok sayıda referans ve alıntı var. Diğer kitaplarda da değindiğim bir konu idi. Özellikle "Accelarate"deki büyük resmi komple bir sistem olarak ele alınıp değerlendirilmeli. Burada da konular diğer konsept ve metodolojilerle birlikte ele alınmış. Doğru yolda olduğumuzun bir işareti olarak yorumlayabiliriz. :)
Kitap özelinde şu kavramlar hakkında bolca not almış, üzerine düşünmüşüm; değinilen konular hakkında bilgi verir belki diye paylaşıyorum:
More Autonomous teams, Team-First Thinking, Cognitive Load, Conway’s law, Dunways number, Stream-Aligned Teams, Complicated-Subsystem Teams, Platform Teams, Enabling Teams, Collaboration, X-as-a-Service, Facilitating…

Cephe gerçekten çok geniş. Sisteme bütünüyle bakabilmek, değerlendirebilmek sadece kendi tecrübelerimizle kotarılabiliecek bir konu kesinlikle değil (yani olmamalı). Okumaya teknik bilgimizi geliştirmeye devam…

Not: Bir konu da “lean software development” ama şöyle bir bakındım çok sıkıcı. O cepheyi bir süre daha açmam gibi duruyor.

Not2: Sırf "Cognitive Load" için ne ağıt yakılır be! Yok yok girmeyeceğim. :)
20 reviews1 follower
August 22, 2020
The main content of the book is worth a 4 or even 5 stars. But it also contains a considerable amount of fluff. And way to many quotes that disrupts the flow of reading, ironically, the word flow is used on almost every page of the book.
Profile Image for Willy Xiao.
34 reviews5 followers
January 2, 2022
After reading this book, I fundamentally don’t have the assumption that more collaboration and communication is “good.” I think this is an easy assumption to make in tech cultures with open floor plans, open-source documentation and code, and even in review cycles being asked to do team collaboration.

Team Topologies hints at such a core pain that I felt at Facebook for years seemingly without a solution: that of information overload in the software development lifecycle - stray quips or lost slack messages pervaded. It felt almost cathartic for team topologies to argue that you want to reduce inter-team communication and increase long-term unthrashed work via “fast flow.” With this core assumption - the book then dives into how to achieve this. A main takeaways are:

1. Design teams and organizations in a “reverse Conway” manner - in that it should imply a technological structure.
2. Have four different team types - stream-aligned, platform, enabling, complicated subsystem.
3. Have three different types of team communications - collaboration, x-as-a-service, and facilitating.
4. Identify moments that ought to trigger an organizational redesign.

Overall I think the book is probably really good for fast growing startups structuring their org for the first time, or any medium or large organization feeling like they’re getting inefficient with work.

I didn’t like the examples in the book so much and thought they could’ve been more software focused; I personally would’ve preferred examples from silicon-valley style companies, and sometimes I found the writing style hard to follow.

I would recommend this, though not emphatically. Similar to many books like this the core idea can sufficiently be communicated in a blog post, convincing the reader that it’s right is what takes a lot of time.
Profile Image for Cliff Hazell.
65 reviews13 followers
September 3, 2020
A must read for anyone designing teams, architecture or org structure.

The ideas around fundamental topologies and patterns, cognitive load and interaction types; are vital concepts beautifully captured by Matthew and Manuel.

Highly recommended
Profile Image for Lukas Vermeer.
311 reviews63 followers
July 11, 2023
This book could have been a blog post, and then I would not have minded the lack of substance as much. As it stands, hundreds of pages of hand waving to present an overly simplified model without ever going into the details or supporting evidence felt like a waste of time.

The four team types are not clearly defined or delineated. Many examples show that choice of type for a team is fuzzy and rather arbitrary. The book lacks clear guidance on how to make these choices.
Profile Image for Tõnu Vahtra.
550 reviews81 followers
January 23, 2020
Some theoretical books from IT Revolution Press can be extremely tedious (but still useful, like The DevOps Handbook), this one is actually very engaging to follow (I had to constantly make breaks to take notes) and it's not that long, merely 240 pages. I will definitely take this book into use in my work life (actually already did). It introduced a few new concepts and novel ideas to my everyday vocabulary like cognitive load, optimizing for FAST FLOW and high fidelity sensing (Cynefin was also briefly mentioned). I had been talking about complexity and complexity threshold but in some situations cognitive load suits better for explaining the same phenomena. There were many discussions about Dunbar's number and explanation on different optimal team sizes for specific challenges (15+ only for sharing information, up to 15 for actually working on something and not over 7-8 on focused high-intensity activities), the concept of trust is also bought into this discussion as enabler of trust. The book stresses the importance of keeping a team stable and minimizing interruptions. The reason why I would not give full 5 stars to the book was that the real-life examples were not very impressive by themselves (mostly just repeating the recommendations without specific context or challenges mentioned). Some of the examples also went a bit too far, for example a company was mentioned who did not allow employees to have more than one monitor "so that they could see themselves past the monitor". In general looking at the "inverse Conoway's law" is an interesting thought model (designing the optimal team structure to suit the available technologies).

“organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations” - M. Conway

Team Cognitive Load is not quite the sum of team members ability, but a limit to take into account to ensure teams are not overwhelmed by the complexity of the software they own.

A strong argument is made against individual cubicles and open space offices with long rows of desk that actually reduce communication (people tend to communicate more virtually). Instead office space should foster team efficiency by letting teams achieve some level of isolation while enabling cross team communication and on-demand collaboration through pair programming/designing, whiteboards, writable walls or event spaces.

“At a conceptual level, software architectures should resemble the flows of change they enable [ in business streams] (because a stream flows).”

STREAM-ALIGNED TEAMS are aligned to streams of work and own their codebase and systems, they optimize their interactions with other teams, they are able to flow work as independently as possible.

ENABLING TEAMS help other teams to improve their capabilities from expertise and tooling to process and practice. The focus of Enabling teams is to grow the other teams and serve their journey towards Autonomy, Mastery and Purpose.

COMPLICATED SUB-SYSTEM TEAMS should be an exception as they help take care of particularly complex part of the codebase, components that need the undivided attention of specialists. They help avoid the extreme cognitive tax that these complicated components would levy on stream-aligned teams.

PLATFORM TEAMS deliver platform as a product to the stream-aligned teams, including the definition of pattern and common concepts.

INTEGRATION MODES. Choice of interaction type needs to be selective and intermittent to streamline delivery. Collaboration has high potential value but high cost whereas X-as-a-Service (chains) provides predictable delivery but with constrain innovation. Facilitating is third standard interaction mode presented, referring essentially to how Enabling teams support the other teams with well described patterns and anti-patterns.

“Disbanding high-performing teams is worse than vandalism: it is corporate psychopathy.” - Alan Kelly, Project Myopia

Profile Image for Mindaugas Mozūras.
307 reviews169 followers
January 2, 2021
Team structures must match the required software architecture or risk producing unintended designs.

A must-read for anyone in a technical leadership role. Team Topologies explains the principles and patterns for successful team structures and efficient interactions between teams. The book is very concrete, practical, and contains useful examples.

While the content wasn't all new to me, I found it very well structured (ha), and it gave me fresh food for thought. We use many of the principles outlined here at Vinted, but often do it implicitly. I think that it might be worth considering making it explicit and base it on this book.
Profile Image for Sophie.
35 reviews12 followers
June 26, 2021
A good book that maps out different types of teams and collaboration approaches to successfully design a software development organisation. Now I can definitely better understand some of the organizational pain points I have observed in the past. The illustrations were also quite helpful to make abstract concepts more concrete. I recommend the book for product/tech leaders, who are the primary audience of this book. It took me a while to actually finish the book, mainly due to the vocabulary being sometimes unnecessarily complicated and sentences being a little dry. Several use cases also did not fully speak to me, possibly because they relate to companies I don't know.
Profile Image for Valerie.
259 reviews6 followers
October 31, 2019
Super interesting book for those tasked with organizational design. Filled with insights on how to structure your organization’s teams in a scalable way that both optimizes for delivery and takes a human-centered approach.

The writing was very dry — a bit white paper-ish — and could’ve used many more real-world examples to support the concepts they propose. Regardless, I found their lens for thinking about teams to be extremely valuable.
Profile Image for Radoslava Koleva.
110 reviews15 followers
January 1, 2023
As a head of product in a massive and - dare I say - a bit outdated in its ways technology organisation, I found this book very instructive. I find the domain of organisational design fascinating and highly appealing as a potential next step in my career.

The whole concept of Team Topologies revolves around the Conway Law: Organisations which design systems are constrained to produce designs which are copies of the communication structures of these organisations.

You can really relate to this if you've ever worked in a software company. It's another way of verbalising the phenomenon of displaying your org chart in your product, which is the proverbial biggest sin of product development. Nobody does it intentionally, and nobody wants it that way. But how do you change it? The forces of a highly complex software application have a willpower of their own. Team Topologies gives ideas how to improve the outcomes an organisation creates by starting with... the org chart. Design the teams in a way that reflects the software you want to develop, and Conway's Law will propel you to success, rather than act like an inevitable curse.

Apart from being full of applicable knowledge, the book is thoroughly researched and gives reference to a host of promising-sounding further reading such as 'Team of Teams', 'Project to Product', 'Guide to Organisational Design', 'Improving Performance: How to Manage the White Space on the Org Chart' - which are now all on my TBR list.

The reason why I rate is as 4/5 is that this book requires a decent amount of concentration and at times goes so high-level in its ideas that I found it almost philosophical. It also has a decent-sized section on designing physical space for effective collaboration but omg which business is fully co-located nowadays? To me that bit felt anachronistic.
99 reviews
April 1, 2021
Finally a fantastic book about org design specifically for building and running softwares. Many of the anti-patterns, cognitive overload, painful transition mentioned in the book, I have either experienced them myself and seen other teams struggling with them. The design is not new to me but still I wish I have read the book earlier and be able to articulate the design principles using the language from the book. Even more, I wish everyone in Engineering could talk in the same language: Conway's law, four team types, three interaction modes, team-first thinking etc.
Profile Image for Ieva Gr.
177 reviews31 followers
August 26, 2023
Why I read this book: It seems to be popular among the managers in my current workplace. I was always curious what the people that organize the ways we work are inspired by. Plus a colleague read it recently and seemed quite hyped about it.

How I read this book: I bought a copy a while ago, but never got around to reading it. So I decided to listen to an audio version first and see if there is something valuable for me there. Indeed there was as the book talks a lot about platform and enabling teams. I’m currently a part of a platform team and wanted to explore in more detail how the authors define them.

What I liked about it:

There were two topics that I was most interested in:

Cognitive load on software development teams. The authors seem to consider cognitive load on a team the main issue that we need to tackle to make the software development as efficient as possible.

“When cognitive load isn’t considered, teams are spread thin trying to cover an excessive amount of responsibilities and domains. Such a team lacks bandwidth to pursue mastery of their trade and struggles with the costs of switching contexts.”

This resonates with me very much. I’ve considered before that the breaking point when I decide to switch jobs or domains is when I can’t handle the cognitive load anymore. I had that experience a couple of times already: I join a product team (I’ve never worked for a project based software company), we work together for a couple of years and then we arrive at a point where we have e.g. 30 microservices to maintain, production incidents to respond to, interns to mentor and it all just becomes very difficult to handle. New members and even whole teams are usually hired during that period of time, but there is the thing with being one of the old-timers - people might want your input on things you built long ago. Or the thing with being a senior dev - at least I feel that I should pitch in not only in team scope, but also on the domain level.

The authors suggest to combat this by:
- Limiting the amount of work assigned to the team. Mainly by defining clear domain boundaries and assigning them to teams following such heuristics: a single team should be able to accommodate 2-3 simple domains OR 1 complex domain.
- Limiting the cognitive load not related with the business logic by creating platform, enabling or complex subsystem teams.
- Defining clear guidelines for communication between teams (collaboration, X-as-a-service or facilitation).

Platform and Enabling teams. From the above list the purpose of platform and enabling teams is the most interesting topic for me. Platform engineering seems to be a popular concept in the last few years, but different companies seem to define it rather differently. So I wanted to explore how it is defined in this book and how it is different from enabling teams. Here is what I found:

“The mission of a platform team is to reduce the cognitive load of stream-aligned teams (similar concept to product or feature teams) by offloading lower level detailed knowledge (e.g. provisioning, monitoring, deployment), providing easy-to-consume services around them. <…> The platform team’s knowledge is best made available via self-service capabilities via a web portal and/ or programmable API. <…> A good platform should make it easy for Dev teams to do the right things in the right way for the organisation. <…> Technology is only ever a part of the platform; roadmaps, guided evolution, clear documentation, a concern for DevEx, and appropriate encapsulation of underlying complexity are all key parts of an effective platform.”

“The mission of an enabling team is to help stream-aligned teams acquire missing capabilities, taking on the effort of research and trials, and setting up successful practices. <…> Jutta Eckstein calls them “Technical Consulting Teams”, a definition that maps well to what we’d expect a consulting team to provide (guidance, not execution).”

What I disliked: I felt some confusion between the roles of platform and enabling teams. The responsibilities like provisioning, monitoring, deployment were mentioned in the definition for the platform team. But there was also this quote for enabling teams:

“Often they are focusing on more specific areas, such as build engineering, continuous delivery, deployments, or test automation. For example, the enabling team might set up a walking skeleton of a deployment pipeline or a basic test framework combining automation tools and some initial scenarios and examples.”

At the very end there was also a quote “organizations should expect teams to collaborate to discover new patterns and execution models, then push these down into the platform and supporting tooling”. This would suggest enabling teams collaborating with product teams and finding new ways and tools of working and then platform team converting them to a stable and mature service when the time comes. But this idea wasn’t expressed explicitly anywhere. Collaboration with teams to achieve as good developer experience was also mentioned for platform teams.

The book is a very lightweight read. I’ve read it cover to cover and wrote down my thoughts in 5 days. I think it mostly serves as a good motivator to hire the authors as consultants for your organization. I imagine it to be a really long road to implement this in practice, especially in a large organization. A lot of the things mentioned here are very complex. For example: finding the correct domain boundaries. I once participated in a two-day workshop with a Domain Driven Design guru dedicated to this very cause and I wouldn’t say I was very happy with the outcome. I believe it is a similar case with defining the boundaries of the platform. I’m afraid that if you encapsulate away too much from the developers they might lack knowledge to make the right decisions. There is also the question of resources. It would be ideal to have optimal cognitive load on each team so its members would also have the capacity to innovate. But there might not be enough developers in the organization and no resources to fill the gap.
Profile Image for Eduards Sizovs.
117 reviews160 followers
March 1, 2020
As a seasoned Continuous Delivery and DevOps practitioner I didn't expect to find something new, but this book positively surprised me. Team Topologies is a great read about scaling organizations and software development. In fine detail, with concrete practices, it explains how to (re)-structure your teams to achieve flow. It's well-written, well-structured, and has lots of take-aways.
Profile Image for Roman.
135 reviews80 followers
December 10, 2020
Tohle je jedna z nejzasadnejsich knih, ktere jsem cetl, a ktera mi pomohla uvedomit, proc organizacni struktury a tymy selhavaji. Kniha vychazi a podle me dokonale vysvetluje vsechny konsekvence Conwayova zakona a jeho vyuziti pro shaping tymu a jejich “rozhrani”. Jestli bych mel doporucit jednu pracovni knihu pro rok 2021, byla by to tato.
Profile Image for Renan Ivo.
20 reviews1 follower
October 26, 2021
A great book about people, communications and culture impact in system design and software architecture. If it had another title, it should be "Applied Conway's Law".
Profile Image for Amir Sarabadani.
60 reviews43 followers
August 20, 2022
One of the worst books I've read. Both in content and writing. My criticisms of it would fill a book.
Profile Image for Zowie.
7 reviews13 followers
April 2, 2022
Insightful, well structured, and written in an accessible way. It can be a bit repetitive at times though.

I would recommend this book to any manager, lead or executive working directly with software development teams.

There is one criticism I have: this book properly articulates the dynamic and complex world of team-based software development, but IMHO spends inadequate time walking you through the pitfalls that are a consequence of such a complex sociotechnical system.

Naturally, you have to interpret these org models within your specific context and adapt them to the environment you're in (the book does a good job of preparing you for that). But it can come across as a 'one size fits all' recipe at times, because little time is spent explaining when timing might not be right - yet - to implement Team Topologies, or where you might encounter roadblocks.

Bottom line: definitely worth reading, but no silver bullet.
Profile Image for Sebastian.
39 reviews
January 3, 2022
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.
Profile Image for Fermin.
21 reviews1 follower
January 15, 2022
Team Topologies propone un framework para montar equipos tecnicos de alta performance basandose en la ley de Conway, es decir, basandose en la estructura de comunicacion y no en la tecnologia.
Junto con accelerate, forman dos libros que pueden servir de inicio para cualquiera empresa mediana/grande q tenga problemas con la entrega de los equipos.
PD: aun no he probado el framework, no se si funcionara, pero tiene buena pinta
Profile Image for Vasya Rudas.
13 reviews
September 28, 2023
Book helps better understand how organization can be built to achieve a fast and independent delivery of new products by using Conway’s Law and four fundamental team types:
- Stream Aligned for regular domain work
- Platform for simplifying infrastructure of SATs
- Enabling for facilitating usage of modern technologies
- Complicated Subsystem for complex domain work
Profile Image for Bjoern Rochel.
377 reviews71 followers
December 13, 2019
Quick, very insightful read centering around the ideas of Conways Law, Dunbars number and Cognitive Load and their effects on organizational design.

Good and useful stuff to reason about team structures in an organization!
Profile Image for Dominykas Punis.
14 reviews2 followers
December 13, 2020
One of the best books on organisational design, especially in technology sector. While mostly applicable to larger organisations with 15+ teams, it's also very useful for companies at a growth/scaling stages. It's mostly based on Conway's law and talks about 4 fundamental team types and 3 cross-team communication methods that companies should follow.
Profile Image for Denis Vasilev.
648 reviews93 followers
September 27, 2022
Паттерны создания продуктивных команд в разработке и способы коммуникации. Указанную тему книга адекватно раскрывает, так что если интересуетесь - непллохо
Profile Image for Simon Hohenadl.
235 reviews10 followers
September 8, 2020
Not much new here for me, but a very good overview of the topic. A must-read for people taking on responsibility for software development teams.
Displaying 1 - 30 of 353 reviews