Author: Jurgen Appelo

Like many authors, I receive a fair share of criticism on my work. Some of it might even be deserved. 😅 But nobody had ever a good reason to accuse me of missing credits and references.

Part of the unFIX model is inspired by the Team Topologies work of Matthew Skelton and Manuel Pais. (Other inspirations were the Spotify model, Dynamic Reteaming, Management 3.0, and more.)

I have often said that each team in a company should be a “value unit”: they should offer something of value to customers, users, or other teams. But I could never figure out how to proceed beyond that. For Management 3.0, I created the successful Meddlers game, which allows people to play with teams and roles, but I didn’t know how to turn that into advice about scaleable organization designs. Clearly, I needed more inspiration.

Some years later, Matthew Skelton and Manuel Pais published their book Team Topologies and offered their take on organization design for software development. They convincingly showed that team structures must consider the cognitive load per team and match the required software architecture.

And that was what I needed. The Team Topologies work helped me get unstuck. I adapted some ideas to fit my context and changed some terminology (but I used similar colors). I added the insights I obtained from personal experience and other sources, and the result is what you find on this website: the unFIX model.

Conway’s Law

Another source that I took as inspiration for my work is Conway’s Law, and the Team Topologies guys have done the same.

Conway’s Law seems like an inverted way of saying, “form follows function”. You only know the form when you know the function. You can only decide what team structure you need when you’ve figured out what the organization should offer in terms of value. Because, inevitably, the form of the organization will be reflected in the design of the system.

To increase an organization’s chances of building effective software systems optimized for flow, a reverse Conway maneuver (or inverse Conway maneuver) can be undertaken to reconfigure the team intercommunications before the software is finished. - Matthew Skelton and Manuel Pais, Team Topologies

Allowing team structures to evolve together with their functions requires a different way of doing organization design. Team Topologies and unFIX are based on this same guiding principle.

Cognitive Load

When writing this article, I had to take out a manual and re-learn how to clean and descale the washing machine. The last time I did that was a year ago. I also had to dig into a FAQ to re-learn how to enable cross-EU VAT in my bookkeeping software. The last time I did that was three years ago. As humans, we spend a lot of time re-learning things we already learned earlier. This sucks. 😕

Looking back at the Team Topologies book, one new concept was that of team cognitive load.

For software-delivery teams, a team-first approach to cognitive load means limiting the size of the software system that a team is expected to work with; that is, organizations should not allow a software subsystem to grow beyond the cognitive load of the team responsible for the software. [...] When cognitive load isn’t considered, teams are spread thin trying to cover an excessive amount of responsibilities and domains. Such a team lacks bandwidth to pursue mastery of their trade and struggles with the costs of switching contexts. - Matthew Skelton and Manuel Pais, Team Topologies

In other words, try not to burden teams with so many responsibilities that they’re forced to swap knowledge in and out of memory. Computers can do that easily. For humans, this can be frustrating and wasteful.

It’s probably of no use trying to remember how to clean the washer because the information will just overwrite something else in my overloaded brain. And then, a year later, I will have to re-learn how to light the Christmas tree.

Team cognitive load is a sound guiding principle. It reminds us not to waste our team members’ time with context-switching and re-learning the same things repeatedly.

Now, let’s have a look at the team topologies!

Stream-Aligned Team

In Team Topologies, the stream-aligned team is aligned to workflow from (usually) a segment of the business domain.

A stream-aligned team is a team aligned to a single, valuable stream of work; this might be a single product or service, a single set of features, a single user journey, or a single user persona. Further, the team is empowered to build and deliver customer or user value as quickly, safely, and independently as possible, without requiring hand-offs to other teams to perform parts of the work. - Matthew Skelton and Manuel Pais, Team Topologies

The stream-aligned team is practically the same as the Scrum team, XP team, Kanban team, Squad, or Feature team, depending on your method or framework of choice. In unFIX, I refer to these as Value Stream Crews. Different name, same animal. The concept of the self-organized, autonomous team organized around the flow of a value stream has been around for decades. Every other agile method and framework out there will tell you to do the same thing. Nothing new under the sun. Been there, done that. Let’s move on.

Enabling Team

In Team Topologies, the enabling team helps a Stream-aligned team overcome obstacles.

The end goal of an enabling team is to increase the autonomy of stream-aligned teams by growing their capabilities with a focus on their problems first, not the solutions per se. If an enabling team does its job well, the team that it is helping should no longer need the help from the enabling team after a few weeks or months; there should not be a permanent dependency on an enabling team. - Matthew Skelton and Manuel Pais, Team Topologies

Teams of consultants, agile coaches, scrum masters, product owners, and facilitators already knew long ago that, even though they offer value to other teams, they don’t make a product themselves. These facilitators organize themselves differently. Therefore, it makes sense to describe them with a different team type. It’s a known, typical pattern, and in unFIX, I refer to them as Facilitation Crews.

The Team Topologies book insists that there should be no permanent dependency on enabling teams. Theoretically, their involvement is often only temporary. But that doesn’t mean that Facilitation Crews should always disappear. On the contrary, their enabling/facilitating role can be long-lived or even permanent. For example, I don’t depend on a personal trainer as a runner. (In fact, I don’t even have one.) But there would be no problem building a long-lived working relationship with someone who keeps pushing me to perform better. 🏃🏻‍♂️

An additional task for a Facilitation Crew can be to help with coordination and collaboration across the Value Stream Crews. As a business, you strive to optimize the whole, not the parts. A significant danger (experienced with the Spotify model) is that teams focus only on their own work. With a Facilitation Crew, you can prevent this from happening. For example, technical leads could form a Facilitation Crew to ensure that design and architecture across the teams move in the same direction. Strictly speaking, the teams don’t depend on such a Facilitation Crew, but the company does!

Complicated Subsystem Team

In Team Topologies, the complicated subsystem team is where significant technical expertise is needed.

A complicated-subsystem team is responsible for building and maintaining a part of the system that depends heavily on specialist knowledge, to the extent that most team members must be specialists in that area of knowledge in order to understand and make changes to the subsystem. - Matthew Skelton and Manuel Pais, Team Topologies

I must admit that I very much dislike the name “complicated subsystem team”. The term is far too ... 🤔 ... complicated. But I agree with Matthew and Manuel that this kind of team is not the same as a traditional component team. The purpose is to offer the value stream teams access to a rare capability, not a standard component.

I disagree that “specialist knowledge” is always about a subsystem. Sometimes, it can be about access to a rare talent (a cybersecurity genius or a machine learning guru). Sometimes, it’s about access to a precious vault of data (like a gatekeeper to sensitive customer information or business data).

Those who offer unique expertise do not always build a subsystem. They provide a rare capability that can take any form. For example, they could be two award-winning UX designers that all twelve Crews would love to work with. That’s not a shared subsystem; that’s shared competence. That’s why I decided to refer to them as Capability Crews. What remains the same is that the guiding principle of team cognitive load makes us treat these as a separate team. Teaching or giving all teams the same capability is either undoable or undesirable.

Platform Team

Finally, Team Topologies offered the platform team as a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams.

The platform team provides internal services to reduce the cognitive load that would be required from stream-aligned teams to develop these underlying services. [...] To avoid the too-common trap of building a platform disconnected from the needs of teams, it is essential to ensure that the platform teams have a focus on user experience (UX) and particularly developer experience (DevEx). - Matthew Skelton and Manuel Pais, Team Topologies

Again, there is not much new here. Platforms have been around for, I don’t know, forever. Based on what I learned from Amazon, Netflix, and others, I discussed teams becoming vendors/platforms to other teams in my first Management 3.0 workshops eleven years ago. And thus, it made perfect sense to include the platform concept in unFIX with the Platform Crew. But—with a hat tip to Team Topologies—I gave them the same position and a similar color in the diagram.

A subtle difference between Team Topologies and unFIX could be that they refer to their platform team as “a grouping of other team types”. In contrast, I usually refer to it as one Platform Crew. In unFIX, if the platform grows to become more than one team, the obvious thing to do would be to split it off as a new Base. And then the new Base is the platform. Same idea, different words.

Base

If we already knew all team types, why does Team Topologies deserve credit? First of all, they introduced the idea of team cognitive load as a design principle, which is super-useful for organization designers. On top of that, as I see it, many of us already understood the landscape of team structures, but Team Topologies created a better map. But that’s where the similarities between Team Topologies and unFIX come to an end. The map of Team Topologies is a great starting point, but I also found it to be incomplete.

First of all, it offers no clarity about the container for the teams. What entity “owns” those teams?

In unFIX, I offer the concept of the Base, which is an adaptation from the tribe in the Spotify model. The Base is the home for all workers and provides them with a sense of belonging, purpose, and recognition. There are good arguments to claim that the Base is the most essential part of the unFIX model. Without the Base, why would people even be bothered to participate in the various Crews? People leave companies because of a lack of belonging, purpose, or recognition. They don’t leave companies because of their cognitive load.

In addition, I describe four Base types: fully integrated, strongly aligned, loosely aligned, and fully segregated. The Base type has significant consequences for the design of the organization and its teams.

With unFIX, I also tentatively propose a way to scale things up in a fractal manner. Like workers belonging to a Base, Bases could belong to a Super-Base. Theoretically, what works at the Base-level should also work at higher levels. I can see how Team Topologies can scale out, but I don’t see how it can scale up.

With unFIX, I made a more scaleable map.

Governance Crew

Another thing not included in Team Topologies is a place to go for the management team. In my experience, if you don’t show where the managers go, A) You might find it hard to get management on board, and B) You run the risk of managers popping up all over the place. You might even see a matrix organization sneaking in through the backdoor.

And that’s not what we want! ☝🏻

In unFIX, I insist that the line managers are Chiefs in a Governance Crew. Line managers cannot be anywhere else but in the Governance Crew. No matrix! You don’t want them in any of the other Crews because this would implicitly create management territories. And good luck to you keeping your team structures dynamic when managers try to protect their territories. No, no, no, no, we don’t do that.

The managers are in the Governance Crew, and they are the only ones with direct reports across the Base.

Experience Crew

I gave up interacting with my Internet provider because none of their tools and customer touchpoints seem integrated. They usually have no clue what another part is doing. Each conversation with them is pure mental agony. 😖 I also kicked out a grocery delivery service because, even though their app is superb, they failed to deliver the right products three times.

I noticed in the software world and across all scaling frameworks the obsessive focus on product development rather than customer experience.

Years ago, organization designers noticed the increasing pressure on companies to offer one cohesive experience to customers. With customer journeys cutting right across websites, apps, chatbots, brick-and-mortar stores, support centers, and more, there is an ever-increasing need to create integrated experiences. And that’s never going to work if you have multiple Value Stream Crews optimizing their own products for customers.

We’re not in the business of offering products; we’re in the business of creating experiences!

In unFIX, I describe the Experience Crew as a special kind of Facilitation Crew. Their purpose is to ensure that the Value Stream Crews are not optimizing locally and, instead, keep their eye on the whole customer experience. And—please pay attention SAFe and LeSS practitioners!—this goes beyond having one Product Owner or Product Manager coordinating a shared backlog for multiple product teams! Because, in that case, you’re still only focusing on the product. And then what about Support? What about Marketing? Finance? Logistics? Don’t they interact with customers as well?

Whenever a user or customer finds that something sucks, the Experience Crew should be the first to know. And then resolve the matter across the various Value Stream Crews together.

Partnership Crew

When you have an Experience Crew for customers, it makes sense also to consider one for suppliers.

I sometimes think that my company is one of the few that cares about freelancers, vendors, gig workers, business partners, and other stakeholders. And more than one scaleup and tech unicorn has shown that screwing the supply-side of your business can take you a long way. But, frankly speaking, I find that a bit unethical.

My brother-in-law keeps telling me that selling his products as a vendor on Bol.com is a pure delight compared to the horrors of signing up as a supplier with Amazon.nl. This gives me hope that Amazon will find it hard to dethrone the Dutch number one online retailer any time soon. Amazon cares much less about its suppliers.

I believe it is worth treating vendors and suppliers with respect. You should offer them a great experience. That’s why I introduced the Partnership Crew. Its goal is to care about any external stakeholders your company depends on. But hey, it’s your business, your choice.

Forums

The Team Topologies book talks about the difference between enabling teams and communities of practice (CoP) but, sadly, does not include the concept of CoPs in its pictures. (Unlike the Spotify model, which shows the CoPs as guilds.)

The members of an enabling team work on enabling activities full-time, whereas a CoP is a more diffuse grouping of interested individuals from across several teams, with an aim to share practices and improve working methods on a weekly (or monthly) basis. - Matthew Skelton and Manuel Pais, Team Topologies

With unFIX, I included Forums as the way for people to discuss similar interests, whether they are functional, technical, geographic, or market-oriented.

Within one Base, the Forums are somewhat similar to Spotify’s chapters (but without line management!). Across multiple Bases, such Forums would be the equivalent of guilds or CoPs.

Interaction Modes

Something I have not included in unFIX is the idea of interaction modes. Team Topologies defines them as follows:

• Collaboration: working together for a defined period of time to discover new things (APIs, practices, technologies, etc.)

• X-as-a-Service: one team provides and one team consumes something “as a Service”

• Facilitation: one team helps and mentors another team

I have difficulty understanding the added value of using these “modes” and I suspect most teams probably apply a combination of these. For example, a Platform Crew would aim for X-as-a-Service (possibly with an API and an SLA), but they might also be in Facilitation mode when offering personal support (teaching other teams the use of their API).

I’ve decided not to prioritize “interaction modes” as I don’t think this is a crucial concept for now. And I am perfectly happy to refer to Team Topologies for more information on this. It’s OK for people to have different maps. Sometimes, you use one; sometimes, the other.

Stable Teams

We finally encounter an interesting point of divergence with the topic of stable teams. In Team Topologies, the authors note that “teams should be stable but not static, changing only occasionally and when necessary”.

I respectfully disagree.

More and more businesses experiment with dynamic reteaming: intentionally and proactively changing team membership to support personal development and business agility. There is no need to do this “only when necessary”. Redgate Software is one of the companies reporting positive results with reteaming once per year. And the Serious Scrum blog reports positive results with reteaming every sprint.

It is best to read changing teams “only when necessary” as “when the benefits outweigh the drawbacks”.

Continuous Transformation

Team Topologies and unFIX agree on the need for continuous innovation and transformation. When the customer experience changes and new value must be offered, the team structure must follow. The organization’s design must be as versatile as possible.

When designing modern organizations for building and running software systems, the most important thing is not the shape of the organization itself but the decision rules and heuristics used to adapt and change the organization as new challenges arise; that is, we need to design the design rules, not just the organization. - Matthew Skelton and Manuel Pais, Team Topologies

To support continuous innovation, unFIX comes with three additional ideas:

• With Business Lifecycle stages, you determine what stage your business model is in, and each business model can start up, scale up, and screw up.

• With Delegation Levels, you can make incremental changes to existing structures, making it easier to move things around by applying kaizen (gradual change) rather than kaikaku (radical change).

• With the Innovation Vortex, I merged all iterative/incremental models into one, which helps to invite the Crews to consider all streams of the vortex.

Conclusion

I have nothing but great respect for the work of Matthew Skelton and Manuel Pais. The industry keeps improving because people inspire each other and build on each others’ work. I am proud that I can make my own contribution to that process. And I can only hope that others will take my work in new directions.

There are no conflicts between Team Topologies and unFIX. The minor differences are easily reconciled, and it’s easy to use both tools in parallel.

1. Team Topologies is for software teams; unFIX is for many kinds of businesses.

2. Team Topologies shows no container around teams; unFIX has the Base.

3. Team Topologies has no element for management; unFIX has the Governance Crew.

4. Team Topologies has no element for customer experience; unFIX has the Experience Crew.

5. Team Topologies has no element for supplier experience; unFIX has the Partnership Crew.

6. Team Topologies shows no communities of practice; unFIX has the Forums.

7. Team Topologies offers interaction modes; unFIX does not.

8. Team Topologies prefers long-lived stable teams; unFIX supports dynamic reteaming.

9. Team Topologies does not mention lifecycle stages; unFIX has the Business Lifecycle.

10. Team Topologies does not mention gradual change; unFIX has Delegation Levels.

11. Team Topologies does not mention iterations/increments; unFIX has the Innovation Vortex.

12. Team Topologies shows no upwards scaling; unFIX suggests the Super-Base.

I hope you found this comparison helpful, and I hope Matthew and Manuel can forgive me for the alternative terminology.

But I stayed true to the colors! 🌈😎