The Intersection Most Fixes Never Go Looking For

Framework

I wrote earlier this week about low-hanging fruit. The fixes that feel like progress because they’re visible and fast, while the real problem sits untouched underneath them. I want to go one layer deeper, because naming the trap isn’t the same as knowing how to avoid it.

Here’s the story again, slower this time.

Teachers kept complaining about student tardiness. So I built a tardy sweep: any student in the hallway after the bell rang got a detention. Miss the detention, get more consequences stacked on top. Simple. Efficient.

There was an initial drop in student tardies. By the end of the quarter, though, the number had stagnated and there was almost no change in the data. The numbers plateaued at some percentage of students who were always tardy, and it was fundamentally the same kids every time. Worse, a student who was late once by bad luck got treated the same as a student who was late every single day. Teachers still complained about tardies. It was abundantly clear that what I’d built was broadly ineffective.

So I started asking them why. I heard the same answer in different words: we don’t do anything in the first few minutes, so why does it matter if I’m there or not?

Then I noticed something else. Some teachers barely had a tardy problem at all. Others had a serious one. The difference wasn’t the students. It was whether the teacher had a relationship with them and a structure that made the first few minutes actually matter.

Simple and significant are not the same axis

Here’s the distinction I didn’t have language for at the time, and do now.

Every fix sits somewhere on two different scales. One is how simple it is to implement: how much time, coordination, and political capital it costs to get it done. The other is how significant it is: whether it actually touches the mechanism producing the outcome you care about.

Those two scales are independent, and that’s the whole idea worth sitting with. A fix can be simple and significant. A fix can be simple and trivial. A fix can be complex and significant. And a fix can be complex and still trivial, all that effort spent on something that was never going to move the number anyway.

The sweep was simple and trivial. Fast to build, easy to defend, aimed at a symptom. It felt like progress because it was visible. It was never going to close the gap. The hallway was just where it showed up.

The same pattern, in a room with no hallway

I see this constantly now, on the corporate side of my work, and it rarely looks like a punishment system. It looks like a Monday standup.

Cameras mostly on. One person talking. Half the room drifting in a few minutes late or slipping out early. Someone asks how the weekend went. Almost nobody asks what’s actually moving this week forward. The fix a leader reaches for is a stricter cadence, or a tighter agenda template, or a rule that cameras have to be on.

Every one of those is simple. None of them touch the actual mechanism, which is that the meeting has never asked anything of the people sitting in it. No ownership named out loud. No plan anyone has to report back on. Nothing that couldn’t have been an email, dressed up as collaboration because it’s recurring and scheduled.

Tighten the agenda all you want. If the meeting still doesn’t require anything of anyone, you’ve made a trivial fix easier to defend, not more significant.

Why the trap is so easy to fall into

Low-hanging fruit isn’t chosen because people are lazy. It’s chosen because it’s legible. You can point to it in a review. You can say “we did this” and have a thing to show. A fix that’s actually significant is often harder to point to in the short term, because it changes a dynamic instead of producing an artifact.

That’s the real cost of years of easy fixes. Not that nothing happens, plenty happens. It’s that the actual problem never gets named, because every visible improvement makes it look like the problem is already being handled.

The question that catches it before you’ve spent the effort

The tell isn’t whether a fix is small. Small is fine, small is often correct. The tell is whether the fix, if it worked perfectly, would change the thing you actually care about, or just produce a better version of something adjacent to it.

Before committing to any fix, I ask one question now: if this works exactly as designed, does the number I actually care about move, or does a different number move instead? A cleaner sign-in sheet, a stricter attendance policy, a tighter meeting cadence: all of those can succeed completely and still leave the real problem exactly where it was.

The fixes worth building are small enough to actually finish and aimed at the mechanism, not the symptom next to it. That intersection is narrower than it looks, which is exactly why most fixes never go looking for it.