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

by Robert P. Colwell

  So the two teams ended up at odds with each other, partly because the usual communications paths had been intentionally severed by management. But we also mutually suffered because (it seemed to me) Intel had just plain never figured out what strategy it was attempting to follow with IPF and IA32.

  Early in the IPF development, around 1994, we were told that the 32-bit x86 line would be superseded by the 64-bit chips by 1999. Our management may have believed this because HP told them so, or maybe the Santa Clara team told them, or maybe it came from their own intuitions, but we didn’t see it that way from Oregon at all. The P6 team believed we could follow the P6 with another 32-bit machine and that prematurely switching to 64 bits would simply cede the increasingly lucrative x86 market to our competition. We saw no real draw for 64 bits prior to 2006 or beyond, so we believed it was ill-advised in the extreme to consider hampering our 32-bit efforts in the desktop or the server markets.

  Within a couple of years, the Merced development effort had had enough trouble, with still no 64-bit killer application in sight, that the idea of migrating Intel’s user base en masse to 64 bits by 1999 was no longer mentioned. Also, we had begun designing what eventually became the Pentium 4, and earlier claims from some quarters that it was impossible to improve on the P6’s performance were being steadily refuted. So the corporate strategy for pushing both product lines mutated into something more like “let the world sort it all out.” Toward the year 2000, the strategy mutated even more, to essentially what it is today: 64 bits for servers and 32 bits for everything else.

  One subtlety that caused a lot of trouble was the insistence that the new 64-bit engine be “fully compatible” with the 32-bit engines being developed. Since we were actively adding instructions to these new 32-bit chips, the Merced project had a moving target to hit and began to feel they could never catch up. So they tried to halt further innovation in IA32, insisting that we stop changing, since their chip was the future anyway.

  This proposal did not go over well in Oregon. We pointed out that the IPF road map was not aimed at desktops, and even if it had been, it would have been too dangerous to risk the company’s major revenue stream on a hope that (a) Merced would be compellingly fast and (b) the world would switch its software from the x86 standard to the new IPF standard fast enough to drive high-volume demand. Meanwhile, our competition would continue to innovate in approximately the same way we would have had we not been stopped, and neither our 32-bit chips (lacking the new address extension features) nor our 64-bit chips (for lack of new software, and because IPF chips were being designed to server economics, not desktop) would be able to counter them.

  I also argued that one of our focus areas with the Pentium 4 was real-time, humaninterface applications, such as audio decoding or DVD playback. If the CPU falls behind, the sound crackles or the screen loses a frame and looks jerky. Historically, to say two processors were object-code compatible simply implied that in finite time, both processors arrived at the same outputs. The faster one would get there first, but both would get there eventually, and for applications such as e-mail, word processing, and so on, that was all users required. Human interface applications were a different breed. Eventually getting a particular video frame of a movie right is not good enough; the processor has to get it right by a certain deadline to satisfy the user. Many of the new IA32 instructions that Merced was struggling to include were aimed at these new real-time applications, and it did not appear that Merced would run those fast enough. So then why was it so important to have those new instructions in the chip? Beyond all that, why would someone buy an expensive new Itanium Processor Family workstation just to run DVD movies on it, in an IA32 format ?4 No matter how you looked at it, the strategy did not appear to be selfconsistent.

  Essentially, the company’s lack of a coherent strategy forced the Santa Clara and Oregon teams into technology and product road map disputes that we had no viable means for resolving. This soured the relationship between the teams, to both teams’ detriment, and I was sad to have witnessed this firsthand. It did not have to be this way.

  Is Intel the sweatshop some people say it is?

  No. And maybe a little bit yes. I’ll explain what I mean, but first, a story.

  In 1984, I was still working on my PhD at CarnegieMellon University, and a large part of my thesis [31] was a deconstruction of Intel’s 432 chip. I had some ideas about why that chip was having trouble getting any traction in the industry, but I needed real data. Fortunately for me, George Cox was Intel’s technical representative to CarnegieMellon, had worked on the i432, and offered to bring me out to Intel’s Jones Farm site in Oregon for a summer to work with the 432 simulators and designers. I did, and the muchappreciated cooperation from company experts such as Konrad Lai and William Bain went a long way to providing me with the data I needed to finish my thesis.

  But Intel in 1984 was a company in trouble [14]. The stock price was depressed, employee stock options were “underwater” and not perceived as very promising, and the overall corporate sales trends were in a free fall. The 432 was not selling well; actually, it was generally regarded as a disaster in the industry [32]. So even though I was pursuing my own work, not immersed in the general design activities around me, there was no mistaking the overall air of gloom.

  But worse than that, there were aspects of the company that made me just shake my head. For example, there was a sign-in sheet if you arrived to work late. The idea was that the company’s workday started officially at 8 A.M. and all employees were expected to be at their desks by then. If an employee arrived at work after 8 A.M., he or she would be requested by the security guard at the front desk to sign a list, documenting the fact that they had arrived late. This list would be stowed after 9 A.M., so anyone who was really late would not have to sign the list. It was not uncommon to see people at 8:45 A.M. sitting in their cars in the parking lot waiting for the list to go away. It was also not uncommon for people to sign the list with alter egos such as Donald Duck, Mickey Mouse, and other names that were probably not in the corporate phone directory. The names on the late list would then be distributed to the slackers’ managers for whatever corporate discipline was deemed appropriate.

  It took only one incident for me to tell my boss I would no longer attempt to honor the late-list scheme. In 1984, the highway intersection with the road to Intel’s Jones Farm plant was not a full interchange. You had to wait in a central turn lane, between the four lanes of highway, for your chance to cross directly in front of speeding vehicles. One morning early in that summer, I was third in line for making that turn when the first car’s driver misjudged the speed of an oncoming Maserati, and clipped its back end. This caused the Maserati to veer toward those of us waiting in line, and when the car entered the median area, it went down into the center ditch, then back up our side of it, became airborne, and crushed the car in back of me. That driver was an Intel employee, as was the person who made the initial error. I told my boss that the only time of day when there was a line waiting at that intersection was just before 8 A.M., because of Intel’s late list, and I would no longer contribute to that problem. He said fine, as he never cared about that stupid late list anyway.

  There were other aspects of Intel in 1984 that were unappealing. For example, there were no bike racks outside, in case you might want to ride your bicycle to work. But that was at least consistent, because there were no showers inside either. Andy Grove used to say he wasn’t running a country club, and that the company owed its employees whatever they needed to get their jobs done, but not more than that. Nowadays, there are exercise rooms, showers, and ping-pong tables. I don’t know if Andy changed his mind about such things, but I do remember unfavorably comparing Intel to other companies at which I had worked. I also distinctly remember driving away from Jones Farm in late August 1984, seeing it in the rear-view mirror and muttering “Thank God I’ll never have to work there again.”

  Fast forward to 1990. Intel still had the exit
bag-checks, but the late list was gone, and there were arrangements with local health clubs for showers and exercise. Things were looking up.

  I have worked at startups and they are immersion experiences. You sign on for the ride, and all you can do is hang on as the roller coaster careens madly around the track for a few years. Your work is your life, and there is not much time left for anything beyond it.

  My experiences at Intel were very intense at times, such as the 3-month push to get the initial P6 behavioral model running, and the 7-month tapeout crunch at the end of the project. But was it a “sweatshop”?

  Intel rewards results. Its corporate structure is arranged in such a way as to identify its top producers and reward them. Native ability, education, attitude, opportunity, experience, and motivation all play roles in how productive a given person can be. But sheer hard work does the rest. If a company has a working performance recognition structure in place, then it logically follows that for any two people with roughly equivalent backgrounds, the one who works harder is likely to be the one who gets the most done, gets promoted soonest, and collects the bigger raises and stock option grants. In that sense, it sometimes seems to people that Intel disproportionately weights time spent working. But for the part of Intel that I knew well, that is a misconception-as managers we worked very hard to recognize results, not hard work per se. Employees who spent a lot of time at their desks but did not accomplish as much as their peers would generally not find themselves on the fast track. So in that sense, Intel did not qualify as a sweatshop.

  In a more subtle way, though, it can feel to many employees as though they are on an invisible treadmill, running about as fast as they can go, when one day their boss sidles up to them and whispers “Great news! You’ve been promoted to Grade 6!” Their immediate reaction is generally joy at this confirmation that their hard work has been noticed, with rewards to follow. But then they realize that more is expected of a grade 6; they have just been put into a new peer group of people who have been operating at a grade 6 level, some of them for years, and their own output will now be compared to this group’s, not the group they had grown comfortable with.

  Some engineers find they either cannot or do not want to operate at this higher level, and trouble may eventually follow in the form of demotions or other disciplinary actions. But most find that the same technical moxie and ability to work hard that got them this far can be expanded and will work again at this new level. All they have to do is apply themselves even harder.

  Little wonder then, that after several years of this, employees may get the feeling that the main reward for success is to be asked for even more output. The company really does operate this way. But thinking in “sweatshop” terms misses the point. The point is that the company continually selects for its highest producers and strives to put those producers into positions of highest output. Personally, I consider this a good thing, but there were times when I could empathize with those who quailed at the long-term pattern this performance evaluation process sometimes evoked.

  How can I become the chief architect of a company such as Intel?

  Part of any manager’s job is to counsel his or her employees in planning their careers. Some employees take career planning very seriously-they know where they want to be and how long they think is reasonable to get there. Most are more like I was. Give me interesting work, creating products that are meaningful, and I will do my best to contribute to them. And if I succeed, my career will take care of itself. At least, I hoped it would.

  I was often asked the question “What must I do if I want to end up with your job?” I used to answer “It’s too late. You had to have been really bad when you were little to deserve this punishment.” (I was just joking; I loved that job during the P6 project.)

  The interesting thing to me was that the questioner was almost always someone quite young, either just out of school or in her early twenties. I no longer remember quite how the world looked from that vantage point, but I know it was much different from how I was seeing things from a 40-something’s perspective. Often, the questioner wanted me to condense the random walk of my own career into a list of just those items that turned out to have been important to my ending up with the chief architect’s job, so that they could then go about collecting those same items on their own resume (and far more efficiently than I). When the last item had been checked off, all they would have to do was wait and an equivalent job would fall into their laps.

  I do not see it that way. If there is one thing I know about the chief architect job, it is that I could not have done it successfully when I was in my twenties. Nearly all of the things I have ever done, including writing code, writing microcode, designing ECL hardware, designing TTL, designing custom CMOS, writing validation suites, debugging hardware in the lab, doing performance analysis, doing technical documentation and presentations, reading magazines and talking to people at conferences, as well as the voluminous nontechnical reading I do, informed the decisions I would make or help make, the directions in which I wanted to take the team or the product, and how I would go about leading the organization. Experience matters, and it cannot be substituted for by intelligence, political acumen, or marrying the boss’s daughter (not that I’ve ever tried that one).

  Find something you are passionate about, and go after it with everything you have.

  In the end, the pattern that makes the most sense to me is this: Find something you are passionate about, and go after it with everything you have. Really apply yourself, holding nothing back, with the aim of achieving excellence, no matter the task, no matter how menial it feels or may seem to others. It may turn out that your real passion lies in designing phase-locked loop circuits, not project management, and if you excel at everything you are assigned, sooner or later you will find that task and end up owning it. The really cool part of doing excellent work is that it catapults you (over time) into the company of people just like you-people intensely committed to success, people you can rely on to routinely turn up brilliant insights, and who will occasionally save your bacon in a most gratifying way. It just does not get any better than that. Do excellent work, and you can write your own ticket regarding what work you would like to be doing.

  Some of you are thinking that “Do excellent work always” is near-vacuous advice; something from Bill and Ted’s Excellent Adventure. I mean something quite specific, though. I mean that no matter what task you have been assigned, take it upon yourself to learn the context for that task. Why was it assigned? Where does it fit in the bigger picture? Why were you asked for a certain result? Is there a better way to achieve what your supervisor was really after? Give her back more than she expected, every single time.’ Sometimes, merely stepping back from the details of the task is all it takes to see a much better course of action. Other times, you just have to slog through the task. No matter what, give every task your entire focus and approach it as though you intend to knock it out of the park. When your management realizes you are reliable in the small things, they will start trusting you on bigger things and your career will jump to a higher energy state.

  Working hard is essential. So is a real commitment to a lifetime of learning, because the field changes so fast that most of what you know is going to be either obsolete or wrong within just a few years. No one can coast and stay at the leading edge.

  But an ability to communicate comes in a close second, in my estimation. If you have a gift for managing people, great that will be very useful to you and much revered by your future bosses. If you are like most engineers, though, you will learn on the job, by trying things and making mistakes. You can rely on good communication skills to pull you through they will help you see when things are not going well, and will help you extract the signal from the noise when your bosses are trying to tell you why.

  Earlier, I argued that Intel’s Operational Excellence iniative was wrongheaded for putting the emphasis on how a product is to be designed, instead of on the product itse
lf. Yet here, I have exhorted you to do excellent work as your ticket to your dream career. I am not being inconsistent; if your task is to paint a building, then you will have produced excellent work when the building looks fantastic upon the job’s completion. OpX would draw your attention to the scaffolding you used.

  Why did you leave Intel?

  I left the company mostly because I was frustrated. I felt that as one of the principals who had led the company to a high-clock-rate x86 strategy, I should have been able to lead it away from that strategy when that became necessary (and we knew from the beginning that it eventually would). But it seemed to me that that time came around 1998, and over the next two years I was unable to even make a dent in the product road maps, all of which called for linear continuation of the various chips we had already designed or which were in the works.

  I was also chagrined that in a company in which everyone was assumed to have read Clayton Christenson’s book on disruptive technology and how successful companies so often keep plying a previously successful strategy well past the point of efficacy, we were doing (in my view) exactly the same thing. And nothing I said to anyone seemed to have any effect.

  I felt that we had hit a home run with the P6 project, and that it was (and is) successful far beyond what anyone had a right to expect. That project was just plain fun, working so closely with so many incredible engineers.

  But the Willamette project was not fun. Part of the problem for me was the design manager, Randy Steck’s successor, with whom I had serious differences of opinion about the chip development process. But an even bigger problem was the corporate interference I have detailed elsewhere in this book. And while I was off trying to keep the company from destructively interfering with Pentium 4 (through quantum entanglement with the Itanium Processor Family) the chip itself was sailing into complexity waters that seem, in retrospect, far too deep for what they were worth. Beyond all of that, however, was a looming thermal power wall that was no longer off in the distance, as in P6, but instead was casting its long, ugly shadow directly over everything we did. That experience was primarily why I was so sure I did not want to work on any high-clock-rate chips beyond Willamette. I just did not think there would be enough end-user performance payoff to justify the nightmarish complexity incurred in a power-dominated, high-performance design.