This article is a detailed analysis of James Shore's talk at the AgeofProduct. We recommend watching the full video of the talk.
We're looking at this case study from the viewpoint of Org Topologies™ to understand better the chain of transformations he is describing in this talk. The story he is sharing spans several years while he was helping a company to move away from a rigid multi-team constellation of component teams to an org design based on mainly stream-aligned teams of Team Topologies® and later on to a more fluid FaST-ecosystem.
The meta-level goal of this article is to demonstrate the power of Org Topologies™ as an approach to visualizing and communicating org design and org change ideas. Thus, this article contrasts three different organizational designs showing their significant differences.
First Org Design: Component Teams
In the video, James Shore first shares his definition of component teams:
In the Org Topologies™ language, we are trying to avoid the black-and-white definitions like 'component teams'. That's why we have a map of 16 archetypes, with 7 of them being the most recognizable.
If we map the 'component teams' as James describes them, they will be represented by the orange post-its on the map below as Y2 and Y3 archetypes. The exact classification will depend on how incomplete or complete those work units are in terms of their technical capabilities:
In James' words:
"Component Teams ... is the most common thing I used to see and actuallty the most common thing I still see today....
This is where each team is focused on a particular technical part of the system... A front-end team and a back-end team... The database team... Or the Ops team... People who are focused on specific technical areas.
James was hired to help that organization with component teams because "the work was grinding to a halt." This is not surprising if we analyze an ecosystem of such teams:
structurally, such teams cannot independently ship customer features or work on business objectives end-to-end (that's why they are mapped at the Y-level, the task focus level. They can't complete user features);
they cannot see the bigger picture, simply because that is not their focus;
therefore, such teams require external specialists and functional groups to provide them with detailed requirements and task breakdowns and help them coordinate and integrate their tasks into a shippable valuable piece of software.
An organization that has such an organizational design will have many blocking dependencies, hand-offs, queues, coordinating roles, upfront plans, dependency boards, and integration issues to manage. Such an organization will be too busy dealing with its world of self-imposed complexity. Rather than being customer-focused, outcome-oriented, and product-centric.
The mapping below depicts all the overhead archetypes that are needed to complement the Y-level archetypes for the whole system to deliver a working product (individuals and groups dealing with analysis, design, coordination, integration, operation, etc.):
No surprise such organizations would want to improve, eventually. But in our experience, the required management awakening can take years. Why is it so hard to change?
An org design with component teams is very sticky.
First of all, the developers in component teams might not see a problem at all! They strongly focus on what they are good at (and everyone likes to have focus). They feel a strong sense of ownership (of components). All the excessive complexity such a component organization needs is handled by people external to the developers. So, the developers usually don't feel the burden.
Sometimes, when you talk to the developers of component teams and ask whether they know of many cross-team dependencies, they might surprisingly respond: "No, not at all!". Component teams might not see the dependencies, as each team has its task-level backlog that someone external to the team populates and manages. They live in an illusion of independence. "We can do those tasks without any other team," they'd say. And they would be correct. But from the value flow viewpoint, a feature touching multiple components that are owned by different teams has to be broken down into separate tasks. And those separate parts of the feature sit in many different team-level backlogs. Will they be picked up by different teams simultaneously and worked on in a single cadence? Very unlikely. So there are dependencies and asynchronous work that slows down the delivery of value, but one needs to see the bigger picture to see that.
This can be summarized by this famous definition of a cognitive bias described by Daniel Kahneman in his book "Thinking, Fast and Slow":
What You See is All There Is (WYSIATI) says that when presented with evidence, especially those that confirm your mental model, you do not question what evidence might be missing.
The dependencies are between the backlogs, not within them. But these dependencies are not what the teams are looking at... That's why component teams might linger in sweet ignorance of being 'efficient' and 'productive'.
This can be illustrated with the following map overlay:
See how this illusion of independence and the focus on internal concerns (better developers' focus, stronger developers' ownership) create a dysfunctional organization where rich collaboration and joint work of multiple teams becomes almost impossible. James reports that the company had 200 engineers, 300 people in the R&D, and 42 teams. And based on his value-stream mapping analysis, it had 97% of waste or wait time! So they were spending months on something that would take just 2–3 days of work. That was caused by all that waiting and asynchronous, unaligned work of the component teams.
James wonderfully describes in one passage the dynamics and culture such an organization exhibits, showing how such companies "get killed by their cross-team dependencies":
A team would start working on something, but they would need another team to do something, so they would hand off and then they would wait. And while waiting they would take on other work. So when another team came to them saying "we need something from you", they said "sorry, we're in the middle of something" and now that team would wait...
They created what James calls "the spaghetti diagram". Each card represents a team and every line represents a blocking dependency:
Second Org Design: Stream-Aligned Teams
James has helped the organization of 42 component teams to move away from the spaghetti state by redefining the responsibilities and making, what he calls, "full ownership teams.", which is very similar to the "stream-aligned teams" popularized by Team Topologies:
Looking at this organizational redesign through the lens of Org Topologies™, this was a move from a Y-level team setup of entangled component teams to an A-level setup with the majority of teams being able to work on customer features end-to-end. And that is a great improvement!
That organizational improvement helped the company to grow and got up to about 67 teams.
However, with the new design and increased number of teams, the company started running into new problems, which were mostly around product management. And this is not surprising:
Every new solution will create new (better) problems.
In an earlier article, we made an extensive analysis of the Team Topologies, and concluded that such a setup creates a low-level ecosystem:
So the "product management" problems referred to in the story by James are caused by the fact that the stream-aligned teams are focusing mainly on what they are good at already. They build and deliver features that lie within their field of expertise. And that is not a coincidence, That’s intentional.
In the language of Team Topologies: "The goal is to optimize for fast flow of change". Because of this optimizing goal, stream-aligned teams will be given work that is in their field of expertise because that is the fastest way to get that work done. They will be given some set of features in which they can develop deep expertise to be fast at shipping those changes. That's why the steam-aligned teams are mapped at the A-level, the feature focus level. Because of the relatively narrow scope of work, stream-aligned teams "did not truly own a significant portion of the final product" (a direct quote from James in the video). A rhetorical question: what happens when you have work units that are fixed to work only on given parts of the whole (components or feature sets)? You will have dependencies between the teams! But we agree such dependencies are less strong than between the pure component teams. So the new setup is an improvement compared to the previous state.
According to the storyline, the new org design with stream-aligned teams was significantly better than the initial one with component teams. With the stream-aligned teams, you can focus more on external concerns such as shipping features to serve known user needs, getting fast feedback thanks to the fast flow of change, and then improving the product features. That feedback cycle is the essence of agility.
Yet, James also mentions issues related to this design. One issue had to do with not having enough "specialties" such as UX, Security, and SREs (site reliability engineers) in each team. In other words, the teams were incomplete (A2 as per Org Topologies™).
In this phase they had to deal with two different kinds of dependencies:
product-level dependencies, due to the narrow scope of work (features) in teams
specialization dependencies, due to the incompleteness of skills in teams
The second issue mentioned is of greater importance. It had to do with the architects (likely a C1 archetype, as per Org Topologies™) not being able to constantly match the team structure to the changing business and architectural needs. This is substantial: the "essential agile" team archetypes, as per the illustration above, cannot sustain business-level agility. By design, such teams tend to be stuck at whatever they are already good at (they have a feature focus). Thus, they are not fluent and unresponsive when it comes to changes in the product strategy or changes in the architecture. They can't adapt quickly and easily. They are stuck to build and ship fast what they know how to build and ship (remember: the fast flow of change is the goal for stream-aligned teams).
To keep the organizational design and the business strategy in sync, narrowly specializing teams (like all stream-aligned teams) need to be reorganized regularly. This is expensive and difficult. James concluded in his story that the architect group failed at that task. But our view on that is that the task of realigning the team structure to the strategy is too complex to be performed by anyone regularly. And the scale they had (40+ teams) was also not making it less of a challenge.
So the next step the company was heading toward was to craft an organizational design that would enable true (business-centric) agility. This should be a design where the structure is in constant re-alignment to the business needs. A fluid structure.
Third Org Design: Towards True Agility with FaST
James got excited about the FaST. He learned it from Quinton (Ron) Quartel and Paige Watson around 2019. FaST stands for Fluid Scaling Technology, and is about combining open space technology (a tool for self-organization) with a frequent opportunity to change team compositions.
The reason FaST appealed so much to James, in his own words:
What we were doing in the Team Topologies approach is that we were scaling horizontally. We're adding people by adding new teams... That requires careful design... Ultimately we're talking about making a big design change to the organization and potentially reflecting that also in the architecture... Sort of a top-down approach ... and to be done in kind of a big bang way.
So the self-managed, bottom-up, and incremental approach offered by FaST was appealing to James, being much more in the spirit of agile:
In the FaST approach we're scaling vertically. We're adding people by having more people participating in one virtual team (a Collective), having more people act as a single team.
Essentially, James ran an experiment in that company with a subset of seven very tightly coupled stream-aligned teams (around 50 developers) and turned them into a FaST Collective. This essentially is a single large team that regularly self-organizes into temporary small teams based on the work at hand.
James concludes with these five key takeaways:
We conclude that FaST has helped to design and sustain a high-level product-centric ecosystem in that company. James also talked a lot about the high transparency such an ecosystem created for its business stakeholders. And we know in empirical process control, transparency is a prerequisite for proper inspection and adaptation. Hence, it is an enabler for better steering and governing. So the third organizational design was displaying better manageability and higher adaptability than the other two options (component teams and stream-aligned teams).
This positions FaST in the top-right corner of the Org Topologies™ map, potentially spanning the area from B2 and B3 up to C2 and C3.
And where does a FaST collective as described in the video live, exactly in the land of FaST?
The vertical aspect:
It depends on the size of an organization: with only 50 people in R&D, all developers would belong to a single Collective. And by definition, that Collective would own the whole product. Therefore, that would be a C-level ecosystem.
We cannot imagine the constant creation of temporary teams with hundreds of developers in an open space every other day (we are open to learning that this is possible, so we need more case studies, experience reports, or invitations to implement this). However, for now, with the facts that we have, we believe that with hundreds of developers, there will be a need for several Collectives. And likely each Collective will own its product part. Therefore, this would be a B-level ecosystem.
The Collective described in the video was formed from seven tightly coupled teams, while the rest of the organization remained unchanged. Although it was not clear in the video whether the Collective worked on the whole product or just its part, it is safe to assume that they worked on a product part. Therefore, the case presented in the video would be classified as a B-level archetype.
The horizontal aspect:
For a work unit (a team, a team of teams) to qualify for a multi learning unit (Y3, A3, B3, or C3) it needs to exhibit a unique observable behavior: over time people in that unit are acquiring new skills, hence they 'multi-learn' (we borrowed this term from an HBD article).
Multilearning is very much different from multi-skill work. In the latter case, people with existing skills work closely together, utilizing their existing skills. In a long-living stable team with a broad product scope, it is simply not possible to keep utilizing one's existing skills forever without being constantly under or overloaded. That's because a constant match between the existing skills and the demand for skills is highly unlikely in a complex work environment (i.e., product development). That means, the fewer skills you have, the bigger the chance you won't be able to utilize them all the time when working on the business priorities. So, in a long-living stable team, to stay relevant, one will have to acquire new skills that are currently in higher demand, hence: multi-learn. That's the dynamics expected in LeSS with feature teams (as a side note: in the video James is misusing the term 'feature teams' equating them to 'stream-aligned teams'; which is a big misunderstanding).
In FaST, people have a chance to change work and with whom they work every few days (for the next FaST cycle) because of the built-in fluidity. Will the people be acquiring new broad skills in such a fluid environment? Or will they follow the work and maximize utilization of their existing skills? Will a back-end developer self-volunteer to work (and multi-learn) a front-end task for the next cycle, or will she be pulled in to contribute with her existing back-end skills? That is very contextual and will depend on many things, including personal motivation, stress, level of engineering practices, code-sharing policies, coaching by the managers, the existing reward systems, HR policies...
So we can't say that FaST will always be fostering the creation of multi-learning work units, though, we believe it is not impossible, but FaST alone (as a process) won't suffice.
Hence, it is safe to assess the target org design in James' story at B2-level Collective.
Summary
This case study illustrates the power of the Org Topologies™ approach in assessing different organizational designs and organizational change ideas from the viewpoint of structural facts and observed inter-team dynamics.
We encourage you to apply it at your workplace and report back. There is a growing learning community:
(C) 2023, Alexey Krivitsky and Roland Flemm. Org Topologies™.
This experience report presents a personal view of the change story based on the provided references. Should you have alternative views or additional details about this particular company's change story, please do not hesitate to contact Org Topologies and submit your version for publishing.
