Too thorough?

Is such a thing even possible for an engineer? Maybe not in a literal sense, but what does it mean when a VP or director says it (because they do say it)?

Short version: When a VP or Director says that, they probably mean “You're giving me too much detail (which I don’t want/need to know); let's get to the high-level information (which I do need to know).” Details follow.

Some years back, when I was working at HP, my boss and I had a meeting with “the great Bernard” (my boss's phrase) to talk about a proposal from a customer—it was AT&T actually. They wanted us to port some of their code into the HP-UX™ kernel, and provide support.

We had studied their proposal; I even had a look at their code. We had prepared some slides (think "powerpoint") and went to see Bernard. Bernard had talked with hundreds of customers and partners, and had a clear idea of what he wanted us to say.

It was not what we had written. Our slides discussed capabilities, testing, limitations and such; we had numbers and details. Bernard took a pad of paper, turned it "sideways" ("landscape" orientation), and started writing:

• HP is fully committed to AT&T System V
  
  
• …

His next points talked about how this would have to be an HP product, available to all our customers.

When we met with the AT&T folks, Bernard did a lot of the talking. He said we were going to sell a product based on their code, meaning anybody could buy it from us. They asked if they'd get some of the money, too. "Maybe," he said. That satisfied them.

The discussion continued at a very high level.

So had we been too thorough?

Well, no. But the presentation materials were too detailed for the level of conversation we were having. Fortunately, Bernard was vetting the materials so that we could have a fruitful conversation with the customer (and our would-be partner).

The lesson from this experience, which probably happened in the late 1980s, was to create a presentation to match the audience. If we were meeting with their technical team, like the folks who had written the code, or their QA folks, our materials would have been great.

I've been taught this lesson many times over the years, but I have yet to fully absorb its importance. I tend to ASS-U-ME that people have the same background as I, are fluent in the same languages (like vi(1) keystrokes), will "get" my allusions, and so on. When I'm my best (most culturally-sensitive) self, I remember not to assume too much, and one would think I'm getting better at this as I get older. Well, hope springs eternal…

Too much detail!

The above vignette makes the point that directors and high-level managers think and talk at, well, a high level. No, really! They don't want a lot of details.

This can be bad (consider the Challenger disaster) but it's also necessary: before we can engage in a detailed discussion, somebody's got to set the rules of engagement, or terms of reference. This is obvious when talking with partners or customers; it's less obvious but sometimes still essential within the company.

When a director asks how it's going, she probably doesn't want to know that I've examined so far at 17 of the 26 potential callers of a particular routine. She is thinking about a milestone we need to hit, or whether a particular design decision looks like it was working out. What we need to do is give them the information they want in a way that they'll understand.

And I don't just mean "easy to understand"; I also mean "nearly impossible to mis-understand." But that's another blog post.

But I spent so much time on this!

When I'm in the midst of analyzing logs and core dumps (or trying to), and somebody asks me what's happening, I want to answer the question as I hear it. My whole mind, hence my whole world, has been wrapped up in these log entries, and these backtraces, and so on. The discipline I need to embrace in these moments is two-fold:

1. to disengage enough from what I'm thinking about and put myself in the other person's shoes, if just for a minute; and
2. to restrain myself from talking too long about something just because I've been thinking so long about it.

An example of how #2 was done right is from the motion picture industry. In Star Wars Episode VI: Return of the Jedi, Luke Skywalker confronts "Jabba the Hutt" at the latter's lair, an intricately constructed craft that looks like an ancient sailing vessel. This thing was carefully designed and beautifully contructed; I seem to recall that there were many arguments over the design and that it took months and months to construct. But it's on the screen for no more than 5-10 seconds.

Why only 5-10 seconds? Because that's as long as the audience needs to look at it. Contrast this with the earlier Star Trek: The Motion(less) Picture, where you feel like you're watching a shuttlecraft approach Enterprise for half the movie.

Conclusion

As my wife often reminds me—or rather, as I repeatedly bang my head against this same wall—there's often a big difference between what she wants to hear when she asks me something, and what I want to tell her about it.