Fixing the incident is not the same as fixing the problem
Imagine the same operational problem appears four times. Each time, somebody jumps in. Customer rescued. Order corrected. Deadline recovered. Everyone moves on. It feels as though the problem was solved. But was it? You solved the incident.
The underlying cause may still be sitting there waiting for another opportunity. That is why some businesses feel permanently busy. They are extremely good at fixing incidents. They are not always as good at removing causes.
Repetition is information
One mistake may be a mistake. The same mistake four times is a pattern. Patterns deserve a different level of attention. Ask: What is common here? Is the same handover failing? Is knowledge missing? Is responsibility unclear? Is training inadequate? Is the process unnecessarily complicated?
Are two systems not talking to each other? Is a manager repeatedly not following through? Is everybody relying on one person? Recurring problems are not merely irritating. They are useful evidence about where the business is weak.
Stop Band-Aiding it
I use this expression a lot. Businesses become very good at putting Band-Aids over things. Temporary workaround. Manual check. Extra spreadsheet. Someone stays late. Manager steps in. Customer gets an apology. Crisis over. Then the Band-Aid becomes permanent. Five years later, somebody new asks:
“Why do we do it this way?”
And nobody really knows. Because the workaround gradually became the system. That is how complexity grows. So when you find another Band-Aid, ask: What would actually fix this?
Good leaders still put out fires
Let's be sensible. If there is a fire today, deal with it. Do not stand there philosophising about process improvement while the customer waits. Fix what needs fixing. But once the immediate problem is under control, come back. Ask: Why did this happen? Has it happened before? What made it possible? What needs to change? That second conversation is where management begins becoming leadership.
Leadership growth changes the question
One of the things I enjoy watching is people growing into leadership. Early on, they understandably say:
“I've got another problem. What do I do?”
Over time, something changes. They begin asking:
“Why does this keep happening?”
Then:
“What should we change so it doesn't keep happening?”
They stop only reacting to today's problem. They start designing tomorrow's organisation. That is a significant shift in thinking.
Look for the hole everyone walks around
I often use the image of a great big hole in the ground. Everybody knows it is there. Every day, people walk around it. They complain about it. Warn new employees about it. Develop ingenious routes around it. But nobody fills the hole. Why?
“Not my job.”
That attitude allows broken systems to survive indefinitely. A stronger culture says: Someone needs to care enough to start fixing this. That is the GAF'er mindset. Notice. Care. Act.
Be a GAF'er
A GAF'er is someone who gives a fuck. They don't have to personally fix everything. That would be ridiculous. But they notice when something matters. They raise it. They take appropriate responsibility.
They do not simply continue walking around the same organisational hole because their job description does not contain the words:
“Fix holes.”
That attitude matters enormously in system improvement. Because every process map in the world is useless if everybody accepts obvious dysfunction as normal.
Ask how many times this has happened
This is one of the simplest diagnostic questions. When something goes wrong, ask:
“Is this the first time?”
If yes, deal with it appropriately. If the answer is:
“Well... it happens quite a lot.”
Now you have a system conversation. How often? Where? Since when? Under what circumstances? What is the pattern? That question alone helps stop businesses treating recurring failures as unrelated events.
Don't rely on memory
Recurring problems are easy to minimise when nobody tracks them. Someone says:
“We seem to get quite a few of those.”
How many? Nobody knows. So capture useful evidence. Complaint type. Error. Delay. Rework. Missed deadline. Whatever matters. You are not trying to build a bureaucratic monster. You are trying to see whether an irritating anecdote is actually a pattern. Evidence makes patterns visible.
Ask what sits underneath the problem
Suppose orders keep shipping incorrectly. The obvious response may be:
“Warehouse needs to be more careful.”
Maybe. But look deeper. Is the order information accurate? Is the product labelled properly? Is there a picking process? Is training consistent? Are similar items easily confused? Does the system allow errors through? Are workloads creating rushed behaviour? Did something change recently? The first explanation is not always the root cause. Get curious.
Do not automatically create another procedure
System improvement does not mean every problem needs another policy. Sometimes the existing process is already clear. The problem is that nobody follows it. That is an execution issue. Sometimes the process is hopelessly complicated. Adding another step will make it worse.
Sometimes there is no process at all. Then yes, perhaps one needs creating. The question is: What is the simplest change that makes recurrence less likely? Not:
“What document can we write?”
Decide what good should look like
Before improving the system, define the desired outcome. What should happen instead? If you cannot describe what good looks like, it becomes very difficult to redesign the process towards it. For example: Orders should move from Sales to Operations with these pieces of information complete.
Customer complaints should have one owner and a response within this period. Every new employee should receive this training before doing the work alone. Important decisions should be captured somewhere accessible. Now you have something to design towards.
Clarify ownership
Recurring problems often live in gaps between people. Sales thinks Operations owns it. Operations thinks Sales owns it. Finance thinks the manager owns it. Manager thinks the employee owns it. Everybody has an explanation. Nobody has ownership. So ask: Who owns this process? Not who is to blame. Who is responsible for making sure the system works? Someone needs to see the whole thing.
Don't confuse process ownership with doing every task
The process owner does not necessarily perform every step. Their role may be to make sure: the process is clear; responsibilities are understood; problems are noticed; improvements happen; and the system continues to work. That is very different from personally carrying every task.
Fix the handover
Many recurring business problems happen between functions. Sales to Operations. Operations to Finance. Manager to employee. Office to field. One system to another. Each part works reasonably well on its own. The failure lives in the gap. So don't only inspect the departments. Inspect the handovers.
What information has to travel? Who sends it? Who receives it? How do they know it is complete? What happens when it isn't? Handover clarity removes an extraordinary amount of avoidable noise.
Capture knowledge before it disappears
Sometimes the recurring problem exists because the solution lives only in someone's head. Something unusual happens. Everyone waits for Fred. Fred knows the workaround. Problem solved. Six months later: same problem. Again Fred. That is not really a system. It is dependency.
If useful knowledge is repeatedly required, capture it. Train someone else. Make the organisation smarter, not merely more reliant on the person who remembers what to do.
Turn the fix into an action
A meeting can identify the pattern beautifully. Everyone agrees:
“Yes, we really need to fix that.”
Then nothing happens. So convert system improvement into an action. What are we changing? Who owns it? By when? What will completion look like? Then record it. Otherwise even the improvement conversation becomes another recurring pattern.
Check whether the fix worked
This part gets missed constantly. New process introduced. Problem solved? Maybe. How do you know? Come back. Did errors reduce? Did complaints change? Did the handover improve? Did people actually use the new process? Did you accidentally create a different problem? System improvement is a test. Make a change. Observe. Learn. Adjust.
Don't build a cathedral to solve a garden shed problem
Not every recurring issue needs a giant project. Sometimes the answer is remarkably small. A clearer field on a form. One agreed owner. A checklist. Better training. Removing a duplicate step. A weekly five-minute review. A decision rule. A simple template.
Start with the smallest sensible intervention. Business systems should reduce friction. Not create a new bureaucracy.
The system should survive ordinary people
A process that works only when your best employee is running it is not a particularly strong process. A useful system should help reasonably capable people produce a reasonably consistent result. That does not mean removing judgement. It means not requiring heroics for ordinary work. The business becomes calmer when normal performance does not depend on extraordinary individual effort.
Watch for workarounds becoming invisible
Long-serving people often stop noticing broken systems. They know the workaround so well that it feels normal. New employees can be very useful here. Listen when they ask:
“Why do we have to enter this twice?”
“Why does this go through three people?”
“Why do we print this and then type it back in?”
Sometimes there is a good reason. Sometimes there isn't. Familiarity can hide inefficiency.
Standardise what should be standard
As businesses grow, what once happened naturally has to happen deliberately. If five managers perform the same routine process five completely different ways, ask whether that variation is useful. Sometimes yes. Often no. Agree:
“This is how we generally do this around here.”
Then leave room for judgement where judgement is genuinely needed. Consistency removes avoidable reinvention.
Don't standardise thoughtlessly
Systems are there to help the business. Not to become sacred objects. If the process stops working, improve it. If conditions change, change it. If people find a better way, examine it. The goal is not blind compliance. It is reliable execution.
Use recurring problems as leadership-development opportunities
When a manager brings you the same issue again, do not only answer it. Ask:
“We've dealt with this before. Why is it back?”
Then:
“What do you think needs changing?”
“What system could reduce this?”
Now they have to think beyond the incident. That is how managers begin developing a systems mindset.
Look at whether your own leadership causes recurrence
Sometimes the process is fine. The leader keeps breaking it. An employee misses the deadline. Leader rescues. Someone ignores the agreed process. Leader makes an exception. Manager makes a decision. Leader overturns it. The system never gets the opportunity to become embedded. Ask:
“Am I undermining the very discipline I'm asking everyone else to follow?”
That can be uncomfortable. It can also be extremely useful.
A simple recurring-problem method
When the same issue appears again, try this:
1. Deal with today's problem
Protect the customer, employee or business where necessary.
2. Ask whether it has happened before
Do not rely on vague memory.
3. Find the pattern
Where, when and how often?
4. Identify the likely cause
What makes this possible?
5. Define what good looks like
What should happen instead?
6. Design the simplest useful change
Process, responsibility, training, information, authority or system.
7. Give the improvement one owner
Someone must carry it.
8. Set a date
By when?
9. Test the change
Use it.
10. Review the evidence
Did recurrence reduce? If not, learn and change again. That is how you move from recurring firefighting towards continuous improvement.
Ask the question that changes the conversation
The next time somebody says:
“We've got this problem again.”
don't only ask:
“How do we fix it?”
Ask:
“How many times have we fixed this already?”
If the answer is three or four, you probably have your clue. Maybe it is time to stop Band-Aiding it. Maybe it is time to stop walking around the hole. Maybe it is time to build the system that makes the same problem far less likely to return.
Because mature leadership is not simply getting better at fighting fires. It is quietly building a business in which fewer of the same fires keep starting.