TL;DR
This is a series of articles (among them are Spotify's Tribes and Squads and Marty Cagan's Empowered Product Teams) where we compare and contrast different well-known approaches applicable to product development organizations to help leaders make better org design decisions.
For our analysis, we are using a map of seven archetypes, that we call Org Topologies™.
This is a long read because we analyze and debunk the claims made by the authors of Team Topologies.
The key idea from Team Topologies:
Team Topologies' promise is to optimize for the fast flow of change.
For the flow of change to grow, the teams' Cognitive Load ought to be minimized.
And for this, it is suggested that teams go with narrow service code ownership.
Team Topologies claim that with such a strong focus on architectural concerns, the negative effects of Conway's Law will be reduced.
We conclude (with the analysis of this article):
To make a change for a customer feature, typically several services and components need to change.
So despite the fast flow of change at the component level (as promised by Team Topologies), the flow of change at the feature level might not improve or even get slow.
The slowness of the R&D and due to narrow code ownership policies, Conway's Law might get reinforced by Team Topologies.
The idea of a developer's Cognitive Load is overplayed and analyzed very one-sidedly in Team Topologies.
Instead of introducing narrow service code ownership, one could as an alternative work to decrease product and engineering complexity by applying modern engineering ideas from companies like Google.
Team Topologies don't seem to offer a strong vision to improve an engineering organization, but instead might let leaders accept mediocrity.
In general, applying ideas from Team Topologies might have serious negative side effects that leaders need to be aware of. And even without those side effects, we find there is too much talk about teams and too little about customer value and how to make the whole organization more adaptive and innovative.
Towards Detailed Analysis of Team Topologies
In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential.
This is a quote from an article dated back to 1986. Since that time, things haven't slowed down, instead speed and flexibility became a standard, a norm to expect from any business.
The concept of Team Topologies has been on quite a rise over recent years. Despite its popularity, there are some essential things in the approach that seriously bother us. In short, we believe Team Topologies done by the book might create a suboptimal inner-focused R&D organization that is optimizing wrong things. For instance, instead of their growth and culture of continuous improvement, the concepts from Team Topologies are likely to optimize peace of mind of development teams.
But is it the right thing to put as a primary optimization concern in product development? In other words: will the application of ideas from Team Topologies help create better business results?
The book talks vastly of Conway's Law and the Cognitive Load of teams. Below, you'll find our detailed analysis debunking these overused terms. We believe those phenomena are somewhat true, but their effect is overplayed and exaggerated. Those things should be accounted for, but should not be your key driving factors in the organizational design decisions.
What can be better primary goals for system optimization and organizational design? For instance, how about long-term speed and flexibility? Or adaptivity and innovation?
But how well are the ideas from Team Topologies consistent with these optimization goals? In short, not much. But we encourage you not to take our word for it – read on and decide for yourself. That is our sole goal with Org Topologies™ – to help organizational leaders (like yourself) make rational, informed, well-thought decisions.
Team Topologies Are About … Team Topologies
Let me start with a little consulting story. Not so long ago, I had a phone call with a potential client. They asked for some training, and I asked them in return how they currently work and why they need the education.
They said they were about to roll out team topologies in the organization. Stream-aligned teams, mainly. I logically asked what those teams will be formed around, and what they will be working on.
The answer I heard back was somewhat obscure. “We have some available product managers to manage some independent product parts, each of them will get a stream-aligned team.” — was the answer. “And then once the first six teams work”, – they continued, “we will add more teams, and then more”.
A quick check with the client six months later confirmed my fear – they were still forming teams and were not ready (in their words) to discuss value areas and coaching for product managers.
And it is not a single case in my practice. Now, what do you read between the lines?
Teams, Teams Everywhere
There has always been a lot of buzz in the agile space about teams. Teams are at the heart of any agile-friendly method, so you can't underestimate their value. I spent years working in and coaching agile teams. It is a vibrant space. You never stop learning and getting surprised.
But what makes teams so crucial in complex product work?
Teams are able to absorb certain levels of complexity, uncertainty and fluctuations , especially when being cross-functional and cross-component. That makes the job of management way easier.
In other words, teams allow the management representatives to stop wasting their precious time and attention on task assignment and task coordination – and engage instead in some significant high-value work. For instance, developing a company's strategy, making internal investment decisions, clarifying and communicating product visioning, and so forth.
Ironically, it is because of the importance of teams in complex product work, we somehow forgot about other aspects. For instance, what to form a team around. A team can do any sort of thing, but the outcome of those efforts depends on the value of that work. That is obvious, theoretically. But we keep seeing company after company that go ballistic on forming and spawning new teams for every new piece of functionality.
That is why the non-team-based organizational archetypes reside at the very bottom of the Org Topologies™. They are at the very beginning of the transformation journey.
If you are new to Org Topologies™, read about it and come back to this analysis of Team Topologies.
Teams 101
Imagine a developer who knows a backend component B1. And another developer who is familiar with a frontend component, F1. When put together as a team, they already know B1+F1.
And if there is a requirement on the product backlog that requires work to be done only in those two components, that small team of two is already capable of doing more than the individual developers separately. They can implement that requirement completely, end-to-end, with no hand-off or delays. That speaks for a short feedback cycle and learning. They ship faster, they learn quicker, and they adapt sooner. Everyone wins. That speaks for agility in its essence.
If a third person with test automation skills joins in, then these three would not just create a working feature, but make sure it will always be working with automated tests. That's significant.
A typical product team has more than two or three developers. So it is not hard to imagine a team knowing collectively 3, 5 or 10 different system components and tech stacks. And it is possible to foresee how such a team volunteers for a custom item of high priority and learns a new component that they hadn't worked with before. Now, they as a team have a plus one skill. And can do even better than before. And the more they learn, the better they learn. As learning is a skill too, a meta-skill.
To conclude, another reason why teams are so crucial in the process of product creation is that:
Team can learn faster than the individuals (the sum of the parts). But more importantly - they are able to accumulate knowledge at the rate no single individual can (they are more than the sum of the parts).
PDE = f (TEC, VD)
Product Development Efficacy = function(Team Engineering Capabilities, Value Definition)
By this non-scientific equation, we mean that it is not enough to consider just how great the teams are in delivering work (Team Engineering Capabilities). But also what those efforts are focused on (Value Definition). That is trivial yet not common to see. If the value is defined wrongly or too narrow, teams will be running at their full speed with little to no contribution to the goals, a measure of the organizational Product Development Efficacy.
In other words:
Value of teams can be only measured by value of their work.
This has been one of the key reasons why we came up with the Org Topologies™. Our mission is to shift the industry into thinking of both aspects: great teamwork on high value.
But what is the promise of Team Topologies from this perspective?
Fast Flow
The entire concept of Team Topologies, as the name implies, is around the teams: the kinds of teams, collaboration styles, team ownership, etc. But what is it for?
One of the authors clarified that goal in a series of tweets:
So, the goal is fast flow (at a team level). Now we need to see if that results in building greater products and serving business objectives better.
In order to know that, we'll have to debug and debunk Team Topologies piece by piece. So we will have to go a bit technical. After reading the book several times (yes, we are masochists) we got a strong impression that the authors build all their arguments mainly on these two overused concepts:
Fighting Conway's Law (168 references in the book)
Minimizing the Cognitive Load (115 references)
We find these ideas easy to sell to tech-savvy managers. Some sort of IT management bingo. But it doesn't require an in-depth analysis to see how these concepts (being referred to so many times in the book) are got wrong and basically misused by the authors for the sake of supporting their questionable beliefs.
Conway's Law?
Mel Conway's Law states:
... the interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it.
In simple language, Mel Conway formulated an observation that organizational design clearly has an influence on systems design (architecture). So, the way developers, delivery teams, and production departments communicate will have some sort of footprint on the product.
This is a mere observation. Not a law. Conway's paper was not accepted by the HBR due to a lack of data. It is more or less an anecdote we share in our field. Though, he had some clues.
Fred Brooks confirmed Conway's observation and introduced an important corollary to it:
Because the design that occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.
We find this logical statement of Brooks way more important to the topic of the org design, than the law itself. In other words, to make sure the architecture can be improved and evolved as necessary, an organization shall be kept flexible.
In contrast, if an organization is not flexible (it is fixed and static), then it will not be able to produce a different (improved and evolved) architecture, as a result of Conway's Law. And therefore might not sustain its product over a longer time. We need evolving architectures that can be improved; hence we need to create flexible organizations. But what are the key pieces of advice the Team Topologies book gives?
Literally, the opposite! The book's authors insist on a strict approach to code ownership. They claim that components/services must be owned by teams:
Few points here. First, Team Topologies suggest that the team design must map to the architecture with narrow service ownership. Does that fight or reinforce Conway's Law?
Secondly, in the tweet above, Matthew agrees that shared code ownership requires engineering maturity. So, is it a bad thing to grow maturity? Isn't that a goal of any engineering leader? It seems so to us. But instead, it looks as if Team Topologies provide a safe harbour to cultivate mediocrity with narrow code ownership discouraging sharing as a concept:
Fast Flow of Change?
Customers don't want changes in components/services. They want product features to get their job done. And how do features typically relate to components and services? They are orthogonal to each other: meaning, to develop a customer feature, it typically requires making changes in several components and services.
This is a profound consequence of org design with narrow code ownership at the component/service level. It will almost automatically create asynchronous blocking dependencies between teams. That means delays and waiting.
Inter-team blocking dependencies between teams with narrow code ownership inevitably result in bigger delays, longer cycle times, slower feedback loops and worse time to market of value. That is lower adaptivity. Fewer innovations.
Wasn't the idea of Team Topologies to improve the fast flow of change as an enabler for customer value and agility?
Team Topologies does promise a fast flow of change. But at the component and service level (because of narrow code ownership) – not at the customer feature level! Can such a well-selling book provide such questionable suggestions?
Implementing Team Topologies will unlikely be your enabler for customer value. And it won't be just the flow of change for features that is slow. But also the flow of changing architecture (which is by definition a cross-component and cross-service concern). And when an organization is unable to adapt its architecture fast enough, isn't that the opposite of agility?
Such dynamics can't be solved fast by throwing money and resources into it and applying fancy architectural techniques (e.g., microservices). See the detailed article Dependencies, Teams, and Microservices by Viktor Grgic analyzing this and related points in greater detail.
We are confident that the authors of Team Topologies might have thought of these consequences. We are not certain why they decided not to point them out. There are now organizations out there that are trying to adopt Team Topologies. And maybe with little awareness of those significant side effects. As you are reading this, your organization might also be on that path. Think slower.
Alternatives?
What are the alternatives? Does the industry know any better?
Yes. We suggest investing in continuously learning feature teams with whole product focus that are working on the most important items from the global viewpoint. That is a fast flow of change and agility if you really care for it.
Feature teams learn to be fluid over time. This creates the necessary flexibility in the organization. And eventually, it elegantly fights Conway's Law. This is because feature teams don't just build customer features faster, but with the constant cross-component work, they also constantly evolve the architecture.
It is not that easy to build such an organization. It has its challenges. For instance, shared code ownership and cross-component work are getting harder with scale. But such an organization learns to solve problems over time. Things will be improving. There will be hope.
Cognitive Load?
Finally, why do Team Topologies advise narrow service/component ownership? The key argument (as we understood from the materials) is to minimize what they call developers' “cognitive load” (this has been mentioned 115 times in the book).
But this concept, as it seems, is also misinterpreted by the authors. Reading this thread on LinkedIn:
It sounds like the authors of Team Topologies got so focused on minimizing what they thought of as the 'Cognitive Load' (they actually meant complexity to working with code) then they seemed to forget to explore other options to minimise it. That is an example of what is known as a false dichotomy – and offered false choice to impress and convince the readers. It implies that either you have a high 'cognitive load' or you need to limit the scope of the team's ownership.
It is hard to argue that the smaller the scope of a team's ownership is, the lower the need and effort for learning, less uncertainty in their work, less stress, shorter lead time to make changes in those known lines. But see how inner-facing those concerns are.
Let ask you: is it the primary concern of your business to make your teams' work easier? Being developers ourselves and working a lot with development teams, we understand that it is the improving the developer experience (DX) is the right thing to do. But this is not what your customers are buying, and the investors are investing into, is it? If you go real extreme on this thinking, you will give each developer a single line of code to own. Individual lead time for change will be extremely “effective”, but what about the feature level, the customer journey level, and the whole product level?
It appears to us that we are confusing the means with the ends here by focusing too much on optimizing the developers' comfort zone? Point one. (Again: we love developers! But we really adore the ones who learned different programming languages and frameworks and keep learning.)
Point two. Narrow boundaries of team ownership (e.g., at the service level as advised by Team Topologies) will inevitably result in more complex inter-team dependencies. Imagine a business requirement that need to be delivered. It is not formulated in the language of services or teams. It goes across several services; hence, several teams will have to do some service-related work to implement it. Do they understand the business requirement or just given tasks to code within their scope of ownership?
Narrow code ownership makes planning and and delivering customer value more complex and less certain. It also distantiates teams from customer problems.
You can't remove systemic complexity by policies. You can only shift it around. And by implementing the ill-advised component/service level-team ownership model, complexity will be moved from the teams' small worlds into the space of requirements and planning. Hence, creating more work for managers, coordinators, analysts, etc. Won't it make the product development process more complex, as well as the entire organization? We are afraid so. This will mean less transparency. So less agility, by nature. Is that what you really-really want?
We doubt that. And we are surprised that Team Topologies provide basically only a single option on minimizing (shifting) the engineering complexity by limiting team's ownership scope.
But as Viktor Grgic mentions above, there is at least one more option on how to systemically minimize the complexity of the engineering work – it is by investing in and improving your engineering practices.
Learn from the best with this book. So let's not ignore the progress our industry has been making to come up with such brilliant ideas to systemically fight the complexity of engineering, to name a few:
Book Review
To sum it all up, we are providing below a screenshot of a detailed review of this book by Bas Vodde, who is an experienced developer and an organizational consultant.
Unexpected Long-Term Negative Impacts When Applying Team Topologies
Despite everything said above, our main complaint on Team Topologies is not their misunderstanding of Cognitive Load or the self-inflicted Conway's Law (discussed above), but these two things:
Legitimization of component development with no perfection vision.
Inward view on organizational design.
Let us elaborate.
Legitimization of Component Development
Imagine an engineering director who has just finished the first few chapters of the Team Topologies book. He takes a look at his org chart and proclaims: “Oh! We have all the team types described in the book! Great!”.
And nothing gets improved in the organization: the existing component work and its negative dynamics remain as it has been. Anyone leading the R&D must understand how the component teams (no matter how modern their names are: “platform teams”, “complicated sub-system team”, “service owning teams”) will promote sequential life cycle:
Value can be delivered only when the work of multiple component teams is integrated and tested. Component teams promote sequential life cycle. So what? With a component team organization, the work-in-progress (WIP) from a team usually waits several iterations before it can be combined into a valuable feature.
Because of these dynamics, the R&D work is slow, expensive, and unreliable. Business people are unhappy and always pushing for more to get at least something. This creates immense pressure and stress on the developers (and this despite the narrow code ownership policies that were to create less stress!). The developers have to cut quality corners to be on time and yet are always behind the unrealistic plans. A blame game kicks in. More work pushers are got hired (we mean 'delivery managers', 'release train engineers', and other representatives of the 'modern professions'). Managers need to be managed, so more managers are hired—more hierarchies and less face-to-face work of the business people and the developers. More misunderstandings, less empathy, tighter deadlines, and more blame. The organization is entering a vicious cycle. Things will be only get worse over time in there. Then later the best developers quit because they are not learning anything and don't grow.
So to change these dynamics and make a U-turn, component team structure and component development need to be minimized. And when it has to be applied, it has to be well thought through, done temporarily as a step towards a greater good.
You Need Perfection Vision to Guide Transformation
When might you need a temporary “complicated subsystem team” from Team Topologies? The answer is obvious: when you have a complicated subsystem!
But isn't this a self-fulfilling prophecy? Will a permanent complicated subsystem team be motivated to reduce complications from the subsystem it owns? Is that true that making the subsystem less complicated might go against the idea of the existence of this team? Will people be working full-heartedly to put themselves out of their job? Complex questions.
In light of such a dilemma, having a clear long-term perfection vision for the organization will help a big deal. So, what that vision can be? For instance, you might want ideally all the teams will be self-sufficient, so-called end-to-end teams. Meaning that they will be able to volunteer for an important piece of work (a feature) and implement it throughout the needed architectural layers, fast and with high quality. And all the teams will be like that. Won't that be cool?
That will imply that the teams will have to know how to work cross-functionally and cross-components, making changes in any parts of the codebase when necessary. Such a mode of work will imply a policy of shared code ownership. This might sound like a dream. Because it is one! But before you start criticizing this vision for its impracticality, will you not agree that this “dreamed” R&D would be great?
Let's imagine that you've settled on such perfection vision (your big, bold dream). It doesn't have to be real just yet. But it has to be set as a long-term target. If made so, it will be pulling you towards a better state of affairs. When the vision is set and communicated, you can start working to make it real (in that order: envision, then work towards the vision). Then your temporary solutions (e.g., forming a temporarily complicated subsystem team) can't be criticized if they take you a step further on that dreamed path. And what now be the mission of that complicated subsystem team – of course, to make that subsystem less complicated! So that other stream-aligned teams could work on it, when needed. Now there is no contradiction. And is always a clear direction and progress.
It is worth noting, and we do appreciate this – the Team Topologies book does state that the stream-aligned teams is a preferred team type, on page 64:
Generally speaking, we need to optimize for fast flow, so stream-aligned teams are preferred.
Then on page 135:
The stream-aligned team is the primary team type in an organization, and the purpose of the other fundamental team topologies is to reduce the burden on the stream-aligned teams.
And finally on page 136:
In a modern software organization, we expect most teams to be stream aligned. The flow of work is clear, and each stream has a steady, expectable flow of work for the stream-aligned team to prioritize.
But are these statements enough to make organizational leaders work hard to avoid other team types? Because Team Topologies list all the team types, we fear that might create a belief in some leaders that those teams should be present permanently. Unless there is big clear perfection vision in the organization in which such teams don't exist.
What we are definitely missing when reading the book is the definition of the true north – a perfection state organizations are to strive for. Instead, we see legitimization and excuses for having different kinds of specialist groups and component teams. That is a good recipe for no real change in organizations implementing Team Topologies.
With no direction, there is no change.
Inward View on Organizational Design
Finally, our claim above describes our fears on how companies might adopt new terminology (from Team Topologies) but without real change that brings you closer to perfection.
Another concern we share is that Team Topologies drive a very inward-focused view of the organization. That can't drive higher customer centricity.
I have heard of another company adopting Team Topologies with a serious intention. What the leaders did in the first place, looked at the product architecture diagram (blocks of services and components) and started defining corresponding teams owning those boxes. That became their transformation roadmap.
Can't you see how wrong that is? That's when organizational design is made dependent on legacy architecture. Can't that be a good recipe for creating great products customers love?
We find that the whole discussion of Team Topologies is very much inward-focused. There is no customer in the middle of the picture, no business objectives on the line. That goes against Lean Thinking when a customer is put in the middle.
'Product Backlog' is mentioned 0 (zero) times in the Team Topologies book. 'Backlog' is mentioned four times, one of those as a 'team backlog'. The authors of Team Topologies seem to be intentionally avoiding the discussion about the business side of things. Here is a public comment made by one of the book authors as a reply to my attempt to clarify this question:
See this thread on LinkedIn. We have no further comments.
The Summary
With all said above, we believe organizations implementing Team Topologies "by the book" represent archetypes spanning mainly from Y1 and up to A2 and A3.
We have covered the Y1 box because we feel some implementations of “enabling teams”, can be mere reincarnations of functional groups doing the work teams (also known as undone departments). And “platform teams” and “complicated subsystem teams” will univocally trigger dynamics of component development (with blocking dependencies and delays described above).
Those component teams can't be working on customer features end-to-end, so their lists (backlogs) will be full of technical tasks to implement in that piece of code they own. That's the lowest scope level on the map – the “task scope”
A2 will be likely a place for stream-aligned teams with blocking skill- and process-based dependencies on other team types. With component teams being legitimized by the Team Topologies, we can't see how to avoid this.
A3 is the best place Team Topologies can target – a modus operandi for standalone stream-aligned teams with zero blocking dependencies. We want to believe the idea behind the book is to get there. But if it is the goal, it is somewhat watered down by all other team classes and collaboration types defined in the book. So, the goal of having all those teams will be very much decided by individual organizations without clear guidelines from the method authors.
Why Team Topologies don't go higher on the map, like up to B or C? That's because Team Topologies prefer “single team service ownership” as a preferred way of operating. This almost certainly guarantees team-level backlogs (with team-level product owners). And it doesn't matter if Manuel Pais or someone else likes the concept of the backlogs or not – there will be backlogs (lists and queues) at the team level. And if the model doesn't define them explicitly on higher levels (B and C row of the Org Topologies™), they will be defined where the managers find it suitable—likely at the team level. That's how organizations behave and support their status quo.
Towards Better Organizations
The goal of Org Topologies™ is not to downgrade other models or provide some sort of basis for yet another maturity assessment model. No, at all.
The mission of Org Topologies™ is to help you, a leader of a given organization, to discover a vector of your long-term organizational development. We believe that higher states of adaptivity, innovation and therefore overall organizational resilience is a great place to grow towards.
So, how to improve your org design if you are considering applying the ideas from Team Topologies:
If you have up to 7 teams (around 50 people):
Consider organizing all them around a common shared objective-oriented product backlog, forming a group of teams, working together. We like calling it a “team of teams”. And try to make all those teams in the group end-to-end, cross-functional, cross-component, customer-facing and long-living teams.
Pitch the long-term vision of the customer value to your “team of teams”. The people need to see themselves sharing the work and needing each other to deliver on that vision.
All the teams in the 'team of teams' group should together receive training and coaching.
And they should be guided by a cohesive overarching strategy defined for that customer value area. Ideally, from an aligned group of product leaders or a single vocal leader.
Apply advanced multi-team facilitation techniques to enable high collaboration between the teams. Ideally, a pair/group of senior Scrum Masters / Agile Coaches to work with the entire group (not a coach per team).
If you have more than 50 people in development, you need to go incrementally (big-bang transformations are … too big and risky):
Try to define a broad-enough customer value area for the first 50 people to start in. It needs to have a clear, long-lasting value to your business stakeholders.
Invite people to form the first team for the group to work in a holistic permanent work unit.
Once the first group settles and functions (in 3-6 months), you can spawn a new group if needed.
At mid-time intervals (quarters, half-years, or just-in-time) engage high-level business stakeholders to reconsider the structure. You can merge groups or move teams between them to better match your portfolio-level investment targets. This way, the organization can be managed and optimized as a whole.
(C) 2022, Alexey Krivitsky and Roland Flemm. Org Topologies™.
Comments