Org Topologies™ is a mapping of recognizable organizational archetypes in product development. We are using the following two axes for creating the two-dimensional map:
Grow team-level capabilities – by deepening cross-functionality to become fluent in delivering value fast.
Grow customer-centric capabilities – by broadening understanding of the problem space.
Being organizational consultants and field practitioners, we (Alexey and Roland) have assembled and generalized our recollections of many organizations that we have worked with. As the result, we've come up with seven archetypes.
Each of them has a recognizable name and a description of its longing—an optimizing goal. If you've been in the industry for at least a few years and have met several companies that differ in culture, you shall be able to recognize and guess most of these seven archetypes
Less generic and more recognizable names of these archetypes are:
Y1: projects and task work
Y2: component development with narrow-specialized teams
A2: hopeful yet entangled teams
A3: proud and autonomous teams
B2: dependent teams tied up on business value
B3: interdependent teams collaborating on business value
C3: holistic product development
Here is how they are mapped along the two axes of the Org Topologies™ map from bottom left to top right by an increase in organizational adaptivity, innovation, and therefore resilience.
Caution (for Systems Thinkers)
The next chapters will describe the most recognizable archetypes of work units (groups and teams) as, we believe, this provides a useful language that we all can learn and start sharing to better communicate org design ideas.
Yet we don't imply one needs to work on improving those work units independently of each other if you have many of them within the organization. This would be a trap and a lack of systems thinking. Those archetypes don't exist in isolation, they interact and influence each other. They actually reside in those boxes (Y1, A2, etc) and are hard to improve exactly because of the interactions among them.
So don't work on them separately - learn to see a system (interacting parts) and approach your transformation as a systemic one. Below is an example of mapping a real ecosystem that contains three groups/teams and one individual (architect) - the dotted lines represent relationships and reinforcements.
Individualistic Work
Project and Task Work (Y1)
Optimizing goal of this archetype: “optimizing for resource utilization of cost centers”.
Meet the 1st lowest group work archetype, located in the Y1 box of the map. That is a sad place to be. Still, we have it on the map because for some organizations it is a starting point on the journey. And we are welcoming them!
Such an organization operates on the lowest level of value definition – the task scope. It knows how to manage the flow of work at the level of individual single-skilled workers. Despite being at the lowest level of the map, the managers are overloaded here. They do everything – from collecting and analyzing the requirements, to breaking them down to tasks and allocating them to skills, from control of task execution to work integration and conflict management. They are so busy and bogged down with micro-work, then they don't have the time to stop, think and change the system. Because of this dynamics and other factors in play, this archetype is very sticky. Organizations can live in such a state for many years without being able to implement a real, deep change. By the way, all other archetypes that we are describing here are also sticky, but each for its own, different reason.
Component development with narrow-specialized teams (Y2)
Optimizing goal of this archetype: “optimizing for narrow ownership”.
At this level, an organization recognizes the value of people working together as a way to accomplish more work. See the Y1 box of the map. Here organization has created narrow-specialized component-oriented and function-oriented groups are got formed. That can be a “back-end service team” or a “testing and automation team”. But they are not yet teams in the way Richard Hackman defines them:
These groups are lacking compelling direction, as their scope of work is at the lowest level – the task scope. No customer requirement can be fully done by any of such groups, so they keep working almost blindly on some parts of features, receiving and passing work like on a conveyor belt.
These groups are also not real teams, as they depend upon external specialists who break down requirements into tasks for them, manage and then integrate those pieces together. Such structure is not enabling team's self-management. As eventually, there are numerous business and system analysts, architects of different kinds and dependency managers meddling with the groups.
The life-cycle of a customer requirement development looks very much like a sequence of touch times from different narrowly specializing groups. A waterfall.
Implementing Scrum with such an org design is truly impossible without changing the structure.
Summary of Task-Level Archetypes (Y1 and Y2)
Y1 and Y2 are very recognizable organizational designs. Lacking a definition of customer value, such organizations focus on what they see and can manage – “busy-ness” of its employees. As we know, being busy has almost nothing to do with learning and delivering value. So, we call these two archetypes non agile-friendly. As their principles of operation contradict just about any value and principles from the Agile Manifesto.
The mission of Org Topologies™ is not to criticize, but to enlighten on the path to undertake. Therefore, these organizations in order to become agile-friendly need to realize two paradigm shifts:
shift to multidisciplinary work (a move right on the X-axis)
shift to user focus (a move up on Y-axis)
Meet the Teams
Hopeful yet entangled teams (A2)
Optimizing goal of this archetype: “optimizing for quick wins and conflict avoidance”.
From the previous two archetypes, we are now jumping one level up and on step to the right. Such organizations understand customer requirements at the level of features (user stories, if you will). They have learned how to manage work at that level, delegating lower level task-related concerns to the teams. For this to happen, they had to assemble stable long-living multidisciplinary teams. So, the moves to the right and to the above on the map support and reinforce each other. This is the A2 box of the map.
Referring to Richard Hackman and his definition of 'being a real team':
The elements that are required to ensure a team is 'a real team' are: the members have a shared task, the team boundaries clearly state who is inside or outside of the group, and the group membership is stable.
Such an organization now has real teams. They can do Scrum and learn to ship fast. This creates “quick wins” as it states in the optimizing goal of the archetype.
Work in such teams is now more fluent on both axes of the Org Topologies™: in delivering and learning value. Yet, this is still far from the perfection-vision as there are glitches and blockages in work of such teams. What is causing them? Such teams might occasionally be missing some skills and responsibilities. Those have not yet been transferred to the teams and are still occupied by individual specialists, specialist groups, or component teams. Breaking down barriers will inevitably create organizational conflicts for which the organization is not ready yet. This issue is highlighted by the part “conflict avoidance” in the archetype's optimizing goal.
This short video explains this archetype with an example of mobile development done by a freshly assembled “mobile team”.
Proud and autonomous teams (A3)
Optimizing goal of this archetype: “optimizing for feature ownership and team throughput”.
Moving one step to the right and realizing the paradigm shift of 'multilearning end-to-end teams', an organization has created proud and autonomous teams. Throughput of individual teams is higher than ever before. And it is likely measured as a team's velocity.
This is a dream of many engineering and DevOps coaches – to be able to form and sustain teams that can work on user featured end-to-end. “You built it, you run it” – as a mantra for such teams. How do you know your organization is at this level? Because of the strong belief in feature ownership, the teams will likely be named after the things they are kept accountable for. You're likely to see an “iOS team”, a “search team”, a “data science team”, etc.
Ownership is a great thing. Such org design allows people to show love and care for the things they officially own. But it is also a double-sided sword: they don't care of the rest. As the rest seem to be taken care of by the others. This creates ours – theirs mentality. A “not our job” kind of culture. This may not have been an issue in another industry, but in digital product development, most of the complex issues happen at the boundaries of sub-systems. In between “ours” and “theirs” – in the space that probably nobody owns. That causes occasional friction in delivery, but not every time. Eventually, an organization learns to live with these issues. And that is why this archetype as sticky. It is stable in the way that an organization can live in it for many years without seeing the need for a radical change.
The next short video summarizes the wins of such an org design. But, as everything under the Moon, solving one problem eventually creates another higher level of problems. “We are constantly moving towards better problems”, one can say.
Summary of the Team-Oriented Archetypes (A2 and A3)
Creating better teams, the so-called “agile teams”, is a target for many organizations that we have worked with. Progressing along the X-axes, and investing in the teams to grow their engineering capabilities, is a great and vital direction. But we believe, in order to realize its true potential – the highest levels of agility (adaptivity, innovation, and resilience), an organization needs to progress along both axes.
One key reason of creating the Org Topologies™ was to show creating great agile teams, it not all that an organization can be dreaming of and strive for. As we concluded in our detailed analysis of Team Topologies:
Value of teams can be only measured by value of their work.
So let's explore higher definitions of value that teams can be focused on to serve a higher cause.
Meet the Team of Teams
Dependent teams tied up on business value (B2)
Optimizing goal of this archetype: “optimizing for managing dependencies”.
This archetype and the two remaining ones can be considered as high-maturity ones. If B2 is done right, the teams do work collaboratively on higher definitions of value. Here, a group of teams can be focused to work on an end-to-end customer journey. For instance, helping a buyer to go from learning about the brand to selecting and configuring products, to purchasing and coming back for service.
Having such a holistic view of an end-to-end customer journey, teams will be optimizing for better customer experience, not just individual features. That will inevitably contribute to having easier sales and higher customer retention. Important business metrics. Thus, the teams should define, measure and own such metrics. This helps teams to make a transition from being delivery team to becoming product teams. Marty Cagan writes a lot about empowered product teams (that's a reference of our analysis of that idea).
The idea behind forming team around broader value areas might some familiar to those familiar with the Spotify's Tribes and Squads model (a reference to our analysis). But take a look at the video below – the idea of teams sharing the end-to-end customer journey only works if they shared a single backlog.
Interdependent teams collaborating on business value (B3)
Optimizing goal of this archetype: “optimizing for control of business goals and customer experience”.
This short video addresses the issue of the previous archetype and goes further in creating well-functioning value areas with multiple teams collaborating.
Summary of B2 and B3: Towards Better Silos
Optimizing goal of this archetype: “optimizing for adaptivity in learning and delivery”.
This level of fluency of value delivery and learning takes and organization closer to the unattainable perfection vision of higher adaptivity and innovation.
At this organizational maturity, the team-level silos have been systemically fought and almost gone. There are no more walls between specialists and teams. All the teams within a given value area work as one. They are now, what we like to call, a team of teams, where multiple teams work as one and form a collaborative ecosystem. Notice how the understanding of team-ness changes in widens as an organization progresses on the map:
A team of teams in a value area is fantastic as it speeds up delivery and learning at the organizational level because of fewer barriers between the individual teams. This creates more transparency for empirical control and improvements.
But are there no walls at all? We can't say that without knowing the context of an organization. But generally speaking, from what we have observed in many organizations, there are high chances, that the value areas are implemented as org units – departments. New kind of departments, value-oriented and customer-facing. However, still departments. And that means new walls and new separation. Yet better walls and better separation because the space in between the walls is now bigger, it can hold more teams, many skills and is a context for collaboration.
Will there always be silos and walls, no matter how well we improve?
A Company is One Team
Holistic product development (C3) and Beyond
At the level of C3, there are no fences in the flow of value within a given organization. All teams are One Team. Owning the product with all its sub-products, parts, and services.
Is that real? Can you go that far? Is such a state sustainable? Won't the local tendencies and desires of individuals go against such a high-state org design? See it more as a journey than the target, then the path itself becomes the goal.
If you're familiar with LeSS, then one of its 10 principles of the whole-product focus will ring a bell, and there are also dozens of LeSS-inspired case-studies on this.
Another great source of inspiration is Cesario Ramos' "Creating Agile Organizations" book and guides.
And if you're not Scrum-biased, then the FaST agile approach might be your path toward the higher archetypes.
Conclusion: Org Topologies™ as a Map
With this, we are concluding the overview of these key archetypes that comprise the Org Topologies™. We've demonstrated how they are mapped along the two fluency axes. We truly believe this map can serve you on your journeys in search for a better organizational design.
© Alexey Krivitsky and Roland Flemm.
