unFIX

View Original

The unFIX Model

The unFIX Company

Author: Jurgen Appelo

How can we change an organization to be as adaptable and versatile as its environment? How can we get our company ready to survive and thrive in the 21st century? Many models and frameworks offer you static or pre-packaged solutions. It is time for an alternative to SAFe, LeSS, Holacracy, the Spotify model, and matrix organizations. We need something that takes flexibility to a new level. Here is my suggestion. I call it unFIX.

This post was updated on 12 May 2022. The first, original version is here.

Let’s first explain what unFIX isn’t.

  1. The unFIX model is NOT a framework. The definition of “framework” suggests an essential supporting structure. But there is nothing essential in unFIX. Everything is optional. A better description would be a pattern library.

  2. The unFIX model offers NO processes. The purpose of unFIX is to cover only organization design patterns and organizational structure. It is easy to find great advice for processes from many other sources.

  3. The unFIX model is NOT for IT only. Everything in the pattern library of unFIX could apply to many different departments, divisions, and companies. It has no built-in assumption of software development.

  4. The unFIX model is NOT top-down. Unlike certain other models and frameworks, the pattern library of unFIX suggests a bottom-up approach. You cannot build something large. You must begin with something small.

  5. The unFIX model is NOT a replacement. There are plenty of good things in other models and frameworks that should not be thrown away. We just hope that, with unFIX, you will unfix the bad parts and keep all the good bits.

Alright. That’s what unFIX is NOT.

Shall we now discuss what the model is? Okay, let’s go.

The Crew (Team, Squad)

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 book Management 3.0, the optimum team size is five. (Some 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 (see below).

There are seven kinds of Crews:

Crews can be any of the seven standard types. However, in a regular business, most Crews should probably be Value Stream Crews. These self-organizing, cross-functional teams 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. The unFIX model allows Crews that are not stream-aligned. There can be good reasons for adopting any of the other seven Crew types.

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 (see below), 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 (Team Lead)

Taking the analogy of ships and planes a step further, I often 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) could insist 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!

The Base (Tribe, Business Unit)

All Crews operate from a Base of between a handful to a few hundred people. This Base has a number of Crews of the seven standard Crew types organized around one or more value streams. The Base acts like a fully grown, independent business. It contains all the necessary skills to design, develop, and deliver products, from Design Thinking to DevOps and from Lean Startup to Lean Manufacturing.

Every person has a 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 the unFIX model. There might be good reasons for keeping the work across all Crews asynchronous. (This would be particularly true for Loosely Aligned Bases and Fully Segregated Bases.) 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 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).

The Forum (Chapter, Guild)

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 a group consisting of people from various Crews. 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 might decide which Forums are needed because some Forums play an essential 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 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.

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.

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 Governance Crew. The managers have the same objectives. When there’s a conflict on a Crew, it can escalate to only one management team! Goodbye matrix.

Scaling Up

Many organizations are larger than a few hundred people. In such environments, workers have to collaborate with colleagues beyond the boundaries of one Base. The unFIX model offers suggestions for scaling whereby everything that is discussed earlier also applies, in a fractal way, at higher organizational levels.

Dozens of Bases can collaborate in a League. Within a League, they might form Clusters (similar to people forming Crews). Some Bases could self-organize into a Value Stream Cluster, others into a Facilitation Cluster, a Platform Cluster, a Capability Cluster, etc. The League has its own management team (Governance Cluster) and is organized around co-dependent value streams or related customer experiences.

Similarly, cross-Base coordination can be handled in Assemblies (similar to people coordinating their work in Forums). These Assemblies are voluntary structures that enable the representatives from Bases to coordinate ways of working across the borders of a single Base.

We can even go another level up and say that dozens of Leagues might form a Crowd. The Leagues could self-organize and collaborate in Coalitions and coordinate their work in Congresses. Again, all earlier patterns repeat at the higher levels which makes the unFIX model self-similar across all scales. It is a fractal model.

To be honest, most of this upward scaling with unFIX is still hypothetical. We know the patterns work at a small scale; we believe they can work at a large scale too. But as I said in the beginning. It’s best to start small, at the level of the Base.

Dynamic Reteaming

The patterns in the unFIX model have many sources. One “piece of the puzzle” is 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 must shuffle 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 unFIX.

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
    (I call this a Value Stream Crew);

  • An enabling team is a team that temporarily helps other teams to get to speed
    (I call this a Facilitation Crew);

  • A complicated subsystem team wraps rare and unique skills inside one team
    (I call this a Capability Crew);

  • And a platform team offers infrastructure or architecture as if it was a supplier
    (I call this a Platform Crew).

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.

(Note that I augmented the existing types with three additional team types: Governance Crew, Experience Crew, and Partnership Crew).

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.

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 made sense to you. With the unFIX model, it is the same. I felt a need to add three additional team types and I offer you the concepts of Crews, Forums, and Bases. Now, it’s up to you to brush off your LEGO skills and start building the structure that suits your needs.

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. (Read: Let’s Unfix the Spotify Model)

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. (Read: Let’s Unfix the Scaled Agile Framework)

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. (Read: Let’s Unfix Large-Scale Scrum)

Holacracy was hyped 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. (Read: Let’s Unfix Holacracy)

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

It took me twelve years to make this.

It is absurd that it took me so long because the solution I showed 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: 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. 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. 🤓