What a Blocker Is

There's a word developers use constantly that I'd never heard before I started building software: blocker.

A blocker is the thing that has to be resolved before anything else can move. Not the hardest task. Not the most important one. The one that everything else is waiting on.

I picked it up building CageList, and once I had the word I started seeing the thing everywhere — in players I coach, in parents, and in about twenty years of my own career that I'd been misreading.

The distinction that matters

Here's what the word gave me that I didn't have before.

Stuck and blocked feel identical from the inside and they are completely different problems.

Stuck is when you don't know what to do next. The answer is thinking, or asking, or trying something.

Blocked is when you know exactly what to do next and cannot start it, because something upstream isn't resolved. The answer is never to try harder at the blocked thing. It's to go find the upstream thing.

In software this is obvious because the machine tells you. You cannot build the booking flow before the schema exists. The computer will simply refuse, immediately and rudely, and there is no amount of determination that gets you around it.

Life doesn't tell you. Life lets you spend a year grinding on the wrong thing.

What it looks like off the screen

A kid comes to me and his swing is a mess. I could spend twelve weeks on his swing.

But sometimes the swing isn't the problem. Sometimes he's afraid of the ball, or he's exhausted because he's playing three sports and sleeping six hours, or he thinks his dad is disappointed in him. Those are blockers. Work on the swing all you want — nothing moves, because the swing was never what everything was waiting on.

Same with parents. Somebody tells me they can't get their kid to practice consistently. That looks like a discipline problem. Half the time it's a logistics problem — there's no facility available at the hour that works, so every session takes an act of will. That's a blocker with a boring solution, and no amount of motivation fixes it.

And in my own story, plainly: at nineteen I thought my blocker was my hip. It wasn't. The hip was a solvable technical problem. The actual blocker was that I hadn't met anyone who'd done it — I had no proof the road existed, so I couldn't start walking it. One conversation with Paul Laxalt cleared it, and then everything downstream moved fast.

I spent months on the wrong problem because I'd misidentified which thing everything else was waiting on.

The three moves

Once you've actually identified a blocker, there are only three things you can do, and knowing which one you're doing is most of the skill.

Resolve it. Go fix the upstream thing. Usually the right answer and usually less work than it looked like, because a blocker inflates in your head while you're stuck behind it.

Route around it. Restructure so the work doesn't depend on it. I ran a lesson business across three states without ever leasing a facility — the lease was the blocker that kills most coaches, and I didn't resolve it, I made it irrelevant by renting time instead of space.

Accept it and re-plan. Sometimes it isn't moving. Four major league organizations wouldn't sign me because of insurance liability on the hip, and there was no version of me that resolved that. What was available was a different route: independent ball, Mexico, Canada, the Czech Republic. Seven seasons on the road that was actually open.

The failure mode isn't picking wrong. It's not choosing at all — sitting in front of a blocker doing neither, calling it persistence.

Why I think this transfers

The reason this concept is worth teaching is that software forces a discipline nothing else does: you have to be honest about what's actually stopping you, because the machine won't accept a story.

You can't tell the compiler you're working hard. You can't tell the database you have a good attitude. It either runs or it doesn't, and if it doesn't you have to go find the real reason rather than the one you'd prefer.

Twenty years of athletics taught me effort. Building software taught me diagnosis. I'm forty-one and I only recently got the second one, and I've become convinced it's the more valuable of the two.

Most people I meet are not short on effort. They're pouring enormous energy into a thing that is downstream of the thing that's actually stopping them.

The question isn't am I working hard enough. It's what is everything waiting on — and then, honestly: am I resolving it, routing around it, or pretending it isn't there.