In my last blog post, I tried to differentiate problem solving and problem dissolving. This post continues to explore the differences. Problem solving is sweet, seductive and addictive. People experience a high when they solve problems. It’s exhilarating to have a problem that has stumped everyone and then come up with solution. Standard performance appraisals have a section where employees are rated on their ability to solve problems and employers reward employees that score high in this area and penalize those who don’t. Job opening descriptions list the ability to “solve problems” as a requisite for applying!
Once a pattern for solving a problem has been identified, it is reused over and over and over again. Because we can solve the problem faster, we tell ourselves we’re getting better at solving the problem. Our confidence rises and with it our level of cockiness. We begin to dare the problem to show up again. (For its own good, it better not).
Allow me to tell a little story that illustrates this. Recently, I worked with a team that had problem where user could no longer see some information. After some analysis, they identified what they needed to do to make the information available again. They had no idea why it had gone missing in the first place, but who cared? They made the information available again and made it available quite quickly. They had done it, they had solved the “missing user data” problem.
They then put a process in place to check if information was not available. They prided themselves in the fact that they were being proactive about it; before the users identified the issue, they would. They were sure that this would bode well in the annual performance appraisal exercise. So for 6 months, they tried to stay ahead by identifying and fixing the problem before their users did. As you can imagine, the results were mixed. Sometimes they identified the issue first and other times they didn’t. Additionally, the team didn’t like the fact that they had to monitor for this. They just wanted to write software. So someone came up with a brilliant idea, after all, they were software engineers. Instead of manually monitoring for the existence of the problem, develop an automated process that (a) identifies the problem exists and (b) fixes it when it does.
Before they could get to developing the solution, they decided to have a conversation about the problem again. The result of a one hour conversation was that a developer identified WHY data went missing and a couple of hours later, had made the necessary code changes that actually dissolved the problem.
Here is the kicker, they had spent over 6 months fixing the problem on a weekly basis but in a couple of hours they had dissolved the problem altogether. Early on, they had decided that the problem was complex and would require much time to figure out so they were better off quickly solving the problem whenever it appeared. There was no need to stop the presses and dissolve the problem. They did not consider the cost of not determining what actually caused problem. The cost of people checking the data daily, the cost of solving the problem, the cost of testing the solving, the cost of deploying the solution, the cost of having the end users look for their information. It all added up. Unfortunately, they can’t turn back the hands of time but they have learned a valuable lesson.
Buyer Beware: If you foster and develop a culture of problem solving, you are hurting your organization more than you probably realize.