The unFIX Model: Organisational Building Blocks Instead of Rigid Structures

The unFIX model by Jurgen Appelo is a collection of building blocks for organisational design: crews, forums, bases as well as clusters can be combined without adopting a fixed overall structure. It suits companies that want to change their existing structure step by step, and suits less those that expect a complete rulebook of roles and routines. Four test questions show whether and how the model can be tried out in your department.

This article describes the building blocks as presented by the author, places the model between Team Topologies, the Spotify model and classic line organisations, and gives managing directors and heads of department a procedure for checking whether unFIX is an option for them. Anyone weighing a new framework should first work through the questions in the article on method FOMO.

What is the unFIX model?

The unFIX model is a pattern collection for organisational design, published on unfix.com by Jurgen Appelo, the author of “Management 3.0”. Appelo describes organisations as an assembly of reusable building blocks from which a company chooses what suits its situation. Besides the building blocks for teams and units, the collection contains patterns such as Delegation Levels for decision rights and the Business Lifecycle for the maturity of a business area. Appelo stresses that unFIX is a pool of patterns and a framework it is not.

The model therefore addresses companies that want neither to design an organisational form from scratch nor to adopt a framework wholesale. It sees itself as a toolkit. That distinguishes it from frameworks that prescribe roles, events and planning rhythms, and it demands more decisions of its own from leadership.

Which building blocks does unFIX have?

The central building blocks are crews, forums, bases and clusters. A crew is a team of usually three to seven people who work together on a task. A forum is a group of people from different crews who share a professional interest and exchange ideas, comparable to the chapters and guilds of the Spotify model. A base is the unit in which several crews work together, from a handful of people to a few hundred. A cluster connects several bases and is, at a higher level, what a crew is at the level of individuals.

The blocks are built self-similarly: a crew is a team of people, a cluster a team of bases. This allows the same patterns to be used at different sizes. Appelo has also published comparisons with well-known models, including one with the Spotify model and one with Team Topologies, showing how their building blocks map onto unFIX.

What is unFIX suited for, and what is it not?

unFIX suits companies that want to solve individual structural problems without converting the whole organisation. Typical occasions are too many coordination meetings between teams, unclear responsibility for cross-cutting topics, or the wish to cultivate expertise across team boundaries. For the last, the forum offers a building block; for bundling several teams into one area of responsibility, the base does. The article on dependencies between teams describes which forms of coordination are available for this.

unFIX suits companies less when they look for instructions with fixed roles, events and rollout steps. The model prescribes no rollout method, and those who need one must design or buy it. Nor does it replace clear decision rights: a forum or a base can only work once it is settled who decides what there. And it helps little when the problem lies in utilisation or in the flow of work, since structural patterns do not change queues.

The primary source is the model's website including the author's blog posts. Studies on the model's effect are hard to find in the academic literature, and decision-makers should bear that in mind. The model is young, and evidence from rollouts comes mostly from practitioners and from the author himself.

How do you test unFIX in four steps?

A company tests unFIX in four steps without changing the overall structure.

1. Name the structural problem: management formulates a concrete problem with a metric, such as the number of coordination meetings between two departments or the lead time of a delivery that passes through several teams.
2. Choose a building block: one block fits the problem. A forum suits shared expertise, a base suits joint responsibility of several crews, a cluster suits coordination of several bases.
3. Settle decision rights: the company writes down who decides what within the block, which budget applies and how conflicts are resolved. Without this step the block remains a name on a slide.
4. Review after 90 days: the metric from step 1 shows whether the block works. If it does, the next block comes into question; if it does not, it is adjusted or ended.

Four test questions before deciding

Four questions show whether a company should try unFIX.

1. Which structural problem do we have, and how do we measure it today? Without a baseline the effect cannot be tested.
2. Are there managers who will hand decision rights to crews, forums or bases? Without that willingness the change stays cosmetic.
3. Who designs and accompanies the rollout? The model supplies patterns, not a rollout plan.
4. What does the new block replace, and what happens to the existing structure? A block added on top of existing committees increases coordination.

The questions tie the model to the business outcome. If the answer to one is hard to give, preparation is not yet complete. How teams can be cut along the flow of work is shown in the article on Team Topologies.

Choosing organisational building blocks with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisational design from the delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects from VC-funded scale-ups to DAX 40 corporations and in more than 20 countries on six continents. In organisational design he defines roles and clarifies decision paths so that deliveries flow through the organisation across team interfaces.

The approach follows the Niehues Delivery Model. Three of its test questions count for choosing organisational building blocks: who decides, who delivers, who uses? Which roles and decision paths does operations need? Which metric shows after 90 days that the solution has landed? The answers produce a selection of blocks that fits the company's problem, whichever model they come from. The scope and terms of an engagement are discussed in the free initial consultation, which you can arrange via contact.