We had an interesting epiphany yesterday.
Despite our continuing efforts to include key factors for prioritization, we found ourselves being pushed to work on things that were not prioritized. And it wasn’t about prioritization.
One of my team members has implemented a very clever prioritization method using Airtable that captures the problem, potential solutions, related meta and then key factors for prioritization including customer pain, frequency, reach and development effort to resolve. Being a bit of a spreadsheet nerd myself, I’m pleased that we’ve found a way to do this in a way that is collaborative, transparent and effective. It’s been an aspiration of mine to have something like this working to ensure that design and development are focusing on the things that matter most for the company.
So why work on something else if it’s not in the system?
The epiphany is that no matter how good your system is, even if it includes company rank, emotions, weather and actual dollar amounts for cost and benefit, humans don’t actually like systems! I mean, I’m a human and I love systems. I love this prioritization system we have because it means that I don’t have to worry that day-to-day we’re missing our target. It means that we have a recorded history of good choices and a plan for future good choices. It’s flexible and sharable. But it’s done by algorithms and not by gut. Humans like their guts. In the end, when all else fails, and even when all else is good, humans want to trust their gut over systems. That’s why process always breaks down: human guts.
(Here’s what I’m not going to talk about: why we should build and rely on processes, models, principles and systems that reflect our aspirations and needs.)
So go out there and build the best systems, for prioritization, delivery, operations, tracking and more! But remember why you’re building it. You’re building it to help humans be more precise, accurate and have better memories. You’re building it to insulate from frustration, impatience, overconfidence, and flights of fancy. But you built it for humans! If your system is too rigid for the dynamic of humans, then they’ll know and they’ll suspect it, fear it and ultimately lose trust it in. And untrusted systems fail. They fail harder with every fracture of mistrust. So be transparent, iterate to improve, but account for human nature too.
I was going to end there, but I think some examples might help you understand some specific human factors that conflict with systems. Consider these, and perhaps your system can account for them. If you can’t, adjust your system.
- Does it really matter if a developer skips the top story in the backlog in favor of another story two down that really gets her excited?
- If the CEO marches down to your desk to tell you about a bad experience he just saw on the site, and he’s rational, is the correct response really just “that’s great, but it’s 30th in line?”
- Do you really wait to implement an internal tool for your Support team when they’re getting bombarded with a demoralizing issue day after day, in favor of another tool or fix that outranks it?
- Do you always tackle the “big rocks” at the top of the list at the cost of one or two collectively larger, themed pile of “little rocks” lower down?
- Do you hold off on a new project because the original estimate caused a lower priority, despite a developer being so excited about it that he’s spending his own personal time to further the code?