Figure 6.1. Dilbert’s coworker gets his iMBOs wrong. Reprinted by permission of United Media.
AMB stands for “As Measured By,” and the list of activities corresponds to the judging criteria.
Each objective must be concrete, specific, and meaningful, and the team must be honest in judging its state of completeness at the quarter’s end. In the sample above, the team felt it had accomplished tasks 1, 3, and 4 for the first objective, but had not completed task 2. We certainly had done better than Dilbert’s coworker in Figure 6.1.
It probably seems as though having a team grade its own accomplishments might yield “perfect” results, quarter after quarter. That can sometimes be a problem; managing with iMBOs can be tricky because, although they are an extremely effective tool when used properly, they are also very easy to subvert. A sure way to destroy the iMBO’s effectiveness, for example, is to tie compensation to the iMBO grading. A great deal of judgment is required to select the right objectives and the best metrics by which to measure them. Any unnatural pressure to score well on iMBOs, meaning any pressure other than having the project turn out as desired, would subvert the process by grade inflation. When every group gets a perfect score every quarter, the iMBOs are no longer filling their role as a planning procedure. And if a manager chooses to be honest even though all the other managers around her are rounding their numbers up, few employees will want to work for her, since it would, in effect, cost them compensation.
I was blessed at Intel with excellent managers-Fred Pollack, Pat Gelsinger, Dadi Perlmutter, Will Swope, Randy Steck, and Mike Fister-all of whom felt that a perfect score on a quarterly key results sheet might mean your group had an excellent quarter, but it might also mean you were not aggressive enough three months ago when you planned this quarter’s activities or that your ability to fairly score your group’s results was suspect.
Subversion aside, the iMBO process is a valuable tool. As Andy Grove mentions in his book [16], the act of identifying what you believe are the highest-priority tasks for your group in the next three months is also the act of ruling out certain other tasks. If they are worth doing, include them, and if they are not on the list, do not do them. Writing tasks down in this way has the salutary effect of forcing a team to be honest about what they think is really important, as opposed to what is simply interesting or fun.
The list of intentions also drives out miscommunication among cooperating design groups. If I receive your list of proposed iMBO objectives for next quarter, and I do not see the completion of some task I was relying on you to accomplish, I will assume the worst and go talk to you about it. It is better to find out now that we have our metaphorical wires crossed, rather than three months from now.
WE ARE SO RICH, WE MUST BE GOOD
The 1990s belonged to Intel (and Microsoft and Dell and many other computer-related companies, except for any of Intel’s competitors). Intel began that decade as a 22,000 person, $2 billion enterprise, and ended it as an 80,000 person, $28 billion behemoth, with large profit margins on parts selling in burgeoning markets for which it held 80%+ market share. Intel even benefited from the “irrational exuberance” of the Internet-boom stock market, when price-to-earnings ratios were considered declasse and high-tech portfolios were de rigeur. Life was good.
The trouble is that, even at a place famous for its paranoia [14], human nature prevails. And it prevails with a vengeance whenever really smart, aggressive people are involved.
Approach any failed startup and ask the principals what went wrong. You may get conflicting stories, but you will have no trouble engaging them on the subject, and you will find them very forthright, humble, and open to other ideas. They know beyond a doubt that their best-laid plans did not work out, and this knowledge seems to help the rational mind push the ego aside and focus on reality. Some may unjustifiably blame others, but few will start singing “Oh, the Cleverness of Me.”
Now approach highly successful corporate executives and try to get an honest appraisal of their efforts over the same period. With very, very few exceptions, you will find that they believe they succeeded because their plans were brilliant, and success was inevitable when a talent as huge as theirs was applied to a problem. Virtually none of them will ever admit that luck might have been a nontrivial component.
I recall feeling the discomfort of that reality in the late 1990s, when I was participating in a high-level staff discussion on strategies and tactics for Intel’s microprocessor development road map. Exuberance was the order of the day. The various staff members got up, one after another, and reminded the audience of what their groups’ plans had been and how incredibly wonderfully those plans were turning out. Nobody questioned anyone else’s plans. All was peace and mutual admiration, like Woodstock without the mud.
But that was not the talk I had prepared. My talk pointed out that for three successive years, our chief competitor (AMD) had not fielded a credible threat to any of our products. I likened it to showing up for the Superbowl or the World Cup and finding that the other team had not appeared, and had forfeited the game. Yes, that means you win, but it does not mean you are good. I gingerly pointed out some of our own execution errors, holes in our overall product road map, and places where we were not cooperating well between projects. My theme was that we were getting away with these errors, but should not count on continuing to do so in the future.
As I waited for the audience reaction, I was reminded of the phrase, “well received.” Although I never quite knew what it meant, it seemed to me that its semantic range must have complete adoring acceptance at one extreme and hostility verging on lynching at the other.
For any reasonable meaning of that phrase, my remarks that day were not well received. The dominant reaction was laughter. Many people thought I was kidding; others thought I was just deluded, somehow blind to the obvious that it was our corporate birthright for things to go extremely well all of the time. I kept hearing the phrases “Chicken Little” and “sky is falling” at lunch that day.
I had not seen this reaction coming. I likened my job as the company’s chief architect of what was (and is) by far Intel’s most valuable product line to that of an army scout. My unique contribution would be to conceptually roam several years into the future and watch how the coming technology might intersect with how the buying public might use it. When I applied that thinking to IA-32 and reported my results to this august group of technologists and managers, they heard only that I was proposing to sell the cash cow and start raising goats.
To be fair, they were not entirely wrong. It was a trivial exercise in the 1990s to graph the worst-case thermal dissipation of each successive microprocessor generation and extrapolate into the future. Depending on your assumptions about new cooling solutions and the effectiveness of yet-to-be-developed, low-power implementation techniques, you could adjust the year at which the curve would become ludicrous. Until that happened, there was still a lot of money to be made doing what we had been doing all along. But there was no mistaking the overall pattern-thermal dissipation was going to lead our industry right over a cliff.
If user demand for faster microprocessors could be counted on to remain unsated through this period, then the additional expense and noise of higher-power processors might not upset the apple cart quite yet. But I was also worried about the speed demand aspect. Historically, computers had never been fast enough; they had enough performance to be useful, but not enough to completely satisfy their users, so each new generation of faster machines was greeted with open arms and wallets.
As Clayton Christenson reminds us, however [17], all technologies climb similar maturation curves and eventually reach a point where their basic performance becomes satisfactory. By “satisfactory,” he means that more performance is not valued enough to remain a viable differentiating sales factor. And as his book clearly shows in example after example, the progenitors of the technology in question are often the very last to realize that the performance horse the
y have ridden to market for so many years has gone lame.
My remarks stemmed from my concern that many signs of this particular end game were on the horizon and that corporate product development and research, and planning as well, should be taking this contingency explicitly into account.
As the laughter died out, it dawned on me for the first time that my career at Intel might not be of life-spanning duration. The culture had entrenched certain trends, influences, and attitudes that I simply could not alter, no matter how well I structured my argument or how carefully I crafted the data in my foils. I suddenly had a much better understanding of why big, successful companies are so seldom still big and successful after technology makes a sharp right turn.
BURNOUT
During P6’s crunch phase, I sometimes heard executives worry that we were pushing the team too hard, that we did not know how to conserve our energy, that our good results to date were because we had got the best out of the team and that they were going to burn out. We managers worried about burnout, too, but we also knew stress levels are affected by more than simply working too much.
Burnout occurs when the employee just does not care about the product any more. The surest way to that outcome is if they do not believe in it in the first place; they must buy into the project’s premise. For the P6 project, this was relatively easy. We all knew the company’s fortunes would directly rise or fall on our product and its children. We also be lieved (despite serious doubts both within Intel and the RISC community in general) that an x86 microprocessor could be a legitimate contender for a performance leader, and that demonstrating such a thing would have earth-shaking implications for the entire industry. We were believers on a mission.
We believed that an x86 microprocessor could be a legitimate contender for a performance leader.
Burnout also follows if engineers lose faith in their management. Engineers will do what it takes to succeed, but nobody likes to feel exploited. They want to know that while they have their heads down, getting the technology right, their teammates in marketing are getting the sales messages down and that management is making the right connections to get this new chip into successful volume production. They also need to believe that their own careers will trend in line with their contributions, sacrifices, and successful results.
Our engineers were not burned out. They were tired, and the cure for that was rest, upper management’s acknowledgment of their incredible work, and immersion in the flow of accolades that follow a successful product. The worried executives were overlooking that key factor-our engineers wanted to succeed. Feeling like all their work was not in vain was the essential balm for these tired souls.
INQUIRING MINDS LIKE YOURS
Critics can’t even make music by rubbing their back legs together. -Mel Brooks
Over the years, I have received hundreds of e-mails and unsolicited inquiries in airplanes, dimly lit restaurants, online forums, parties, and street corners. It seemed fitting that I devote some part of this book to the more thought-provoking of these questions.
What was Intel thinking with that chip ID tag, which caused such a public uproar?
What was Ford thinking when they designed the Edsel? Or Coca-Cola when they did the New Coke? Beforehand, they thought “This is going to be great!” and afterwards they thought “Whoops! Whose stupid idea was that?”
To see how Intel started down this particular garden path, we must start with Intel’s motivation and the chip feature that started all the trouble.
The yield’ that a silicon manufacturer attains is an extremely important factor in determining a company’s profitability and the final chip’s price. To help track some of the variables related to yield, Intel’s manufacturing engineers had long ago inserted dozens of fuses, which could be selectively blown during manufacture, to help mark individual silicon die as to XY position on the wafer, wafer lot, fab number, date, time, and other infor mation. With cumbersome test procedures available only to Intel technicians, these fuses could later be read and correlations drawn.
In 1998, an Intel marketing person had what they thought was a great idea. Many software vendors, most notably Microsoft, had long been asking for a hardware mechanism by which they could permanently and irrevocably tie their software to a specific hardware platform to help combat software piracy. The marketer knew about Intel’s manufacturing fuses and proposed that we incorporate those fuses into a new product feature called “Unique ID.”
I objected, on the grounds that Intel manufacturing was not set up to coordinate unique fuse settings on a worldwide basis. Nor was there evidence that, if the fuses happened to be blown incorrectly as a result of a fab error, Intel would be willing to trash the entire wafer. The feature would have had to be a very valuable one to make that a viable proposition.
The marketer proposed that we simply rename the feature as “processor ID” to get around the uniqueness concern, and Microsoft agreed that in the unlikely event that two microprocessors were made with the same ID, that alone did not fatally compromise whatever antipiracy measures they were thinking of.
At the time, Intel marketing was looking for additional ways to increase the appeal of the new Pentium III microprocessors. They came up with a marketing campaign that was to be kicked off in a January 1999 Superbowl TV ad. The ad’s message was that listeners should go buy a Pentium III system, because only those systems would have this ID scheme. If any Web denizens tried to access the new Web site without a Pentium III, they would be turned away, but Pentium III owners would be recognized (by dint of their CPUID, automatically read by the Web site) and given some series of incentives once inside the Web site.
In only a few weeks, once it became known that the Pentium III had an internal ID tag, visible from the outside, there were picketers in the streets. Foreign governments were passing formal resolutions to prevent the use of Pentium III’s in their countries. Customers were up in arms at what they perceived to be Intel’s attempt to force (Intel’s idea of) morality on them. Only a few days before the Superbowl ad was to have aired, a shocked Intel sold that time to someone else and pulled the plug on the Processor ID feature as a way to attract new customers. Intel issued new driver software to turn the feature off by default and the uproar gradually subsided.
This was the second time I had seen the surprising interactions between a high-tech product and the buying public. The FDIV bug episode had occurred a few years earlier, but it was not my chip’s bug, so I was more insulated from the issue. The same pattern of quasiirrationality was present, however-we would ask the very people who said they were most upset about this perceived invasion of their privacy, “Why have you not been equally concerned about the unique ID of your Ethernet adapter, which is also visible from the Web?” but get no useful answer. They had simply accepted that, but they were not going to accept this, and either did not feel the need to explain, or did not understand the irony.
Was the P6 project affected by the Pentium’s floating point divider bug?
In summer 1994, the chief P6 floatingpoint architect, Patrice Roussel, walked into my office and whispered “There’s a bug in the Pentium chip.” I said “I sure hope you’re wrong. Show me.”
Patrice reached over to my keyboard and quickly brought up three windows side by side on my workstation. The leftmost window was a 486-based computer, the middle was a Pentium machine, and the rightmost window was a simulation of the P6 chip we would be taping out only a few months later. I looked at all three windows and observed the obvious: “The 486 and the P6 agree, but the Pentium says something slightly different.” Patrice whispered, “Yes, I know, that’s the point. The Pentium is wrong.” I asked Patrice who knew about this; he said so far it was just him and me. I said “Then I’ll tell you what you have already figured out: Problems like this can have serious corporate consequences and have to be handled carefully by our executives, so tell the Pentium design team what they need to reproduce the problem and debug it, and don’t tell anyone
else. Let the executives handle this.”
The reason for this secrecy was to minimize the problem of “insider trading.” Trading securities on the basis of information that is not generally known to the buying public is illegal and unethical. Patrice had just come across information that (as far as he and I knew) could affect the stock price, so we had both just become “insiders,” no longer able to trade any of our stock until the situation had been publically resolved. The point of the secrecy was to keep our fellow engineers from joining us in this predicament.
About three months later, a college professor stumbled across the same bug, failed to get satisfaction from Intel, and went to the brand-new WorldWide Web with his story. The press picked up the story of how Intel’s chips did not work, Jay Leno made fun of it, and Pentium jokes became all the rage:
Q: What’s another name for the “Intel Inside” sticker on a Pentium chip?
A: A warning label.
Q: What do you call a series of FDIV instructions on a Pentium?
A: Successive approximation.
And on and on. I happened to be traveling from Oregon to Boston in the second week that this story was hot. I got into a Boston cab and the driver asked me where I worked. “Intel,” I said. “Whoa! How about that Pentium bug?” he said. I thought it was weird that even the cab drivers knew about an obscure floatingpoint CPU bug. He dropped me off at the hotel and as I checked in, the clerk noticed my affiliation and said, “Hey, I heard about that Pentium bug!” I was starting to wonder if the whole thing was an elaborate setup, like Candid Camera. But when I got to my room, I decided to call my mother and (I am not making this up) she said, “Hi. Hey, your chip doesn’t have that Pentium flaw I’ve been hearing about, does it?”
Then one night, while patrolling an Internet news group for P6-related questions, I noticed a post that really set me back on my heels. The poster said that he didn’t blame the engineers for having designed the FDIV bug into the chip, nor did he blame validation for not having caught it. He opined that the person most culpable in the whole affair was the Intel manager who first knew of the errata but did not post it immediately to the Web so the Pentium users would know of it. He argued strongly that said manager should go to jail over this egregious failure of public responsibility.
The Pentium Chronicles: The People, Passion, and Politics Behind Intel's Landmark Chips (Practitioners) Page 28