Open Thinkering

Menu

Month: June 2024

TB871: Rethinking organisational structure through VSM

Note: this is a post reflecting on one of the modules of my MSc in Systems Thinking in Practice. You can see all of the related posts in this category


The Viable System Model (VSM) conceptualises an organisation as a network of systems, each with its own purpose and autonomy (Hoverstadt, 2020). This approach helps in managing complexity and promotes a recursive approach to organisational structure, balancing autonomy and control.

Traditional hierarchical models of organisation emphasise top-down control, meaning that decision-making power is concentrated at the higher levels. This approach tries to minimise complexity, whereas the VSM embraces complexity by acknowledging that people at various levels of the organisation are best equipped to handle decisions relevant to their specific areas (The Open University, 2020).

Matryoshka dolls nested inside one another. A small person is inside saying "Keep breaking down the issue..."
CC BY-ND Visual Thinkery for WAO

A key aspect of the VSM is the balance between autonomy and cohesion. Too much autonomy can lead to fragmentation, while excessive control can stifle innovation. The VSM addresses this by allowing different parts of the organisation to operate semi-autonomously within defined constraints. This recursive or fractal nature of the VSM means that each part of the organisation, regardless of its complexity, is viewed as a viable system with similar needs and structures to the whole. (In other words, much like the Matryoshka dolls in the image above, they are nested inside one another.)

Understanding the structure of an organisation through the VSM involves distinguishing between primary and support activities. Primary activities deliver value directly to customers, while support activities sustain the organisation’s operational capabilities. This distinction helps in identifying the organisation’s core identity and value delivery mechanisms, with the idea that each component aligns with the overall purpose. As I have said before, this feels like a wider and deeper approach than that provided by OKRs, for example.

The VSM is a conceptual model rather than a prescriptive methodology. As such, it provides principles, laws, and axioms that guide the management of organisational complexity. It facilitates both diagnosis and design by comparing real-world situations with an idealised model, meaning that weaknesses can be identifyed and mismatches discovered to be addressed.

On a practical level, I see one of the VSM’s key use cases as helping organisations understand how to set up in a recursive way. By managing complexity at each level and devolving responsibility, managers can focus on their immediate areas of influence without micromanaging sub-levels. This approach aligns with the principle that managers should set purposes for the systems they directly manage, leaving sub-management levels to handle their respective systems. (It’s difficult to talk about this non-hierarchically, which is a problem that perhaps I’ll come back to.)

For example, in a software development company, the lead developer manages the development team, dealing with internal complexities, while the project manager oversees client interactions and project timelines. Each level handles its complexity, ensuring that the overall organisation functions smoothly. The recursive approach means that the problems faced by each level are similar, which simplifies management processes across the organisation.

There’s so much more to explore here. For example, I had a fascinating conversation with Steve Brewis yesterday, who knew Stafford Beer personally, and who uses the VSM in his consulting practice. I wanted to talk with him because I saw reference to his ‘snowflake model’ of the VSM which he used while working at BT. However, I think that should be the focus of a separate post.

References

  • Hoverstadt, P. (2020). ‘The Viable System Model’. In Reynolds, M. & Holwell, S. (eds.) (2020). Systems Approaches to Making Change: A Practical Guide. London: Springer, pp.89-138.
  • The Open University (2020) ‘3.3.3 Applying System 1’, TB871 Block 3 Tools stream [Online]. Available at https://learn2.open.ac.uk/mod/oucontent/view.php?id=2261487&section=4.3 (Accessed 26 June 2024).

Weeknote 25/2024

Part of a rain-covered tent with sunrise over trees in the distance.

I’m going to resort to bullet points this week, as today has been particularly busy and I want to get this finished to watch the EURO 2024 games kicking off in 15 mins.

So, this week I’ve been:

  • Accompanying my son to an open day at Edinburgh University. It cemented for him that he wants to do Physical Geography / Environmental Science rather than Human Geography.
  • Getting blinds fitted to the front of our house, which has made a massive difference as it’s east-facing.
  • Working with Laura on submitting a WAO response to an request for proposals from P4NE.
  • Running a small workshop with DCC staff as we come towards the end of our work with them, for now.
  • Attending an in-person event called AI for Good which I wrote about afterwards.
  • Starting reading Adam Greenfield‘s new book, Lifehouse: Taking Care of Ourselves in a World on Fire. It’s not out until July 9th, but I pre-ordered it and the ebook version was already available to me when I logged in on the Verso website! We interviewed Adam as part of the last series of our podcast.
  • Studying for my MSc module TB871 in Systems Thinking:
  • Going round the local high school with my daughter (and wife and son) as she moves up there in September. She seems fine about it.
  • Catching up with Rosie Clayton and Tim Riches.
  • Going to the doctor to get preventative migraine medication. Although they’re not as severe as they used to be, I’ve had more recently. My options are limited due to my asthma and having tried others that made me tired. I’m trying a low dose of a blood pressure-reducing drug which dilates blood vessels, so fingers crossed!
  • Contributing to a WAO co-op half day where we did some planning and plotting.
  • Hosting my son’s friends for the (very disappointing) England game on Thursday night.
  • Putting together a bookcase with my son and a wardrobe with my daughter for their respective bedrooms.
  • Attending an interview for a university role. They used Microsoft Teams, and the link was different in the calendar invite to the email. Hence, I sat in the wrong lobby for 10 mins before I realised something must be up, clicked the email link, and was taken in to a virtual room with some stern professorial faces.
  • Walking and drinking whisky to mark the solstice with Aaron. I did my first wild camp in about a year and it was glorious.
  • Going with my son to his basketball awards ceremony. He won a fun award for having the best nickname, which I didn’t actually know about!
  • Running a bit less than previous weeks, but going to the gym a bit more.

Next week, I’ve got a couple of job interviews, I’m taking my daughter to a couple of football things, and my son to open days in Loughborough University and Lancaster University. There’s some potential WAO work coming our way, otherwise I’ll also be applying for more jobs — and/or making it more obvious to my network that I’m looking for my next thing.


Photo taken at around 04:30 on Saturday morning at sunrise over Doddington Moor

TB871: Managing variety using amplifiers and attenuators

Note: this is a post reflecting on one of the modules of my MSc in Systems Thinking in Practice. You can see all of the related posts in this category


Balancing autonomy and control is crucial for maintaining a viable system. This balance is especially important in a software development team, where management seeks to guide the complex processes of development, testing, and deployment effectively. The diagram below illustrates this within a software development environment, with the rest of this post exploring how ‘amplifiers’ and ‘attenuators’ help manage the variety in such systems, ensuring effectiveness and coherence.

Diagram titled "Managing variety within software development teams" showing interconnected sections: "Environment," "Operations," and "Management,” linked by grey arrows forming a loop.
Diagram based on an original, which used a different example, in the module materials (The Open University, 2020)

Autonomy and Control

Autonomy refers to the degree of freedom and self-direction possessed by parts of a system. Control is the ability of the overarching system to direct these autonomous parts towards a common goal.

According to Ashby’s Law of Requisite Variety, for a system to be viable, the variety (i.e. complexity) in the controller (management) must match the variety in the system being controlled (operations). Achieving this balance is often challenging due to the inherent complexity and unpredictability of the wider environment of software development.

Amplifiers and Attenuators

To manage this complexity, systems use amplifiers and attenuators. These help align the variety between management and operations in an attempt to enable effective control without stifling autonomy.

Amplifiers increase the system’s capacity to handle variety by making use of additional resources and/or decentralising decision-making. In the software development example, this could include:

  • Automated testing: using automated testing tools increases the variety of tests that can be conducted without overwhelming the developers.
  • Flexible work schedules: implementing flexible working hours allows the team to adapt to varying workloads more effectively.
  • Delegated authority: empowering team leaders or senior developers to make decisions on the spot can address issues promptly, enhancing responsiveness and reducing the burden on upper management.

Attenuators reduce the variety that the management system needs to handle. Again, in our software development example, this might look like:

  • Segmented development phases: instead of tackling the entire development process at once, projects can be broken down into phases like development, testing, and deployment, reducing the amount of complexity involved.
  • Standardised development frameworks: implementing frameworks like Agile or Scrum can help ensure consistency and predictability, which in turn can simplify management oversight.
  • Departmental organisation: dividing the team into specialised units (e.g., front-end, back-end, quality assurance) helps manage complexity by narrowing the focus of each group.

A balancing act

The key to a viable system lies in the delicate balance between autonomy and control. Too much control can stifle creativity and responsiveness, while too much autonomy can lead to chaos and misalignment with organisational goals.

Amplifiers and attenuators are helpful tools in achieving this balance, as they ensure that management can effectively guide operations without being overwhelmed by complexity, and that operational units have the freedom to adapt and respond to immediate challenges.

References

css.php