A problem just landed on your desk.

Maybe a client's upset about a missed deadline. Maybe a team member made the same mistake for the third time this month. Maybe a supplier dropped the ball and now you're scrambling.

Most business owners do one of two things when this happens. They roll up their sleeves and fix it themselves. Fast, but the same problem shows up again next week. Or they find someone to blame. Unfair, and the problem still keeps coming back.

Both responses miss the point.

There's a third option. And it's the only one that actually works: build the system that stops the problem from happening again.

That's what this article is about. The act of solving business problems at the root, not just at the surface.

Fixing vs solving

Let me draw a line that most owners never draw.

Fixing is what you do in the moment. Patch it. Move on. Hope it doesn't come back.

Solving is different. Solving means the problem stops recurring. The root cause gets addressed. The system that should have prevented it gets built or repaired.

Fixing takes 10 minutes. Solving takes two hours. And that's exactly why most owners never solve anything. The urgent always drowns out the important.

But do the math. Every problem you systemically solve is a problem you never see again. If that issue would have shown up 50 times this year, those two hours just saved you 500 minutes of firefighting. And the mental load that comes with it.

Fixing is a tax you pay on your time. Solving is an investment that compounds.

If you want the deeper logic behind this, I wrote about it in the article on systems reduce business problems. This one is the follow-up. The how-to.

A 5-step framework for systemic problem-solving

Here's the framework I use with clients. Five steps. Simple. Repeatable.

You can run this on any recurring issue in your business, from a client complaint to a supply chain glitch to a sales process that keeps breaking down.

The 5-Step Systemic Problem-Solving Framework

A repeatable process for solving problems at the root.

Trigger: A recurring problem shows up  |  Owner: Business owner or Systems Champion  |  Timeline: 2–4 hours over 1 week

  1. Document the problem specifically. What happened? When? How often? What did it cost in time, money, or trust?
  2. Find the root cause using 5 Whys. Ask "why?" five times. Each answer becomes the next question.
  3. Identify which system should prevent it. Does it exist? Is it outdated? Or is it missing entirely?
  4. Build or fix the system, assign an owner. Keep it simple (checklist, short video, one-page procedure). Give it a human owner.
  5. Measure recurrence. Did the problem go away in the next 30–90 days? If not, iterate.

Result: The same problem stops consuming your time. You solve it once, not 50 times.

Step 1: Document the problem specifically

Vague problems don't get solved. Specific ones do.

Write down what actually happened. When it happened. How often it happens. What it cost you (in time, money, or trust).

Don't say "client communication is bad." Say "three clients in the last two months have complained about not knowing when their project would be delivered, which cost us one referral and about four hours of crisis calls."

The specific version is actionable. The vague one is a feeling.

Step 2: Find the root cause using 5 Whys

The 5 Whys is the simplest root-cause tool ever invented. Toyota built it. You can use it in 10 minutes.

You take the problem and ask "why?" five times. Each answer points to the next why. The fifth one usually lands on the system that's missing or broken.

Step 3: Identify which system should prevent it

Once you know the root cause, ask: "Which system in our business should have caught this?"

Sometimes the system exists but nobody's following it. Sometimes it exists but it's outdated. Sometimes it doesn't exist at all.

That last one is the most common answer by a long shot.

Step 4: Build or fix the system, assign an owner

Now you build the process that prevents the problem. Keep it simple. A checklist. A short video. A one-page procedure.

And critically, assign a human owner. A system without an owner is a system that rots.

Step 5: Measure recurrence

Did the problem go away? Give it 30 to 90 days depending on frequency. If the issue comes back, your system isn't working yet. Iterate.

This is the step most people skip. Don't. Measurement is what turns problem-solving from wishful thinking into a real discipline.

Case study: Luke Davies (Davies Construction)

Luke runs a custom home-building business in New Zealand. Design-and-build homes for real clients, not cookie-cutter lots.

If you've spent any time around construction, you know it's full of moving parts. Every home has a unique design. Every site has its own conditions. Every client wants something slightly different. The number of decisions, handoffs, and communication threads is enormous.

For years, Luke was the glue that held it all together. Every question came through him. Every decision needed his input. Client communication gaps were a constant source of rework and frustration. The business couldn't scale because it was entirely dependent on his personal capacity.

Then he read SYSTEMology. Something clicked.

He committed to documenting every stage of his design-and-build workflow. From the first client meeting through to handing over the keys. Each stage became a system in systemHUB. A documented way of doing that thing, so the result didn't depend on Luke being on the phone.

Client communication got its own system. Project kickoffs got a system. Site inspections, client updates, change orders, handovers. One at a time.

The outcome? Luke has extracted himself from day-to-day project management. His team runs each project independently, following the playbook. He's now free to focus on sales and growth instead of firefighting. The business is more scalable, more profitable, and the stress has dropped dramatically.

Same construction chaos. Different relationship to it. The only thing that changed was the systems underneath.

David Jenyns holding SYSTEMology book — the framework Luke Davies used to extract himself from project management
The SYSTEMology framework is what Luke used to solve his problems at the root. Read the full Davies Construction case study

Why most owners skip the systems step

If this framework is so useful, why does almost nobody run it?

Because it feels slow.

When a problem shows up, the fastest path is to fix it yourself. You know the answer. You can make a few calls, send a few emails, and the fire's out in 10 minutes.

Building a system takes two hours. Maybe a full afternoon if you want to do it properly. It feels like you're solving less in more time.

But here's the arithmetic. Fixing it yourself costs 10 minutes and buys you zero future prevention. Building the system costs two hours and prevents 50, 100, or 500 future occurrences.

You're not comparing 10 minutes to two hours. You're comparing 10 minutes forever to two hours once.

Most owners can't see past the urgency of the moment to do the math. That's the trap.

The way out is to make systemic problem-solving a habit, not a heroic effort. A 30-minute debrief after every recurring issue. A Friday afternoon ritual of reviewing the week's fires and picking one to actually solve. Small and consistent beats big and never.

If you want more on this mindset, the articles on what is a business system and characteristics of good business systems both dig in deeper.

The 5 Whys in practice

Let me walk you through a real example of the 5 Whys so you can see how it works.

The surface problem: "We keep missing project deadlines."

The fifth why lands on the missing system. There's no documented kickoff process that brings sales, delivery, and the client into alignment at the start of a project.

So the solution isn't "yell at the salesperson to communicate better." It's a 45-minute kickoff meeting with a checklist and a shared project brief. Documented once. Run the same way every time.

One system. No more missed deadlines. Or at least, the same missed deadline never happens for that reason again.

That's how root cause analysis works in a small business. Simple questions. Uncomfortable answers. Real systems built from the learnings.

If your problem is structural rather than process-based, the article on the Theory of Constraints is a good companion piece. It helps you find the one bottleneck that's holding the whole business back. And once you've solved the top few problems, Kaizen gives you the continuous-improvement rhythm to keep solving the smaller ones over time.

Case study: Gary McMahon (Ecosystem Solutions)

Gary runs Ecosystem Solutions, a firm of ecology consultants based in Australia. Professional services. Scientific assessment and reporting work.

His problem wasn't quite the same as Luke's. It was a quality and compliance problem.

When you've got multiple consultants in the field doing ecological assessments, the methodology matters. One consultant might collect data slightly differently from another. Reports might use different formats. Compliance requirements might get interpreted inconsistently. In a science-based consultancy, that inconsistency becomes a real risk. Errors in reporting can damage client relationships, trigger regulatory issues, and undermine the firm's credibility.

Gary's solution was to document the methodology. Every service type got its own system. Data collection procedures. Report templates. Compliance checks. Quality review steps.

The outcomes? New consultants can be onboarded and trained far more efficiently, because the "Ecosystem Solutions way" is written down, not trapped in senior people's heads. Project management is streamlined. The risk of errors in compliance and reporting has dropped significantly.

Gary didn't solve his problems by hiring more senior people. He solved them by documenting the methodology so ordinary people could produce consistent, high-quality work.

Two different businesses. Construction and consulting. Same pattern. Find the problem. Trace it to the missing system. Build the system. Move on.

systemHUB platform — the place to build, store, and share every system that solves your recurring business problems
systemHUB: one place to store the systems that stop your problems from recurring.

The bottom line

Every problem you keep fixing is a system you haven't built yet.

You don't have a problem problem. You have a systems problem. The fires aren't random. They're predictable. And predictable problems can be designed out of existence.

Document the issue specifically. Run the 5 Whys. Find the missing system. Build it. Assign an owner. Measure recurrence.

That's how you stop fighting fires and start building a business that doesn't keep lighting itself on fire.

Start with one recurring problem this week. Pick the one that's costing you the most time or sanity. Run the five steps. Build the system. See what happens next month when that problem doesn't show up.

Simple beats perfect. Always.

Ready to start building the systems that prevent your recurring problems? systemHUB gives you one place to build, store, and share every system in your business. It comes loaded with 100+ templates to get you started. Try it free.