In his cheat sheet to cognitive biases, Buster Benson categorises the 200+ he identifies into three ‘conundrums’ that we all face:
- Information — there’s too much information to process, and we have limited attention to give, so we filter lots of things out.
- Meaning — lack of meaning is confusing, and we have limited capacity to understand how things fit together, so we create stories to make sense of everything.
- Time — we never have enough time, resources, or attention at our disposal to get everything that needs doing done, so we jump to conclusions with what we have and move ahead.
One of the reasons that the Manifesto for Agile Software Development has been so impactful, even beyond the world of tech, is that it’s a form of granting permission. Instead of having to know everything up front and then embark on a small matter of programming, there is the recognition that meaning can accrete over time as systems develop.
It is therefore crucial to ensure that the project heads off on an appropriate trajectory. It’s also important that it can be nudged back on course should it stray from meeting the needs of users/participants/audience.
A tendency that I see with many innovation projects with which I’ve been involved is a lack of tolerance for ambiguity. By this I mean that because, as Benson notes, we never have enough time, “we jump to conclusions with what we have and move ahead”. In addition, because the world is a confusing place (especially when we’re doing new things!) “we filter lots of things out” and “create stories to make sense out of everything”.
It’s understandable that we do this, either consciously or unconsiously — and I’m certainly not immune from it! However, ever since studying ambiguity helped me with my doctoral thesis, I’ve been interested in how understanding different forms of ambiguity can help me in my work as a cooperator and consultant.
I’m going to discuss a Continuum of Ambiguity which I developed, based on the work of academics, and in particular Empson (1930), Robinson (1941) and Abbott (1997). I’m going to try and keep what follows as practical as possible, but for background reading you might find this article I wrote over a decade ago useful, or indeed Chapter 3 of my Essential Elements ebook, which is available here.
If we imagine ambiguity to be a continuum, then a lot of what happens with innovation projects happens at either end of the continuum. To the far left, things are left unhelpfully vague in a way that nobody really knows what’s going on. Anything and everything is up for grabs.
Alternatively, to the far right of the continuum, there’s a rush to nail everything down because this seems just like a project you’ve done before! Or there are massive time/cost pressures. Except of course, it isn’t just like that previous project, and by rushing you burn through even more time and money.
In my experience, what’s necessary is to sit with the ambiguity that every project entails: to understand what’s really going on, to look at things from many different angles, and ultimately, to shepherd the project into a part of the continuum I call ‘productive ambiguity’.
To define quickly the three parts of the Continuum of Ambiguity:
- Generative ambiguity — words are used as symbols for ideas that are very hard to express. If an idea is generatively ambiguous, then it might make sense to you, but not so much to others.
- Creative ambiguity — one part of an idea is fixed, but the other part has a lot of freedom of movement. If an idea is creatively ambiguous, then other people who share your context might kind of see what you’re getting at (but others probably don’t).
- Productive ambiguity — the idea you re expressing has resonance for many people. They ‘get’ it. If an idea is productively ambiguous then real work can be done at scale, usually because the metaphor being used crosses contextual boundaries.
There was a time when ‘Uber for X’ was a popular way of getting funding. Without nailing down exactly what would happen or how it would work, the simplicity and game-changing approach that Uber took to booking a taxi could be applied to other areas or industries.
These days, ‘Uber for X’ is a dead metaphor as it’s been overused and is little better than a cliché. This is important to note, as an idea does not become (or remain) productively ambiguous without some work.
I’m working with the Bonfire team at the moment on the Zappa project. Unlike something such as Mastodon (“Twitter, but decentralised!”) or Pixelfed (“Instagram, but federated!”) the team hasn’t completely settled on a way of describing Bonfire which is productively ambiguous.
The tendency, which they are resisting nobly, is always to nail things down. Especially when you have funders. For example, it would be easy to decide in advance what is technically possible when attempting to counteract mis/disinformation in federated networks. Instead, because Bonfire is so flexible, they are sitting with the ambiguity and searching for use cases and metaphors which will help illuminate what might be useful.
One promising avenue, as well as doing the hard yards of user research and the synthesis of outputs this generates, is to use Marshall McLuhan’s notion of ‘tetrads’. The above example is taken from a post by Doc Searls in which he explicitly considers social media and what it improves, obsolesces, retrieves, and reverses.
There is no one framework or approach which can give the ‘truth’ of how a project should proceed, or what users want. Instead, by considering things from multiple angles, the overlap between desirable, technically possible, and needed by users comes into focus.
Instead of a conclusion, I will instead finish with an exhortation: sit with ambiguity! And while you’re sitting with it as a team, talk about it and resist the temptation to bring in dead metaphors. Instead of conceptualising the conversations you have about the project as “going round in circles” consider instead that it’s more likely that you are spiralling round an idea in an attempt to better understand and define it.
