Understand your system better with Marr's 3 levels of analysis
Learning from the science of vision
What are you doing right now?
There are many ways you could answer this question. For me it would be equally true to say:
I am typing
I am working
I am writing a substack
I am digesting my lunch
I am living in London
I am surviving my 30s
Is any of these the right answer? No - they are all equally true, but answering the question from a different level of analysis. Analysing from the perspective or level of my lunch, I am digesting. At the level of my keyboard, I am typing.
Life and the world are complex, full of infinite interactions and possibilities. When we choose to look at a situation, we inevitably do it from just one of many possible perspectives. When we choose to take one perspective, we inevitably miss out on others. This is a problem facing anyone trying to understand anything interesting.
Which is the right level of analysis to use? Where should we start?
This is a question that laces its way through cognitive science, and in this post I want to introduce you to an incredibly insightful model from cognitive scientist David Marr in the study of vision. I’m then going to show how taking this kind of approach can help us be more wise and effective when introducing tooling and frameworks to our teams and organisations.
Learning from the science of vision
Humans are so good at vision that we aren’t aware of how complex, clever and intricate it is. Vision is in many ways our archetypal sense. Visual metaphors work our way through all our language - we ‘see’ someone's ‘point of view’, we find ideas ‘illuminating’ and try to ‘focus’. With such a central role in our cognition, vision has attracted a huge amount of attention from cognitive scientists looking to understand how we make sense of the world.
David Marr was an influential cognitive scientist (who sadly died at 35 in 1980). He laid down many foundations for how to make sense of vision and complex information processing systems that are still in use today. One particular framing at the centre of his approach is his 3 levels of analysis.
Marr argued that vision science of his day was focussed on trying to find the roles of particular neurons, or understand particular anatomical pathways between the eye, brain and nervous system, but that this did not give a wholescale explanation of how vision works:
it gradually became clear that something important was missing that was not present in either of the disciplines of neurophysiology or psychophysics. The key observation is that neurophysiology and psychophysics have as their business to describe the behavior of cells or of subjects but not to explain such behavior. What are the visual areas of the cerebral cortex actually doing? What are the problems in doing it that need explaining and at what level of description should such explanations be sought?
If we want to understand phenomena like vision, we need to do more than just describe the physical machinery involved in it. We need analysis at multiple levels.
Marr proposed 3 levels of analysis through which one can understand any information processing system (Marr treated vision as an information processing problem. This is not the only way to do it but let’s leave that for another time). He referred to the process that takes place in vision as a ‘computation’ of visual data about the world into some kind of sense making for the organism. We’ll hang on to that computation language for the time being.
Level 1: The computational theory
This is the most abstract level - it asks what problem the computation is coming to solve. In vision for example, before we get into neurons and ganglia and all the wet stuff, we need to ask why an organism would need vision to begin with.
In vision, Marr describes the computation: ‘In the theory of visual processes, the underlying task is to reliably derive properties of the world from images of it’
Vision helps an organism solve the problem of how to navigate the world using images.
This might seem obvious, but failing to address this level can lead you astray. If you try to understand vision just in terms of neurons, you won’t understand vision.
Marr again - ‘trying to understand perception by studying only neurons is like trying to understand bird flight by studying only feathers:’
The computational theory of flight might be ‘give the bird the ability to get to the treetops and high up rock faces to access food and nest there away from predators’.
The Computational Theory is the Why. Why do we need this computation.
Level 2: Representation or Algorithm
In this second level, Marr describes the algorithmic approach that is used to solve the Computational Theory. If Computational Theory is the Why, Algorithm is the What - what approach will you take to solving the computational problem, and what rules will you use.
Note that Algorithm isn’t the nuts and bolts of Implementation - that’s for level 3. Level 2 asks how are you going to go about taking the information for the computation and transforming it into the output you need.
To extend Marr’s earlier example of flight - if the Computational Theory is flight, the Algorithm level is flapping.
In the case of a flying squirrel the Algorithm would be gliding. Different strategies for solving a problem depending on various biological and environmental constraints.
Marr also called this level the Representational level. One element of the algorithm is how you choose to represent the problem - if I’m doing maths and I want to deal with the number 18, I can choose to use Roman Numerals (XVIII), Arabic Numerals (18), words (Eighteen), or Binary (10010). How I choose to represent the number will impact which algorithm I choose for the computation.
For example if I want to add 3 to 18, using Arabic numerals I do what we learnt to do at school - I add the 3 to the 8, which gives me 11, I carry the 1 and add it to the ‘10’ of 18 and I get 21. This kind of arithmetic addition is so familiar we forget it is a kind of algorithm.
If you’re using binary, adding 00011 to 010010 would require a different algorithm - albeit one beyond my mathematical capabilities. Similarly if I ask you to multiply XVII by CIXVI you would have to rely on a different method than the one you learnt in school for Arabic numerals.
Marr argues that the Romans didn’t invent mathematics because their way of representing numbers made complex mathematics too difficult. The way we choose to represent a problem impacts which approaches we can use to solve it. I'll write more about that next week.
An algorithm Marr proposes for vision (and it's not wildly important that you understand the details of this) is a ‘primal sketch’ or an outline of the image, followed by a ‘2.5D sketch’ which represents contours, depth and orientations. Then a ‘3D model’ which gives a fuller representation of a shape. Check out the book for more detail about that.
The important thing here is that we aren’t yet talking about eyes or retinas or neurons, we’re talking about algorithmic strategies for achieving the computational goal of vision.
Level 3 - Implementation
Implementation is the way that an organism brings its algorithmic or representational approach to life via its body - it's physiology and anatomy. In the case of the bird:
Computation: Flight
Algorithm: Flapping
Implementation: Wings and Feathers
The implementation makes a different kind of sense when we can appreciate how it is the way we will bring the algorithm to life, for solving a bigger computational problem. Marr’s point is that if you understand a behaviour or a function at all these three levels you have somewhat of a complete account of it. If you only pay attention to one of these levels you miss the global integrated picture of how a process works.
If Computation is the Why, Algorithm is the What, Implementation the How. How will you bring the Algorithmic approach to life?1
In Vision, this is eyes and neurons and optic nerves and retinas, that allow the body to carry out the algorithm described above.
Here’s a handy table describing the 3 levels from Vision.
That was some (hopefully) interesting theory about information processing systems. So the question begs - what’s this got to do with me and my team?
The 3 levels of team behaviour analysis
There are two ways that I can see Marr's 3 levels being of use to someone in a team.
Understanding how a team solves a particular business problem
Bringing in new ways of working
1. How does a team solve a particular problem
A team could use the 3 levels to make sure they understand the full context and implementation strategy of their work. Sometimes teams are approached with really specific requests and no context, other times the team is given a big hairy problem to solve and no details.
Using Marr’s 3 levels could help the team make sure they have a shared view on how to approach their work.
When presented with some problem to solve a team could ask:
What is the Computational Theory - Why do we need this website button? What problem in an environment is it looking to solve?
What is the Algorithm and Representation? - How are we going to build this new website? Are we going to do it all in one go, in pieces, by copying an existing one, by inventing something new?
How are we going to Implement it? - Which technologies are we going to use, how are we going to get this idea out there into the hands of users? Who do we need help from?
The 3 levels here help a team make sure they are capturing the abstract, computational context, all the way down to the nitty gritty implementation levels.
Let’s take a non software example - a hospital team has been asked to improve the way they give information to patients who are being discharged. Maybe the 3 levels could look like this:
Computation - Patients who are discharged from our ward are phoning up the hospital to ask for information about their follow up care. The phone lines are busy and expensive to maintain and the information is actually available on an app
Algorithm/Representation - We’re going to make sure every patient who leaves the hospital have downloaded and logged into the app before they are discharged
Implementation - Let’s get volunteer teenagers from the local school to walk around and guide patients through the process of downloading and logging onto the app before they leave
You could argue with whether or not these are good ideas, but it represents a wholescale articulation of the problem and the solution. I challenge you to ask your teams to think about these three levels when they receive a new project or request.
By bringing the 3 levels to your team you can share a model of how to understand the whole project from why to how. Then the team can say things like ‘I think we nailed the ‘Computational’ level of this but we actually didn’t have clarity on the Implementation and we wasted time’. Something like that.
2. Bringing in new ways of working
One of the problems facing agile practitioners is that we often end up spending too much attention on the Computation or the Implementation levels. In the former case, it’s all theoretical wishy washiness. We talk big ideas that sound nice but don't relate to the day-to-day of the team.
In the latter case you can get caught arguing for one meeting methodology, or one piece of work management technology over another and you get lost in the weeds.
As a Collaboration Coach I’m often asked to help a team try new formats or meeting methodologies. Most ink has been spilled over the issue of Story Pointing so let's start there.
Story pointing is a practice in which some teams assign numbers to items of work to represent how complex they appear to be. This practice can be a tool of oppression - it leads to managers and stakeholders thinking that they can do maths and prediction based on what is essentially the team’s guess about how hard a piece of work is. It can also be a tool of liberation - inviting necessary clarifying conversation and helping a team get on the same page.
The 3 Levels could help me introduce Story Pointing in a more subtle and appropriate way.
Computation - We need a way of breaking down our work into small chunks so that we are encouraged to work on simple problems
Algorithm/Representation - use numbers (specifically the Fibonacci sequence to avoid quibbling about small differences that don't matter, eg between a 22 and a 23) to represent complexity. If an item has a number over - say - 13, we agree to split it
Implementation - The team plays ‘planning poker’ and assigns story points every 2 week cycle during their planning meeting, we write them on our Jira tickets.
An alternative version of solving the same computation could be
Computation - We need a way of breaking down our work into small chunks so that we are encouraged to work on simple problems
Algorithm/Representation - take each user story and split it out as much as is feasible and trust our intuition about what the smallest feasible chunk is. No numbers necessary
Implementation - During our planning meeting we hold up each work item and ask ‘can we make this simpler?’, whoever thinks of a good way of feasibly making it simpler gets a chocolate
Or even you could use the 3 levels to clarify that the Computation is a different one
Computation - Management are all up in our grill wanting to know if their big exciting feature is going to be ready before the big shareholder meeting
Algorithm/Representation - represent each story as a number, and use those numbers to make up a ‘velocity’ and a project scope which we can use to forecast when this work will be done
Implementation - Each sprint we will play planning poker, and use the numbers to update a burn-up chart which coarsely shows when we might be done. We update the burn up at each sprint planning.
I’m not meaning here to take a side on story points vs story splitting, or the merits or demerits of burnup charts. One of the things that most attracts me to cognitive science as a discipline is that it seeks to look beyond particular stances or explanations for phenomena, and draws your attention to the o the lenses through which the question is asked.
By doing this, by questioning the lenses that we use to address questions in the world around us, we can become better problem solvers.
I’m hoping that this article gives you the lens of Marr’s 3 levels to take to your teams and practice. Go, try it out, either use it explicitly with your team or in just how you think about your team and let me know how you get on
If you enjoyed this and want more articles and podcasts along a similar theme, you can subscribe to receive a free weekly newsletter. If your boss is paying for it and you want to signal to me to continue this work, do consider upgrading to a paid subscription
Finally you can let me know what you thought about this article by:
Leaving a like < a comment < filling in the feedback form < sharing it on LinkedIn