I often see situations like this in software teams:
Alice: “We can’t begin testing because we’re still waiting to hear from Bob about when the RC will be ready. He will let us all know in the official Slack channel. Stand by.”
Bob: “I know you’re all waiting for the RC but I need confirmation from Craig first, and he’s not responding to his email”.
Craig: “Usually it’s Dan who makes this decision but he’s on holiday and he didn’t brief me on this when he handed his tasks over to me…”.
Typically, I (mis)diagnose this as a problem of ignorance. The roles and responsibilities are not clear enough! Let’s make another checklist, create another role, set another OKR. This will help people to understand exactly when they’re right or wrong.
Today I had a little epiphany: it’s not an ignorance problem — it’s an indecisiveness problem. Often we’re not clueless — we’re just unwilling to make a decision.
The incumbent mental model in our industry is that making software is like manufacturing electric cars (or rockets). It seems that we’re in love with the idea of the archetypal engineer, whose decisions are imbued by the exacting precision of the scientific method. But making software is really more like playing rugby (despite the clichés). It’s chaotic and messy. It relies way more on in-the-moment decision making and quick reads of your teammates than on your ability for careful reasoning.
So what keeps people from making good local decisions? Even if I have perfect knowledge of how to do something, I will avoid making any decisions that could get me in trouble if I fail. In fact, this fear could leave me paralysed.
We’ve been hearing a lot about “psychological safety” and “safe-to-fail” recently, but it boils down to something simpler: courage — and it starts with us as agile practitioners. Let’s stop hiding behind the default “process process process” modus operandi and start focussing on helping people make the tough and meaningful decisions they’re expected to make every day.