When working in complexity, where the right thing to do emerges and we learn by actually trying things rather than by analysis, there’s a very human instinct that happens when we think of probes to try out. I see it all the time when I teach Cynefin, and I sometimes catch myself doing it (which means I fail to catch myself doing it a lot; welcome to bias).

I see people think of perfectly lovely, lightweight probes. “Let’s try using Slack.” “We could set up a visual board…” “Let’s try talking to the Ops team.” “It looks like a simple fix, and we can back it out easily if it fails.”

The urge that kicks in is then to take these lovely lightweight probes, which are perfectly safe-to-fail, and add stuff to them to give them a better chance of working.

“Slack? Fantastic; I’ll need the list of everyone to add to it, and I’ll set up these fifteen channels, and we’ll have a launch party in two weeks to encourage people to join…”

“A visual board? We should copy it into JIRA as well, and make a key of what colour post-its to use and here’s all the information that we need to put on them…”

“Our Ops team? Let me set up a meeting with our senior stakeholders and third-party suppliers so we can talk through what we need…”

“Release? You’ll have to work with the other teams and join the release schedule we’ve already set…”

The trouble is, these speculative investments of time, money or effort can mean that the probe is that much less safe-to-fail. Communicating a probe without being really clear that it’s just trying something out can result in communicating intent, leading others to create commitments around it, cementing it in place. The sunk-cost fallacy kicks in. “What do you mean, it’s not working? We spent two weeks on that…” The more people it reaches, the greater the impact and the need for success.

Having an awareness of this tendency has helped me to ramp it back. Instead of trying for something that will probably work, think about keeping it lightweight, so that if it doesn’t, it’s easy to fix or reverse or dampen in other ways. We’re aiming for things that might possibly work, or even plausibly work (I saw a figure from Ozzie Yüce that suggests only 1 in 3000 new ideas are actually successful). Keep it simple, small, or cheap, or short, or even hacked-into-place if that’s something you’re good at.

(Probes don’t have to be simple, small, cheap, or short, but I’ve found those are pretty good heuristics to work with.)

Resist the urge to double down by surrounding the probe with expensive scaffolding to prevent the failure. If it seems like it might not work, try to find ways instead to make it safe-to-fail. Those options that you make available for handling failure will work with other probes, too. (Automated rollback, for instance, makes all kinds of production releases safer, allowing all the teams involved to try things out more easily.)

And if you hear someone else’s ideas, please also resist the urge to tell them all the reasons you can think of that mean it’s going to fail, unless it really isn’t safe to do so (or your feedback has been explicitly invited).

In the complicated domain, things will work as predicted; in complexity, probably not so much. And that’s OK.