Confidently Wrong About the Bottleneck

Standing in line at the grocery store, I do the thing everyone does — scan the other lanes, guess which one is faster, switch. I am wrong about half the time. The line that looks slow because of the register is actually slow because of the person three back who forgot their card.

I get called into companies to do a version of that on purpose. Walk the floor, look at the handoffs, find where the work backs up. It's the part of the job I'm best at and the part I've been most confidently wrong about.

Here's the wrong version. I look at the flow — where the queue builds, where the tickets stack, where the number says stuck — and I name it. Clean, defensible, backed by a chart. And sometimes the chart is right. But more than once I've named the wrong link because the flow only shows me the process, not the person standing in it who is waiting on an answer they're too nervous to chase, or covering for someone, or just quietly out of capacity in a way no dashboard tracks.

I'd been doing a worse version of this for years before I found out it had a name — Goldratt's idea that a constraint is wherever you decide to look. I used to think that meant find the real one and fix it. What it actually means, the part that took longer to land, is that you can point at almost any box and make a case for it, and if you're not careful you'll optimize the box you picked instead of the one that's actually costing you.

The one I still remember: I told a team their fulfillment step was the bottleneck, moved resources at it, nothing changed. Took me two more weeks to find out the real hold was one manager who didn't trust the number coming out of the step before it, so he was quietly redoing the check himself. That never shows up on a process map. It shows up when you ask someone why they're doing something twice.

I still lead with the diagram. I don't know how else to start — you need a place to look. What I don't have is a reliable way to tell, standing in front of a flowchart, whether I'm looking at a process problem or a person who's stopped trusting a step and hasn't said so.

If you do this kind of work — how do you tell the difference before you go fix the wrong thing?