There’s a Hole in My Bucket
If you’ve never heard the children’s song “There’s a Hole in My Bucket,” the premise is pretty simple.
There’s a hole in Henry’s bucket.
“So fix it, dear Henry,” Liza tells him, suggesting some straw.
The straw is too long. Cut it.
The knife is too dull. Sharpen it.
With what? A stone.
The stone is too dry. Wet it.
With what? Water.
How do you carry the water? In the bucket.
“But there’s a hole in my bucket, dear Liza, a hole!”
And here we are.
How many times do we solve problems in our organizations exactly like Henry and Liza?
We encounter an obstacle and figure out how to get around it. Something about the workaround creates another problem, so we solve that one too. Then we solve the next one.
Every individual decision makes sense.
And somewhere along the way, we forget there is still a hole in the bucket.
Is there actually a problem?
In Henry’s case, he actually has a problem. But before we start solving things in our organizations, it’s worth asking whether the thing bothering us is actually broken.
Sometimes it is. A process takes too long. People are duplicating work. A system can no longer support what we need it to do.
But sometimes the thing bothering us is simply inconvenient.
Passwords are inconvenient. Approval processes can be inconvenient. Requiring someone else to review something before it goes out can definitely be inconvenient.
Maybe those steps are unnecessary friction. Or maybe the friction is doing a necessary job — protecting information, creating accountability or making sure someone is looking at the whole rather than just one piece.
This is where “efficiency” can get us into trouble.
Removing steps certainly looks more efficient. And sometimes it is. But if the step we eliminate was managing a risk, preventing an error or coordinating work happening somewhere else, we may have solved the visible inconvenience by creating a new problem we can’t see yet.
Efficiency isn't "How do I get Henry to stop complaining about the bucket?" Making something easier is a worthwhile goal, but a solution doesn't become a good solution simply because it makes the complaint go away.
Sometimes the right conclusion is that the inconvenience is worth living with. Sometimes there’s a better solution than the one that seems easiest to the person experiencing it.
That’s not an excuse to tolerate bad processes. It’s a reason to understand what the process is doing – and what it’s supposed to do – before we start removing pieces of it.
So before asking how to fix something, start with a more basic question: What, exactly, isn't working?
A workaround is not a solution
Of course, sometimes we need the straw.
Workarounds keep organizations moving. They’re often evidence of people being creative and resourceful with the tools and resources they have.
The problem is that a good workaround makes it easy to forget that we worked around something. The immediate pain disappears. Everyone gets back to work. There’s another fire demanding our attention, and the temporary solution quietly becomes “how we do it.”
Until something else doesn’t work with the workaround. So we build another one. Eventually we find ourselves maintaining an elaborate collection of solutions to problems we never actually solved.
Getting something working again is not necessarily the same as fixing it. Once the immediate fire is out, we still need to ask what the workaround got us through — and what we need to come back and solve.
Zoom out before you solve the next thing
Even when we turn our attention back to the underlying problem, it’s easy to keep our focus too narrow.
The problem in front of us may only be where a larger issue became visible. What looks like a staffing problem might really be a process problem. Frustrations that seem unrelated may trace back to the same underlying gap. That changes the business case.
Instead of investing in something because it fixes the pain point that finally got our attention, look at what else touches it. Who else depends on it? What happens downstream if we change it? Sometimes when we zoom out, we discover we’ve been solving the same problem in five different places.
Zooming out means looking forward, too. We can’t predict everything our organizations will need three or five years from now. But uncertainty about the future doesn’t mean we know nothing about it. We usually know something about where we hope to grow, what we’re considering doing next or which processes are already starting to strain. We can consider those possibilities without designing for every hypothetical future.
The goal isn’t to predict everything. It’s to avoid building a permanent solution around only the snapshot we happen to be looking at today — and then immediately having to design the next workaround.
Remember the bucket
None of this means eliminating every workaround or turning every operational decision into a six-month strategic planning exercise.
Sometimes there’s a hole in the bucket and we need water. We don't have time to redesign the entire water-delivery system.
So patch the bucket. Borrow one. Buy a new one. Do what you need to do to get the water.
But once you have it, don't immediately move on to the next thing. Go back and look at the bucket. Maybe it was just an old bucket that finally gave out. Maybe Henry needs better repair supplies. Maybe there are termites where he’s storing the buckets. Maybe he should just stop using wooden buckets altogether.
The point isn't to turn every hole in a bucket into a strategic planning exercise. It's to know when you've solved the immediate need and when you still have something worth understanding.
Every once in a while, look at all the solutions you’ve accumulated and ask whether they’re actually getting you where you wanted to go.
Because we can spend an awful lot of time sharpening the knife, wetting the stone and finding the straw.
And forget that what we actually needed was water.






Comments