Sitting with ambiguity for innovation projects (or life in general!)

Ambiguiti.es Agile, ambiguity, bias, Bonfire, Buster Benson, information, innovation, Marshall McLuhan, meaning, tetrads, time, Zappa project

When we're doing new work, we tend to jump to conclusions and define things too quickly. This post outlines why that's a bad idea, and what we can do to counteract these tendencies.

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.

A tendency that I see with many innovation projects is a lack of tolerance for ambiguity. By this I mean that because we never have enough time, we jump to conclusions with what we have and move ahead. It's understandable that we do this, either consciously or unconsciously.

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. To the far right, there's a rush to nail everything down. 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'.

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.