Have you read the introductory article Seven Archetypes (the Alphabet) of Org Topologies™? That would help.
The big determining factor on the vertical axis is the type of input a given unit receives:
Does the unit receive tasks?
... feature requests?
... business objectives?
... product goals & customer challenges?
Tasks provided as inputs to the unit would classify the unit as the Y-level.
Constant feature requests (and nothing else) would classify the unit as an A-level archetype.
Business objectives, product goals, and customer challenges - B or C (the higher archetypes), depending on how broad the scope of work and ownership is.
This very simple logic will help you determine the vertical level of a given work unit (individual, functional group, or team). This is an outside, black-box view from the mere viewpoint of the inputs a work unit receives.
The input levels a unit receives are not random in a given context but are a function of:
org & power structures
work breakdown and work integration processes
believes of the management
cultural aspects
Therefore, the correct determination of the vertical a unit belongs to, says a lot about the organization structure, process maturity and culture.
But what if we look inside the box?
"There is a whole universe within a universe."
Looking inside a team might have a completely different picture of how the work is received, perceived and gets done.
In the theory of networking there are six different types of networking topologies possible to perform a (networking, routing) operation:
And if we consider an org work unit (i.e. a team) as a graph of connections and relationships between its members, we can assume some of these classical networking topologies have their place.
Consider the star topology above - one person (i.e., a team lead) decides who works on what, then divides and distributes the work accordingly. This central hub of a network might receive feature requests (an A-level per Org Topologies™) but then break down the work into tasks to be fed to his teammates (almost like a Y0 level - individualistic task work). That creates a conflict! From the outside, the work unit acts like an A-level (let's say an A2) archetype that doesn't require external micromanagement and can convert a feature request into a working feature. But once we unwrap the black box, we see that most of the team members exhibit the Y-level dynamics: they work on tasks, don't see the bigger picture, don't speak the customer's language, and require a task coordinator.
The same logic can be applied to at least one more networking topology - the line topology. At a team level, it will result in sequential work with hand-offs between single-skilled individuals, a mini-waterfall.
The mesh topology is probably the best representation of how any team coach would want an agile team to operate. But also with dynamic relationships. There, the people work with whoever they need to work on at any given moment of time without any central hub to be held responsible for the overall coordination.
Coaching opportunities
"Give me a lever and a place to stand and I will move the earth".
If you uncover a mismatch between an external view (e.g. A2) of an archetype and how it operates inside (Y0 with individualistic work or maybe Y1 with a mini-waterfall), this means that a given team doesn't live up to its full potential yet.
Hence, you've found your coaching opportunity - a lever! This can be visualized with the sub-levels as illustrated in the picture below:
Imagine every box of the Org Topologies™ map has a smaller map inside. As we described above, with the help of the networking topologies, an A2 archetype can be different when studied from the inside. This is what you typically see around when coaching the A2 teams:
some A2s will have a team lead and be more like a Y0 inside
some A2s will have mini-waterfalls and act inside like a Y1
others, more perfect A2s, will be more like real A2s
So, by putting a map inside a box, you can find the internal gap - a coaching opportunity:
Summary
Applying Org Topologies™ to coach organizations requires observing the system as a whole as well as its parts. Studying the whole system or its parts are two different approaches that are valuable in understanding the whole ecosystem.
Working with the whole
When we observe the whole, we assess which elements are in the ecosystem and study the interactions between them. We are not zooming in trying to improve the performance of a single part. We design and sustain the org design by working at the level of the organizational building blocks (the archetypes). Once we understand how the parts are interacting and what level of adaptivity this produces for the whole system (i.e. the development organization), we can formulate actions to redesign it to obtain higher adaptivity at the whole level. An example of such a systemic change is moving a collection of teams that work independently from each other with feature ownership towards a team of teams that work as one on a business objective.
Coaching the parts
We can also deliberately zoom in and study the parts internally. In other words, we consider the organizational element that we examine to be the boundary of our system. Inside that system the mapping of Org Topologies™ can be equally applied to study the interactions of individuals inside an org unit. We will find many coaching opportunities by going to Gemba to coach the teams. We can help them to unleash their true potential by leveraging their inter- and in-team collaboration skills.
© 2023 Roland Flemm and Alexey Krivitsky for Org Topologies™.
