Thoughts about "Team Topologies" by Matthew Skelton and Manuel Pais

This time, let's talk about "Team Topologies: Organizing Business and Technology Teams for Fast Flow," a book about organizational design written by Matthew Skelton and Manuel Pais.

Looking at the title, this book is not about product management or business analysis...

Yes, you are right. This book is about constructing teams and establishing their interactions. It is not about my day-to-day work, but it is an area of my concern. I tend to read general books about management more and more. So we will discuss more such books in the future.

How did you find out about "Team Topologies"?

I heard about it during the Platform Engineering fundamentals course brought by Tyk (I have a fancy certificate, by the way). There were a lot of references to that book, so I decided to add it to my reading list. It is funny, but "Team Topology" references many other sources but combines them into a solid idea.

The book basically addresses the most common problem, probably on the humanity level.

What kind of problem do you mean? We have plenty of those.

Communication. The lack of it, to be precise.

It is the most crucial aspect of any organization, but we discuss software development here and in the book. I have almost a decade in the industry, and how communication is defined within an organization causes the most severe problems. That is why the team structure, or topology, is so important.

And the book addresses that: not answering all questions (no silver bullet), but giving guidance at least.

Ok. What is the main idea of the book?

We should build the system architecture and then define the team structure using specific principles. Also, while the architecture evolves, the team topology should also evolve to address the changes.

Key takeaways:

• Four fundamental team types:
  • stream-aligned
  • platform
  • enabling
  • complicated-subsystem
• and three core team interaction models:
  • collaboration
  • X-as-a-service
  • facilitation

The current issue is that managers are building the organization structure, architectures are designing systems, and in the end, those things do not match well with each other. Those sides usually don't interact mostly because they are structured to exist in silos.

That is all about Conway's law, which states that organizations build systems similar to their communication structure (my interpretation). So no matter how good your new design is, if your org structure is not flexible to adapt it, you are fucked doomed anyway.

Also, take into account the rising complexity bar with cloud, microservices, DevOps, and now AI on top of that. The approaches that worked for ten years with dedicated front-end teams, who interact with back-end teams and who interact with database administrators, are not working anymore. You can still develop software in the old way, but that does not allow you to compete with big guys.

So the book suggests utilizing, quoting:

... "inverse Conway maneuver" (or reverse Conway maneuver), whereby an organization focuses on organizing team structures to match the architecture they want the system to exhibit rather than expecting teams to follow a mandated architecture design.

Skelton, Matthew; Pais, Manuel. Team Topologies (p. 40). IT Revolution Press. Kindle Edition.

The team interaction models areus, plus I don't want you to retell the book. Let's touch on the team types. The platform is evident here, but the remaining is not.

Platform team is my specialty, but we should start with Stream-aligned teams, which might also be called "domain" or "capability" teams. They are working on something that generates revenue. The critical question is how to define those streams and domains and correctly split the teams. Again, there is no universal answer here. However, we can use the concept of cognitive load and some other techniques described in Chapter 6.

And one more important fact: we are talking about cross-functional teams that have every competence they need to do their job: back-end, front-end, DevOps, etc

A Platform provides an easy-to-use service around stream-aligned teams to reduce their cognitive load. It is a vast topic, and I prefer to write a separate article about it someday.

Enabling is a consultancy service: very high-skilled folks appear to bridge the knowledge gap in a particular team for a limited time. And these are the full-time folks.

And complicated subsystems: there might be systems and technologies that require a very narrow and specific knowledge, resulting in a special team to address those particular areas.

That all sounds straightforward. Why are organizations still suffering, then?

Due to various reasons. One of them I already mentioned: different people are building organizational structures, and another is designing systems. And they do not talk with each other. In turn, that creates bottlenecks that are almost impossible to resolve.

And what I see from my practice is that DevOps as a separate unit is always a bottleneck, at least in the organization I worked with. Separated UX designers might also be a bottleneck if teams wait until they draw you UI mockups.

Also, chaotic team communication adds a lot along with cognitive load. The book mentions that there should be a team's API: the described written way of what resources they own, what documentation they provide, and how to communicate with the team.

Ownership itself is a critical topic. If no one owns something, then no one owns it. That isn't good, especially when we are talking about code.

So many aspects should be considered, but the focus should be on the team first.

That makes sense. I usually quote Ed Catmull from Pixar, who said that a brilliant team can take a mediocre idea and make something extraordinary.

Right. There should be a team-first approach. All should be focused on achieving team goals, not evaluating individual contributions. I feel stupid when I am forced to set up individual OKRs. Achieving team goals is the only thing that matters. A team matters more than individuals.

Ad-hoc changes, headcount deduction, and other "re-structurization" eliminate the team's ability to deliver software effectively. I observed how bad organizational decisions almost destroyed great teams and even software. So, not only building but preserving an effective, empowered, and motivated unit is the most complex task.

Last question: to whom do you recommend reading this book?

I recommend that book to people who see that the organization has good professionals and looks like a reasonable process, but that all does not generally work. So basically, everyone who has "manager" in their title should read the book.

Again, it does not provide all the answers, and some points could be argued. But the book can give you food for thought if you seek an answer on how to build an efficient organization to deliver software in a highly competitive environment.

Software development shifted in the wrong direction when managers with a background in traditional industries came there. They tried to adapt the manufacturing approaches and principles. Thus now we have a lot of software which is shitty and unreliable.

I consider software as a piece of art, and building it requires tremendous creativity from organized groups of people. But the difference with traditional art is that software is delivered immediately (and provides some real value rather than aesthetics only). That is why different approaches should be applied there.

We made a step forward twenty years ago with the Agile Manifesto. Nowadays, we are a few steps back from where we expected to be.

Take care,

Ilya