The process of solving problems and the process of creating solutions aren’t exactly the same. They’re adjacent and related, but there’s a time and a place for both. If you mix them up, you’re often making things worse for yourself.
Consider a burning building. While the building is on fire, that’s the wrong time to think about designing and installing a sprinkler system. It’s the wrong time to research pricing for flame-retardant carpeting. If a building is on fire right now, you should put the fire out – even if you have to do so in a less-than-perfectly-efficient way.
This is true even (and especially!) of smaller problems. If you respond to every problem by going to the drawing board for a system-wide solution, you’ll be spending far too much juice on every issue. You’ll also be making a lot of snap decisions when you often should do nothing at all, besides just address the current scenario as-is.
Instead, you should have a set schedule for visiting larger, systemic issues within any system. If you run a business, problems are going to come up all the time. Each one will seem like a major emergency. Most won’t be, and very few will actually require designing an entirely new system to handle.
When a problem occurs, solve it and track it. If a light burns out, replace the bulb, and note that you did so; don’t install a whole new lighting system. Every quarter, review your notes on the problems. If a bunch of bulbs burned out, then sure – take a look at a deeper issue. If it was the one time, you’re fine buying a new bulb now and then.
Taking this approach also lets you deploy those solutions in a reasonable way. If you’re running around in a panic all the time, those solutions aren’t going to be implemented well. They won’t be communicated well, either. If you only create new systems at regular intervals, you build for stability in the long term.
The Opportunity Machine 