The Business Sensei

When Goals Take Over

“Just give me the numbers!”

Falling firmly into the “I just can’t make this stuff up” category, the preceding statement was made by the head of a certain engineering department. He wanted the performance figures on a series of database lookups so that he could determine if the database code was performing up to specifications. This would be a perfectly reasonable request except for one minor problem: the database code was not producing the correct results in the first place. Performance was sort of irrelevant given that getting the wrong answers quickly is not necessarily all that helpful, although it may be less irritating than having to wait for the wrong answers. It’s rather like driving at 75mph when lost: you may not know where you are or where you are going, but at least you’ll get there quickly. Or something.

In another example, the engineers developing a bioinformatics data analysis package spent all their time arguing about the correct way to set up the GUI elements on each page. The problem was that when they actually ran one of the calculations, the program appeared to hang. In fact, I was assured by everyone, it just “took a long time to run.” How long? The answer was, “maybe a few weeks.”

This may come as a shock to those few people who have never used a PC, but a few weeks is generally longer than most computers will run before crashing (or installing an update without warning). Besides, the complete lack of response from the program regularly convinced users that the program had crashed. The engineers did not want to put in some visual indicator of progress because they felt it wouldn’t look good visually. They refused to remove that calculation from the product because “someone might want to try it.” Eventually, they grudgingly agreed to warn the user that it “might take a very long time to run.”

In both of these cases, the team was solving the wrong problem. Although there were definitely complaints about the speed of the database, speed was very much a secondary issue so long as the database wasn’t producing correct results. And while the user interface decisions were certainly important, designing an elegant interface for a feature that will convince the user that the product is not working is not particularly useful. At least rearranging the deck chairs on the Titanic was only a waste of time. It didn’t contribute to the ship sinking.

So why were these teams so insistent upon solving the wrong problems? If you give someone a problem they can solve comfortably, and one that they have no idea how to approach, they will do the former. At that point, once goals are set, they become the focus of everyone’s attention and a lot of work goes into accomplishing them. That is, after all, the best thing about goals; unfortunately, it can also be the worst thing about goals.

While clear, specific goals are certainly good things, goals also have to make sense. You need to have the right goals. It can be a very valuable exercise to look at the goals assigned to each person and each team in the company. Do those goals make sense? What problems or challenges are they addressing? Are the goals complementary, or are there significant gaps? If the engineering team is being evaluated on how many bugs they can fix and the QA team on how many new bugs they can find, what happens to the step where fixed bugs get verified? If no one is responsible for that happening, it won’t get done (and didn’t, in several software companies!). If the team focuses on the wrong problems, they’ll spend their time fighting symptoms or revisiting solved problems, and never deal with the real issues.

Therefore, even before you can set goals, you have to know what the problem is that you are trying to solve. That means first separating the symptoms of the problem from the problem itself. The symptoms are only symptoms; frequently, they can point to many possible problems. It’s important to look at the symptoms and brainstorm which problems they could be indicating. When you start developing possible solutions, you then need to ask what the final product will look like if you go ahead with your solution and you need to know what success looks like. Make sure that your proposed solution will actually solve at least some of the potential problems you’ve identified, and develop some way of testing to make sure you are solving the correct problem. In other words, have some checkpoints along the way so you can make sure that you’re actually improving things. Only then can you start to set goals that will effectively guide you to producing the results you actually need.

Once goals are set, they have a way of taking over. What are you doing to make sure you don’t set goals before you know where you’re going?

How Do You Make Sure You’re in the Right Place at the Right Time?

This article was originally published in Corp! Magazine.

“Slow down.”

I can’t count the number of times that my original sensei would say that to me when I started practicing jujitsu. It drove me nuts. I never felt like I was moving fast. Besides, what was wrong with going fast? Now, after twenty years of jujitsu practice, I’m constantly telling my students to “slow down.”

Speed is a funny thing. It appears to be the most important thing in martial arts: being able to block quickly, hit quickly, throw quickly. However, when you move fast, there’s a tendency to overshoot the target, to over-commit. The block is too wide or the punch is over-extended, leaving you vulnerable. It’s easy to miss obvious feints by an opponent, and walk into a fist. Speed also leaves you physically and emotionally exhausted, unable to actually complete a workout. Indeed, the most skilled practitioners never seem to move all that fast. Rather, they become extremely good at always being in the right place at the right time. Speed comes from precision, but precision does not come from speed.

I’m frequently reminded of this phenomenon when I work with my clients. There is a tendency at many companies to try to do more and more in less and less time. The logic seems to be that if people just worked quickly enough, they would be able to get the job done. Instead, though, the error count is increasing even faster than the productivity. The time spent going back and correcting problems and fixing bugs more than makes up for the time saved by moving faster.

In jujitsu, moving fast can appear to work for a while. Eventually, though, you run into someone who knows what they are doing and you get punched in the nose. In a business, moving fast can also appear to work for a while. The major difference is that when you get punched in the nose, it’s not quite as obvious. It still happens though, and usually when you least expect it.

The problem once again is that moving rapidly does not equate to moving precisely. In a corporate setting, that lack of precision translates to instructions not being read closely, exceptions not being recognized, assumptions not being tested, or flat out inaccurate information not being corrected. It can also mean overreacting to a competitor’s product release or to a news story. In jujitsu, you may not have time to stop and think: if you haven’t prepared and trained, then you may just be out of luck. In a business environment, you may feel that you can’t stop and think, but the reality is far different. Unlike jujitsu, decisions don’t need to be made in fractions of a second. There is time to pause and consider the situation: even in the Apollo 13 disaster, NASA’s Eugene Krantz slowed everyone down and collected information before deciding what to do. Knowing when to slow down is what saved the astronauts; moving too quickly would have only compounded the problems beyond recovery.

Fortunately, most of us will never face the kind of life-or-death scenario that Eugene Krantz had to face. That, in turn, only makes the tendency to move too fast even more inexcusable.

The first problem, of course, is recognizing that you are moving too fast. Just as in jujitsu, it is surprisingly not obvious to the person, or team, that they need to slow down. It helps, therefore, to learn to recognize the symptoms of speed.

One of the easiest ones to spot is when the same types of errors just keep cropping up no matter what you do. You fix them in one place, they appear somewhere else. You come up with procedures for reducing the errors and for each mistake that you remove, a new one takes its place. One health related company demanded such a high throughput of patient claims that they were constantly dealing with forms being rejected because of mistakes. So they put in a layer of checklists to make sure the forms were done correctly. Then a layer of paperwork to make sure the checklists were correct. The errors simply kept shifting and the responses only created a slower and steadily more unwieldy system in which the ability to generate billable hours is limited by the need to do paperwork. The company is now one of the leading exporters of red tape. If they had but slowed down a little, they would have finished considerably more quickly.

Another common symptom of moving too fast is feeling like you’ve spent the day on a treadmill: you’re exhausted but it feels like nothing really got accomplished. Items on the to-do list never seem to go away or items that are crossed off keep coming back a few days or weeks later. When problems that were thought solved keep reappearing, that tells you that you need to slow down and put more time into understanding what’s going and devising more robust solutions. Unfortunately, when you’re feeling rushed, a quick solution feels good and creates a temporary oasis of calm. That feeling can be addicting: at one software company, one department developed the habit of simply marking any bugs that had been around for a while as fixed. They knew that it would sometimes take at least two or three weeks before the bugs could be verified. Maybe they’d go away. Maybe they would no longer be relevant. Maybe there’d be more time later to actually look at them. Sure, they almost always came back, but so what? They bought themselves time to relax, and managed to make themselves look good because their bug count was always low. The actual problems with the product, on the other hand, were never addressed.

If you want to move fast, you first have to learn to move with precision. That means starting slowly and learning how to be in the right place at the right time. Otherwise, you spend all your time and energy rushing about overshooting your target and fixing your mistakes.