Most business writing treats lousy systems as a purely negative condition to be eliminated on sight. Everything broken is bad. Everything undocumented is a problem. Every informal workaround is an urgent fix-it ticket.
This is mostly true. It's not entirely true. A contrarian view worth considering: some of the lousy systems in your business are secretly useful. They're telling you something. They're serving a purpose you haven't identified. They're cheaper than the systemised version would be. Or they're giving you operational flexibility that a rigid documented process would strip out.
This article makes the case for when lousy is fine, when lousy is actually telling you something, and when lousy is a real problem worth fixing. Not all mess is equal. Learning to tell the difference is a genuinely useful operational skill.
Why "systemise everything" is bad advice
Three structural reasons the blanket "fix every broken system" directive misleads small business owners.
Design effort is expensive. Every process you systemise costs time to design, document, train against, and maintain. That time is finite. Spent on the wrong processes, it's time that couldn't be spent on the right ones. A mess that isn't actually hurting you is cheaper than an immaculately documented library of things nobody uses.
Some flexibility is worth preserving. A documented process is a commitment to a specific way of doing things. For work that genuinely needs to flex (creative work, bespoke client engagements, early-stage experimentation), tight documentation kills the thing you were trying to protect. Some operational areas are better left loose because looseness IS the operational advantage.
The mess is often diagnostic. Lousy systems almost always tell you something about the business. A process that's been "lousy" for years without being fixed is a signal — either about priority, about genuine difficulty, or about cost-benefit. Fixing it without understanding what it was telling you often means re-creating the same mess in a different form later.
The 4 upsides of lousy systems (when to leave them alone)
1. They're a real-time priority signal. The processes that stay lousy for years despite everyone agreeing they're lousy are the ones nobody actually prioritises fixing. That's signal. If a lousy process has survived three quarterly reviews, one Systems Champion appointment, and two "this time we'll get to it" moments, the business is telling you it doesn't actually care enough about this process to fix it. Which usually means it doesn't matter enough. Leave it. Fix something that's actually on the priority list.
2. They force creative problem-solving from the team. Over-systemised operations produce teams that execute the documented path and don't develop the judgement needed when the path doesn't fit. A bit of operational mess forces the team to think, adapt, and build the problem-solving muscle that pays off when genuine novelty hits the business. This doesn't mean being sloppy deliberately — just that the discipline of NOT over-designing keeps the team sharper.
3. They preserve negotiating room. A lousy process is open to being redesigned to suit the next client, project, or regulatory change. A tightly-documented process resists change — you've trained the team on it, written the manual, built the reviews. Re-opening is expensive. In fast-changing operational categories, under-systemising deliberately can preserve the option to pivot cheaply when the context shifts.
4. They expose the weakest link when everything else is tight. In a well-systemised business, the one remaining lousy process is very obvious and very fixable — everyone can see it, everyone knows it's next in line. In a poorly-systemised business, everything is lousy and nothing stands out. Paradoxically, the most effective systemisation programmes leave some mess visible specifically to concentrate the team's attention on what actually needs fixing.
Four upsides. Each one genuine in specific contexts. Collectively they argue against the "systemise everything" reflex that drives most small businesses to over-build their libraries and under-execute on the few systems that actually matter.
When lousy genuinely is bad (and how to tell)
Four signals that a lousy system is the real problem, not a secret upside:
It's producing recurring customer-visible problems. Same type of complaint, same class of error, showing up month after month. Internal mess is tolerable; customer-visible mess is not. Fix.
It's single-point-of-failure dependent. One team member holds the whole thing in their head. If they're out, operations break. Fix — this is a resilience issue, not a flexibility benefit.
It's blocking scale. You'd hire, you'd take on more clients, you'd open a second location — but the lousy process wouldn't hold up at higher volume. Fix, because the mess has moved from low-cost to growth-blocking.
It's eating senior-team time. The owner or leadership spends hours every week firefighting the lousy process. Even if customers don't see it, the internal cost is real. Fix, because leadership time is the scarcest resource in a small business.
If none of those four fire, the lousy process is probably fine to leave alone. If one fires, it's on the backlog. If two or more fire, it's the next priority.
The quiet discipline most owners miss
The real discipline isn't systemising everything. It's diagnosing which processes earn the design investment and which don't. Most small businesses either under-systemise (chaos at scale) or over-systemise (bureaucracy that kills flexibility). The right answer is selective: heavy design on the critical few, looser operations on everything else, explicit review of which category each process belongs in.
This requires a rhythm the Systems Champion can own: quarterly, walk the operational landscape, ask "which lousy processes are producing customer-visible damage, single-point-of-failure risk, scale-blocking friction, or senior-team time drain?" Those are the next quarter's design targets. Everything else stays lousy, deliberately, for now.
The teams that execute this well end up with fewer documented processes than teams that tried to systemise everything — and they usually run noticeably better. Less documentation, more judgement, tighter focus on what matters. That's the contrarian upside worth learning.
Ready to diagnose your mess? Instead of asking "what isn't systemised?", ask "which of our lousy systems is actually hurting us?" The answers usually surprise owners — most of the mess can stay. For the ones that genuinely need fixing, start with a systemHUB free trial to house the documentation work.