Team Topologies: Organizing Business and Technology Teams for Fast Flow

In our ever-accelerating world, one of the fundamental qualities of a good system is its ability to change and adapt. This requirement applies both to companies wishing to keep pace with competitors as well as to the software supporting their business goals. Within the context of software systems, one of the best practices is to compose them of independent, goal-oriented components. If the architecture achieves the so-called “low coupling and high cohesion”, there is a good chance that new business requirements would result in quick changes in a single part of the system, as opposed to the lengthy, costly and error-prone releases which plague the mismanaged software. “Team Topologies” demonstrates that the pressure for adaptability should not only restructure the computer programs, but also - and maybe even more importantly - the IT departments creating them. In my opinion it is an excellent work showing that IT should be thought of holistically, not as separate parts of technical code and people’s organization. The basic premise of the book - that the structure of software reflects the organization building it - is not new. Known as the “Conway’s law”, the insight is over 50 years old. But I believe there weren’t too many titles so cogent in explaining its ramifications. In conscious embrace of Conway’s inevitability, the authors propose a toolkit of organizational building blocks - the eponymous team topologies - to use within software development structures. A team is meant to be “the smallest entity of delivery”; it is teams that build software, not individual engineers. Any team, to be valuable, should be long-lived, purposeful and autonomous. Under such conditions it is truly able to take ownership of the part of the system it develops, to build knowledge and to work with a minimized risk of errors. There are four proposed team types. Most engineers should be expected to work within “stream-aligned” teams, focused on delivering value for the customers. Other teams take a more supportive role - delivering platforms for developers, building complicated subsystems which require specialized knowledge, or enabling stream-aligned teams to gather new skills and practices. Team structures can be nested e.g. a platform can be internally developed by its own stream-aligned teams. In addition to team types, the book describes expected interactions between teams depending on their type and role in the project. In my opinion, Matthew Skelton and Manuel Pais make a compelling case that organizations applying the proposed approach - with team boundaries and responsibilities formed deliberately, which translates to proper boundaries and coupling within software components - can expect gains in the speed of delivery, as well as in software stability and employee morale. What is not stressed enough, in my opinion, is how difficult it is to design the aforementioned boundaries of responsibility of the team (and - by Conway’s law - of software built by it). From my experience it requires a deep knowledge of the business domain and is a daunting task for any large organization. The authors give a high-level overview of possible “fracture planes” (e.g. division by business domain, technology, customer type etc) but with only slight descriptions of how to find them precisely. In this regard, the book shows the end goal for how an IT organization should be structured without a detailed map on how to get there. It’s not a huge drawback, though, there is a lot of insights and knowledge to unravel nonetheless, I believe the book warrants multiple readings. I came to think that what “Team Topologies” propose is a convincing application of principles from agile and DevOps movements coupled with modern managerial practices, all while respecting Conway’s law. It is not a framework, though - I would rather call it a set of tools and insights to experiment with, regardless of any Named Frameworks™ your company might be using. All in all - I recommend this book to IT managers, architects, scrum masters and engineers interested in what happens outside of their teams. I guess it could be read by the business stakeholders as well, it is written in a way that won’t scare off non-technical people while giving insights on how IT could be more aligned with their needs. An instant classic if I ever saw one.

We read this book as part of a work book club and while there was a lot of good ideas and content, many found it tough to absorb and apply. Perhaps it was not the right read for us at the time but I definitely will continue to use this book as needed, just tough to sit down and read it consistently over a couple weeks.

You ship your org chart. Therefore, to fix shipping, fix your org first. This is often called the "Inverse Conway maneuver". Or, more verbosely, something like - "developing software is a socio-technical complex problem. We often naively focus on the technical part and only reactively look into the org part much later in the process. This should be turned around. Start with building the right org. In fact, the right org should be the very FIRST deliverable of a system architecture." All good, except there is no existing framework, empirical literature or large-scale study of "technical org design". That results in biased, reactive and unnecessarily nested, if not random, engineering orgs. To try to produce what we ought to, we lean into what we had in the past. That primarily results in huge communication overhead. This book methodically shows how to think and act on org design. It lays out four primary org types - value stream- (say, feature teams), enabling-, 'Complicated Subsystem- (say, databases or network), and Platform teams. It also shares three interaction modes these teams could work with each other - Collaboration, X-as-a-service and Facilitating. The 4x3 framework itself is a very powerful outcome from this. It also offers deep insights into composing, evolving and improving teams, and therefore the outcome of engineering orgs. Some key takeaways - -- Treat people & technology as a single carbon/silicon system. -- Hallmark of good org design is where the communication pathways converge with the org chart. Org-charts are top-down constructs, most human communication at the workplace is "lateral" - with their peers. Pay attention to this when taking an org chart driven decision, -- When a team's "cognitive capacity" is exceeded, the team becomes a delivery bottleneck. -- Conway's big idea really was this question - "Is there a better design that is not available to us because of our org?" An org has a better chance of success if it is reflectively designed. -- Orgs arranged in "functional silos" (e.g., QA, DBA, Security) is unlikely to produce well architected end-to-end flow. -- "Team assignments are the first draft of the architecture". -- "Real gains in performance can often be achieved by adopting designs that adhere to a dis-aggregated model". -- High performing teams, by definition, are long lived. Regular reorg for "management reasons" should be a thing of the past. -- Single team is typically upper bounded at a size of 15 people. That is the ceiling of people with whom "we can experience deep trust". -- Three types of cognitive load - Intrinsic, Extraneous and Germane. Germane is more domain specific - where value is added. Our goal therefore is to eliminate "extraneous cognitive load", e.g., worry-free, reliable build with automated tests should be a promise fulfilled. -- Rather than choosing the architecture structure (e.g., monolith etc), therefore a leader's objective function should be to manage the cognitive load of every team to achieve safe and rapid software delivery. -- High trust team management is essentially "eyes on, hands off". -- SRE teams are not essential, they are optional. The single most important "business metric" for SREs is "error budget". -- Designing platform team(s) is one of the hardest decisions. Left to engineers alone, Platform will be overbuilt. A 2x2 framework -- "Engineering Maturity" (High-Low) vs. "Org Size or Software Scale" (High-Low) is a good conceptual model to choose the right platform team model. e.g., for highly matured teams operating at a lower scale/size, individual teams could subsume platforms with right collaboration. Less matured orgs at a large size should lean toward the "Platform-as-a-service" model. -- 3 different dependencies between teams - Knowledge, Task and Resource. -- Only around 1-in-7 to 1-in-10 teams should be "non-stream aligned", i.e., one of the other three types - Platform, Complicated Sub-system or Enabling teams. -- "When code doesn't work...the problem starts in how teams are organized and how people interact." -- While we intuitively think of monolith as the "codebase", this mental model can be expanded. Monolithic Builds (when there is ONE giant CI, even with smaller services); Monolithic Releases (when different services still rely on one shared env for testing, say); Monolithic Standards (e.g., tight governance of tool/language/framework); Monolithic Workplace (e.g., Open-plan office). -- "Fracture Plane" (aka seam) is a good metaphorical framework to think about "how to divide teams". Such planes can be thought of from "bounded context" (i.e., business domain); Regulatory Compliance (e.g., PCI DSS/Payments); Change Cadence (e.g., annual tax vs. accounting modules); Risk (e.g., money movement, loan vs. dashboards); Performance (e.g., highly sensitive components vs. others); Technology (e.g., Rust, Golang etc); Geography (e.g., offshore vs. HQ etc). Traditionally, and unfortunately, we divide teams more on technology than on other, often more powerfully valid, dimensions. -- "If you have microservices but you wait and do end-to-end testing of a combination of them before a release, you have a distributed monolith". -- Intermittent collaboration is better than constant interaction. Collaboration leads to innovation, so do not suppress all human-to-human collaboration in naturally aligned teams, but pay careful attention to whether communication cost far exceeds collaborative benefits. Collaboration tax is worth it if the org wants to innovate very rapidly. Increased collaboration != Increased communication. -- Interaction modes between teams should be habits, i.e., a targeted outcome of org design. This is essentially what Jeff Bezos' famous "Teams only interact with each other with API or please leave" memo does. -- Be alert for the white space between the roles, gaps that nobody feels responsible for. -- Biggest change in last decade -- historically, "develop" and "operate" were two distinct serialized phases with one way arrow from develop to operate. The best orgs have a tight feedback loop from operating back to develop. Customers know the best! The "operate" phase emanates "bottom-up" signals from customers via logs, metrics and other data that developing teams must pay equal - if not more - attention to as it does from other "top-down" directives (say, from PMs). These are essentially "synthetic sense organs for the outside". -- Software is less of a "product for" and more of an "ongoing conversation with" users. This, to respond to users, MUST be an integral part of the development team's responsibility. This should not be forked out to a separate, isolated "BAU or Service Maintenance team". Excellent book - must read if you are leading teams that are growing.

Collaboration is good for innovation but increases cognitive load. And not all work is innovative. Managing this tradeoff between collaboration and focus is central to the theme of Team Topologies. Team Topologies presents some core patterns of team organization and communication that can help your team deliver effectively while minimizing (excess) communication overhead and maximizing necessary interactions. The authors emphasize that structuring your team isn’t simply something that you do once; you need to be alert to signs that your team (and architecture) need to be realigned. At first glance, this seems to be about “Conway’s Law,” and Conway’s observation that “organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations” is a central and recurring theme in the book. Team Topologies goes a bit deeper and presents some principles for defining and organizing your teams so that the teams and their communication structures support an architecture that makes sense (rather than the reverse). The book builds on various work around teams, teamwork, communication, and collaboration. While it did miss a few sources (such as [Thomas Allen](https://amzn.to/4cj0Lh8) for the role of office space in collaboration and [Organization Patterns](https://amzn.to/438d1N0) by Coplien and Harrison, it cites many essential works. Software architecture and technology problems can be challenging, but people architecture can be the more challenging of the two. Since teams of people build software, it’s important not to ignore the structure of your organization. While much work focuses on technology or technology, for complex systems, the interaction between people, processes, and technology is essential to understand since addressing issues on only one part might only be a short-term fix. Team Topologies can help you understand the role of the organization structure and dynamics in building good software architecture and data flow. If you want to understand how organization affects your architecture and how to work to align your team structure to get the architecture you want, this book is worth a look.

Skelton and Pais successfully demonstrate the powerful link between how software teams are organised and interact with each other and the corresponding impact on software change velocity and quality. This book is a quintessential guide on how to organise development and operations team to win in a rapidly changing business environment. While the ideas contained here on DevOps and Agile are not new the authors provide a detailed, thorough and practical guide on how to align business, dev and ops team to deliver. As it were, they answer the existential question on how to move from traditional functional teams to cross functional teams that follow agile and DevOps principles to delivery value faster. This book is a must read for any technology leader who wishes to successfully implement DevOps and/or Agile.

I hoped for a deep dive into the tradeoffs and tension between vertical vs horizontal teams (stream aligned vs the other three in the book’s parlance). Instead the first section contains countless quotes that are nice, but platitudinal. Then they provide basic introductions of their team types, then provide contextless examples of structuring a group of teams. There was no second order analysis such as observing the side effects and potential weaknesses or strengths or how to balance or offset these. It served as an okay list of definitions but failed to go further or provide a deeper look at the inherent tradeoffs or push and pull dynamics. To make the feedback explicit, one example of missing substance was a complete absence of the observation that service teams (all 3 kinds) inherently introduce the risk that product teams can become blocked because they must wait for the service teams to build and deliver their tools and services. What happens when the tools team needs 6 months to get their stuff ready? Should the product team work around them? What happens when the product teams implemented 10 ad hoc versions of the tools they were waiting for in the interim? How should you unwind this? Which is preferable, how do you weigh these tradeoffs?

Great read!

This is a totally unbiased review. I didn't get paid for this and I don't know the authors. This book covers every type of Team you could imagine for your business. The book is practical and makes you want to redo your whole org chart. If you're into Agile, Lean, or DevOps, please consider this book as a first step. The pages are in color and the illustrations are amazing. Kudos to the authors for imagining these concepts and bringing them to life. Big and small companies are using these topologies, so the sooner you learn them the better! Enjoy!

One of the only books I've found on team structures ( topologies) with large systems thinking. It felt unbiased with good references. Useful book to have in any leader/coaches arsenal.

Wie gestaltet man Team-Strukturen optimal und passt sie aktuellen Gegebenheiten an? Grundlage der Gedanken von Skelton und Pais sind die Erkenntnisse, die Conway bereits 1968 hatte: „Organisationen, die Systeme entwerfen, […] sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.“ Das bedeutet konkret für die Software-Erstellung, dass die Teamorganisation und die angewendeten bzw. etablierten Kommunikationsstrukturen das Ergebnis bestimmen. Es ist anzunehmen, dass dieser Ansatz auch für andere technische Entwurfsprozesse wie in der Elektronik-Entwicklung oder dem IT-Betrieb (Managed Services) gilt. Die Grundthese ist, dass man einen direkten Zusammenhang zwischen dem Produkt/Service und den Entwicklern/Ingenieuren herstellt, damit ein unmittelbarer Fluss und eine Rückkopplung entstehen kann. Das erinnert stark an die Paradigmen im agilen Setup. Bei diesen geht es darum, dass kleine Teams von 5 bis 10 Personen für konkrete Ergebnisse verantwortlich sind. Die These wird durch folgende, von Conway inspirierte Frage, noch weiter auf die Spitze gebracht: "Gibt es ein besseres Design oder eine bessere technische Lösung, das/die uns aufgrund unserer aktuellen Organisation nicht zur Verfügung steht?“ Damit man diese Frage regelmäßig beantworten, bearbeiten und diskutieren kann, benötigt man ein standardisiertes Set an Teamstruktur- und Kommunikations-Elementen. Genau um diese Elemente und deren Anwendung mit vielen Praxisbeispielen geht es in dem Buch. Man erhält einen Werkzeugkoffer zur iterierenden Verbesserung von Teamstrukturen. Vier Teamtypen … Der Aufbau und Betrieb eines Softwaresystems kann nach Ansicht der Autoren mit nur vier Teamtypen erreicht werden. Mehr Teamtypen können für eine Organisation aktiv schädlich sein, behindern aber auf jeden Fall die effiziente Weiterentwicklung. Es ist unbedingt darauf zu achten, dass jedes Team nur eine klar umrissene Aufgabe hat und in sich arbeitsfähig ist. Dafür muss es alle erforderlichen Skills wie Architektur, UX, Testing, Betrieb und auch Produktmanagement-Kompetenz mit an Bord haben. Die vier grundlegenden Team-Topologien sind: - Stream Aligned: ein Team, das auf den Hauptfluss der geschäftlichen Veränderungen ausgerichtet ist; mit funktionsübergreifendem Skill-Mix und der Fähigkeit, signifikante Inkremente zu liefern, ohne auf ein anderes Team zu warten. - Plattform: ein Team, das auf der zugrundeliegenden Plattform arbeitet und die Stream-aligned-Teams bei der Bereitstellung unterstützt. Die Plattform vereinfacht die ansonsten komplexe Technologie und reduziert die kognitive Belastung für Teams, die sie nutzen. - Enabling: ein Team, das andere Teams bei der Übernahme und Modifizierung von Software als Teil einer Übergangs- oder Lernphase unterstützt. - Kompliziertes Subsystem: ein Team mit einem speziellen Aufgabenbereich für ein Subsystem, das zu kompliziert ist, um von einem normalen Stream-aligned Team oder einem Plattformteam bearbeitet zu werden. Ein solches Team ist optional und wird nur dann eingesetzt, wenn es wirklich notwendig ist. Die Kombination dieser spezifischen Teamtypen ist alles, was für eine effektive Softwarebereitstellung mit schneller Anpassung an die Erfordernisse erforderlich ist. Die Interaktionsmodi zwischen diesen vier grundlegenden Team-Topologien sind jedoch von entscheidender Bedeutung für das Verständnis und die Förderung einer effektiven Softwarebereitstellung. … und drei Interaktionsmodi Eine effektive, moderne Organisation, die Software erstellt und betreibt, ist das Ergebnis von Interaktionen zwischen Teams. Doch viele Unternehmen versäumen es zu definieren, wie gute Team-Interaktionen aussehen. Das führt zu Verwirrung, Ärger und Ineffektivität. Es reicht nicht aus, einfach eine Reihe von Teams mit Verantwortungsgrenzen zu definieren, um ein effektives soziotechnisches System zu erzeugen. Man benötigt klar festgelegte Interaktionsmuster zwischen den Teams: - Kollaboration: Zwei Teams arbeiten für einen bestimmten Zeitraum eng zusammen, um neue Muster, Ansätze und Grenzen zu entdecken. Die Verantwortung wird geteilt und die Grenzen verschwimmen, aber Probleme werden schnell gelöst und die Organisation lernt schnell. - X-as-a-Service: ein Team nutzt etwas (z. B. einen Dienst oder eine API), das von einem anderen Team "als Service" bereitgestellt wird. Die Verantwortlichkeiten sind klar abgegrenzt – und wenn die Abgrenzung effektiv ist, kann das konsumierende Team schnell liefern. Das Team, das den Dienst bereitstellt, versucht daher, die Nutzung seines Dienstes so einfach wie möglich zu gestalten. - Erleichternd: Ein Team hilft einem anderen Team für einen bestimmten Zeitraum, neue Ansätze zu lernen oder zu übernehmen. Das Team, das die Erleichterung anbietet, möchte das andere Team so schnell wie möglich autark machen, während das Team, das die Erleichterung erhält, eine aufgeschlossene Einstellung zum Lernen hat. Die Kombination aus den richtigen Teamtypen und Teaminteraktionen bietet ein tolles Modell, teambasierte organisatorische Effektivität zu fördern und die Unklarheiten und Konflikte zu vermeiden, die viele Organisationen erleben. Die vielen Beispiele und konkreten Anwendungsfälle geben dem Leser die Möglichkeit, das Potenzial des Werkzeugkastens zu erkennen. Und vor allem wird klar, dass die Zeiten von statischen Organigrammen, die über Jahre gelten, mit dieser Methodik ein Ende haben. Denn auftretende Probleme werden iterativ korrigiert. Für alle Teammitglieder verliert diese Art von Veränderung ihren Schrecken, weil Umbauten über das Modell einfach und klar zu beschreiben sind. Das Buch nutzt dafür eine graphische Notation, so dass man die neuen Organigramme auch einfach an die Mitarbeiter kommunizieren kann. Noch etwas anderes wird mit diesem Modell klar: DevOps ist mit diesem Modell absolute Selbstverständlichkeit. Und ich gehe davon aus, dass auch Managed Service-Organisationen mit diesem Modell viel erfolgreicher werden können.

A good literature review and general coverage of teams and team interactions. Fairly well referenced and with quite a few case studies or real world examples. Sets out a thesis around the constraints and interactions implied by different team configurations, and a basic language for talking about and designing teams. I found it useful, and crystallised some thoughts on this topic and gave me plenty more directions to go to read more and think about this. Useful.

Excelente livro. Responde a várias questões da área de TI, principalmente por que aumentar a comunicação não resolve todos os desafios encontrados.

This book is valuable for almost everyone in IT. We need to understand why the company should do digital transformation and what is the impact on projects from the organizational structure. It will help people to understand why there are so many limits to delivery values rapidly and propose a proper team topology facing on diff situation. Also, the authors give us an idea about how and when to apply the new team topology. All the measures aim to stream more values. Those who work as a dev, qa, eng manager, director, enterpreneur...should understand the principle from the book. It will be a great acceleration in their career and business.