The Optimizers, Both Good and Bad

Once in the mid-nineties I was at a client site. I and the client team were finishing up some documentation. A colleague—I’ll call her Brenda—had a long list that she needed to pull out of a table and assemble into a list. The data were in a format that could not just be pasted directly into her word processor. It was about 1200 items in length.

Brenda—a real “power user” of the word processor, immediately saw that this was going to be a couple of hours of work. So she decided to optimize. Rather than hand edit every item and then reformat it for the document, she would use a set of macros to pull the data into the document and then auto-format it, stripping away the extraneous characters and displaying the list in the desired style.

Brenda knew that it would take some time to program the macros. But once they were right, it would take literally five seconds to perform the transformation. So she set about developing the macros and I went back to my cube.

As I finished up my parts of the document and went back to check on others, Brenda was in the midst of a frustrating debug effort. The macros were not behaving correctly, but she couldn’t be sure what was wrong. Documentation on the macro editing features was wrong in the user manual, and Brenda was stretching her skills as a BASIC programmer. So I had a “sanity check” discussion with her.

Bruce: Is it possible that we’ve shifted our goal? It’s interesting to try to get the macros working, but it won’t take that long to just retype the whole thing.

Brenda: Yes I know, but I’m so close! I just know that after this next test, it’ll work fine—I think I know the problem.

Bruce: When’s the next test?

Brenda: It’ll be ready in about 30 minutes.

So I decided to run a little experiment—Brenda and I had already devoted many cups of coffee to discussions about IT, productivity, methods for using tools effectively, lost time in the office, and how badly we needed to pee.

I made a deal with her. I would type the 1200 item list—I thought I could get it done in about two and a half hours. It would take me longer because Brenda is a technical writer and 10-fingered typist while I am more of a finger-poken-mitten-grabben experimental keyboard user. But I volunteered for the sake of the experiment. While I was typing, she could use the rest of our allotted time to debug the macros.

I had to leave for the airport three hours later. By the time I left, I had finished the list and passed it on to Brenda. She was still feverishly debugging as I walked out the door—success was “just around the corner” and she knew that her next test would be successful. I left my text as the fallback.

Brenda is an optimizer. She believes in tools and she believes in productivity—even to the detriment of her own productivity.

Do you see how Brenda’s behavior could be viewed as Jetsonian? She’s optimizing, but her optimization is misplaced. Because it is not aimed at getting the result that she wants—the sorted and organized list—but to get that result with as little boring and repetitive effort as possible. It’s actually a good trait not a bad one, right? She is following the philosophy, “Let the machine do the work.” And it’s a good philosophy.

What’s happened in Brenda’s case is that she is carrying the philosophy past the point where it optimizes. She is using a Jetsonian laziness to do more work rather than less. So it is a self-defeating behavior. But Brenda doesn’t catch it, because she’s caught up in optimizing her optimization philosophy—and not in optimizing the task at hand.

So you can see that Jetsonian thinking is not just laziness. Indeed, Evan is much lazier than Brenda, and Evan is not a Jetsonian at all.