NASA optimizes for performance. We optimize for cost. They pay five times the cost for the last 5 percent of performance.
- Tom Mueller, Vice President of Propulsion, SpaceX
Everything should be made as simple as possible, but no simpler.
- Albert Einstein
Anybody interested in improving personal or group performance struggles constantly between “Get it Done” and “Get it Perfect”. We want to do our best, and to be proud of the work we do. We also want to get things accomplished and move on to the next important thing.
We make this compromise in two distinct ways. First and most obviously, we do our best up to a point, declare the work “good enough” and then move on. The other way we create “good enough” solutions is to ask a different question, reframe it as a simpler problem and solve that with a simpler solution.
Most of the time, these are good compromises to make, but many times — too often, in fact — they create bigger problems than they solve and can cause a cascade of disasters.
Half-assed is worse than lazy
People at the supermarket who don’t put their shopping carts back annoy me. They make parking spots unusable and make parking lots difficult to navigate for everyone else. One supermarket where I used to shop was on a main highway, and carts would roll out of the parking lots and into oncoming traffic! People create this disorder and mayhem to save themselves about twenty or thirty feet of walking. Seriously, how much lazier can a person be?
But in their laziness, these people have spawned a second solution. Supermarkets hire people to scour the parking lot for carts, gather them together and wheel them back in front of the store. There are downsides. Prices are higher because the market has at least one more salary to pay. Parking lots are still littered with stray carts, but that can be managed to the point of a low-level annoyance that most people don’t even notice anymore. In short, it’s an ugly solution but for the most part it works (even if it does cause a bit of resentment from people who put their carts back themselves).
If we have two working solutions, then why is there a problem?
There is a third group of shoppers who are the actual cause of the shopping cart madness. They push their carts over to the holding stall like group one. But instead of stacking the carts together, they fling them from about six feet away and make a group two style mess inside the holding stall (see pic above).
By committing half-way, they make the holding stall unusable, not only for group one, but for the supermarket employees in group two. They may sort of solve the problem of their individual cart but their “compromise” has broken the entire system of dealing with all carts. To a large degree, they are guilty of creating the hassle that drives people to join group two in the first place.
The worst part, is I’m sure these people think they are making a good compromise. “At least I didn’t leave the cart in the parking lot,” they must think, “It’s not perfect, but it’s good enough.” Nothing could be further from the truth.
- Think about the effects of your “good enough” compromises and try to see where you may be unintentionally creating “group three” disasters.
- When giving performance reviews, do you recognize your “group three” employees as negatively affecting your team, or do you fill the box for “Consistently puts shopping cart back in stall” with “Meets expectations”?
Simple is Better than Overly-simple
I’m a big fan of simplification. When we try to tackle a seemingly insurmountable obstacle, the best way forward is often to break it down into simple manageable chunks. If we ask less complex questions, good answers are easier to find.
And if simple is good, simpler is always better, right?
Wrong.
Once a client asked me to design a simple group calendar with some automated workflow through Outlook forms. Because of some inconsistencies with their Outlook deployment, it turned out to be not such a straight-forward endeavor. The forms worked for some people, but not for others.
There were two solutions on the table that would have solved the problem. We could have re-imaged about 50 computers to ensure that everyone in this workgroup had an identical build (i.e., solve the problem by fixing Outlook inconsistencies). Alternately, we could have quickly built a web-based solution that hooked into Exchange server on the backend (i.e., sidestep the Outlook issues altogether).
It was decided that both of these solutions were too complex. We were told to continue to troubleshoot the “simple” Outlook forms solution. Though we spent a little less time than we would have with one of the proposed solutions, ultimately we wound up with a half-working process that was part manual and part automated and wasn’t really any better than the original manual one.
Sure we saved time by removing complexity. But we would have seen a much more worthwhile return if we invested the time in one of the more permanent fixes. We over-simplified the problem to the point that we didn’t solve the original problem. It would have made more sense to scrap the initiative altogether.
- Think for a moment about past projects that didn’t go to plan. Can you identify an instance when over-simplifying caused you just as much work as tackling the original problem?
