Systems Not Tactics

The mallet comes down. Direct hit. Satisfying thwack. One second later, a different mole pops up two holes over. The mallet was never the problem. Neither was your aim. Tactics fail in the same place every time, and it’s not because the tactic was wrong. It’s because a tactic is aimed at where the problem […]



The mallet comes down. Direct hit. Satisfying thwack.

One second later, a different mole pops up two holes over.

The mallet was never the problem. Neither was your aim.

Tactics fail in the same place every time, and it’s not because the tactic was wrong. It’s because a tactic is aimed at where the problem became visible — not at why it showed up there in the first place. Systems thinking for business works differently. It asks what’s producing the symptom, not just where the symptom landed.

The Tactic Graveyard

Every founder has one. A growing pile of things that were supposed to fix it — whatever “it” currently is. A new CRM. A better intake script. A laminated SOP nobody opens. An ops hire who was supposed to take things off your plate. Each one felt like the answer when you bought it, hired it, or wrote it.

  • “We switched CRMs and it’s still a mess.”
  • “We hired an ops person and I’m still the bottleneck.”
  • “We wrote the SOP and nobody follows it.”
  • “We did a training and the same mistakes came back within a month.”
  • “We bought the tool. We still do it in a spreadsheet.”

None of these failed because the team didn’t try hard enough. They failed because a tactic, by itself, is a patch applied to a symptom — and the system underneath the symptom never noticed the patch was there.

Why the Mole Keeps Moving

Here’s the mechanism, plainly: a tactic addresses where a problem became visible. It does nothing about why that’s where the problem showed up. If the underlying system that produced the problem is still intact, the pressure that created it is still there too — and pressure finds an exit. Usually a new one.

“A tactic fixes where the problem is visible. A system fixes why it’s there at all.”

Swap the CRM, and the data is still messy — because the mess was never about the software, it was about nobody agreeing on what “qualified” means. Hire an ops person, and you’re still the bottleneck — because nobody redefined who’s allowed to make which decisions, so everything still routes through you out of habit. The mole didn’t get smarter. The hole never closed.

Tactics vs. Systems — What’s the Difference

It helps to be precise about the distinction, because the two get used interchangeably and they’re not the same thing at all.

A Tactic

A specific action aimed at a specific symptom. A tool, a script, a one-time fix. Swappable. Replaceable. Can be purchased or implemented in a week.

A System

The structure that determines how work, decisions, and information actually move through the business. Foundational. Invisible until you go looking for it. Takes longer to see, and longer to fix.

A tactic can be excellent and still fail — not because it was the wrong tactic, but because it was solving a problem the system kept regenerating. Good tools deployed onto broken systems just produce better-documented versions of the same dysfunction.

Why Founders Default to Tactics

This isn’t a failure of judgment. Tactics are faster. They feel like progress immediately — you bought the thing, you hired the person, you wrote the document. There’s a visible artifact by Friday. Systems thinking for business doesn’t work like that. It’s slower, it’s less visible in the short term, and under growth pressure, slow and invisible loses to fast and tangible almost every time.

That’s not a character flaw. It’s an entirely reasonable response to running a business where everything feels urgent. The problem isn’t that founders reach for tactics. It’s that tactics get treated as the whole answer instead of the visible 10% of it.

Tactics feel like progress. Systems are progress.

— Rachel, Marketplace Maven

What Looking at the System Actually Means

This isn’t an argument against tactics. Tools, scripts, and hires are useful — sometimes necessary. It’s an argument against stopping at them. The shift is in the first question you ask. Not “what tool fixes this,” but “what’s actually producing this in the first place.”

That question tends to point somewhere in one of five places — how the business is positioned, how much authority it’s built before the sales conversation even starts, what actually happens during conversion, how the lifecycle handles a customer after the deal closes, or whether anyone has real visibility into what’s happening across the other four. Most tactics get aimed at the symptom without ever checking which of those five the symptom is actually coming from.

The Bottom Line
  • The mole isn’t the problem. The hole is.
  • A tactic that doesn’t stick wasn’t necessarily the wrong tactic — it may have been aimed at the wrong layer.
  • Systems thinking for business isn’t slower because it’s harder. It’s slower because it’s actually solving something.
  • Good tools on a broken system just produce a better-documented version of the same problem.

If you want to see what a real check on the underlying system looks like, start with Revenue Health Check 101. For the full mechanics of how the five systems get evaluated together, see The Revenue Health Matrix™ Deep Dive.