This year (2025), I had the pleasure of participating in a very interesting panel at the Agile meets Architecture conference on the topic of “5 years of Team Topologies”, where we reflected on the impact, adoption, and developments around Team Topologies since its release five years ago. This was an excellent experience for me, as I was on the panel with people whom I genuinely admire and respect and with whom I have learned a great deal. Thank you to Michael Ploed for inviting me and assembling such a great panel.

We covered a wide range of interesting topics, and the discussions covered some very interesting points. Given that the video of the panel is now available (you can watch it below), I took the opportunity to review it and jot down some of my own notes and insights triggered by the conversations we had.


💡Main insight: although the Team Topologies book has been around for 5+ years now, the level of understanding and adoption of its essential principles and patterns varies wildly. There is nothing wrong with this, and it is expected - as Team Topologies is not a step-by-step implementation framework (as many people consider). It is also essential to recognize that Team Topologies does not answer all of the questions concerning organization design and evolution - and it is not fair to expect that from the book. Still, it is exciting to see how many threads of developments and improvements it has triggered.

Starting question to the audience: Team Topologies is now 5 years old; what is your summary?

Audience Question 1


This was the starting question to the public, and the answers show how wildly different people understand Team Topologies and how various phases people are in on their journeys of leveraging Team Topologies ideas in their organizations and activities.

💡insight: I personally think this is perfectly normal and expected. Although Team Topologies proposes some clear patterns (four fundamental team types + three fundamental interaction modes), it does not stop there. It encompasses many other concepts and principles that are not as trivial or concrete. As one of the comments highlighted, the basic ideas are just the start, one needs to go deeper to avoid this becoming yet another superficial organization “framework”. Some well-known frameworks have done that - simply taking the team types and not considering the rest of the ideas. Obviously, this is naive and will not provide the necessary foundations to enable a faster flow of value.

On the comment: “redefining what stream-aligned teams are, mostly as we discover teams are more ephemeral”

💡insight: I fully agree and understand that in many organizations, teams should be more fluid, and that may (eventually) happen rather dynamically as the different “streams of value” of a domain discover and notice things where effort should be put in. Still, it is essential to acknowledge that this is not incompatible with Team Topologies’ core ideas and principles, as many people seem to suggest. The book emphasizes the importance of having “stable teams” aligned with the key streams of value to the customer. It encourages the creation of supporting teams that help the primary teams build customer value, thereby achieving a fast flow. The book does not say that teams should be static and never change or evolve. Concerning the ephemeral, I can see value for some of those, particularly as the organizations evolve and the practices and ways of owning and evolving the necessary systems mature in organizations - and when organizations practice certain generative behaviors, eventually, there is a level of ability to have that sort of “teaming strategy”, which does not need very structural teams to exist for all the developments in the organization. In these highly mature environments, the level of fluidity can indeed be much higher, as there tends to exist a strong collective and distributed ownership and decision-making ability. I do explore this topic deeply in my work around “Architecture Topologies”, where I also emphasize that it is naive to think that any organization can get into this “fluid” organization with more ephemeral teams. It takes time and effort to get into that type of organizational dynamics, and Team Topologies serve as a great language to develop those behaviors and dynamics. For example, I have recently started exploring the idea of leveraging “Collaboration” as a means to have a temporary group of people - who have an understanding of the challenge at hand and, as such, can become a “temporary/ephemeral team” that helps to shape a particular topic or challenge, which they can solve or define how it fits into the existing stream-aligned teams (or there is a need for a new team). I don’t think many people see this nuance of the “Collaboration interaction mode”, but I am seeing really interesting developments in this area, while still maintaining the longer-loved stream-aligned teams with proper stewardship of the existing systems. I am working on more detailed writings on this topic; stay tuned, as I will be publishing them soon.

Question to audience: Which team Topologies, Practices, and principles are you adopting in your organization?

Audience Question 2


The second question addressed to the audience concerned the level of adoption of different principles, patterns, and practices of Team Topologies. The panel had some interesting reflections on the results.

Why is there so low adoption of “Fracture Planes”?

Simon: I am surprised, but not entirely, as there is a significant focus on the “human side” (teams) of Team Topologies; however, Team Topologies is also about Architecture at the same time.

💡insights: this is a very interesting perspective, and I do share Simon’s remark: it is not enough to focus on the “four team types” and try to somehow “map” the existing teams to the Team Topologies fundamental team types. In fact, this is a very dangerous exercise that many organizations attempt to undertake in an effort to “adopt Team Topologies.” Organizations need to go further and understand what are the essential domains / value streams / “fracture planes” and try to leverage those to have better ways of identifying team boundaries and structures to organize their teams around (again, to allow maximizing flow of value creation). It is tough to achieve those goals when we don’t invest in “good organization and team boundaries” and also embrace that those will be continuously changing and require continuous adapting (this is where the interaction modes are essential, as a means to cope with that evolution).

Over-focus on Team Types & Overlooking the Interaction Modes

Kenny: there is a big focus on structures - the team types, but many people overlook or simplify the actual social/team interactions.

💡insights: I am with Kenny on this, and as mentioned earlier, this is probably the biggest anti-pattern and “misapplication” of Team Topologies. Unfortunately, it is easier to focus on the part of the book that covers the fundamental Team Types and stop there. The “Team Interactions” and evolution principles of the book tend to be overlooked. Then we have some people claiming that Team Topologies does not support evolution when, in fact, that is the core goal of the book. For example, the careful leveraging of “Collaboration” as a means for multiple teams and people to understand and shape how to address a challenging issue, define their focus, and determine who should take action is a clear example of this. These ideas are in the book and have been promoted and further developed by many people over the last five years. Still, it seems that most people prefer the big focus on the “static teams structures”. This is definitely simpler to embrace and adopt. However, it will not allow for the full exploitation of Team Topologies’ ideas and principles because things will be changing, and teams should be able to evolve to support those needs, demands, and opportunities.

Topic: Where have you seen the most challenging problems and difficulties around the application of Team Topologies principles and ideas

Stream-aligned Teams and Platform Teams are becoming obvious, Enabling Teams are harder to position and “justify the investment”, and Complicated Subsystems are still unclear for many

Carola: Stream-aligned teams were easy to map into our organization; we already had them. Platform Teams was a great addition, as it emphasized the importance and value of teams and people working on products that enabled stream-aligned teams to move faster. However, the other two are much more challenging: for example, some experts come together to help others, and they fall in love with that work, not wanting to leave it (“it is hard to find the end”). A complex subsystem is something we never fully understand.

Simon (on Enabling Teams): Prioritizing and investing in “making the work better” rather than just doing the work is an important nuance when we talk about investing and supporting enabling teams. This is often difficult, as we can’t easily put a business case on that.

💡insight - on the Enabling Teams positioning and funding: this is a recurrent discussion I have with many people I work with. It is hard for organizations to justify the investment in experts who are not working on building “product features” and delivering direct, measurable value. However, as I delve into this topic in depth in my video course, Effective Enabling Teams, the multiplying impact of enabling teams on improving work done on stream-aligned teams yields a massive return on investment. We don’t want 100 teams to spend time learning and struggling with the same challenge and finding 100 suboptimal solutions when they could address that 5-10% of the time if they had the support of someone who is an expert on that topic. It is not difficult to make the business case for enabling teams - but in most organizations, managers and leaders are too busy to even consider it. From my experience, organizations that embrace these ideas are the ones that move faster and are the most effective in their work, contrary to the myth that “experts are not producing value when they are helping others”.

💡insight - Enabling Teams ≠ Facilitating Interaction: I highlighted this as a common misunderstanding I often see in many organizations. Embracing this idea is crucial and helps address the significant challenges of kickstarting and enabling teams within organizations. The fact is: most of the time, we don’t need “official Enabling Teams”. We primarily need to create space for individuals who are knowledgeable about specific topics to assist others who require assistance in those areas. For example, if multiple people are struggling with a given technology or technique, and there is someone who has been using it for a long time and knows a lot about it, that person should be incentivized and provided with space to help those from multiple teams struggling with it. We can then accelerate learning. This can happen in various ways, such as training or pairing, and in most cases, it should not require the creation of an official enabling team or the allocation of a budget for that purpose.

Topic: Incentives are fundamental for an Enabling Culture

Carola: In our company, we have defined a simple rule to promote an enabling culture, where we say everyone can help others for 2 half-hour sessions of their time without any approvals or discussions. If it is more, people should discuss with the project leaders to agree on how to make more time for the enabling work that needs to be done. This has changed everything - we allow people to help each other more easily.

💡insight: although many may think this will happen naturally, the fact is when we “codify these principles” and make them clear and “official”, people will become more comfortable and stop “feeling bad” from helping others and doing this sort of work. This also creates what Carola called “Enabling Culture”, where everyone feels incentivized to help and make things better. I loved this part of the conversation, and I think it highlights a fundamental principle that allows Team Topologies ideas to flourish.

Topic: Which stakeholders should be involved in the adoption of Team Topologies

Kenny: Look at the ranking theory and involve the managers and people who have a lot of rank.

Evelyn: Pay attention to people who may feel that things are being taken from them, and involve them in navigating the changes that are happening.

💡 insights: Keeping people involved, particularly leadership, who should create the space and incentives for change to occur, is essential. In this journey, it is also fundamental to work with the people that feel “threatened”. As Evelyn shared, it is natural and human to respond defensively if people think that something is going to be taken from them. This is not easy, but ignoring tends to lead to amplify the challenges at hand.

Tsvetelina: focus on leveraging the early adopters as a way to amplify learning and adoption.

💡 Insights: In my perspective, this is a fundamental principle when introducing Team Topologies or any other ideas in organizations. People resonate more with seeing things being adopted by colleagues than with an external consultant sharing information. People are more receptive when they see other teams sharing stories of their adoption experiences and the benefits and caveats they encountered along the way. This tends to be one of my top recommendations for clients seeking to improve their organizational dynamics: intervene and help, but also encourage the “early adopters” to share their learnings with others within the organization.

Carola: The pattern and principles of Stream-aligned teams, which build customer value, tend to be easily adopted. However, Platform Teams tend to have a much more difficult curve of adoption - “we are building something so important, why should we care of making it simple to use?”. This is really hard: how to convince Platforms to be as a service to others.

💡I see this challenge in basically every organization I work with. Platforms and people working on platforms tend to have the most challenging work in companies, often being bombarded with requests and pulled in many different directions. When we come to them and simply ask, “Now you need to focus on building amazing services for the customer-facing product teams,” but do not spend the time working with them on creating the necessary conditions to make that happen, we are not being fair nor realistic with them. The move towards Platform Teams that can be customer-centered and are building amazing platform products that all product teams want to use requires efforts to stop the old ways of working, where platform teams are essentially being bombarded with “tickets” to implement things. Over the past few years, I have been emphasizing the need to help platforms navigate this transition. This can mean many different things, but typically a focus on clarifying their boundaries (what is the scope of each platform team - and very importantly, “what is not”), improving interactions with product teams (focus on having a more product-oriented approach, listening and identifying the most critical challenges that should become part of platform products. This takes time to learn, and typically, Platform Teams also need to have Product Managers - or that sort of skill to start doing that listening and prioritization, instead of prioritizing everything) refine expectations (help them stop being a ticket-machine team, where Product Teams are asking anything they are struggling with. This cannot be the case; they will be focusing on fewer things, which also requires Product Teams to up-skill into several areas and topics they need to do themselves), etc. Bottom line, it is crucial to help people on platform teams to have the conditions to behave as a platform - this is not an overnight change that follows from an email communication.

Simon: Start where you are, map things out, and meet people where they are.

💡 Insight: This is one of my most fundamental principles, particularly now that I’m working as a consultant with many different organizations at various stages of their journeys. Organizations have a team topology; they have certain cultures and dynamics, and we can only help address their challenges and opportunities when we recognize those and work on the things that are “blocking” the improvement from happening (yes, pretty much like the principles of “Theory of Constraints”). Team Topologies was never created to be a “framework” with step-by-step implementation. It is a set of principles and practices that enable us to have conversations, and it helps a lot when we have that as a means to discuss where we are and identify where we should improve next. However, Team Topologies will not work if one “throws” the basic ideas, conducts some training, and ignores the organization’s current state.

Closing questions & Reflection: Where are we & What are the principles behind Team Topologies

There were several takes and interesting remarks as to where we are in Team Topologies adoption

Kenny & Evelyn: triggered some good discussions around stopping focusing on the definitions and instead embracing the process of shaping the clarity of language that exists or resonates with the organization.

💡 insights: Team Topologies can provide a starting point and an accelerator for us to have a more explicit language, but on its own, it is not enough; it requires practicing and aligning as an organization so we can communicate the change we are making effectively.

Simon: “Embrace the messiness that exists in the organization, and leverage Team Topologies as a means to navigate that. Don’t see Team Topologies as a rulebook to be implemented - that will fail, just like what we see with many “agile implementations”.

💡 insights: I really loved this remark from Simon, and I believe it’s probably one of the biggest mistakes that organizational leaders make: trying to oversimplify, plan, and control all the things that need to happen in the organization. This is a problem because we cannot predict what will happen in most cases, and as such, we cannot plan and control things in detail. The alternative feels uncomfortable to many, as it means letting go of power and allowing people close to problems to learn, design, and decide more. To me, this is one of the most crucial steps any organization should invest in when striving to achieve a faster flow of value.

Simon Wardley’s Final Question: “What are the principles behind Team Topologies”?

Last but not least, Simon Wardley, who was in the audience, asked a pretty fundamental and powerful question to the panel: “What are the basic principles of Team Topologies”.

Simon explained that when creating Wardley Mapping, he distilled certain fundamental principles and practices (which he called “Wardley Mapping Doctrine”) that, when adopted, tend to lead to a natural emergence of organizational structures that support those principles. Simon has collected those - from experiences and organized them in multiple phases (check them here). The key idea, also concerning Team Topologies, is that we should not focus on changing the structures. Instead, we should focus on fostering the necessary principles, which then support the structures to emerge and support organizations to achieve a faster flow of change.

💡 insights: I loved this question, and I couldn’t agree more: we should focus on the Team Topologies principles rather than just focusing on the structure (“we need to have these teams”). In our responses, we touched on a few of those principles. For example, one of the fundamental principles in Team Topologies - basically focuses on having teams (and structures) that consider the team cognitive load as a means to evolve the team and its interactions with others. I think this neatly supports the fundamental idea of Simon Wardley as if we follow that principle, we should be able to sense that a given team will need to be split or augmented, as there is too much happening on their scope of work, or they may need some platform support for certain extraneous activities that are distracting them from their primary focus. However, this is just one of the principles; there are several other principles to consider. A complete list can be found here; interestingly, the first principle is “Focus on Flow, not Structure.”

This question from Simon Wardley triggered several ideas, which I am exploring with other Team Topologies practitioners. Specifically, we do have a set of principles; however, what would be the “phasing of principles” to help organizations evolve and mature towards a faster flow of value? More on this soon - and I appreciate this trigger question, as this is not a clearly addressed topic in the book nor in other materials. It should be helpful to have some extra guidance to navigate this evolution.

Credits: I would like to thank Michael Ploed for the invite and excellent moderation and Evelyn Van Kelle, Tsvetelina Plummer, Carola Lilienthal, Kenny Baas-Schwegler, and Simon Rohrer for being such an open and constructive group. It was a pleasure being part of this panel with you.