Firefighting can make a business look productive while leaving its systems, authority and training unchanged. Track recurring problems, fix root causes, turn solutions into standards and push ownership down so the company learns to have fewer fires.
Newsletter #13
Start Removing Fires.
Each week, I share practical ways to improve profit, control, time and enjoyment in your business, without making every decision depend on you.
This week: five ways to remove recurring problems, three leadership mistakes that make them worse, and seven actions to take immediately.
I worked with a founder who had built a good business.
Good customers. Good people. Healthy margins. Real opportunity.
There was only one issue.
He could not leave the business alone for more than a couple of hours.
A customer complained? Call the founder.
A supplier was late? Call the founder.
A discount needed approval? Call the founder.
A machine stopped? Call the founder.
Someone could not find a delivery docket? That somehow needed the founder too.
He had become the company’s emergency service: CEO, Chief Fire Officer and, on occasion, the lost-property department.
The problem was not that he was incapable. He was extremely capable.
He was so good at fixing problems that everyone had learned the same lesson:
Do not solve it. Escalate it.
Each rescue made the next escalation more likely.
Over time, the company developed a very simple operating system:
When in doubt, ask the boss.
He thought he had a leadership team. What he actually had was a queue.
And the queue ended at his desk.
The turning point came when we stopped asking, “How do we solve today’s problem?” and started asking:
“Why does this problem keep reaching you?”
That question changes everything.
A problem solved once is work. A problem solved twice is a warning. A problem solved every week is a system failure.
What Next
The unofficial org chart in too many founder-led businesses.
Firefighting feels like progress.
Something goes wrong. Phones ring. People move quickly. Meetings are called. The owner gets involved. A decision is made. The immediate issue disappears.
Everyone feels that something important has been achieved.
Often, all that has happened is that the business has been restored to where it should have been in the first place.
The customer is appeased. The late order is recovered. The stock count is corrected. The approval is given.
But the process has not changed. Authority has not changed. Training has not changed. The system has not changed.
The problem has simply gone quiet, until the next time.
This is how businesses become excellent at reacting and poor at learning. The people who solve emergencies become indispensable. It can feel like strength.
It is usually dependency in disguise.
If your company only works because a small number of people know how to rescue it, then you have not built capability.
You have built reliance.
How do i change this lightbulb?
The escalation system: even the smallest decision finds its way to the top.
Most companies track sales, profit, cash, labour and productivity.
Very few track how often the same operational problems come back.
Start doing it.
Create a recurring-problem register. Keep it simple. Every time a significant issue occurs, record the following.
| Record | Why it matters |
|---|---|
| What happened | It separates the facts from the story around them. |
| Where and when it happened | It exposes patterns by team, process or time period. |
| What it cost | It makes the true impact visible. |
| Who fixed it | It shows where dependency is sitting. |
| Whether it has happened before | It identifies repetition early. |
| What changed afterwards | It tests whether the response was permanent. |
Within a few weeks, the pattern usually becomes obvious.
The same delivery issue. The same stock discrepancy. The same pricing mistake. The same overtime problem. The same customer complaint. The same manager escalating the same decision.
What appears to be 30 separate problems may really be five failures repeating in different forms.
That is where the opportunity lies.
When something goes wrong, the natural response is:
“How do we fix this?”
A better question is:
“Why was this able to happen?”
The distinction matters.
Replacing a wrong customer order fixes the customer issue. It does not necessarily fix the process that produced the wrong order.
Recounting missing stock corrects the number. It does not explain why the stock went missing.
Giving a manager an approval solves today’s decision. It does not solve the lack of authority that caused the escalation.
Use the Five Whys. Keep asking why until you reach the condition that allowed the problem to occur.
| Question | Example answer |
|---|---|
| Why was the customer order late? | Production finished late. |
| Why did production finish late? | A required component did not arrive. |
| Why did it not arrive? | Purchasing placed the order late. |
| Why was it placed late? | Nobody knew stock had fallen below the required level. |
| Why did nobody know? | There was no reorder trigger. |
Now you have something worth fixing.
The late order was the symptom. The missing reorder trigger was the system failure.
This is where businesses often waste experience.
Someone solves a difficult problem brilliantly. Everybody is relieved. Then the business moves on.
Six months later, the same issue reappears and the team starts from scratch.
That is expensive.
Each time you solve an important problem, ask:
“What should become standard because we have learned this?”
It might become a checklist, a standard operating procedure, a system rule, a training module, a pricing rule, an approval limit, an automated alert, a dashboard measure, a supplier standard or a customer-service process.
The goal is simple:
Do not pay twice to learn the same lesson.
A business improves when knowledge moves out of individual heads and into the way the business operates.
Chief firefighter
Rewarding the same rescue is not the same as fixing the cause.
One of the main causes of recurring problems is that the wrong person keeps solving them.
In founder-led businesses, that person is often the owner.
A manager has a problem. They call the owner. The owner gives the answer. The problem is resolved, for now.
Soon, the organisation learns something dangerous:
When in doubt, escalate.
The manager does not become more capable. The founder becomes more overloaded. The business becomes more dependent.
Instead, ask:
“Who should be capable of solving this without me?”
Then give that person what they need to own the result.
| Requirement | What it means |
|---|---|
| Clear authority | They know which decisions are theirs to make. |
| The right information | They can see the facts required to decide well. |
| Defined limits | They know exactly when escalation is still necessary. |
| Accountability | They own the result, not simply the task. |
Sometimes the most useful thing a leader can do is refuse to solve a problem that somebody else should own.
Not because the problem does not matter.
Because capability matters more.
Most management teams measure actions.
Problem identified. Action assigned. Action completed. Green. Done.
Not necessarily.
The real question is:
“Did the problem come back?”
A completed action is not the same as an effective action.
If the same issue reappears 30 days later, then the root cause was not removed.
When you address a recurring problem, set review dates for 30, 60 and 90 days. Then ask:
If not, reopen it.
The objective is not to close actions.
The objective is to remove problems.
Founder delegation, advanced level.
The person who saves the day gets noticed.
The person who quietly builds a system that prevents the crisis may not.
That creates the wrong behaviour.
Imagine two managers. Manager A has ten crises and solves all ten brilliantly. Manager B builds strong processes and has only two crises.
Who is doing the better job?
Too often, Manager A gets the praise.
Strong companies value prevention as much as problem solving.
“This customer is different.”
“This project was unusual.”
“That supplier let us down.”
“That week was exceptional.”
Sometimes those explanations are true. But if different explanations repeatedly produce the same outcome, look deeper.
Recurring problems often wear different clothes.
Late delivery. Overtime. Low margin. Customer complaints. Credit notes. Rework.
They may all come from one root cause: poor planning, unclear ownership, bad data, weak processes, insufficient capacity planning or a lack of authority.
Do not let every symptom convince you it is a new disease.
Something goes wrong on Monday. By Wednesday it is fixed. By Friday, nobody is thinking about it.
Nothing gets documented. Nothing gets changed. Nobody checks whether it can happen again.
That is how organisations build recurring problems into normal operations.
Every meaningful problem should end with one final question:
“What must change so that we do not have to solve this again?”
That question alone can transform how a company operates.
Do not start with new problems. Start with the old ones, the issues that keep appearing in meetings, emails and phone calls.
Think beyond cash. Include management time, lost sales, wasted stock, rework, refunds, discounts, customer frustration and employee frustration.
Recurring problems are usually far more expensive than they first appear.
Do not try to fix everything at once. Choose one issue with a material cost or repeated escalation.
Do not stop at, “Someone made a mistake.” Ask why the mistake was possible, why it was not detected, why the system relied on memory or why responsibility was unclear.
Change a process, a rule, a system, a checklist, a training requirement, an authority limit or a reporting measure.
Do not simply tell people to “be more careful”.
That is not a system.
One name.
Not “Operations”. Not “Finance”. Not “the management team”.
One person owns making sure the problem stays fixed.
Did it happen again?
If it did, keep digging. If it did not, you have genuinely improved the business.
Then move to the next issue.
The goal is not to run faster towards the fire. It is to stop lighting the same one.
Madness
Every business has problems. That is normal.
Growth creates new problems. Customers create new problems. People create new problems. Markets create new problems.
The goal is not to build a company where nothing ever goes wrong.
The goal is to build a company that learns.
A company where every meaningful problem leaves the organisation slightly better than it found it:
The real danger is not having problems.
The real danger is paying to solve the same problem again and again.
Great companies do not become brilliant at firefighting.
They become brilliant at having fewer fires.
So this week, do not ask your management team:
“What problems did we solve?”
Ask them:
“What problem have we made sure we never have to solve again?”
That is how chaos becomes control.
And that is how you build a business that can grow without everything eventually landing back on you.
Put This Into Practice
The CEO Scorecard gives you a clear view of the constraints affecting profit, cash, the team and your time.
Continue Reading
Back to all articles