Many organizational problems aren't people problems. They're systems problems. The challenge is that "systems problem" isn't a diagnosis. So where do you start? When I'm trying to understand why a process isn't working, I don't start with solutions. I start with questions. Who owns the process? Can anyone see where work is sitting? Where does work change hands? Is the process documented? How do people report problems, and what happens after they do? None of those questions

Shared inboxes are a great place to start asking questions. Who decides what's urgent? How is work assigned? What happens when two people assume the other is handling it? What happens when no one responds? How do you know whether a message is being worked on, or just sitting? Does using the inbox require additional flagging, categorization, or workarounds that create more problems than they solve? Shared inboxes are often an easy solution to a problem that wasn't fully diagno

We've all run into situations where an organization decides on a solution before fully diagnosing the problem. Not surprisingly, it doesn't work. One of the biggest conclusions I see organizations jump to is staffing. It's a natural progression: something fails, everyone is overwhelmed, so the answer must be more people. But that's rarely my first conclusion. Before hiring, restructuring, retraining, or, above all, buying new software, it's essential to understand how the wor

Eleven is a design failure. We count: Ten. Eleven. Twelve. Thirteen... Then suddenly: Twenty-one. Twenty-two. Twenty-three. If we were inventing English today, would anyone create "eleven" and "twelve" on purpose? Probably not. And don’t even get me started on French. Quatre-vingt-dix. OMG STOP. It should be TENTY-ONE. Not eleven. TENTY-TWO. Not twelve. TENTY-THREE. Not thirteen. I know I sound like Lewis Black, but I’ll happily die on this hill. It’s not really about numbers