Skip to content
  • Retrospective: Modelling Overleaf with the Viable System Model

    Posted by June on September 24, 2019

    At Overleaf, we run regular retrospectives, bringing the team together in a video call to reflect on our progress and think of ways to improve ourselves as an organisation. We also like to experiment with the format of these retrospectives, changing the structure and topic of the meeting to shift our focus and see ourselves from new angles each time. For our last retrospective, I asked the team to zoom out and look at Overleaf as a full system, through the lens of the Viable System Model.

    A Quick Introduction to the Viable System Model

    The Viable System Model (VSM) is a model of organisation structure developed by Stafford Beer in the 1950s and 1960s, and expounded on in his books "Brain of the Firm", "Heart of the Enterprise", and "Diagnosing the System". Beer spent most of his career in operations research and management consulting, and his VSM is one of his major contributions to the field of Management Cybernetics.

    The model emphasises the complex nature of organisations of all kinds (including companies) and the necessity of a whole-systems approach to management. This places the management (and design) of organisations squarely in the realm of cybernetics and complexity science.

    The "Viable" part of the name refers to the concept of viability, the ability of a complex system (such as an organism, or organisation) to continuously produce itself and adapt to its environment over time. A viable system persists and mutates in step with the changing environment, while a non-viable system falls apart in the face of challenges from the rest of the world. Of course, all companies want to be viable, so it makes sense to analyse the company in these terms.


    While working in operations research, Beer drew inspiration from the emerging field of Cybernetics (and in particular its crossover with Biology), and noticed similarities between the processes he saw operating inside companies, and the processes which constituted living organisms, the latter being an obvious example of complex systems which navigate complex environments and continuously adapt.

    Viable systems must interact with the environment while maintaining some internal balance, then integrate that internal state with sensory information to come to a higher-level balance with the environment (however temporary that balance might be). Crucially, viable systems must learn, and adjust their internal structure as they go along, and then learn to predict the outcomes of their actions, otherwise they are likely to be thrown out of balance by unforeseen events, or by the results of actions taken which turn out to be against the organism's (or organisation's) best interests.

    Beer identifies five essential sub-systems of any viable system:

    • System 1: Primary Activities
    • System 2: Coordination
    • System 3: Synergy and Cohesion
    • System 4: Intelligence and Foresight
    • System 5: Policy and Identity

    These systems and their interconnections are often laid out in a diagram like this one:

    a viable system model diagram

    The blob shape on the left is the "Environment"; everything that is not inside the system being studied.

    In an organisation, System 1 is all the value-producing activities which the organisation undertakes. For a software company, this is the various development and operations processes which produce the software being sold. These processes are deeply connected to each other, and connected to sub-sections of the environment, analogous to the muscles and organs of a biological organism. The System 1 processes are mostly autonomous and should be thought of as full viable systems in themselves. In this way the VSM becomes a recursive model of organisation, where each layer of the organisation is composed of autonomous sub-units, being held together by the support systems of management.

    System 2 is the coordination infrastructure which helps the System 1 elements to coordinate, and prevent oscillation in their operations, much like the peripheral nervous system and spinal column.

    System 3 is like the lower brain, integrating and balancing the whole internal environment and performing higher-level coordination of activities, ensuring that the whole system adds up to more than the sum of the System 1 parts. System 3 is concerned with the whole "Inside and Now" of the organisation.

    Once the "Inside and Now" is taken care of, there is a need to deal with the "Outside and Then", and that's where System 4 comes in. System 4 faces the future and is concerned with adaptation and planning, continuously folding the state of System 3 into its predictive models of the future environment.

    System 5 is the policy level, the identity and values of the organisation, binding the whole thing together into a cohesive unit — this set of values influences the 3/4 loop and guides the various planning operations of the organisation.

    The Retrospective

    At Overleaf, we use Miro boards as a collaboration tool for our retrospectives. This gives the whole team a large drawing surface on which to work while the discussion goes on. In this instance, we split the board into three areas, corresponding to three phases of the exercise.

    In phase one we created a flurry of (virtual) post-it notes to capture everything we could think of about Overleaf. Every process, tool, entity, everything we do and interact with daily.

    In phase two, we shifted focus to a quick overview of the VSM, before moving on to phase three, in which we collectively mapped our pile of post-it notes onto the VSM diagram, roughly categorising things into the five systems. To keep things moving along, we had everyone take turns to pick one item from the pile and place it on the diagram, with a brief comment on why they thought it belonged there. Of course, we found some items that were ambiguous and warranted discussion along the way.

    This is the diagram before any of the post-it notes were placed:

    a screenshot of the board

    The Results

    And this is the diagram at the end of the session:

    a screenshot of the board with post-it notes added

    As you can see, there's a lot going on there!

    What We Learned

    In general, this exercise helped us to identify the primary value-producing activities which makeup Overleaf, and to better understand the different kinds of coordination and management systems which assist those primary activities. We also came to a better understanding of the interface between our System 1 and the various elements of our environment, such as users, customers, software vendors, and the scientific community.

    With this diagram, we can also get a sense for how the various components of Systems 3 and 4 are connected in a feedback circuit which drives the company's "Engine of Planning".

    We can also clearly see the role that various tools play in System 2, keeping the interactions between Dev and Ops projects stable as we develop Overleaf. Automated testing keeps the build stable, standups keep our projects stable, and Slack forms the high-speed communications nervous system of everything we do.

    Some of the most exciting phenomena are at the boundaries and crossover points between systems. Sales and Support mediate the boundary between Overleaf and its environment, making them some of our most important motor and sensory organs. Kanban boards and Retrospectives are on the crossover points of Systems 1 and 3, while our planning sessions and backlog triage sit in the System 3/4 loop.

    Once we're thinking about boundary-crossing processes, we can start thinking about the quality of the channels on those boundaries. Can our support process handle the variety and volume of support requests coming in? Do our support channels cover everything the user could need? We've certainly had days where we needed to divert resources from development to support to handle a spike in traffic, and now we can conceptualise that re-assignment as a function of System 3.

    All of this can help us to understand the systemic function of the things we do all day and could help us to diagnose problems with our company structure. We could ask ourselves questions like "We saw a serious oscillation between these System 1 units, how can we improve System 2 to dampen that kind of oscillation in future?", or "If our technical management is tied up with the hiring process for a few weeks, won't that impact our System 3 and 4 processes?". At the end of the session, we concluded that we might want to pay more attention to System 4 in future, focussing mainly on very long term trends in scientific authoring and new developments in technology.

    When we try out other new and interesting retrospective ideas, we’ll be sure to blog about them. Be sure to follow us on Twitter to find out about future posts.

    Further Reading

Sign up for a free account and receive regular updates

Kayıt ol

Popular Tags

Start writing now!

Create A New Paper

Overleaf is Ücretsiz

New to LaTeX?
Start with a template