At first sight, the Viable System Model can look rather complicated. Five systems, lots of lines, and a language of its own. So let’s start with something familiar: a team trying to deliver useful work.
Who makes which decisions? How do people coordinate their work? Who looks beyond the next delivery? And how can the team act with enough autonomy while remaining part of a larger organisation?
These are the kinds of questions for which I use the VSM. I like to begin with the things we actually do: the work, the meetings, the roles, and the tools. The model helps me put these things into context - and see what may be missing.
Below, I introduce the model and work through an Agile software example. If you already know the basics, jump to the four friends starting a business or try the mapping exercise.
What is the Viable System Model?
The Viable System Model (VSM) is Stafford Beer’s model for understanding how an organisation can maintain its identity and adapt within a changing environment. Its foundation is management cybernetics: the study of communication and regulation in organisations.
Beer identified five interacting functions: operations, coordination, internal management, adaptation, and identity. Each contributes something the organisation needs. Just as important are the relationships between them. How does information travel? Where can a decision be made? How does a change in one part affect the others?
And what does viable mean here? An organisation may deliver today while losing touch with its environment. Or it may have wonderful plans for tomorrow while struggling to get today’s work done. Viability asks us to consider both: continuing to exist as this organisation, with the capacity to respond and adapt.
The five systems - and the question behind each one
The numbers give us a common language. They do not tell us who is more important. Here is a first orientation.
| Function | What it contributes | A question to ask |
|---|---|---|
| System 1 Operations | The primary activities through which the organisation fulfils its purpose in its environment. | Where do we produce and deliver value? |
| System 2 Coordination | Arrangements that reduce conflict and instability between operational units. | How do we keep our work from getting in each other’s way? |
| System 3 Internal management | The overview of current operations: resources, accountability, and opportunities to work better together. | What does the whole need from its parts - and what do the parts need? |
| System 3* Audit channel | A sporadic route to operational reality, complementing routine reports to System 3. | How do we notice what our usual reporting misses? |
| System 4 Intelligence and adaptation | Attention to the wider environment and possible futures, in dialogue with current capabilities. | What might we need to do differently tomorrow? |
| System 5 Identity and policy | Purpose, values, and policy; the balance between current operations and future adaptation. | Who are we, and what holds us together? |
A small nerd remark: System 3* belongs with System 3. It is an additional channel, not a sixth system. In my Canvas article, I discuss why I associate it with activities such as retrospectives and Gemba walks. This interpretation is open for debate. The context and the way an activity works matter more than the label we put on it.
Start with the environment
Before drawing a diagram, decide what you want to examine. A team? A business unit? The entire company? This is your system in focus.
Then explore its surroundings. Who uses what it delivers? What do these people need? Which suppliers, partners, regulations, or technical conditions influence the work?
An internal team also has an environment. Its customers may sit just across the corridor. Starting here helps us understand why the team exists before we get lost in its internal responsibilities.
A practical VSM example: four friends start a software business
In the video, I use the story of four friends founding a company to explain an Agile software development team. Let’s continue that story as a thought experiment and look at the different functions.
For this exercise, the young business is our system in focus. It exists to provide useful software to its customers. The same four people do the delivery work and take care of the business. Five systems do not require five departments. But the friends do need to notice when one kind of activity crowds out another.
Delivering something useful
The friends talk to customers, develop software, release it, and support its use. Here we look for System 1: the primary operations.
Should we put “design”, “programming”, and “testing” into three separate System 1 boxes? Be careful. They may be complementary activities within one operational unit. Follow the work through to the result for the customer before deciding where the boundaries belong.
Keeping the work from colliding
Suppose two people want to release changes to the same service. A shared release procedure, clear interface agreements, and a short coordination conversation can help them avoid unnecessary disruption. These can serve System 2.
Does the arrangement reduce friction? That is the useful question. Counting coordination meetings will tell us very little.
Making today’s work possible
Now a support issue competes with a promised feature. The team has to look at capacity, commitments, and resources together. This is a System 3 concern.
The response could be to renegotiate the delivery date, reserve support capacity, or change a working agreement. Who can make that decision? Do the people doing the work have the authority and information they need? This is where a mapping can make a conversation quite concrete.
Checking what the dashboard misses
The dashboard shows a healthy delivery rate, but the friends repeatedly work late. A closer look at how the work actually happens may reveal something missing from the routine reports. Here we have a possible use for the System 3* channel.
A retrospective could help, provided it allows honest inquiry and leads to a response. Just holding the retrospective does not tell us whether this function is working.
Looking beyond the current backlog
Customers begin asking for a different way to use the product. Is this an isolated request? A wider change? Something worth testing? Investigating these questions is System 4 work.
The findings need to meet the reality of current operations. What could the business learn or change? What can it afford to try? System 3 and System 4 need to talk to each other.
Deciding what kind of business this should be
The friends need a shared understanding of purpose and boundaries. Which customers do they want to serve? What would they refuse, even if it brought revenue? How much present delivery can they trade for future development?
These are System 5 questions. The answers should guide decisions. Otherwise, the purpose statement remains a nice sentence on a wall.
As you can see, one person can contribute to several functions. A planning meeting can also serve more than one. Look at what people actually do and how these activities connect. A job title or the name of a ceremony gives us only part of the picture.
Recursion: the model within the model
The VSM is recursive. A viable organisation contains operational units that can be examined as viable systems themselves, within a larger system. So we can use the same model to explore the whole and its viable parts.
In our software business, this becomes particularly interesting when distinct product teams develop. What can each team decide locally? Which decisions require an agreement across the business? And how does information travel between those levels?
Autonomy needs working boundaries, resources, and feedback. Without them, “you are empowered” can mean little more than “please solve this somehow”. Recursion helps us ask what each level needs to handle for itself and how it contributes to the larger whole.
How I would start applying the VSM
One way into the model is mapping. Take the activities, roles, meetings, and tools of an organisation and explore how they contribute to the VSM’s functions.
This approach is criticised within the VSM community. There is a real risk of filling boxes and stopping there. I still like it because it helps us see what we do - and what we don’t do. The interesting discussion begins when we ask whether those functions and relationships actually work.
- Choose the system in focus. Write down its purpose and the level you are examining. Keep that boundary visible throughout the exercise.
- Explore its environment. Identify the people and conditions to which it must respond. My environment model can support a deeper conversation.
- Follow the value-producing work. Map the operational units and their relationships before filling the other systems.
- Explore the supporting functions. Use actual processes, roles, meetings, and tools. Follow information and decisions between them. If people disagree, keep the disagreement visible. It may tell you something useful.
- Investigate one imbalance. Perhaps a team cannot resolve a recurring conflict. Perhaps strategy receives information, but operations receive no response. Check the situation with the people involved, try a specific change, and review what happened.
You can use the free VSM Canvas templates for this exercise. The System View gives you an overview; the Recursive View makes the nested systems more explicit. For the full step-by-step exercise, see how to use the Canvas.
The price of simplification
Every simple introduction leaves something out. This one does too. A completed diagram gives us material for diagnosis, but it cannot establish viability on its own or settle a disagreement about purpose.
Watch out for mappings that simply reproduce the existing departments, turn System 5 into the daily approval desk, or explain every difficulty as a “missing system”. The useful work is to explore how the functions and their connections operate in this particular organisation.
What should you change after that? It depends. The model gives you questions and relationships to investigate. The people involved still have to understand the situation, make decisions, and learn from what happens.
Continue exploring
- The introductory video series explores the why, what, and how of the model.
- An Agile Team as a Viable System offers a different, deliberately simplified view of roles and relationships.
- The Activity Series contains examples including a family, a consulting business, and a football club.
- The downloads page brings together templates and learning materials.
- VSM7 for Practitioners takes you through a structured VSM workshop series, keeping the design results together as the work develops.
- In the Pasta Lasta simulation, your group runs a fictional restaurant through an eventful week. Who decides what? What can people resolve themselves? Use the VSM to explore the consequences of your decisions.
For the foundations, I recommend returning to the model’s original sources. Stafford Beer’s Diagnosing the System for Organizations is his practical handbook. You can also read Metaphorum’s introduction, Jon Walker’s VSM guide, and Raúl Espejo and Antonia Gill on recursion, autonomy, and cohesion.
I wish you happy experimenting!