Before Codemotion Madrid, where he will let the dance begin with his keynote “Playing Tetris with Cognitive Load”, I had the pleasure of asking Manuel Pais a few questions about his book “Team Topologies: Organizing Business and Technology Teams for Fast Flow”, about his current activity and what he is planning to do next future:
As an introduction, can you explain what you are doing currently?
Today people know me as one of the authors of the book on team topologies. In practice, that means I’m a speaker, I do training, and I assess organizations as well. I also develop products related to the ideas in team topologies. It involves multiple things, and managing my own cognitive load is not always easy, but there are a lot of interesting things happening.
Can you explain the term “topologies” more specifically?
The term ‘topologies’ is commonly used in engineering, particularly around network topologies. The word comes from Greek and refers to how different parts of a system are interrelated or arranged together. In the context of our book, it means thinking about how different teams relate to each other, whether they are connected or not, and making intentional choices about these connections. Should they be more connected? Should they collaborate more, or should they be more independent? One of the key points we discuss is being more intentional about the type of interactions that should happen between teams, deciding when it’s beneficial to collaborate to solve a common problem, and when such collaboration might be hiding a lack of capabilities in some teams.
“…topologies comes from Greek and refers to how different parts of a system are interrelated or arranged together…”
Before I started reading the book, which I find very interesting by the way, some friends of mine told me that your strategy has just been adopted by Amazon as a reference for organizing internal teams. What are your feelings about this endorsement?
It’s quite interesting because we didn’t work directly with Amazon or AWS on this, but since the book’s publication nearly five years ago, we’ve seen a shift in the types of requests we get. Initially, it was mainly from early adopters like smaller companies in 2020 and 2021, who found the ideas very helpful and wanted to make organizational changes. Over the years, we’ve begun seeing interest from bigger companies and traditional industries such as banking and insurance, where new ideas, especially about ways of organizing and working, tend to be adopted more slowly. It’s very rewarding to see not only small companies but also big names like AWS applying the concepts from team topologies. They have been using similar approaches since the early 2000s, where they emphasize that teams need to own their services and be decoupled, knowing when to collaborate and when not to over-collaborate.
We know that architecture and team structures should be designed in such a way as to avoid multiple teams being involved when a new feature is developed. But we also know that this happens sometimes, and that’s OK. In other words, how can you arrange for different teams to work together when tasks are not independent?
“…Over the years, we’ve begun seeing interest from bigger companies and traditional industries such as banking and insurance, where new ideas, especially about ways of organizing and working, tend to be adopted more slowly…”
That’s an interesting question. First of all, it’s true that we will not always have teams that can work fully autonomously on their own backlogs. The idea is for teams to be more independent and self-sufficient. However, there will certainly be situations that require multiple teams to synchronize to implement a change. If we have a good balance, say 80% of the time teams work on their own backlogs and 20% or less they need to collaborate with other teams, that’s much better than always needing three to five teams to get anything done. How to handle this in practice depends a bit on the nature of the tasks common to these teams. If it’s a matter of well-defined interfaces, teams can initially collaborate to define these interfaces, then possibly use mock services to independently test these dependencies, while regularly checking in to ensure they remain in sync as things evolve. If it’s more involved, you might need a daily sync-up among all teams to make sure the right people are collaborating and that dependencies are managed effectively.
What are the main objectives organizations aim to achieve by adopting the structures and strategies outlined in team topologies? Can we define some objectives to aim for initially?
Often, organizations are trying to scale; they are growing, they have been successful with some products or services, and they are starting to see where their structures are breaking down. This could work in a smaller context or when a product could be owned and built by one or two teams. So they realize this won’t work as they grow, and they start to identify missing capabilities, maybe needing different platform services, as discussed in the book. It’s often about growth and scaling in a sensible way because what works today won’t scale tomorrow. It’s also about achieving faster flow, being able to respond more quickly to competition, or bringing new products or value to market faster. Depending on the economic situation, like a hiring freeze or reduced investment, the focus might shift to cutting costs in a way that doesn’t slow down teams, maintaining effectiveness even when not growing in size.
It’s clear that you come from a DevOps background, What I want to ask is how the fundamental team types in “Team Topologies” align with DevOps principles.
That’s a great question. My background is in software engineering, and I’ve been deeply involved with DevOps and continuous delivery. The team types we discuss are closely related to DevOps principles. For instance, one of the three ways of DevOps is achieving faster flow, meaning faster delivery of value to customers. The first team type we discuss is streamlined teams, which focus on achieving this faster flow. In DevOps, we emphasize shorter feedback loops and greater autonomy, which streamlined teams exemplify. They manage the product end-to-end, from understanding customer needs to delivering and monitoring the product in production, aligning with the first way of DevOps—improving flow. The second way is about fast feedback, and these teams, by virtue of their structure, can gain quick insights because they are not heavily dependent on other teams. The third way is continuous learning, which is integral for teams that handle end-to-end ownership, requiring a broad set of skills and knowledge.
Let’s dive deeper into individual team dynamics. I read a quote that said individuals within these teams grow closer to act as a unified team rather than just a group of people. Can you suggest best practices for selecting individuals who perform well in such a team environment?
The team types we’ve defined help guide the selection of individuals not just based on operational needs but also on personal motivations and preferences. For instance, someone with specific expertise who enjoys sharing knowledge might fit well in an enabling team, while someone who thrives on handling technical challenges may be better suited for a platform team. It’s important that team members have a mix of skills required for their roles. However, in many organizations, it’s challenging for individuals to move to roles where they feel more motivated. Often, individuals are recruited for specific teams, and later they find that it’s not the best fit. There are instances where members of enabling teams have moved to platform teams because they prefer to build solutions directly rather than teach or mentor. Ideally, organizations should facilitate such transitions to ensure individuals are in roles that best suit their skills and interests.
Do you think this approach should be adopted from the top down in an environment that supports professional development, or can it start from the bottom up, beginning with the individuals within the organization?
It’s interesting because many new organizational approaches, including those in engineering, often require a combination of bottom-up and top-down strategies to become established. When we were writing “Team Topologies” we initially thought it would primarily interest management and those deciding on team structures. However, we were surprised to find that agile coaches, architects, and even individual contributors were picking up the book. There are aspects of our approach that can be implemented from the bottom up. For example, teams can be more intentional about how they interact with other teams, and about how they define and communicate their team APIs to clarify their preferred interaction modes and practices. If these practices are adopted at the team level and prove beneficial, they can influence broader organizational changes. Ideally, both approaches are used: people within the organization adopt and advocate for the practices, and leadership recognizes their value and supports broader implementation.
Very interesting. Lastly, does artificial intelligence impact team topologies, and if so, what are the main effects?
Yes, artificial intelligence, particularly generative AI, is significantly impacting team topologies within technology-oriented teams. It’s important for organizations to be intentional about integrating AI tools. This isn’t just about adopting new tools like Copilot; it’s about understanding how these tools change our ways of working and affect our cognitive load. Organizationally, we need to think about how to use AI effectively across the board, which might include creating enabling teams to spread good practices and address ethical and security concerns associated with using AI. Ultimately, effective use of AI in organizations should be viewed as enhancing capabilities, not just at the individual team level but across the entire organization.
I saw a video in which you were talking about topology in security. It’s your next topic. Are you planning to develop something along these lines? Are you writing a book about this, or are you working on another book?
No, we’re not writing a book specifically about that. The success of team topology is quite fascinating because it has inspired people to expand on some of the ideas in specific domains, like security, for instance. I think you’re referring to a session I had with Mario Platt, who is a security expert. He was explaining different security topologies that focus on enabling a mindset that helps teams understand security well enough to integrate DevSecOps practices into what I would call streamlined teams.
Security is a broad domain, and there are many aspects to it. For example, Eduardo da Silva has done some really interesting work on how enabling teams can help build data science capabilities. Our current work isn’t about writing specifically on these topics, but rather about amplifying the great work that these experts and others are doing.
My focus, along with Matthew, is on how these ideas around fast flow, team topologies, and the patterns can be applied more broadly, not just within engineering. For example, we’ve spoken with organizations in various sectors, such as a law firm that doesn’t build software and healthcare organizations. These discussions revolve around how to accelerate work processes while improving the systems we operate in, ensuring fast feedback, and addressing critical aspects like patient safety in healthcare.
There are interesting examples, particularly in the UK, of applying these ideas during the pandemic, like developing systems for managing vaccinations. So, while we’re not planning to publish a book this year or next, we are considering compiling these experiences into a book in a few years, offering a broader and more consistent perspective.
Thank you very much for your time, i hope to see your keynote on Codemotion Madrid
It’s been a pleasure , Hope to meet you in Madrid
