The UnFIX Model — A Pattern-Based Approach to Organizational Design (2024)

Because I have found a lot of great ideas and techniques via the Management 3.0 website, and also through books and articles authored by the visionary behind Management 3.0, Jurgen Appelo, it was with more than a little curiosity that I ran a web search on a term that was unfamiliar to me until this week — the unFIX Model.

If you’re even a little bit like me, you might have a tendency to harbor some doubt any time you hear about a new model, even when it’s being articulated by someone you admire and respect. I suppose that for me this natural skepticism has a lot to do with George Box’s now well-known aphorism “Essentially, all models are wrong, but some are useful.” I’m happy to say that in this case, I am very glad I spent some time getting more familiar with what was for me an unfamiliar model. And it is with that in mind that I share this summary, so that you too, can learn moree about it for yourself, and perhaps even take some of these ideas for a test drive in your context.

The banner that is visible at the top of the unFIX Model website leaves little doubt about what the model does, and does not, seek to accomplish. It reads as follows:

Organization Design for Continuous Innovation and Better Human Experience

Not Another Agile Scaling Framework

To summarize, consider what is articulated near the bottom of that web page:

“The unFIX model is a simple tool that helps you with versatile organization design. Unlike many agile scaling frameworks and self-management methods, unFIX has its focus on continuous innovation and the human experience. It facilitates gradual change, dynamic teams, and an important role to play for managers. The model is inspired by innovative companies such as Haier and Tesla, various agile scaling frameworks, and books such as Team Topologies, Dynamic Reteaming, and Organization Design.”

Something else that resonates with me is the choice of image that adorns the website banner — it’s an image of a bridge. I say that because based on my initial reading, this model does indeed serve as a bridge, connecting ideas gleaned from many sources, several of which are mentioned in the preceding quote.

A Brief Digression Into Recent History with Agile at Scale

Over the years, many ideas have surfaced with respect to what “agile at scale” can look like — to name a few examples:

• Spotify Engineering Culture — although never intended to be a “model” or a “framework,” what Henrik Kniberg articulated via a couple of
  short videos about Spotify Engineering Culture almost a decade ago continues to be influential
• Scaled Agile Framework (SAFe) — SAFe is particularly common in large enterprises, most notably in big private-sector companies and quite a
  few federal government entities, where it’s not at all uncommon for there to be dozens and even hundreds of teams across the organization. There are various flavors of SAFe, and it borrows heavily from Scrum, Kanban, and DevOps, along with other sources.
• Large Scale Scrum (LeSS) — As its name suggests, LeSS is a means of applying the basic tenets of single-team Scrum, where to put it in simple terms, teams are clustered together, and where additional coordinating roles are included to provide coordination across those clusters.

Note: The brief overview I just provided is intentionally just that — brief. There is plenty available for you to read, should you want to learn more. And, there are many other approaches to Agile at scale, all of which have plenty written about them, and each of which has its own set of proponents, its own set of critics, not to mention a whole host of framework agnostics.

If you’re wondering at this point why I used the terminology “pattern-based approach” to title this blog post, there are several reasons:

• Based on my own experience, and that of many other agile practitioners, I’ve found that when organizations promulgate a framework or methodology, in a top-down fashion, bad things tend to happen
• Patterns resonate with many people in the agile community. Not only is the term “pattern” familiar to many in a software development context, it implies that a spirit of innovation and experimentation applies, where there is often more than one way to do something, and where discovery is a natural part of the thought process.
• Appelo himself uses the term as the title of the blog post “Don’t implement frameworks; try some patterns.”

Here’s a quote from that blog post:

“Some people go around asking, “Which companies have implemented SAFe?” “Where is the Spotify Model being used?” “Which organizations are based on Holacracy?” They even ask me, “Which companies have implemented the
unFIX model?” And all I can think is that it doesn’t work that way. A way of working is not something to be “implemented”. Of course, you can try to achieve some of the outcomes as described in the books. You may even end up with something that looks like one or two of the pictures. But that doesn’t mean you’ve implemented the book. Nobody is expecting you to do everything: to recreate all urban design patterns or cook all Jamie Oliver’s dishes orwork your way through all the yoga forms. That would be silly.“

Pro tip: be sure to check out the case studies that are available:

• Ministry Group
• Pipedrive
• Coolblue
• BBVA Next
• VRT

What unFIX is NOT

I hinted at what the unFIX Model is not at the beginning of this post. Let’s now dig deeper, and to do that, we’ll turn to Appelo’s blog post “The UnFIX Model.” In that article, he says that the UnFIX Model is NOT:

• A framework. As soon as the term “framework” is used, it implies that there are certain things that must be in place. However, everything is optional in unFIX. “A better description would be a pattern library.”
• A set of processes. The unFIX Model focuses on organization design patterns and organizational structure. Organizations are free to develop their own processes, and/or to leverage them from agile, Lean, Devops, and other sources of inspiration.
• IT- or software development-centric. Although it’s certainly true that unFIX works perfectly fine for technologists, it can work just as well across the various business units, departments, groups, and teams that might exist in any organization.
• Top-down. The wreckage from top-down approaches litters the organizational landscape. The pattern library of unFIX favors a bottom-up approach.
• A plug-and-play replacement. Chances are, there are plenty of things that are already in place in your organization that are working fine, or maybe just need some adjustment. The unFIX Model assumes that you’re open to experimentation, so that you can jettison the things that impede organizational growth and innovation, and keep the things that are net positives.

unFIX Model Components

Let’s now unpack the basic components of the unFIX Model:

• Crews (teams), where each team has a Captain
• The Base (a Business Unit, in medium- to large-sized organizations; and in smaller organizations, the Base can encompass the entire
  company)
• Chiefs (leadership team)
• Forum (cross-cutting group consisting of members of various Crews, which has a Chair (moderator)

See the illustration below to see how these components interrelate.

Note: Be sure to visit the unFIX Model Website, where you can join the community for free, read more about the model, download all sorts of artifacts that are associated with it.

I hope that this brief overview will motivate you to take a closer look at the unFIX Model. Based on what I’ve uncovered about it so far, it has a lot going for it. For example:

• It builds on the marvelous work about Team Topologies, by Matthew Skelton and Manuel Pais, adding three additional team types (note: for a summary of some additional insights from their book, see my blog post https://medium.com/agile-outside-the-box/team-apis-af2dbc1805e7)
• It leverages some important ideas, inspired by the Spotify Engineering Culture, such as building Communities of Practice, while avoiding some of its pitfalls, such as the matrix problem, where Crew (aka Squad) members may end up reporting to different leaders (note: for more about Communities of Practice, see my blog post https://medium.com/agile-outside-the-box/unlocking-the-wisdom-of-the-crowd-through-communities-of-practice-1fea61be1271)
• It avoids many of the problems that so often plague top-down instantiations of the “Agile Industrial Complex,” where it’s so common to see scores of Consultants descending from on high with overly prescriptive approaches to ways of working
• It can serve as a scaffold on which to build and experiment with other ideas, originating from Management 3.0, Lean, and other sources