I’m currently working with a founder who built his entire business on spreadsheets. Sales data, client records, lead routing, all of it wired together with formulas and webhooks. It worked until it didn’t. Leads started disappearing. Others ended up in the wrong client’s pipeline. The webhooks connecting the intake forms to the spreadsheets were silently failing, and because everything was built on top of everything else, nobody could tell exactly where it was breaking or how long it had been happening.

When he brought me in, his first instinct was to fix everything at once. Rebuild the lead routing. Clean up the client records. Replace the cheap webhook service. Document all the processes. Migrate off spreadsheets entirely. All of it, right now, before anything else went wrong.

I understood the impulse. When you can finally see how fragile something is, the urge to overhaul it completely is hard to resist. But that approach was going to make things worse, not better.

Why fixing everything at once doesn’t work

The problem isn’t ambition. The problem is that broken systems are usually interconnected. Fix the webhook service before you’ve mapped how leads are supposed to flow, and you’ll route them correctly into a structure that’s still wrong. Clean up the client records before the intake process is stable, and you’ll clean them again next month. Start migrating off spreadsheets before you understand what each spreadsheet actually does, and you’ll rebuild the fragility into whatever replaces them.

Nothing is finished until everything is finished. And in the meantime, the business is still running on the broken version, which means new problems are accumulating on top of the ones you haven’t solved yet.

Research on task-switching shows it can consume up to 40% of productive time, not because people lack focus but because the cognitive cost of moving between different systems and contexts compounds quickly. That’s true for individuals, and it’s true for improvement efforts. Splitting attention across six broken workflows means you’re never far enough into any single one to understand where it actually breaks.

There’s another cost that’s easier to miss. Once you’ve started rebuilding something, abandoning it feels like failure. So you don’t abandon the six parallel tracks. You keep them all open, half-built, which means you now have two versions of everything: the old way that works (badly) and the new way that doesn’t work yet. That friction quietly kills any chance of the new system getting traction.

One thing first

We started with the lead routing. Not because it was the most strategic problem, or because it was the easiest, but because it was the one actively costing him business right now. Leads going to the wrong client is the kind of problem that damages trust fast. Everything else could wait two weeks. That couldn’t.

This is the question I always ask when a client wants to fix everything: which one is actually hurting you this week? Not which one should be fixed, not which one would make the most strategic difference. Which one is costing you time, money, or client trust right now.

In The Self-Managing Business, I describe this framing directly: the question isn’t which workflow is most important. It’s which one hurts. Importance is strategic. Pain is immediate. And when you’re trying to stabilize something that’s breaking in production, immediate is what you can actually act on.

Fix that one. Make it boring to manage. Then pick the next one.

The weekly improvement review is what makes this sustainable over time. Fifteen minutes, same day every week. Look at what broke, identify the pattern, make one fix. That cadence turns sequential improvement from an intention into a rhythm.

It also answers the question everyone asks when you tell them to pick just one thing: “But what about everything else?” Everything else waits. Not forever, but until the current one is stable enough that you stop thinking about it every day. Most things that feel urgent enough to demand immediate attention are stable enough to survive two more weeks. And by the time you get to them, you’ll have actually finished something, which matters more than it sounds. Finishing one thing gives you a reliable reference point for what “done” looks like in this specific business.

You’re the bottleneck partly because the systems underneath you are fragile. Spreadsheet-based ops feel fast to build and easy to adjust, until one webhook drops and suddenly nobody knows where three weeks of leads went. The answer isn’t to rebuild everything at once. It’s to fix the process before you automate anything, one layer at a time, in the order that the pain tells you to.

Pick the one that hurts most. Make it boring. Then pick the next one.