| Whether you are a software development manager or his manager, you are going to have a variety of real-world problems to solve day in and day out. How do you go about solving problems? Is this a random process that sometimes works and sometimes fails miserably? Do you get "stuck?" Do you have trouble directing your creative energy, and do you have difficulty achieving closure? We all do. However, there is a way to get control of this very important process. I solve problems by going around the circle in Figure 1.1 at least twice, and more than that if required. In the real world, it is possible to begin the process at almost any point on the circle, but for convenience I begin my explanation at the most "logical" place, nine o'clock. And I'll switch from "I" to "we" because we are going to do this together! Figure 1.1. The iterative problem-solving clock. 
The First Time Through the Loop The first time we go through the loop, the steps are a little different from those on subsequent trips: Nine o'clock: Observe. We need to be aware. We need to have our antennae out all the time. We aggressively watch what is going on around us, and we try to sniff out problems. Eleven o'clock: Listen. Having detected a problem, we engage with others to find out what they think. We use active listening, creating a Socratic dialog with our conversational partner, alternating teacher and student roles. We try to listen more than we talk, and we take good notes. One o'clock: Empathize. I separate this from listening to make sure that you understand the difference. One can listen to get "objective" data; empathy is the bridge between listening in the fact-gathering sense and the beginning of the synthesis part of the process. We listen with our ears and synthesize with our brains; empathy involves use of the heart. It requires that we step outside ourselves and truly put ourselves in the other person's shoes. This is not always easy to do when what we are hearing does not agree with our previous notions. Hence we must empathize before we can synthesize. Managers who come from engineering sometimes skip this step because they are used to solving problems that are 99.44 percent technical in nature; unfortunately, this is not the case with most general management problems. Three o'clock: Synthesize. Here we bring together all the pieces: The data we have gathered through observing and listening The affective elements discovered by seeing it from other people's perspective All our previous experience in dealing with problems of this type Other "lateral" experience that may be relevant Our "tool bag" of methods, processes, strategies, tactics, techniques, and tricks We fabricate a trial solution to the problem, using everything we know
Five o'clock: Try It Out. In this crucial step, we perform tests and do experiments to see if our solution is workable. Here is where we weed out those ideas that looked good on paper but are unimplementable in the real world. We can't discover this until we try it. Be especially hard on yourself in this phase; shooting down bad solutions is a vital part of the creative problem-solving process. Seven o'clock: Write It Up. Here is where you document your solution and the tests and experiments you have performed. This is how you are going to present your solution to the rest of those involved, so take the time and care to do a good job of it. If you don't write it up, you will have a harder time selling your idea, and things that are not written down tend to fade quickly.
The Second and Subsequent Times Through the Loop We've gotten the trial solution out, and enough time has gone by for people to evaluate it. Now it is time to go through the loop again. Here is what the six steps look like this time: Observe: See how people are reacting to the trial solution. Have we made a dent? Listen: Talk with people about the pluses and minuses of the solution. Get them to tell us what they like and don't like, what works and what doesn't work. Empathize: What factors could be influencing what we are hearing? Are people just resistant to change? Is someone's personal ox being gored by the solution? Are there side effects or unintended consequences that are causing people grief? Or, is there "irrational exuberance"? Synthesize: We need to take the new data and fold it back into the synthesizing process. Can the original solution be tweaked, or does it need a major overhaul? Most of the time we can go forward by modifying or improving on the last pass. But we shouldn't be afraid to start our synthesis from scratch if we blew it the first time. Try It Out: With each pass through this station, we should become more intelligent about how to test the solution. After all, we have the tests from the previous pass, plus new data on what to look out for. Beat up the solution worse than the critics will. Anticipate objections or problems, and see how the solution performs when confronted by them. Write It Up: Using the original document as a starting point, modify what we need to, and point out what we have changed and improved.
When Are We Done? When are we done? Closure is important; we don't want to cycle through the loop forever. A good guideline is to stop when there is very little significant new information obtained during the observing and listening phases. The process can begin at any point on the circle. We must be opportunistic when it comes to problem-solving. Real life is "messy," and sometimes the germ of an idea may come up, for example, through some random synthesizing going on at the time. While it might seem better to stop and go back to nine o'clock, sometimes the best thing to do is to seize the moment and go forward from there. Don't forget, we will always do at least two complete cycles no matter where we start, so feedback is ensured. That's why that step at seven o'clock is so importantit's what precipitates the feedback. Note also a very important beneficial side effect: Because we have been "writing it up" as we go through the process loop two or more times, we don't have a huge documentation chore at the end. We will have progressively built up the "final documentation" as an organic part of creating the solution in an iterative way. Solutions obtained using this method tend to "stick." The art is to navigate through the six steps crisply and with all deliberate speed. Don't skip steps, and don't get stuck too long on any one step. Once you gain experience with the approach, you can improvise at will. But in the beginning, use the framework to add discipline to your creativity. You may be surprised and pleased with the results. |
