unFIX is a collection of patterns that can be used – just as lego bricks – to build a versatile organizational design centered around the human experience.
Introduction to the unFIX model
The title of this post hits the nail right on the head: unFIX is a collection of patterns that can be used to design an organization ready to survive and thrive in the 21st "post COVID" century.
unFIX was published only one year ago in January 2022 by Jurgen Appelo, the author of Management 3.0. That on the one hand means that unFIX provides tools designed to handle challenges inflicted by recent events (COVID) and developments (remote work, VUCA world). On the other hand, this also means that sometimes experience is lacking or that parts of it are still work in progress. Yet there are plenty of interesting case studies provided, and I personally think that it has reached a certain degree of maturity.
unFIX itself is new, but its patterns actually aren't. Most of the patterns appear in existing and well established frameworks, or at least have been mentioned in books out there. Some of the better known are: Team Topologies, Dynamic Reteaming, Management 3.0, Scaling Agile @Spotify (aka Spotify model) and many more. Let's have a closer look at unFIX.
(This is how an organizational design could look like when applying provided unFIX patterns – screenshot from https://unfix.com/)
To understand the patterns better, we introduce a non-official typification of the patterns at hand:
- structural patterns
- role patterns
The structural patterns are the Lego bricks that can be used to put an organizational design together. When you do that, you should follow the principals. And to give recognition to the employees, you can use the role patterns.
Structural patterns can be scaled up. For all the patterns mentioned below, there are counterparts on a larger scale.
Base (Tribe, Clan, Business Unit)
"The base is the group where people feel safe and at home" – but not only that, when reading about it the base feels a little bit like a container (or a Lego baseplate) for the other patterns that can be attached to it. A base can be home to as little as a single crew to up to a few hundred people (there are no hard numbers, the idea is that bases are self-managed and know best when to reorganize themselves).
A base has a single business model. As the base is the home to these people, it has to actively monitor motivation and happiness of the people working in it. Within a base, there exists no middle management – this is to support a high level of agility and versatility. The people in a base organize their work as self-managed as possible.
There are four kinds of bases:
Each type serves a certain purpose. For details, click on the type you want to know more about – a detailed description would go beyond the scope of this post.
A scaled up base would be called a league – again, a detailed description would go beyond the scope of this post.
Crew (Team, Squad, Pod, Cell)
"A Crew is a small team on a mission with a defined goal" – and completing a mission typically is done best in a small, autonomous and self-organized group of people. The people in this group should know each other, and there is no manager on the crew. There are seven kinds of groups with a well-defined purpose:
- Value Stream Crew (Scrum Team, Agile team)
- Governance Crew (Management Team)
- Platform Crew (Service Team, Infrastructure Team)
- Facilitation Crew (Support Team, Coordination Team)
- Capability Crew (Component Team, Specialist Team)
- Experience Crew (Customer Journey Team)
- Partnership Crew (Vendor Team)
While all of them have a right to exist, I'd like to point out a few. Value Stream Crews are responsible to continuously deliver value for a product by applying lean and agile practices. There is exactly one Governance Crew in a base which is responsible for the purpose of the base, for the motivation of the workers in the base, for the management of the stakeholders and for the extent of the self-management in the base. If a single Governance Crew cannot handle the workload anymore it is time to reorganize. The sole purpose of a Facilitation Crew is to support other crews, and a typical example could Agile Coaches or Scrum Masters.
Scaled up crews are organized in a cluster – again, a detailed description would go beyond the scope of this post.
Turf (Area, Territory)
"A Turf is an area cultivated and protected by the same people" – while a cultivated area can be anything with a clear boundary, e.g. intellectual property that needs protection, physical property that needs housekeeping, digital property that needs maintenance. A turf should have a reasonable size and there should be clarity of ownership and responsibilities regarding the turf. Simple examples of a turf could be a codebase shared by multiple crews or a house/office shared by people from a base.
A scaled up turf is called domain – a detailed description is beyond the scope of this post.
Forum (Chapter, Guild, Community of Practice)
"A Forum is a place to talk and make important decisions" – and that is the sole purpose of a forum: discussions and decision-making. The members of a forum are also members of a crew, which is where they do most of their work. And there are no managers in a forum, only a moderator.
To make sure that the discussion in a forum is driven by outcome, there are 9 defined types:
- Functional – discuss work for specific functions, roles or job types
- Product – discuss work for a specific product type or category
- Market – discuss work for a specific market or market category
- Channel – discuss work for a specific sales or marketing channel
- Business Model – discuss work for a specific (category of) business model
- Customer Journey – discuss work for a specific (step of a) customer journey
- Regional – discuss work for a specific region or geographic area
- Technological – discuss work for a specific tool-set or technological area
- Seasonal – discuss work for a specific holiday, season or annual event
A scaled up forum is called an assembly – a detailed description is beyond the scope of this post.
Role patterns are special roles that can be implemented within certain structural patterns.
Chief (Manager, Executive)
"The Chiefs are the only managers in a base" – and they only exist in a Governance Crew (one of the 7 crew types). Chiefs do not report to anyone else in their base, and they are the line managers of the people who work on crews in their base. They are responsible e.g. for contracting and promotions. They set limits to self-organization in their base, and they are also responsible for splitting a base when it keeps on growing.
Captain (Team Lead, Squad Leader, Champion)
"A crew should have a representative" – and that is their main functionality. They serve as a representative for their crew wherever a representative is needed, e.g. in a forum or in intercommunication with other crews. The decision-making of who will be a Crew's Captain depends on the maturity of the self-organization within the crew's base. By the way, a Captain could also act as a tie-breaker when important decisions have to be made.
Chair (Moderator, Principal, Speaker)
"Forums need someone to manage their meetings" – the Chair is not a line-manager but a moderator and hence the first among equals inside a Forum. The role is one of high reputation and should not be fulfilled by a Chief. Yet Chiefs can restrict the position of a Chair to people with a certain level of seniority.
UnFIX maintains a dynamic set of principles – which actually is according to its principles. At the moment, unFIX defines 7 principles:
- It Depends and Everything is Optional → put everything in context and in doing so all practices unFIX provides are optional
- Try: Cheap, Safe and Fast - Don't Fail → run experiments – every experiment was a success when it was cheap, safe and fast and when you learn from it
- Experience Beats Product and Service → a good product is important but even with a good product you can screw up, that's why experience is even more important as that is what people really care about
- Where is the Customer? - Everywhere! → the focus of unFIX is organizational design, not processes. Customers are not the only stakeholders, and everything is designed to serve all kinds of stakeholders
- Balance High Cohesion with Low Coupling → a paradigm from software development which also should apply to organizational designs as complex systems usually cannot be understood by single people as a whole
- Increase Simplicity, Embrace Variety → simplicity is not the goal, but the goal is to survive in an ever-changing environment, so try to make things simple but not simplistic
- Manage the System, Lead the People → management is not the same as leadership – a system should be managed, but people should be lead and a good system promotes leadership
There is a lot more to discover and write about (Did I tell you about models?). But what has been written here gives you a broad idea of what unFIX is and what it provides and can be used for. Stay tuned :)
UnFIX is still in its infancy, but the principles it uses and the patterns it has defined make a lot of sense to me. The fact that it was published during the Corona pandemic, when the working world changed faster than ever before, can only be a benefit: very recent organizational issues are already tackled by unFIX concepts. I have to admit that I am not an unFIX expert at all (yet?) but I personally will keep an eye on where unFIX evolves and I would not be surprised if we all hear from it more often in the near future.
Looking for more expertise? Our consultants are happy to talk about agile topics with you and provide help on agile project management: Leave us a message.