The Pentium Chronicles: The People, Passion, and Politics Behind Intel's Landmark Chips (Practitioners)

by Robert P. Colwell

  But we should have known that nothing is ever easy. At exactly the same time we were getting used to Willy, we were informed that a central research group in the company had just created the New Standard Simulator Which We All Must Use (NSSWWAMU), and were politely given the proverbial offer we could not refuse. Willy was obviously redundant and a symptom of old-fashioned thinking. The new simulator was already standard everywhere in the company except our little Oregon outpost, and our upper management was squarely behind this standardization initiative. So get with the program, please.

  Now, corporate “everyone do things the same way, please” initiatives are not new. They appear with regularity every six months or so, and some actually yield real results. Others are an annoying distraction from the real work of designing competitive microprocessors. The way I routinely handled the second category of initiatives was to ignore them for awhile. If the ideas turned out to be not particularly well thought out and had appeared only because someone was running them up the flagpole to see if anyone would salute, they would go away on their own if left to age properly. By sitting on them for a while, I prevented the company from siphoning off people or focus from my project.

  With both NDFA and Willy online, I felt no need for yet another simulator, so at first I tried giving this initiative my standard second-category treatment. After several months, however, it became clear that real people with real energy were behind this new simulator, and they had spent those months enlisting allies, including my upper management. The politeness went away, but the insistence did not. These folks were not easily discouraged.

  I next tried my Backup Gambit B: Show that the new initiative, brilliant though it may be, did not apply to my particular project, so please come back in a few years when we start something new. Because we were the only design team in the company pursuing new out-of-order microarchitectures, we had so far escaped any corporate initiative for any new simulators well suited to out-of-order designs, which this new simulator was not. Unfortunately for Gambit B, it did not take much work by the NSSWWAMU folks to remove this objection.

  So I resorted to Gambit C: Like the second-category treatment, C was a delaying tactic that gave at least the appearance, if not the reality, of taking the NSSWWAMU simulator out for a test spin. I asked Michael Fetterman, who like Mike Haertel is one of those rare people equally gifted at software development and microarchitecture design, to go investigate this new corporate simulator and make a recommendation as to how we could not reasonably be expected to use it. Unfortunately, Michael concluded that though Willy was a direct match for our project (which was no surprise, considering its origins) the corporate simulator could be made to do what our project needed, given enough time and effort to make the switch. Fortunately, by this time, the Willamette project was far enough along that this effort was no longer a direct threat to our project schedule, which was a good thing, too, because I was out of gambits.

  PROJECT MANAGEMENT

  Having just delved into the psychological realm and exposed the occasional irrationality and unpredictability of microarchitecture design and development, it seems fitting to segue into project management. I will revisit people issues in more depth later (in “The People Factor,” Chapter 6), but the realization phase of a project is the quintessentially management-driven part of a project, and it seems more appropriate to talk about some of the project management foibles here.

  Awards, Rewards, and Recognition

  I once took an Intel management course in which the instructor, Bill Daniels, told the class that he was a behavioral psychologist who knew what people would do, even though he did not know why. He gave the example of praise. People, according to Bill, respond in a predictable way to praise: They like it. Through his studies, he had identified the most efficacious times and methods for bestowing praise on coworkers or subordinates (or bosses). It surprised him that even telling people ahead of time they would be set up for praise did not seriously diminish its effectiveness once they got it. He then gave our class some minimal task at which we all succeeded and told us how well we had done and that he was pleased with us. Presto, the room was instantly full of beaming people, just as he had predicted.

  People respond in a predictable way to praise: They like it.

  Engineers are perhaps even more susceptible to this kind of benign manipulation because of their innate parsimony. When an advertiser wants to know how well their latest ads are succeeding, they commission a survey of the intended audience. We engineers get so many of these surveys that even if we wanted to, we could not participate in all of them, so some advertisers have taken to inserting a crisp new dollar bill in the survey envelope. This additional financial incentive does not create more hours in our day, nor is it even close to the amount it would take to fairly compensate us for the 15 minutes we will have to invest in the survey. Yet that dollar bill works-no engineer is going to throw it away (an unforgivable waste), and having accepted it, will feel duty bound to complete the survey.

  Finding the right incentives to get a large design team to its maximum output and then keep it there for years is crucial to a project’s success. Obviously, getting paid for work done is a key motivator, and design teams are full of professionals who will always try to give a day’s work for day’s pay. But if that is all management is getting from their team, real trouble is afoot.

  The difference between getting maximum output from a team and getting only a day’s work for a day’s pay cannot be overstated.

  The difference between getting maximum output from a team and getting only a day’s work for a day’s pay cannot be overstated. An absolute requirement for achieving a world-class product is a design team that is fully committed at every level and at all hours. Sound technical ideas I have had or have witnessed others contributing have come during showers or while walking around aimlessly or driving-any activity other than sitting at a desk actively pondering the problem. Something about being outside the pressurized corporate environment while engaged in a task that can be performed without your entire consciousness tends to free up the creative muse and let the really good ideas bubble up into view. (Yes, driving ought to be done with your entire consciousness, but empirical evidence and the preponderance of cell phones on the ears of one-handed drivers suggest that such focus is seldom achieved.) When your design team is routinely reporting creative solutions to their troubles, and a large fraction of those are coming from pondering in off-hours moments, you know that your team is fully engaged and giving the design everything they have.

  So what motivates a team to go above and beyond the call of duty, to think it worth pondering a problem during mundane activities? Career advancement is one reason. A team’s top producers are, in effect, investing their time and energy speculatively, trusting in the team’s management to notice their standout performance and take the appropriate action when the time comes, be that promotion, pay raises, or stock options.

  But for most people, an even stronger incentive than “What’s in it for me?” is “What will my peers think?” The act of engineering a product is pitting your training, talent, intellect, and ability against both competitors and nature itself. This is the draw and the scary part of an engineering career, since no matter how many times you have succeed ed at similar projects, the current project could always turn out to be the one that crashes and burns because the design team came up one good idea short. And the only people on earth who really understand just how truly great your efforts have been are your peers on the same design team. Coming from a peer, a little encouragement that your design is on the right track can boost your morale and confidence more than any other incentive.

  As with military organizations, large companies learn that for very little expense, a lot of good will and bottom-line output can result from organized efforts to show recognition, especially the kind you get in front of your peers. Pay raises and stock options are important, but they are private transactions. Bill Daniels had it right there is
nothing like hearing your name called in an auditorium full of your peers to make you work like a madman so that it can happen again.

  The Dark Side of Awards

  The flip side of recognition is that for every person for whom performance recognition generates X units of good will, you might have four or five who would like to string you up. Among those watching the jubilant engineer make her way down the auditorium aisle to receive her award are those who are bubbling with righteous indignation. Hell hath no fury like an engineer who feels his contribution was overlooked, or worse, misattributed. The rage and betrayal he evinces are awesome to behold and terrifying if directed at you.

  Anger at having your work misattributed to others is common in all fields. Thomas Edison had many helpers in his lab, even if it was generally just his name on the patents [9]. Eckert and Mauchly are not household names, but the von Neumann computer architecture that we all routinely use in today’s microprocessors came from them, not von Neumann. Watson and Crick discovered the double helix topography of DNA molecules and deservedly won a Nobel Prize for it, except that Rosalind Franklin should also have been named. Indeed, the one thing you can reliably predict about each new set of Nobel Prizes is that they will compel someone, somewhere to step forward and claim they were unfairly excluded.

  For all the team motivation reasons just described, Intel tries hard to recognize team members who rose to the challenge during chip development projects. They follow six steps, roughly summarized below.

  1. Form a group to identify candidate achievements worthy of the awards in question while not overlooking any.

  2. Ask that group to prioritize these achievements, which may be as varied as an extremely clever and intricate electronic circuit or an unusually effective marketing initiative or an innovative legal maneuver.

  3. Decide whose names will go on the achievements that made the cut.

  4. Weigh the results in a larger context. Overrewarding one group can result in a corporate net negative overall motivation, even if that group’s output appears to warrant such action.

  5. Look for “firefighting by arsonists.” You must not reward extraordinary efforts that only became necessary because of earlier errors by the nominees. (Yes, this does happen.)

  6. Achieve all of the above without talking to the engineers themselves, because these awards work well only when they come as a surprise.

  Do not reward firefighting by arsonists.

  Number 1 is relatively easy. All managers propose their own group’s list of awardquality activities. Number 2 could be tricky. The group might decide that a clever intricate circuit is just the result of the engineers doing their job, but readily agree that what the marketing group accomplished was truly outstanding. That would be hard to sell to engineers who face mainly technical challenges.

  Numbers 4 through 6 should be doable if the group (and the staff) has learned to communicate honestly, directly, and diplomatically. By the way, one of the reasons for the surprise element in Number 6 is that if an engineer believes he is being considered for an award and then doesn’t get it, he now has a good idea of what was prized over his own work. And if he doesn’t agree with that prioritization, his morale asymptotically approaches zero.

  Number 3 is often ridiculously hard. Achievements large enough to deserve awards are almost always built of stepping stones. Some are so substantial that nobody would overlook them, but some are right at the border of the twin cities It-Was-Their-Job-Anyway and Without-Them-There-Would-Be-No-Great-Achievement-Here. If you step over to the second city, you end up with three dozen names and glaring disparities between their relative contributions. If you step over to the first city and painstakingly identify the five major contributors, the next 15 on the list (not having as complete a picture in front of them) will camp on your doorstep the next day, demanding that you right this great wrong that was visited upon them by your ineptitude or malevolence (they don’t always care which).

  I had my own battle with Numbers 3 and 4 in 1995, when we decided to nominate the P6 project for two Intel Achievement Awards, one for the microarchitecture and one for the Pentium Pro chip itself. The IAA is Intel’s top individual award. Once a year, the IAA awards committee solicits nominations, and they go through a company-wide exercise of Numbers 1 through 5.

  A short time after the nomination, communication through back channels revealed that the IAA awards committee was not inclined to bestow two of their awards on the same project (see Number 4). All our project management staff except me took this as a positive sign convert our two nominations into one joint one, and we would be a shoe in.

  Far from agreeing, I thought this was a horrifyingly bad idea. Intel awards IAAs every year, but large design teams come up with a new chip only every four or five years. I found it grossly unfair to penalize such design teams by making them self-select at most one IAA prospect every five years. Moreover, we were just finishing a mountain of architecture work that led to the P6 microarchitecture, work that we were intentionally investing on Intel’s behalf so that future derivative chips could benefit from our foresight. Giving this group of architects an award that, in effect, said “Thanks. Nice Chip” would accomplish the opposite of motivating them. It was tacit proof that upper management did not, in fact, understand what the architects had just accomplished and, therefore, could not possibly appreciate it properly.

  So I stood my ground and refused this compromise, and even threatened to stage a public plaque-burning ceremony if they went ahead with it anyway. In the end, we did ap ply for both IAAs and got both of them (deservedly, in my view: it was a darned good implementation of a darned good microarchitecture).

  Back to Number 3. I was in the group that decided who got various accolades for the P6 design, and assembled the list from design, architecture, and presilicon validation names. Intel even put a nice exhibit into the microprocessor museum in their Santa Clara Robert Noyce building with a picture of the design team’s leadership and the entire list of names we had supplied.

  But as soon as that exhibit opened, I got a polite but pointed e-mail from a system validation manager who wanted to know why the list had not included any postsilicon validation names. I had thought that exclusion appropriate because at the time they wanted the list, the included people had already invested five years of their careers in the design, whereas the postsilicon validation effort was still getting underway. Including the postsilicon validation list would have added hundreds of names to a list that was already hundreds long. And finally, the list that had been solicited was specifically the names of the people who had created this new chip, and it would have seemed an injustice to find the name of some postsilicon validation engineer who had not, to that date, had anything to do with the chip, whereas some of the design and architecture names had not taken vacations or holidays in several years.

  The validation manager had a point, though. Postsilicon validation is just as necessary as design itself, and the people who perform that vital task are very often taken for granted by all concerned. Indeed, the only time they are very clearly visible to upper management is when an important design error has eluded them and manifested itself in volume production. It is very hard to keep a team motivated when they accurately note that the only time their supervisor even notices them is when they goof (especially when they were not the ones who caused the bug to take up residence in the first place).

  I felt terrible about appearing to have joined the camp of people who undervalue validation, especially at the exact moment when I most needed them to grab the baton and run with it. But, in the end, you have to draw the line somewhere. Giving out awards is an exercise in compromise no less difficult than the design itself. So I reluctantly agreed to put the line between the design team and the postsilicon validation team and hoped any damage to the relationship between those groups could be repaired later.

  Difficult judgment calls like this seem impossible at the time, but after enough time has elapsed, sometimes th
e right call appears much clearer. This did not happen with “Do we include postsilicon validation in the design award?” Years later, I still think of it as a toss-up, with strong negatives either way.

  A similar issue arose concerning the names that should go on an IAA for the conception and realization of a certain chip feature. As the nominating manager for this issue, I had to construct the list of names to go on the award. I was in deep trouble. The list was long, with no clear breakpoints, and my own name was on it.

  I prioritized the list as best I could and sanity-checked it with a few other managers. On a list of 20 names, my own was twelfth. Clearly, if I were to draw the line just under my own name, there would be a strong appearance of impropriety. But it was quite clear that the twentieth name had about I% of the overall impact as the first few names, so including all 20 was not right either.

  I ultimately decided to draw the line just above my own name. Everyone higher on the list than I would be named on the award, and everyone below me (including me) would not. That way, I figured people who believed their contributions should have placed them on the award list could at least not accuse me of malfeasance.

  How naive I was! One of the people at the very bottom of the list and one person who was not even on it decided that a grave injustice had been visited upon them, and they embarked on an epic quest to rectify it. For the next couple of years, one manager after another, some quite high in the management hierarchy, called me. They explained they had been approached by one or the other of these aggrieved individuals and wanted to make sure justice was being pursued. I stoically defended my position and eventually the calls stopped.

  Having lost all these appeals, one person simply gave up, but the other took to simply ignoring me or throwing visual daggers, depending on his whim. I was sorry that this episode permanently soured a working relationship, but I was very glad I had the foresight to anticipate a claim of impropriety and avoid the appearance of such by leaving myself off. People can get really worked up about perceived injustices, especially those to themselves. (I know the feeling. See “How would you respond to the claim that the P6 is built on ideas stolen from Digital Equipment Corp.?” in Chapter 7.)