Brainstorming, Influence, and Icebergs

Bob Colwell

Abstract: Brainstorming done right is an exhilarating, exhausting process.

Two heads are better than one as long as both are actively trying to accomplish the same goal. But those two heads also can achieve less together than either could alone. It depends on many things.

In the best case, both people realize that for nontrivial problems, neither one has all the right answers. They engage in a discussion with the intention of letting both persons put forth their best ideas, and the ideas themselves drive a rational process forward.

This kind of cognitive humility is one of the general traits I like best about engineers: We know we don't have all the answers, and yet we recognize that our designs must move forward even when our imperfect knowledge can have serious or even life-threatening consequences. Engineers should study general engineering failures because they serve as stark reminders to constantly look for the line between well-considered risk-taking and fatal hubris. For many engineers, the urge to constantly seek to improve their designs isn't motivated solely by economics.

There are three classic ways in which engineers try to move forward despite having imperfect knowledge. The first is the solo Eureka! effort. In this approach, a muse pays a fleeting visit and confers a Really Cool Idea that we then share with our colleagues in exchange for admiring glances and a patent plaque to hang on the wall. The second way is for engineers to put their heads together and attack a problem in a communal fashion, such as brainstorming. A third way is to ignore the problem as long as possible, hoping it will go away. I don't recommend this third option, but I mention it here because of its eternal if misguided popularity.

Brainstorming Done Well

Brainstorming done right is an exhilarating, exhausting process. My fondest memories of working on engineering projects are of participating in such brainstorming sessions.

When you find yourself in a room with several of the brightest people you've ever met, all working at the top of their game, the concepts fly like sparks from a grinder. Even a moment's distraction will have you spending the rest of the session futilely trying to catch a fast-moving train by running down the tracks waving at the caboose.

The right mix

The personnel mix in a brainstorming group is crucial. Ideally, the group includes at least one and at most two "idea fountain" types, the kind of people whose brains automatically generate 10 ideas for every one being discussed. Why limit this type of participant? Because they also tend to suck all the verbal bandwidth out of a room, making the others frustrated and cranky.

There should be at least one experienced person who knows that brainstorming sessions need a lot of operating room, but not so much that the session enters a fatal, irreversible reality distortion field.

The group also should include at least one person who strongly wants useful results out of the session, such as the team leader or an architect looking for a solution to a particularly vexing problem.

One team member should be someone who has the mental horsepower to keep pace with the intellectual sprinters but is willing to stay half a step behind them during the session to help spot strengths and weaknesses in the ideas they are volleying back and forth. This person subtly helps direct the group's energies toward the most promising ideas, after enough time has been spent generating them.

Generating sparks

One of life's transcendent moments occurs when one person's partial idea sparks another's a true example of the result exceeding the sum of the parts.

It's surprising to discover how often pointing out what seems to you an almost embarrassingly obvious idea will startle one of the other brainstorming participants, who clearly did not find it as obvious as you feared. It's a thrilling experience when the other person then uses that idea as a starting point to launch into an unexpected direction that you wouldn't have considered on your own. It packs the same emotional wallop as that Aha! feeling you got when you first glimpsed the transcendent beauty of calculus or realized that it's not so much that we learn statics and dynamics as it is that we recognize them for the first time.

Brainstorming works best when all the participants focus on the technical problems at hand, not on who said what first or how to get credit for the results.

Brainstorming Done Badly

Then there are the brainstorming sessions from hidden-agenda hell. On the surface, certain engineering miscreants seem prepared to argue the issues on their technical merits, but their true aim is to "win"where they define winning as having their own ideas adopted.

New engineers who approach their craft in this way don't go very far in today's engineering organizations because their colleagues customarily lack the stupidity gene and will quickly learn to keep their distance. This helps keep such engineers from being promoted to positions in which they can inflict real damage on the company.

In the insidious case, experienced engineers who should know better become so enamored of their own ideas that they truly believe that the company's best interests must align with their own no matter what it takes. These people may not have ski masks on their heads and knives on their fingers, but they could be instructors at the Freddy Kruger Slasher School of Charm.

Although they give the outward appearance of actively listening to others' points of view, and they proffer their own ideas as part of the discussion, these meeting participants are really just collecting ammunition for the ambush. They will use whatever it takesdebating tactics, political pull, stonewalling, outright rudeness and hostility, appeals to any higher authorities they happen to know personallyto prevail.

A favorite tactic of the "one of us is going to win this debate and it's gonna be ME" crowd is the half-truth, a ploy that exploits a common weakness of scientists and engineers. To wit: We're used to making judgments based on the available facts, and we accept that our knowledge of any situation is limited. We pride ourselves on sensing when we know enough about something to justify taking action and when we should withhold judgment until we've accumulated a critical mass of knowledge.

The trouble is that people who know that we follow this paradigm can make it seem as though the critical mass has been achieved by revealing only what they want us to know, leaving out the facts that don't lead to their preferred conclusion. If we don't know all the facts, we could arrive at a decision that is at least considerably less justifiable than we ourselves believe, and it could in fact be quite wrong.

In my opinion, people who have the skill to coerce engineers into conclusions in this way are among the most dangerous in any company because they champion shortcuts that circumvent the normal scrutiny of dozens of stakeholders. This tactic neatly evades much of the cross-checking of ideas that is essential in large, complex organizations.

This tactic is employed outside engineering as well, especially in political ads. I predict that among the numerous "candidate A is great and that other slimy cretin is evil incarnate" ads you'll see, not one will attempt to lay out both sides of any important issue and let you draw an unbiased conclusion. If you try to combine two such ads, one for each candidate, and throw out what A says about B and B about A, you'll find that the remaining material doesn't seem very trustworthy either.

Ideas and Influence

The coin of the realm in large companies (or governments) isn't position or money, per seit's influence, the ability to get others to pay attention to your point of view. (Note that I didn't say they must adopt your point of view.) The higher a person rises in any organization, the more important the ability to influence becomes. Beyond a certain point, even in the strictly technical ranks, the ability to communicate your point of view to your peers and management is crucial to further career advancement.

Influencing your peers in a technical organization is simple: Have something worthy of their consideration, and the battle is more than half won. Realizing that good ideas don't just sell themselves, even in technical arenas, will cover most of the other half.

Communicating With Upper Management

At a company's technical levels, the purist ideas-stand-alone concept works well because simulators or analysis can test ideas objectively. The trouble comes when an engineer has risen through the ranks and is now attempting to influence the company's upper management. The same communication skills that let that engineer influence his peers, to the benefit of all, now threaten to work against him as he naively continues to apply them.

When engineers are present at a meeting with upper management, it's usually for a project status review. These events are ostensibly a means for upper management to stay in touch with important developments, which implies a one-way flow of information. However, most executives will sit quietly through a data dump only if they're extremely distracted by some unrelated impending disaster, the supply of which seems generally ample. Instead, they ask questions, point out project weaknesses and schedule slips, decry the company's fate because yesterday's newspaper had an article about how great the competition is, and so on.

In other words, regardless of their official billing or the presenter's misguided expectations, these reviews are interactive sessions. Engineers and project leaders who don't know this have prepared for the wrong thing in the first place.

The engineer appears at these reviews armed with the best PowerPoint presentation the staff could conjure up with a week of effort and doggedly proceeds to slog through the foilset in order, come what may. After eventually getting to Technical Problem Number 3, she mentions why it has become important and describes what's being done about it. When she thinks this topic has been disposed of for the purposes of this particular meeting, she smoothly segues to another one. To her way of thinking, she isn't looking for input on the problem, she's simply informing management of its status.

But to her surprise, the executive becomes agitated and takes immediate executive action by yelling at the engineering team, demanding that this problem must be resolved, and soon, or the project is doomed.

Belatedly sensing that this session is not directed toward a sum-greater-than-parts outcome, the luckless engineer makes subtle course corrections, trying to redirect her presentation to expose the issues without alarming the executive to the extent that he does something regrettable about the project.

For his part, the executive is doing what comes naturally: mentally correlating the raw information from the engineering staff with all of his other sourcesproject manager status reports, private discussions with the top technologists, advice and direction from his own management, and criticisms he's heard from other projects, some of which are openly competing with the one he's reviewing.

Ice Chunks on the Deck

Can you see the collision coming? It's reminiscent of the Titanic, when the lookouts finally saw the iceberg a few kilometers away. There were still several minutes left before the passengers could fill their cabin's ice bucket by simply placing it on the deck, yet the coming unpleasantness was real, imminent, and thoroughly unavoidable.

The engineer knows the technology but lacks the larger corporate context; the executive knows the context but only knows pieces of the technology, and those imperfectly. Bridging this gap can be extremely difficult, and it's possible only if both sides are willing to try.

A successful technologist once told me that whenever he had the opportunity to influence corporate directions, he always carefully chose the facts he presented. He expressed horror at the prospect of laying out all of the available facts in front of the executives and having them deduce the "correct" answer from them. He believed the odds were simply too high that they'd pick the wrong answer, and he'd be less able to sway them toward the right choice later.

I told this technologist that if I were a CEO and I found that someone was trying to get me to make a decision while purposely withholding facts contrary to his position, I would fire him on the spot. He muttered something I couldn't quite hear, but I'm pretty sure it included the words "fat chance" and "CEO."

I once witnessed an attempt to influence Intel's Andy Grove in this way. The speaker had an extensive background in sales and marketing, and he approached his presentation as an exercise in moving his listener from point A to point B. But as the speaker began to present his carefully chosen facts, Andy asked him about something else. Rather than answering Andy's question, the presenter began again, this time trying to move him from point C to point B. Andy interrupted him and said, "I don't see where you have answered my question. Try one more time."

The presenter still didn't see the iceberg, and he tried the same gambit, this time starting at point D. Andy again interrupted the speaker and said that if he didn't get an answer to his question this time, the presentation was over. You guessed itice cubes all over the deck, with the erstwhile presenter seated and wondering what new career might be best.

The Thin Line

I'm biased toward letting the facts stand because I have a great deal of respect for the engineering process and how thin the line is between successful products and utter disasters. To be true to my own dictum, I must therefore also relate to you the converse of the Andy Grove story.

More than once, I've attended high-level project reviews in which the presenter gave an engineer's view of the project status, warts and all, only to be publicly excoriated by management and purposely made to feel ineffective and humiliated in front of his peers. This tends to have a dampening effect on the candor of the next speaker. In such circumstances, the temptation to regale management with only rosy stories of what's going well becomes overwhelming. If the presenter regales well enough, there isn't enough time left to cover any of the project's less important (and more negative) aspects.

With time, of course, the person who told the truth finds himself or herself with a successful project in hand, while the project leaders who hid the dirty laundry earlier now discover that their project has crashed and burned.

You might think such an experience would convince the executives in charge of these projects to be less critical and more distrustful of seeming good news, but that's not always what I saw. Instead, after one such bearer of bad news had been exonerated by history, the executive told him, "Okay, maybe I was a bit hard on you, but all you had to do to avoid it was tell me what I wanted to hear." A truly Dilbertian moment in the annals of engineering.

Conclusion

Andy Grove was an extraordinary technical leader. I can't in good conscience suggest that you ought to develop your communications methods with the assumption that someone of his intellect and integrity is your audience. It may be that you'll encounter more "tell me what I want to hear" types than you will Andy Groves. Whatever such travails fate throws your way, the important thing is to find a communication style that lets your project succeed and keeps your management informed.

And if your lookouts report seeing big white things floating in the water ahead of your ship, well, sometimes hypotheses like "I believe my ship is unsinkable" are better left untested.

Bob Colwell was Intel's chief IA32 architect through the Pentium II, III, and 4 microprocessors. He is now an independent consultant. Contact him at bob.colwell@comcast.net.