You know, at some point, fixing the same problem repeatedly stops being good management and becomes evidence that the business perhaps needs a better system. Every business has problems. Customers will complain, someone misses a handover, a report is wrong, an order gets delayed, a process breaks, something fails between two people.
Fine. Problems happen. But if you keep solving the same problem over and over again, eventually the question has to change. Not how do we fix this, but how do we stop this happening again? That's a completely different way of thinking. Fixing that one incident is not the same as fixing the problem Imagine the same operational problem appears four times.
Each time somebody jumps in, customer is rescued, order corrected, deadline recovered, everyone moves on. It'll feel as though the problem was solved. But was it? You solved the incident, but the underlying cause may be sitting there still, waiting for another opportunity. That's why some businesses feel permanently busy.
They're extremely good at fixing incidents, but they're not always good at removing causes. Repetition is information. One mistake may be a mistake. The same mistake four times is a pattern, and patterns deserve a different level of attention. So I'd love people to ask, "What is common here? Is the same handover failing?
Is knowledge missing? Is responsibility unclear? 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're useful evidence as to where the business is weak. You know, in my work as a business coach, I use the expression band-aiding a lot.
Businesses become very good at putting band-aids over things, temporary workarounds. A manual check, an extra spreadsheet, someone will stay back late. A manager will step in. A customer will get 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 has gradually become the system. That's how complexity grows. So when you find another Band-Aid, it would be good to ask, "What would actually fix this?"
Good leaders still put out fires. If there is a fire today, of course, deal with it. Don't stand there philosophizing about process improvement while the customer waits. Fix what needs fixing. But once the immediate problem is under control, you really should come back and ask, "Why did this happen? Has it happened before?
What made it possible? What needs to change?" This second conversation is where management begins to become leadership. 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?" And then, "What should we change so it doesn't keep happening?" They stop just reacting to today's problem, and they start designing tomorrow's business, and that's a significant change. It's a significant shift in thinking.
I often use the image of a big hole, a great big hole in the ground. Everybody knows it's there. Every day, people walk around it. They even complain about it. They warn new employees about it. Did they develop ingenious routes around it? But nobody fills the hole. Why? It's 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's the GAF'er mindset. Notice, care, act. A GAF'er is someone who gives a f*ck. 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 don't simply continue walking around the same business hole because their job description does not contain the words fix holes. That attitude matters enormously for system improvement because every process map in the world is useless if everybody accepts obvious dysfunction as normal. One of the simplest diagnostic questions when something goes wrong is, "Is this the first time?"
If it's yes, deal with it appropriately. If the answer is, "Well, it does happen quite a lot," now you should have a system conversation. How often? Where? Since when? Under what circumstances? And what is the pattern? That last question alone helps stop businesses treating recurring failures as unrelated events. And don't rely on memory.
Recurring problems are easy to minimize when nobody tracks them. Somebody says, "We seem to get quite a few of those. Let's record how many," because nobody knows usually. Capture this as useful evidence. Document the complaint type, the error type, the delay, the rework number, whatever it is that matters. You're not trying to build a bureaucratic monster. You're trying to see whether an irritating anecdote is actually a pattern. Evidence makes patterns visible. Then ask what sits underneath the problem. Suppose orders keep shipping incorrectly.
The obvious response may be, "Warehouse needs to be more careful." Well, maybe, but look deeper. Is the order information accurate? Is the product labeled properly? Is there a picking process that needs improving? Or is training inconsistent? Are similar items easily confused? Did something change recently? The first explanation is oftentimes not always the root cause. You need to get curious. And don't automatically create another procedure. System improvement does not mean every problem needs another policy or another procedure.
Sometimes the existing process is already clear. The problem oftentimes is that nobody follows the system, and that's an execution issue. Sometimes the process is hopelessly complicated. Adding another step will just make it worse.
Sometimes there's no process at all, and then, yes, perhaps one needs creating. The useful question is, what is the simplest change that makes recurrence less likely? Not what document can we write. Before improving the system, define the desired outcome. What should happen instead? If you can't describe what good looks like, it's very difficult to redesign the process towards it. Orders should move from sales to operations with the required information fully complete.
Customer complaints should really have one owner and a response within an agreed period. Every new employee should receive the right training before being asked to do the work on their own. Important decisions should be captured somewhere central and accessible. Now you have something to design towards. Recurring problems often live in gaps between people.
Sales will often think operations should own that. Operations will often think sales should own that. Finance will think the manager should own it, and the manager thinks the employees should own it. Everybody can have an explanation, but nobody has ownership. So ask, "Who should own
this process?" Not who's to blame, but who should be responsible for making sure that this system works. Someone needs to see the whole thing. Process ownership does not mean personally doing every task. It may mean making sure the process is owned, it's clear, the responsibilities are understood, the problems are noticed, improvements happen, and the system continues to work.
That's a very different proposition from personally carrying every task. Many recurring business problems happen between functions. The gap between sales to operations, operations to finance, manager to employee, office to field, one system to another. Each part works reasonably well on its own, but the failure lives in the gap.
So don't just inspect the departments, inspect the handovers. What information needs to travel? Who sends it? Who receives it? How do they know it's complete? What happens when it's not? Handover clarity removes an extraordinary amount of avoidable noise Sometimes the recurring problem exists because the solution lives only in someone's head.
Something unusual happens in those circumstances. Everyone waits for Fred. Fred knows the workaround. Problem solved. Six months later, same problem. Again, let's ask Fred. That's not a system, it's a dependency. If useful knowledge is repeatedly required, capture it. Train someone else on what Fred knows, and make the business smarter by having it centralized.
Let's not merely rely on that person more and more. We can't just have one person who remembers what to do. A meeting can identify a pattern beautifully. Everyone can agree in the meeting, yes, we really do need to fix that. But oftentimes after a meeting, nothing much happens. So we have to turn the fix into an action.
What are we changing and who owns it by when? And what will completion look like? And then record it. Otherwise, that important conversation becomes another recurring pattern. We have to check whether the fix worked, and this is the part that gets missed so often. New process introduced, problem solved, maybe.
But how do you know? Come back and check. Did errors reduce? Did complaints change? Did the handover improve? Do people actually use the new process? Or did we accidentally create a different problem? System improvement is a test. Make a change, observe, learn, adjust. But 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 or a field that is non-negotiable, the form cannot close without that one field being filled out. One agreed owner, a checklist, better training, removal of a duplicate step, a weekly five-minute review, a decision rule, a simple template.
Oftentimes you just start with the simplest and the smallest sensible intervention. Business systems should reduce friction, not create new bureaucracy. A process that works only when your best employee is running it is not a strong process. A useful system should help reasonably capable people produce reasonably consistent results.
That does not mean removing judgment. It means removing heroics for ordinary work. The business will become calmer and stronger when normal performance does not depend on extraordinary individual effort. Watch for workarounds becoming invisible. Long-serving people often stop us noticing a broken system because they know the workaround so well that it feels normal.
New employees can be very useful here. Listen when they ask, "How do I do that thing?" Or, "Why am I entering this thing twice?" Or, "Why does this go through two people's hands? Why do we print it and then type it out again?" Sometimes there is a good reason, but sometimes there's not. Familiarity can hide inefficiency.
As a business grows, what once happened naturally now has to happen deliberately. If five managers perform the same routine process five completely different ways, you have to start asking whether that variation is useful. Sometimes it's okay. Sometimes it's a preference. But oftentimes it's not a very useful variation.
So what we need to do is agree this is how we generally do this around here, and leave a little bit of room for judgment where judgment is genuinely needed. Consistency removes the avoidable reinvention. But don't standardize thoughtlessly. Standards are there to help the business, not become sacred objects.
If the process stops working, improve it. If conditions change, change it. If people can find a better way, examine it. The goal is not blind compliance, it's reliable execution. Recurring problems are excellent management development opportunities. When a manager brings you the same issue again, don't just answer the issue.
Ask, "We've dealt with this before. Why has that come back? What needs changing? What do we think is causing this? What system could reduce it?" Now, it's about thinking beyond that one incident. And that is how managers begin to develop a systems mindset. Sometimes the process is fine, but the leader is the one that keeps breaking it.
An employee misses the deadline, or the rescue is happening from the leader or the manager. Someone is ignoring the agreed process. Someone is making an exception, or we're overturning it. The system may never get the opportunity to become embedded. So you have to ask, "Am I undermining the system? Am I undermining the very discipline that I'm asking everybody else to follow?"
And that can be uncomfortable. But it also can be extremely useful. So when the same issue appears again, use a simple method. Deal with today's problem, and then look beyond the problem. Ask whether it happened before. Don't rely on vague memory. Try to find the pattern. Where, when, how often?
And then identify the likely cause. What is making this possible? And then define what good looks like. What should happen instead? And then design the simplest useful change, whether it's process, responsibility, training, information, systems. And give the improvement into one person's hands. Someone must carry it by a date, by when, and then test the change.
Use it for a while. Review the evidence. Does it work? Does the recurring pattern reduce? If not, learn and change again. That's how you move from continuous firefighting towards continuous improvement. The next time somebody says, "We've got that problem again," don't just fix it. Ask, "How many times have we fixed this already?"
If it's three or four, you probably have your clue. It's time to stop Band-Aiding it. It's time to stop walking around the hole. It's time to build a system that makes that same problem far less likely to return because mature management is not simply getting better at fighting fires, it's quietly building a business in which fewer of the same fires keep starting
Fine. Problems happen. But if you keep solving the same problem over and over again, eventually the question has to change. Not how do we fix this, but how do we stop this happening again? That's a completely different way of thinking. Fixing that one incident is not the same as fixing the problem Imagine the same operational problem appears four times.
Each time somebody jumps in, customer is rescued, order corrected, deadline recovered, everyone moves on. It'll feel as though the problem was solved. But was it? You solved the incident, but the underlying cause may be sitting there still, waiting for another opportunity. That's why some businesses feel permanently busy.
They're extremely good at fixing incidents, but they're not always good at removing causes. Repetition is information. One mistake may be a mistake. The same mistake four times is a pattern, and patterns deserve a different level of attention. So I'd love people to ask, "What is common here? Is the same handover failing?
Is knowledge missing? Is responsibility unclear? 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're useful evidence as to where the business is weak. You know, in my work as a business coach, I use the expression band-aiding a lot.
Businesses become very good at putting band-aids over things, temporary workarounds. A manual check, an extra spreadsheet, someone will stay back late. A manager will step in. A customer will get 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 has gradually become the system. That's how complexity grows. So when you find another Band-Aid, it would be good to ask, "What would actually fix this?"
Good leaders still put out fires. If there is a fire today, of course, deal with it. Don't stand there philosophizing about process improvement while the customer waits. Fix what needs fixing. But once the immediate problem is under control, you really should come back and ask, "Why did this happen? Has it happened before?
What made it possible? What needs to change?" This second conversation is where management begins to become leadership. 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?" And then, "What should we change so it doesn't keep happening?" They stop just reacting to today's problem, and they start designing tomorrow's business, and that's a significant change. It's a significant shift in thinking.
I often use the image of a big hole, a great big hole in the ground. Everybody knows it's there. Every day, people walk around it. They even complain about it. They warn new employees about it. Did they develop ingenious routes around it? But nobody fills the hole. Why? It's 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's the GAF'er mindset. Notice, care, act. A GAF'er is someone who gives a f*ck. 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 don't simply continue walking around the same business hole because their job description does not contain the words fix holes. That attitude matters enormously for system improvement because every process map in the world is useless if everybody accepts obvious dysfunction as normal. One of the simplest diagnostic questions when something goes wrong is, "Is this the first time?"
If it's yes, deal with it appropriately. If the answer is, "Well, it does happen quite a lot," now you should have a system conversation. How often? Where? Since when? Under what circumstances? And what is the pattern? That last question alone helps stop businesses treating recurring failures as unrelated events. And don't rely on memory.
Recurring problems are easy to minimize when nobody tracks them. Somebody says, "We seem to get quite a few of those. Let's record how many," because nobody knows usually. Capture this as useful evidence. Document the complaint type, the error type, the delay, the rework number, whatever it is that matters. You're not trying to build a bureaucratic monster. You're trying to see whether an irritating anecdote is actually a pattern. Evidence makes patterns visible. Then ask what sits underneath the problem. Suppose orders keep shipping incorrectly.
The obvious response may be, "Warehouse needs to be more careful." Well, maybe, but look deeper. Is the order information accurate? Is the product labeled properly? Is there a picking process that needs improving? Or is training inconsistent? Are similar items easily confused? Did something change recently? The first explanation is oftentimes not always the root cause. You need to get curious. And don't automatically create another procedure. System improvement does not mean every problem needs another policy or another procedure.
Sometimes the existing process is already clear. The problem oftentimes is that nobody follows the system, and that's an execution issue. Sometimes the process is hopelessly complicated. Adding another step will just make it worse.
Sometimes there's no process at all, and then, yes, perhaps one needs creating. The useful question is, what is the simplest change that makes recurrence less likely? Not what document can we write. Before improving the system, define the desired outcome. What should happen instead? If you can't describe what good looks like, it's very difficult to redesign the process towards it. Orders should move from sales to operations with the required information fully complete.
Customer complaints should really have one owner and a response within an agreed period. Every new employee should receive the right training before being asked to do the work on their own. Important decisions should be captured somewhere central and accessible. Now you have something to design towards. Recurring problems often live in gaps between people.
Sales will often think operations should own that. Operations will often think sales should own that. Finance will think the manager should own it, and the manager thinks the employees should own it. Everybody can have an explanation, but nobody has ownership. So ask, "Who should own
this process?" Not who's to blame, but who should be responsible for making sure that this system works. Someone needs to see the whole thing. Process ownership does not mean personally doing every task. It may mean making sure the process is owned, it's clear, the responsibilities are understood, the problems are noticed, improvements happen, and the system continues to work.
That's a very different proposition from personally carrying every task. Many recurring business problems happen between functions. The gap between sales to operations, operations to finance, manager to employee, office to field, one system to another. Each part works reasonably well on its own, but the failure lives in the gap.
So don't just inspect the departments, inspect the handovers. What information needs to travel? Who sends it? Who receives it? How do they know it's complete? What happens when it's not? Handover clarity removes an extraordinary amount of avoidable noise Sometimes the recurring problem exists because the solution lives only in someone's head.
Something unusual happens in those circumstances. Everyone waits for Fred. Fred knows the workaround. Problem solved. Six months later, same problem. Again, let's ask Fred. That's not a system, it's a dependency. If useful knowledge is repeatedly required, capture it. Train someone else on what Fred knows, and make the business smarter by having it centralized.
Let's not merely rely on that person more and more. We can't just have one person who remembers what to do. A meeting can identify a pattern beautifully. Everyone can agree in the meeting, yes, we really do need to fix that. But oftentimes after a meeting, nothing much happens. So we have to turn the fix into an action.
What are we changing and who owns it by when? And what will completion look like? And then record it. Otherwise, that important conversation becomes another recurring pattern. We have to check whether the fix worked, and this is the part that gets missed so often. New process introduced, problem solved, maybe.
But how do you know? Come back and check. Did errors reduce? Did complaints change? Did the handover improve? Do people actually use the new process? Or did we accidentally create a different problem? System improvement is a test. Make a change, observe, learn, adjust. But 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 or a field that is non-negotiable, the form cannot close without that one field being filled out. One agreed owner, a checklist, better training, removal of a duplicate step, a weekly five-minute review, a decision rule, a simple template.
Oftentimes you just start with the simplest and the smallest sensible intervention. Business systems should reduce friction, not create new bureaucracy. A process that works only when your best employee is running it is not a strong process. A useful system should help reasonably capable people produce reasonably consistent results.
That does not mean removing judgment. It means removing heroics for ordinary work. The business will become calmer and stronger when normal performance does not depend on extraordinary individual effort. Watch for workarounds becoming invisible. Long-serving people often stop us noticing a broken system because they know the workaround so well that it feels normal.
New employees can be very useful here. Listen when they ask, "How do I do that thing?" Or, "Why am I entering this thing twice?" Or, "Why does this go through two people's hands? Why do we print it and then type it out again?" Sometimes there is a good reason, but sometimes there's not. Familiarity can hide inefficiency.
As a business grows, what once happened naturally now has to happen deliberately. If five managers perform the same routine process five completely different ways, you have to start asking whether that variation is useful. Sometimes it's okay. Sometimes it's a preference. But oftentimes it's not a very useful variation.
So what we need to do is agree this is how we generally do this around here, and leave a little bit of room for judgment where judgment is genuinely needed. Consistency removes the avoidable reinvention. But don't standardize thoughtlessly. Standards are there to help the business, not become sacred objects.
If the process stops working, improve it. If conditions change, change it. If people can find a better way, examine it. The goal is not blind compliance, it's reliable execution. Recurring problems are excellent management development opportunities. When a manager brings you the same issue again, don't just answer the issue.
Ask, "We've dealt with this before. Why has that come back? What needs changing? What do we think is causing this? What system could reduce it?" Now, it's about thinking beyond that one incident. And that is how managers begin to develop a systems mindset. Sometimes the process is fine, but the leader is the one that keeps breaking it.
An employee misses the deadline, or the rescue is happening from the leader or the manager. Someone is ignoring the agreed process. Someone is making an exception, or we're overturning it. The system may never get the opportunity to become embedded. So you have to ask, "Am I undermining the system? Am I undermining the very discipline that I'm asking everybody else to follow?"
And that can be uncomfortable. But it also can be extremely useful. So when the same issue appears again, use a simple method. Deal with today's problem, and then look beyond the problem. Ask whether it happened before. Don't rely on vague memory. Try to find the pattern. Where, when, how often?
And then identify the likely cause. What is making this possible? And then define what good looks like. What should happen instead? And then design the simplest useful change, whether it's process, responsibility, training, information, systems. And give the improvement into one person's hands. Someone must carry it by a date, by when, and then test the change.
Use it for a while. Review the evidence. Does it work? Does the recurring pattern reduce? If not, learn and change again. That's how you move from continuous firefighting towards continuous improvement. The next time somebody says, "We've got that problem again," don't just fix it. Ask, "How many times have we fixed this already?"
If it's three or four, you probably have your clue. It's time to stop Band-Aiding it. It's time to stop walking around the hole. It's time to build a system that makes that same problem far less likely to return because mature management is not simply getting better at fighting fires, it's quietly building a business in which fewer of the same fires keep starting
