At some level of size you end up with more teams than any one leader can handle and we tend to create sub-structures to simplify the complexity of the system and make it more manageable. We see this time and time again over thousands of years with evidence of this going back to human prehistory. Countries have provinces/states/regions, those have villages and cities which can have further sub-regions (boroughs). Armies have divisions which have brigades which have battalions which have companies which have… Health care has hospitals which can have facilities, wings, units, wards, and other meaningful sub-slices.

There is also a common misconception that humans can operate well as a swarming hive of fungible units like the Borg from star-trek (a collective single mind shared between all individuals) or workers in a sweat-shop doing low-skill low-knowledge work, but in reality, for all but some tiny sliver of organizations (hint: if you have internet, the skill to read this text, interest in it, and the time to read it, you probably aren’t in that sliver), this model is a fantasy at worst and an misunderstanding at best. In reality even in environments where culturally they don’t believe they have a team, somehow a de facto team still forms to ship value even if they are poorly defined teams, ephemeral interactions, or just short-lived teams.

How to group teams doesn’t always need to be about deepening a command-and-control hierarchy (imagine the ancient Roman military). For example, even in holacracy (a self-organizing company instead of a management-organized company) teams still form even without a manager, and those teams may often need to interact with each-other. They still have all the challenges of being a team: needing to deliver value and managing the team’s collective cognitive load. Removing official stamps or documentation that explains super-structures of teams doesn’t mean they don’t exist in practicality, but it does make it harder for both self-organized companies or management-organized companies to deal with the complexity that comes from having lots of teams. They have no guiding document to discuss them with.

How can we find the right way to group teams together? Can we shake this awkward hangover everyone has that feels like ideas that haven’t really budged since 500 BCE?

Let’s apply a few different lenses to this challenge and explore ways that grouping teams might be meaningful when trying to design organizations for Fast-Flow of value and healthy cognitive load.

The Dunbar-Westrum Lens

Dunbar provides a set of numbers to help us understand how humans can maintain stable social relationships, and at what level of bandwidth those relationships can be maintained. It’s best if you look at these numbers as fuzzy ranges and not hard cutoffs. The point is to map out how much bandwidth is reasonable at different sizes. While the specific numbers are debated, the concept (in my opinion) is really there to illustrate that the bandwidth available for social cohesion drops off as the social network someone is part of grows. Many organisations around the world and over all history have independently converged on many ways to create nested sets of relationships that span from a few very close ones to many disparate relationships.

It also seems there’s some hidden variables to influence those Dunbar ranges. There’s evidence in ancient history a lot of social group sizes were driven by food scarcity/availability. In modern times, it appears that the quality of relationships can be increased or decreased by the level of trust and cohesion inside a society. For example, in many parts of Norway it is common for parents to leave their 2 month old newborns unattended outside in a stroller while they go grocery shopping or enjoy a moment in a cafe. This is not something I would advise doing in Times Square NYC. Taking that concept to the workplace, the number of people you can work with to really move quickly and deliver a project is easier to do with a larger and larger group when you know some basic “infrastructure” is in place: mission-driven peers, being in a supportive environment instead of cut-throat greed, a place where failure is celebrated and leads to healthy conversations, etc. You have to be very careful who you trust in pathological (see: Westrum’s Culture Topology) culture, but you can give out trust at will and move quickly in a generative one.

The question is really about the bandwidth of human interactions. I’m sure if we augmented our brains with computers and AI we could exceed this lens, but for now we’re simply Human, not Human++, so we have to work with this opaque constraint, not against it.

I find that this “Dunbar-Westrum Lens” helps us understand how big a group might be, but it doesn’t offer the constraints to explain who belongs inside and outside a group of teams. It only hints at the size boundaries and how we might modify them.

The PPP&T-Leadership Lens

(“People, Process, Product & Technology”)

We need to first clarify that this really is about leadership and not reporting lines. Management reporting-lines is a different orthogonal concept to what teams you have, especially as often teams are managed by cross-functional people who often preferred to be managed by people who deeply understand their specific discipline (developers often want a technical manager, Product managers often want a manager who knows a lot about product, etc). This is not a hard rule, but it is an industry-wide tendency that goes far back, even mediaeval guilds appear to take this shape. To be successful at Team Topologies we need to really free our minds and understand that reporting lines are not the same thing as cross-functional teams.

Yet organizations often find it convenient to have all reporting lines bound to the same team sub-org. For example, each Engineering Manager or Product Manager will often have a director who runs the same Tribe/BusinessArea/Group.

Leadership should function as an enabler to help their group function better, stay aligned, and keep healthy connections open to peer groups. All of this is there to reduce organisational friction when trying to make changes, and strengthen the people who need to make the change. While group leadership containing manager-of-managers could help reduce friction by allowing them to set job expectations aligned with the needs of the group, the key people who manage this group should really be ones who understand how to enable the entire group of teams. This doesn’t even need to be a dedicated role, but could be formed as a virtual team out of members of existing teams (assuming the complexity of their in-team work is reduced enough for them to do that enablement work successfully).

Time-to-time I hear a complaint from managers of teams at larger organisations stating that they feel their team is clearly in the wrong business unit and they don’t understand why. They have no reason to interact with the other teams, but they are forced into that group anyway.

What can be gleaned through this lens is that teams want alignment and enablement on people, product and process shaped challenges, as well as someone who can support the skill development of team-level leaders. It seems that teams also prefer this kind of support from leaders who are not only skilled enough with core leadership and management skills, but also those who understand the job discipline and the topics the teams are working on. As group-level leadership may be formed (or partially formed) from a “virtual team” out of existing team contributors, cohesion of topics teams in a group work on becomes a natural force for the upper limits of how useful leadership can function as an enabler.

This leadership group not only facilitates teams, but also removes cognitive load from teams because leadership has removed many challenges by design. There is a concept called “Thinnest Viable Platform” where teams may mutually contribute to something as small as a shared guiding document which sets standards and reduces complexity from everyone. Leadership may also be responsible for this on people and process topics, instead of the building of capabilities or doing functional tasks that are often thought about when looking at teams.

The Mission Lens

Imagine a big boat on a lake with 10 people inside it, and everyone gets a paddle. If everyone in the group has a different direction or mission they are chasing after, the boat is likely to spin in circles instead of getting anywhere at all. Another interesting metaphor: imagine how much sunlight hits a sheet of paper on a bright day. Focus that light down to a 1x1 millimeter square and you have enough heat to cut through metal or turn sand into glass.

A shared mission or even just mutually-aligned missions should have this effect. Instead of peppering focus in every direction, they get a massive effect in a very specific spot that would not be possible otherwise. Imagine some shared strategic direction such as “increasing task automation” with the specific goal of reducing costs. If everyone does this independently it might have some success, but if everyone cooperates we can actually quickly agree to get teams to do that work that often falls into the gaps between teams, quickly solving it with autonomous and spontaneous temporary collaboration where needed (instead of mandated, planned, scheduled collaboration from above).

Putting a box around a team can be meaningful when we identify all those teams are trying to really get to the same (or mutually beneficial) goal. It can unlock teams being ready to self-unblock themselves without needing a “higher up” to step in and give orders for what the priority is.

Thinking about the inverse situation: if we create groups of teams that don’t share missions or have aligned missions we will increase the natural friction that allows teams to quickly adapt and cooperate as the org changes. This is because the prioritization model, and the context loaded into the minds of people in those teams is less likely to be aligned when missions are drastically different. It’s not impossible, but it is the kind of thing that works against changing interactions quickly and forces conversations such as: “We won’t have time to work on that until next quarter”.

Lastly, having a shared mission seems to be a symbiotic enabler for the PPP&T-Leadership lens. Leadership has more focused efforts and can work on higher impact topics when this fundamental alignment is granted simply by org design.

A shared mission provides a common reason inside the group to quickly change interaction modes to collaboration and facilitation. Without it, we have to wait for the planets to align, or someone has to accept to “lose”.

While the PPP&T-Leadership lens may appear to be quite similar, the distinction here is that PPP&T focuses on enablement to keep the group aligned and reduce their complexity. This mission lens is a bit more “upstream” of that challenge and focused on making the mission clear. To make the distinction more clear: consider that it is possible for a leadership group to try very hard to keep everyone aligned despite not being able to succeed. It is also possible for a group to be entirely unaligned despite having one very clear and shared mission. The two lenses ideally enable each other.

The Coupling & Cohesion Lens

If we remember Conway’s law, we’ll know that the system design often mimics the team design and way humans work, so we can use the “Reverse Conway Maneuver” to design teams according to a desired architecture instead. If we go a bit deeper into software design we will find the concepts of Coupling & Cohesion.

Coupling is a way to show what modules are and there can be various levels of coupling ranging from loosely coupled to tightly coupled. The tighter the coupling, the more likely a change to one system will force developers to make changes to others.

Cohesion is a way to measure how related things are inside a module (or “package” or “bundle” etc…). Similar to coupling, there is a range of how cohesive the units are inside a module. If we have a bunch of random unrelated stuff in the same module (anyone with a “/util” folder in their project?) or they can be highly cohesive in that all the parts must work together and it only contains parts that are part of that work (a car engine).

If we give a bit of leeway to the idea, the Reverse Conway Maneuver can almost show us that teams are themselves a type of “module”, and they can therefore be coupled (or decoupled) to other teams or belong in a cohesive (or incohesive) package.

Team Topologies already directly discusses coupling of teams through the interaction modes. We know cooperation and facilitation are meant to be short-term interactions (“coupling”) that are meant to either disappear or transform into one team providing a service (“XaaS”) to another. The motivation for this is to keep teams moving quickly; cooperation is a very expensive type of interaction that slows down flow through requiring work to happen outside of one team, and also increases the cognitive load required to get work done. Team Topologies biases teams towards a less expensive interaction coupling (and raises awareness of system design coupling by exposing XaaS interactions). Cohesion is also discussed indirectly by encouraging teams to transform away from handoffs as work moves from idea-to-value with a focus on stream-aligned-teams owning the whole flow-of-value. It clearly states that owning “end-to-end value” for a stream-aligned-team is a cohesive element and would be a sub-optimal design for fast-flow and cognitive load if value was executed via handovers or long-term collaboration.

It would be a mistake to think a group of teams is therefore taking end-to-end value delivery away from an individual team. What do good architecture principles tell us about coupling and cohesion? I like to refer to the “Principles of (software) package design” often when I create systems. I’ve added short explanations here because it’s hard to find these online. You have to find them in software architecture books right now after a few Wikipedians went on a deletion-spree and blogs about it have been deranked in favour of “package” cardboard box design (physical consumer goods). 🤷.

Principles of software package design

Principles of Cohesion – Designed to help avoid unhealthy coupling

Reuse–Release Equivalence: What you release should be limited to what will be reused (don’t ship a kitchen sink), and if you can’t actually release something to others it won’t actually be reused by others. The implications here are many: software packages need to be convenient and reusable by the target audience, what is exposed must be a tool for reuse, the team maintaining it must actually be able to maintain it.
Common-Reuse: If you reuse part of a package you will use all the package. Components that are tightly bound together should be in the same package. Don’t pack several different features into one package. Don’t assume things not shipped with the package will be available in the reuse environment.
Common-Closure: If you change one part of a package, it should not create a “cascade” into many other packages also needing changes. Generally speaking this means that maintainability will be more important than reusability, where all changes should tend to occur in one package. It bunches together components that usually all change based on the same kind of reason for change.

Principles of Coupling

Acyclic-Dependencies: No cycles in the dependency graph. This leads to situations where making a change to one package requires a change in the other package, which loops back around to the first package and ultimately trapps developers in a high-cognitive-load development cycle where the only way to beat the system is to pretend both packages are one big monolithic package that change at the same time (which defeated the purpose of having two packages).
Stable-Dependencies: The things your packages depend on should be more stable than your package. Stability should not be confused with things like “clean code” or “best practices” or “good versions”, it is an indicator about how likely it is that the package will need to be changed. If it never needs to change, it is very stable. Lots of things can influence stability that are outside of a package itself, such as how many other packages it depends on; an update inside a package dependency can force a package to change in response. Likewise, a package can be forced into stability by having many packages use it (a big change would be unlikely or irresponsible if it would break hundreds of other packages). The point here is that to balance out this behaviour of upstream-and-downstream dependencies, the deepest packages in the dependency tree should be stable, and the ones at the top (with no other packages depending on them) are free to be highly unstable and change rapidly. If we do this the other way around, we force changes to ripple out upwards through the dependency graph. Even if there were no code changes, the underlying behaviours are subject to change or risk of changing.
Stable-Abstractions: Stability of a package should match how abstract it is. To take a concrete idea and abstract away from it is to remove the details and specifics from it, and remain with a still meaningful model. It tends to be the case that the more abstract something becomes, the less likely we need to change it. A “media player” is more abstract than a “DVD” player, which is more abstract than a specific make and model of a DVD player, which is more abstract than a specific make and model playing a specific DVD. Those DVDs are likely to swap in and out at high velocity all the time. The specific DVD player will remain for years. The DVD standards will last for decades (nearly 30 years old already!). The point here is that those unstable packages shouldn’t try to abstract anything and be full of very specific details, while the very stable packages should lack specifics and therefore rarely need to change. Concrete details usually move fast, abstractions should not.

Yes, those are all about software packages and not teams, but it’s not hard to see how they hint at implications for Team Topology design.

Implications for team interactions (“coupling”):

The deeper the platform, the more it should only offer abstractions. Adding the details a team should take care of will create an org that either regularly has to switch out of XaaS interaction and over to collaboration work to re-tool their boundaries, or offers a greater cost forced on all teams at once. Each capability consumed by a team should have fewer details about the business a team manages to avoid switching back to collaboration mode frequently.

All XaaS offerings can only be truly “opt-in, decoupled” when teams offer a way to keep running but also deprecate/discourage use of “older” versions that would force teams to change their work. This does add overhead to any team that exposes an XaaS. This creates a tension with the above implication where there is likely a tradeoff curve between offering backwards-compatibility and forcing a breaking change. Part of that equation involves how many teams consume the service.
Teams can be tricked into thinking they have an XaaS boundary, but due to design issues they might need to constantly collaborate to change that boundary due to dependency cycles in the capabilities offered by the teams
Collaboration work needs to consider if the forces that cause a service to change will cascade into service consumers or will remain isolated to one team. Collaborators must also think about the way they will support migrating/upgrading to new versions of the service offered.
For facilitation to have a more long-term impact when training another team, there should be a focus on the facilitators offering abstractions which are less likely to change (frameworks, guidance, constraints) and the consuming team providing the more concrete details that change from day to day (the business rules, specific ways-of-working, interpersonal details, information about specific code, etc). If facilitators offer ideas that change all the time, it ends up trapping them into doing the work of the team themselves without teaching the team how to do that work.
Many teams using what you provide can force you to change your services less often, which can easily become a major hurdle when trying to reduce cognitive load.
Using what many teams provide can create high unpredictability and instability in your team. If you depend on 20 teams, there’s 20 chances for your team to directly be coerced into changing something they didn’t plan on.

Implications for team grouping (“cohesion”)

Changes in one grouping of teams should very infrequently coerce multiple other teams to change in response. If this does happen a lot, the grouping is wrong or the way group boundaries are implemented is wrong. This could take the form of leaders mixing up a “this is how it works today” group with a “desirable model” vision when discussing what groups exist. In this case it might be impossible for a group to be “decided” by someone with authority and instead needs to be “implemented” by doing the technical and domain-mapping work to keep any change-cascades bound to one group.
A group of teams should expose a common set of functionality that is likely to all get used together, and not expose an “al la carte” menu of disjointed seemingly unrelated products. If your group exposes accounting software for example, it should not also expose dental x-ray software because there’s no reason for them to change together or share enough similarities. Therefore it is unlikely to reduce cognitive load by being put into the same group.
If a group of teams do contain unrelated teams it could actually harm teams by encouraging interactions that might benefit short-term but are constantly pulled in different directions due to disjoint domains, missions, or goals.
Teams that offer a service to other teams will need to change for more abstract reasons than a customer-facing team would. However, depending on the nature of those capabilities they might belong to the same group as customer-facing streams, or outside in a group that only exposes platform capabilities.

Getting coupling & cohesion right can help with:

Reducing the frequency of switching from XaaS to Collaboration, removes the peaks
Reducing the amount of cognitive load that one team can coerce onto another team
Reducing the “switching cost” of changing interaction modes
Reducing the risk of “locked in” cognitive load overwhelming a team or external teams overwhelming team capacity.

The Cognitive Load Lens

Cognitive load is a useful way for us to figure out if the amount of work a team has is either overwhelming or there’s room for more. If we take a deeper look we can understand where the load comes from too, which allows us to create structures to reduce the load.

There are the three types of cognitive load:

Intrinsic: The load from “doing the task”.
Extraneous: The load from the environment itself,
Germane: The cognitive load of Intrinsic and Extraneous combined, but only for parts that are essential to the task itself (for example, dealing with someone distracting you from some focus work is “extraneous” but definitely “not germane” to the cognitive load of the task)

The amount of load for each is not fixed for any given task but rather situational to the task, the people or persons involved, and the environment the task is in. Consider the same tools, environments and people between two situations between two different tasks.

An individual team can create an environment where the cognitive weight of a task is superficially reduced, the environment itself is streamlined for change, and non-germane factors can be reduced. However, teams that do this without taking part in a broader ecosystem of teams often become a “bubble” world, insulated and isolated from the rest of the organization until something unexpected from outside the team forces that bubble to burst. By sharing some common “cognitive load reducers” with other teams this is less likely to happen. What is more likely is that with each additional team that can share in a common pool of things that reduce cognitive load, the more possibility there is for a few people to solve problems for many people, and further evolve capabilities that everyone benefits from.

In more concrete terms, this could be that most teams in a group consumes from the same platform. It could also be that everyone in a group follows the same set of standards, has a common understanding of the domain model, understand and has personal connections to other people in the group, a shared set of cultural ideals, and other things that reduce day-to-day friction or complexity when moving around between two teams.

Interestingly enough, I suspect the way to do this can only be accomplished via other lenses, and those lenses are best guided through this one.

The Idea-Aether Lens

Fish don’t know they’re in water. If you tried to explain it, they’d say, “Water? What’s water?” They’re so surrounded by it that it’s impossible to see. They can’t see it until they jump outside of it. - Derek Sivers

The way modern people think about things has been heavily influenced and shaped through thousands of years of history. Stories from our ancestors. Ideas from great philosophers. Our modern zeitgeist. Whatever content the algorithms are pumping into your brain right now. All of this stuff influences us in ways that are hard to explain, hard to prove, hard to control, hard to influence, and very hard to ignore. These coalesce into the “social Mores” of our time. This is that faceless, anonymous, non-specific authority figure and shared knowledge that Jacques Lacan called the “big Other”. This is the Overton Window. It’s all the ideas about the world that stick to us as we move through it.

As we zoom in on different subcultures (like “Tech Startups”), we find that there are even sub-discussions going on. 20 years ago everyone “knew” that the only right way to design a system was with one massive database, yet today this is highly rejected in favour of multiple specific databases. We shift values and mindset of what is the right way to create software, manage a team, do product management, and countless other things that we all “know”.

We don’t travel through this all together either. As we zoom in further we can see that teams, companies, and industries can shift their ideas around on what “the right way” is. We can run into major conflicts between two teams when they exist in incompatible Idea-Aethers. There does appear to be a Dunbar-style relationship to the Idea Aether. The Dunbar-Westrum lens looked at how big a group could form, however, the Idea-Aether hints at the quality and volume of bandwidth possible between any two people ( … or teams, groups, orgs, cultures, etc), as well as how quickly they can change interaction modes.

I’m lacking a strong model to implement this, but hypothetically there are ways to introduce, craft, and modify, this Idea-Aether inside of a company. HR teams might call it “cultural transformation”, but I think that is only part of the problem space.

Being able to influence the Idea-Aether intentionally will let us creates a “default environment” that reduces cognitive load over all teams. It would be a virtual “0 cost” platform and facilitator that both aligns and constrains choices by default. That might sound manipulative on the face of it, but it might also be as simple and honest as giving thought-leaders in your company a way to amplify their message into the Idea-Aether.

The Planning and Delivery Lens

For teams to flow-fast they need to take total ownership “from idea to value” fully end-to-end and keep iterating on it. The most effective team is not only responsible for delivery of software (“shipping and running stuff”) but also the discovery work (selecting opportunities, experimenting, testing ideas, doing research).

Artificially coupling teams together to plan and deliver at the same time assumes that delivery and planning of very specific features is being orchestrated at a higher level, which means teams are not really going from idea to value, they receive it via a handover (which is an anti-flow manoeuvre).

There is a concept from SAFe where teams could be grouped around sharing a planning and release cadence. Unfortunately, due to Brandolini's law I will have to dedicate an entirely new long-form post to really dismantle this flow-destroying concept. The ART in SAFe was a process designed for removing the chance of total project failure by introducing multiple early opportunities for integration of software between multiple teams. It is designed for a world where teams that do not own end-to-end-value are making monolithic plans to orchestrate multiple interdependent teams. It doesn’t help us extract complexity from teams so they can discover and flow value to users faster, and it doesn’t help us keep teams autonomous.

This is not a lens that respects the principles of fast-flow and cognitive load, but instead wrestles with an inability to design them out of teams. It takes some of the pain off of a risky process that is a result of a flawed team structure.

Building our telescope

If we combine all of our lenses we can create a form of telescope to look for groupings of teams.

Team Topologies surfaces ever-changing team dynamics that allow us to have conversations. Those conversations create fast-flow and healthy cognitive load. These lenses can be used to look at a collection of teams and figure out how well enabled they are for both of these, as well as the reasoning for how fast-flowing or cognitively heavy they are. With that reasoning, we can discover actions to take that will create faster, healthier groups.

While team topologies diagrams create a snapshot of team dynamics, many of the topics here do not apply to the snapshot but rather things that either enable or hinder change of those dynamics. It may be hard to express all of those factors with only minor changes to existing Team Topologies team-interaction diagrams, but if the ideas here can be simplified it might be possible.

Lastly, while looking through each lense individually I came to a conclusion that we simply cannot define a group of teams by sitting down in a management room, drawing a box around a bunch of teams and telling them “ok, this is the group”. It truly appears to me that team groupings are emergent constructs, not ones we can dictate. We can possibly design a vision of how teams end up grouped together, but we can only reach a grouping here through changing the team-level factors.

If we sit down and just draw boxes around teams, we are more likely to create a work of fiction instead of having captured actual team dynamics. That fiction can be a useful target, but the actions that make groups emerge is the only way to make it a reality.

Heuristic

Here’s a set of questions to help you think through some of these lenses and question if groups are really enabled for fast-flow and a healthy cogntive load. I think this Heuristic is prone to change, but it is a good first step and can already drive interesting conversations that improve your teams.

How many people are in your group?
What Westrum-culture is your group?
Does group leadership facilitate alignment of people, process, and product+tech topics between all teams (as opposed to only some teams, or multiple leadership teams in the same group splitting teams and topics)?
Is your group going after one goal, or multiple cohesive goals?
Are teams exposing abstractions or concretions in their interactions?
1. Inside the group to other teams?
2. Outside the group to other groups?
Are two groups frequently switching between XaaS and Collaboration interaction modes?
Do all teams in a group share common factors that reduce cognitive load?
Do thought-leaders in a group promote ideas that simplify complexity and remove cognitive load for all teams in the group?

What comes next?

Discussion, trials, and simplification. I think this entire concept is just too complicated to make it readily usable, and I have a sense that there is a way to simplify the tooling here to make it something that could be easily picked up by many people with much less reading. These ideas will have to ferment for a while before I figure out exactly what that is, but I’d also be happy to hear from anyone with ideas of how to distil this concept.

At the same time, while everything here fits a consistent narrative and my personal experiences, I would like to get more practical in terms of using this to both evaluate team groupings as well as find actions to take that improve the state of team groupings.

Articles and Posts

Searching for higher-order team structures