(The original version of this article was published on the Shiftup website and reposted here for historial completeness.)

Author: Jurgen Appelo

It is time for an alternative to SAFe, LeSS, Holacracy, Management 3.0, the Spotify model, and matrix organizations. We need something that takes flexibility to a new level, and that embraces hybrid working as the new normal. Here is my suggestion. I call it unFIX.

It took me twelve years to make this.

It is absurd that it took me so long because the solution I show here seems pretty obvious. In fact, it has been around for years already, and I know companies successfully applying this. It just seems that nobody documented, visualized, and named it before. To the best of my knowledge, the organizational model described in this post is the most versatile around. The structure is not new, but this description of it most certainly is.

And let me be clear upfront: almost none of the ideas in this post are mine. I could only draw and describe this model because of suggestions I borrowed from many sources, which I allowed to simmer and mingle in my head for many years.

Let’s review a few of these sources.

Dynamic Reteaming

If I were asked to name a “final piece of the puzzle”, it would be the concept of dynamic reteaming, as described in the book with the same name by Heidi Helfand. Heidi’s book helped me realize that static teams are not agile. There are at least four reasons why managers must make it easy and painless for workers to reorganize themselves into different teams:

The increased pace of environmental change and the challenge of one crisis followed by another requires an ability to form new teams rapidly. When your business is hit by a data leak, a ransomware attack, a Covid virus crippling half your teams, or a strategic move by a competitor, you have no time for your response team to go through a six-week-long episode of forming, storming, norming, and performing.
There is no way around Conway’s Law. Your business will make products with architectures that resemble your organizational structure. If you want to remain flexible by offering a dynamic set of products and services, you need to have a versatile team structure and do everything possible to prevent silos and ossification. Only flexible team structures produce flexible product architectures.
As “the Great Resignation” shows, apart from offering a great Customer Experience (CX), you are also responsible for improving the Employee Experience (EX). For sure, employees want a sense of Belonging, Friendship, and Loyalty, but they are also driven by Curiosity, Creativity, and Competence. (See the 25 Drives Grid.) A great employee experience includes personal development and career growth beyond just one team.
Last but not least, well-meant suggestions to measure team performance rather than individual performance, and to reward teams instead of individuals, easily leads to suboptimization at the team level. You might end up with competition between teams! If you want teams to care more about the whole customer experience than their local performance, you will have to put some effort into cross-team collaboration.

Don’t get me wrong. I am not suggesting that you should be shuffling people around every month. There are indeed essential benefits to having stable teams. But stable is not static! Starting, stopping, and changing teams is an opportunity, not a risk. That’s why dynamic reteaming was an essential principle for the model I describe in this post.

Team Topologies

The second source worth mentioning is the book Team Topologies by Matthew Skelton and Manuel Pais. In their work, they emphasize that the responsibilities of a team should never exceed the cognitive load of its team members. Teams should always understand every part of the work that they own, or else the constant relearning slows them down tremendously. (With my terrible memory and oversized portfolio, I personally suffer from this every day!)

The book also describes four fundamental team types:

A stream-aligned team has end-to-end responsibility for an entire value stream;
An enabling team is a team that temporarily helps other teams to get to speed;
A complicated subsystem team wraps rare and unique skills inside one team;
And a platform team offers infrastructure or architecture as if it was a supplier.

These four types are as simple as they are powerful. In my earlier work, I never got further than suggesting that each team or value unit must offer some defined value to their clients (which could be customers or other teams), but the team topologies language and pictures suddenly make my vague idea a lot more practical, and I am very grateful for that.

I used team topologies as a second guiding principle because the standard advice that “all teams should own a value stream” is too abstract, simplistic, and not actionable for most companies.

Virtual and Hybrid

My third source of inspiration is, strangely enough, a computing concept. Virtualization is the act of making a virtual version of something, including hardware, software, and interfaces. A virtual machine is a piece of software that mimics a physical machine. A virtual team is a group of people acting as if they were physically located together.

If you want an organizational structure that can handle the challenges of the 21st century, you need to ensure that there’s practically no difference between a physical team and a virtual team. You must be able to create virtual teams almost instantly, with dedicated team members working from anywhere, in a larger group, that knows how to make their teams jell.

This becomes even more important nowadays with the emergence of hybrid working. Some team members are at the office while others work from home or elsewhere. They are moving in and out all the time, and office work will never return to the way it was. Anyone suggesting that “teams must be collocated” is still stuck in pre-Covid times!

Virtualization is the third principle I applied in the model described below. Your organizational structure needs to work both physically and virtually, allowing people to work in hybrid ways. Each of your virtual teams is an instance created by a larger group, and they could be working all across the planet.

Shall we now move on to the model? Okay, let’s go.

The Crew (Team, Squad, Pod, Cell)

In the unFIX model, a Crew is a team that usually consists of three to seven people. More people is possible, depending on context, but in many cases, I would not recommend it. As I explained in my first book, the optimum team size is five. (Other frameworks suggest seven, but I believe that hybrid working calls for a somewhat smaller average team size.) Team members are mostly dedicated to their Crew, but it’s okay if they reserve a small part of their week for work on a Forum or Club (see below).

Though each Crew can be any of the four standard team types described above, in a regular business, most Crews should probably be stream-aligned teams. These self-organizing, cross-functional teams (referred to as feature teams in the LeSS framework) manage their own meetings (planning, check-in, review, and retros); they manage their own documentation and releases, and they may operate according to a team agreement that defines team identity, shared rules, and more. Unlike LeSS, this model allows Crews that are not stream-aligned. There can be good reasons for having any of the other three team topologies.

As autonomous teams, these Crews have responsibility for their roles, the methods they use, the objectives they aim for, their production cadence or continuous flow, and their dependencies on other Crews. As long as a Crew takes full responsibility for the value they provide, they have the final say over how they get their work done. Nobody else in the business is as close to the customer experience as they are.

Some people refer to these Crews as squads, pods, or cells, which is totally fine. I like the word Crew because the word suggests that its members manage a journey together. The crew of a ship takes care of the ship and its passengers. The crew of an airline is responsible for a plane and its flights. Each crew in a software company takes care of a codebase and releases. Following the principle of dynamic reteaming, we expect these Crews to be stable, but they are not static. It should not be made difficult for people to switch Crews now and then.

The Captain (Leader, Pilot)

Taking the analogy of ships and planes a step further, I see a need for one crew member to act as its Captain. Not three captains, not two captains, only one. This person is the primary contact for the outside world, and she has final responsibility for whatever happens on the journey. This does not mean that this Captain gives everyone orders. On the contrary, in his excellent book Turn the Ship Around, David Marquet explains that a good captain makes very few decisions indeed. A well-performing Crew knows how to self-organize, and its Crew members understand their responsibilities!

A Crew can have a few additional roles, such as Product Lead, Tech Lead, etc. Depending on the product and its dependencies on the outside world, different Crew members can manage different communication channels. In fact, each Crew member could be a “lead” in some area! There’s nothing wrong with that. But a shared responsibility equals no responsibility. The Base (see below) insists that only one person carries responsibility for how the entire Crew operates on its journey. That’s the Captain.

The Base may have some rules and restrictions on who can be the Captain on a Crew, considering skill level, seniority, tenure, etc. Captains can be appointed, or they can be elected. However, the Captain never has line management responsibility on a Crew. The Captain does NOT discuss career development, compensation, or promotions with her crew members. Depending on the context, this person’s official job title could be Product Manager, Project Manager, or Platform Manager. Either way, she is the manager of the journey, not the crew members!

We do not want line management in the Crews because this makes Crews much less flexible. As soon as a line manager has a territory, she will protect it and resist any attempts to change it. On top of that, most team members don’t like changing their manager and having to build up a new relationship of mutual trust and respect. If you have line managers in the crews, you can forget about dynamic teaming!

Note: This should make things a bit easier for Captains who lack the people management skills to talk about salaries and promotions. I have been guilty of promoting software developers to team captains who then struggled tremendously doing performance appraisals with their teams. It may not have been my most brilliant move.

The Base (Group, Tribe, Clan, Business Unit)

All Crews operate from a Base of between 10 to 150 people. This Base has a number of Crews of the four standard team types organized around multiple value streams. The Base acts like a fully grown, independent business. It contains all necessary skills to design, develop, and deliver products, from Design Thinking to DevOps and from Lean Startup to Lean Manufacturing. (With the possibility of recruiting people from all over the world, this shouldn’t be too hard.)

Every person has only one Base. It is their home. The Base offers its people a sense of purpose, belonging, and recognition. It provides comfort, personal safety, connectedness, a shared culture, shared toolsets, and career opportunities for all its workers.

Ideally, the Base covers a customer domain, not a technical domain. It is similar to a tribe in the Spotify model and an Agile Release Train (ART) in the Scaled Agile Framework (SAFe). However, cadence and synchronization of work are optional. The Spotify model doesn’t prescribe it, and neither does my unFIX model. There might be good reasons for keeping the work across all Crews asynchronous. It’s your Base, your decision.

A critical job of the Base is to continuously reorganize itself depending on the needs of the customer experience. We know that organizational structure is directly linked to product architecture. When the architecture needs to change, the organization needs to change. Therefore, the Base does everything it can to support its Crews in remaining flexible. This includes taking care of minimum standards and rules across all Crews so that reteaming is as painless as possible.

The Chiefs (Management, Leadership Team)

When I wrote my recent book Startup Scaleup Screwup, I spoke with many startups and scaleups (and screwups) across Europe, including Spotify, Flixbus, Wise, Typeform, Zalando, Booking, Intercom, and Futurice. I recognized one pattern across many of these successful, young businesses that didn’t make it into the book. It was the simple pattern of a team of Chiefs leading their business.

The leadership team typically consists of a Chief Product, Chief Technology, and Chief Marketing. But sometimes, the division of roles is a bit different, and sometimes, they are a team of four or five instead of three. Regardless of positions and number, in most cases, the Chiefs have line management responsibility for everyone in their Base. They are, literally, the management team. Depending on how the Chiefs divide the roles, each of them would have between three to twenty direct reports. Typically, all back-end developers would report to a Chief Technology, and all UX people might report to a Chief Product, and so on. But context should dictate what is reasonable.

The primary benefit of this approach (which various scaleups discovered long before me) is that the Base has a stable management reporting structure, no matter what happens with the Crews. People could hop from Crew to Crew five times per year (if the experience of customers or employees required it), and nobody would ever change their manager, and there wouldn’t be any management territories to protect! Only the Chiefs are responsible for recruitment, compensation, promotions, and so on. At the same time, they can delegate the value streams to the Captains of Crews and functional alignment to the Chairs of Forums (see below).

Note: The inclusion of line managers in the unFIX model is in stark contrast with the “manager-less” approach of the Scaled Agile Framework. SAFe is intentionally agnostic concerning line management to make it easier to introduce in existing bureaucracies. However, the resulting matrix management overload is a potential nightmare!

As a leadership team, the Chiefs carry responsibility for product, marketing, and technology across the entire Base. They set the course on vision, objectives, processes, recognition, and rewards. (Though, in practice, they will be so busy that they will gladly delegate a good portion of that to Crews and Forums.) However, like the CEO acting as the top senior executive, there should be one Chief leading the entire management team of a Base. The larger organization outside of the Base wants one person to represent the whole unit.

The Forum (Chapter, Department)

A small team of two or three Chiefs can easily manage a Base of a dozen people. But things become a bit more problematic after that. When the Base has grown to 50 or more, the leadership team will have delegated a good part of their responsibilities. As I indicated before, all value stream work happens in the Crews, but some things within the Base need to be coordinated along functional lines.

A Forum is an optional construct consisting of between two to forty people. Forums go by the name of chapters in the Spotify model, but I prefer the name Forum because it indicates that its primary purpose is for like-minded workers to get together, talk, and make decisions together. There could be a DevOps Forum, a UX Forum, a Growth Hackers Forum, etc. In traditional organizations, the Project Management Office (PMO) could be turned into a Forum, and in more agile companies, the Product Managers could have their own Forum. The Chiefs of the Base decide which Forums are needed because Forums play a formal role in the organization’s structure.

Chiefs can delegate work to Forums, such as standardization, templates, toolsets, infrastructure, personal development, cross-team coordination, and so on. They can expect each worker in the Base to be a member of exactly (or at least) one Forum and to participate in the conversations and decisions that matter for their functional areas. The role of Forums is to be the connective tissue between the Crews.

Now, before you say that this is the same as what chapters do in the Spotify model, let me insist on one crucial difference: There is NO line management in the Forum! Recruitment, compensation, career development, and performance reviews are NOT part of a forum’s mandate. The purpose of a Forum is for people in similar roles to agree on how the work is done within the Base in a self-organized way so that dynamic reteaming is as painless as possible.

For example, when the performance of two Crews suffers because two people wanted to switch places, their Forum should figure out the root cause and do something about it. Was their onboarding insufficient? Did the ways of working differ too much between the two Crews? Had their Crew cultures taken priority over the culture of the Base? The Forums aim for optimization of the Base over the optimization of individual Crews.

The Chair (Moderator)

The Chair is the manager of the Forum and NOT the manager of the people. Let me repeat that, just to make sure I am fully understood. The person who moderates a Forum has responsibility for the workings of the Forum. He is not the manager of the people who participate in the Forum. The role of Chair is a part-time job, typically taken up by someone with some seniority in the Base. He manages discussions and decisions, but he has nothing to say over compensation or promotions. You can say that the Chair is the “first among equals”.

The main reason for not having line management in Forums is, again, to keep the business flexible. The last thing we want is a re-introduction of functional departments! When the leaders of Forums get management responsibility for people, the people become part of their territory. This makes it much harder to shrink, split, or merge Forums. Also, what you would end up with is a matrix organization. And that’s absolutely not what we want.

I once worked on a team in a matrix organization. My project manager came from one part of the organization, while my functional manager worked in a different part of the company. In a matrix, these two people often don’t even know each other, and they work toward entirely different purposes. From my perspective, their management lines disappeared over the horizon in opposite directions. Fortunately, I didn’t suffer from it, but I know many other people do. For good reasons, matrix organizations have a not-so-good reputation.

The unFIX model is not a matrix organization. Sure, different Crew members participate in different Forums, and they may have different Chiefs as managers. But no matter which Crew you look at, the Chiefs always work on the same leadership team. The managers have the same objectives. When there’s a conflict on a Crew, it can escalate to only one management team! Goodbye matrix.

The League (Division)

Many organizations are larger than 150 people. In such environments, workers have to collaborate with colleagues beyond the boundaries of one Base.

The formal way of doing this is to combine multiple Bases into a League or division. The League has its own management team and is organized around co-dependent value streams or related customer experiences. For example, multiple Bases with B2C models could be wrapped in one League while Bases with B2B products could be covered in another League.

The construct is similar to the solution level in the Scaled Agile Framework, which wraps multiple Agile Release Trains that deliver value to the same or similar customers. (The Spotify model does not describe a similar construct.)

The Club (Guild, Community)

Finally, a standard informal solution for cross-Base collaboration is what is often known as the Community of Practice (CoP), Community of Interest (CoI), or Center of Excellence (CoE). These informal Clubs are voluntary structures that enable workers to coordinate ways of working across the borders of a single Base (and even multiple Leagues).

Clubs commonly emerge bottom-up, and they are often dedicated to functional areas in a way similar to Forums. However, the big difference is that Forums are formalized and launched top-down by the Chiefs of a Base while Clubs can emerge spontaneously and bottom-up at any time.

Is it possible to formalize things across multiple Bases, such as standards, toolsets, and infrastructure? Sure! But that requires a Club to be officially recognized by the Chiefs of each of the Bases participating in it. And the Forums in those Bases would have to cede some of their power to the larger Club of which they would all become a part.

Let’s Wrap It All Up

The team topologies approach gave us a language to talk about different team types. It is up to you to draw organizational structures consisting of these four types in a way that makes sense to you. With the unFIX model, it is the same. I offer you the concepts of Crews, Forums, Bases, Clubs, and Leagues. Now, it’s up to you to brush off your LEGO skills and start building the structure that suits your needs. You can have Forums consisting of Forums, Bases serving other Bases, Clubs that wrap multiple Leagues, and so on, and so on.

And how does unFIX compare to the alternatives mentioned above?

When it comes to the Spotify model, I suspect that every company implementing it will run into the matrix problem: squad members report to different leaders who don’t sit with each other on the same team and who might work toward different objectives. Also, the Spotify model offers no suggestion for the layer above the tribe. I addressed both issues with the model in this article.

The Scaled Agile Framework has a much larger scope than the unFIX model. Its target audience is large, traditional corporations. SAFe is too big and bureaucratic for younger and smaller companies. On top of that, SAFe is intentionally agnostic about line management. That means that any SAFe implementation on top of an existing management structure is an open invitation to a tremendous amount of malaise in the matrix.

The LeSS website suggests the collocation of teams that should “stay together forever” and offers no place for enabling teams, platform teams, or complicated subsystem teams. Hybrid working, team topologies, and dynamic reteaming get no love from the LeSS framework. It seems to me that this framework is not ready for the future.

Holacracy was a hype eight years ago, but few people still talk about it. It offered some innovative ideas, but Holacracy failed because it was too weird, too abstract, and too technical. The unFIX model is closer to current reality as experienced by many workers around the world. Therefore, it should be easier to evaluate organizational changes that would help a business get closer to the idealized picture.

And finally, what about Management 3.0? Well, I never dared to offer any specific organizational model in my earlier work, apart from the suggestion that all teams should become value units. Management 3.0 has always been a management philosophy and a toolbox of valuable practices. I never meant it to be a framework. But the model I described in this article finally offers a structure that Management 3.0 has always lacked and that could tie the whole toolbox together.

Conclusion

As I said before, the picture is new; the ideas are not. I know fast-growing startups and scaleups that already follow most of what I described in this article. They might say tribes instead of Bases, teams instead Crews, or functional units instead of Forums. The terminology doesn’t matter. I offer different words because they can help people distinguish the new from the old. Ultimately, an organizational structure is not about the naming; it’s about intent, responsibilities, and decision-making.

I believe the unFIX model as described here is ready for a future of dynamic reteaming, team topologies, and hybrid working. It allows a company to become a genuinely versatile organization. Maybe you already knew most of this because you saw similar advice in other places. That’s great. But I’m sure that my pictures are prettier. 😎

The unFIX Model for Versatile Organizations