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

by Robert P. Colwell

  At this point I was struggling with whether to feel annoyed that this guy was wasting my time at 3 A.M. on a Sunday, or amused at how sincerely he was trying to obey his corporate directions and keep me and my phantom neighbors from burning up in an imaginary fire.

  I could feel annoyance getting the upper hand. “If I had the music up that high, it would indicate that I have a very serious hearing loss. And with a hearing loss that profound, I might not hear the normal alarms anyway. What provision has the company made for indicating a fire alarm to putatively hearing-impaired people such as myself, anyway?”

  The security guard looked around, saw the alarm horns, and realized no such provision had been made for the hearing-impaired. He recovered nicely. “We’re not discussing that. We’re talking about violating the company’s rules about listening to music while at work.”

  Annoyance thoroughly trounced amusement, and even sarcasm beat a hasty retreat. “Well, tell you what. I’m going to sit back down, and you’re going to leave my cubicle and go back to your desk at the front door. When you left my cube, the subject had been informed of his violation of a sacred precept of the company, so you can tell whomever needs to know that you did a good night’s work. As for me, when you walk away, I’m going to start the Led Zeppelin song over again, because I hate to start in the middle, and then I’m going to finish the work I came here to do.” (Appropriately enough, the Led Zeppelin song in question was “Communications Breakdown.”)

  A few days later, my general manager, Will Swope, asked me how things were going, and I related this story to him. He was aghast, promised to investigate, and said that in the future security guards would be permitted to approach the engineers only to ask, “Sir, can I bring you a cup of coffee?” I think he really did follow through with that, because the headphones issue never resurfaced. Of course, the fact that all new PCs and engineering workstations were equipped with CD-ROM drives complete with convenient headphone jacks might also have contributed. Intel security may have realized that this was a losing battle.

  As a bonus, a few weeks later, the company added flashing strobe lights to the fire alarm system in that building.

  Exiting the Exit Bag Check

  From its earliest days, Intel had a formal company policy that all bags were to be checked upon exiting the premises. Like many high-tech firms, Intel knew that its family jewels were the intellectual property inside its best products. This IP existed in several forms, such as books, documents, and computer storage media, and the exit bag check was aimed at these targets. Intel also made large quantities of small computer chips that were quite valuable. Presumably, security guards would also be quite interested were they to spot an outgoing bag with a lot of chips inside.

  Whatever its original motivation, by the 1990s, the exit bag check had long outlived its usefulness. Its main effect was to establish a constant line of from five to 15 irritated engineers, all just trying to get home after a very long day. But because their employer obviously did not trust them, they were expected to waste (by actual count) two to eight minutes per evening getting out the door.

  The security guards tried hard to implement a consistent policy for bag checks for all U.S. sites. Unfortunately, it was pretty stringent, and the laptop bag I was using had nine zippered compartments. So every single night, the guard would exercise all nine zippers while I and everyone behind me did our best to enjoy the spectacle.

  It got worse. In the mid-1990s, CD-ROMs became a popular way to distribute software, and writable CD-ROMs became common. In my laptop bag was a CD-ROM carrying case containing a mix of software, backup copies of presentations and other files, and music CDs. Every night, as the guard rummaged around in my bag, he or she would find this CD case, and feel obliged to open it and check the identity of each and every CDROM. Some guards also shared their opinions of my musical tastes, which I often found difficult to appreciate.

  One night, I became exasperated with the CD-ROM part of the search and asked, “Exactly what is it that you’re looking for in that CD case?”

  The security guard said, “We have a report that a particular CD-ROM was stolen a few months ago and we’re watching out for it.”

  “But the only way you’re going to find it that way is if the thief is a certified moron. Do you see that rectangular piece of plastic on the side of my laptop? That’s a CD-ROM drive. Since the laptop is not powered up, you can’t see what’s in that drive. How do you know the CD-ROM you’re looking for isn’t in that drive?”

  The guard looked wary, but interested. “Is it?”

  “No!” I exploded, “And that’s not the point. See all these people in line? They all have dial-up or cable access to Intel’s computers from home. If they’re not smart enough to get the information off the CD-ROM you’re looking for and get that data to their homes without your knowledge, then they’re not smart enough to work here.”

  I realized I was yelling at the wrong person. The guards do not make the policies; they just implement what is handed down as best they can. I decided to change tactics and go after the policy makers.

  I started sending e-mails to higher-ups, trying to figure out who was in charge of company policies about security and exit bag checks. I firmly believe that policies affecting the entire company on such a fundamental basis must be decided with the participation, or at least the full understanding, of the company’s workers, never secretly or in a vacuum. Allowing small, secret groups to quietly determine general policies virtually guarantees irrational acts and inefficiencies.

  For the next few years, I routinely traded e-mails with various company policy makers, urging them to rethink the exit bag checks and to clearly post the rationales for the various exit checks still being inflicted. I got a lot of encouragement from my coworkers. One very senior engineer told me that he had long ago decided to test the exit bag check policy by simply refusing to cooperate with it. When he first did that, he assumed it would bring the issue to a head and the company would undergo the appropriate internal debate. But instead, the security guards passed the word that this person was to quietly be allowed to go out without the check.

  I thought that was a fascinating insight into the effectiveness of the whole scheme, but it was not helping me. I did not want special treatment, I just wanted the whole thing to go away.

  Then I visited Intel Israel. The first time I left the plant in Haifa, I put my bag up on the counter and waited, as I had been trained to do over the years. The security guard looked at me strangely and shrugged his shoulders. They didn’t do exit bag checks in Israel! (Years later, I was told that they used to do them there but stopped for some reason.)

  When I got back home, I fired off another e-mail to the security policy folks, in which I wrote, “I think it’s important that the general engineering population in the U.S. be notified that American engineers are, by official corporate policy, much less trustworthy than their Israeli counterparts. I bet they don’t know that, and they have a right to know.” Evidently, the policy makers did not agree with my proposal, because no such memo was issued, but they uncharacteristically did not try to refute my point in private, either.

  The entire matter came to a head months later, when I was in the exit line behind an Intel VP carrying a large legal briefcase stuffed with documents of all colors and sizes. I sighed; this search was going to take 5 minutes all by itself. But to my astonishment, the VP put the bag down, flashed something in his hand and immediately went on his way. I asked the guard what he had shown to avoid the bag search. The guard refused to answer the question, but I was determined. “Is there some secret pass? How does one qualify? Do you have to take a lie-detector test, or get special ethical training? Would a note from my mother suffice?” The guard looked very uncomfortable, but would not talk. Now I was really intrigued-after all the e-mail I had traded with the security officials, nobody had ever even hinted at special secret passes.

  So that night I sent an e-mail message to my general manager, w
ho, as it turned out, also had a secret pass. When he offered to get me one, I refused and said that I preferred to fix the whole stupid system instead. I again appealed to the policy makers, writing, “Well, it turns out that the U.S. engineers not only are less trustworthy than the Israelis, they’re also less trustworthy than people above grade 11, because that’s the threshold for applying for the secret pass. Our employees have a right to know these rules.”

  The policy makers responded that upper executives had begun finding it embarrassing to have their non-Intel guests searched on the way out. I wrote back, “Then those executives now know exactly how annoying, condescending, frivolous, intrusive, and embarrassing those same checks are to the people who actually work here, except that we have this done to us each and every day.”

  I got back an odd response that essentially said, “This problem is going to go away.” A week later, the exit bag checks were gone. I don’t know if I should get the credit for this, but I certainly lobbied tirelessly to make it happen.

  Sailboats and Ditches

  Many management books recommend “teambuilding exercises,” in which groups of people who normally work together professionally get to interact with their peers in new ways, while climbing a mountain, playing paintball, and engaging in other activities not normally found in their job descriptions. Intel provides many such opportunities, but when these activities are executed from within the normal hypercompetitive Intel culture, they do not always have the desired effect.

  I once attended an off-site meeting in Monterey, California, for the leaders of all microprocessor development activities within Intel. The concept was that we would split into groups of six, and each group would take a sailboat out to a designated figure-eight racecourse. The first one back to the docks won.

  As my boat left the docks, its owner asked if any of us had sailed before. I’m no expert, but I have had a sailboat for many years, so I raised my hand. No one else did. But someone else immediately leaped up and said “How hard can it be?” and took over. Within a couple of minutes, we were becalmed, watching the rest of the boats sailing serenely out to the racecourse. Judging from everyone else’s sails, there was not a surplus of wind anywhere on that course, but at least they were moving. Now that we were in irons, sailing ability did not matter much, so everyone took a turn at pretending they were Captain Ahab, looked enviously at the sailboats in the distance, and muttered about the would-be captain who had got us into this predicament. Never mind that any of the others would probably have accomplished the same outcome. Finally, one VP had an inspiration, “The rules are that we were to leave the docks, sail around, and the first one back wins, right? So let’s wait until the right moment, start up the motor, and cruise into the harbor just ahead of the otherwise-fastest boat. We will have met all of the requirements.” We thought he was kidding, but I really do not think he was. Nobody else had any better idea, so that is what we did, or rather what we tried to do. The event’s organizer knew his staff too well, had anticipated shady maneuvers, and had provided a spotter on the pier, who ruined the plan. How this kind of behavior was going to meld us into one high-output team was a little hazy, but nobody seemed surprised or at all worried about the idea of putting winning ahead of competing fairly.

  Not that I am immune to ignoble competition. At another off-site meeting, we rented 12 full-motion flight simulators and flew two teams against each other. If you were shot down, you would be reincarnated a minute later, often in the same spot, about 2000 feet above your aircraft carrier. One of my counterparts within Intel, a guy whom I routinely found on the opposite side of whatever I thought was right, was flying for the other team and had shot me down at least twice. He would anticipate where I would be reincarnated, wait there until it happened, and then shoot me down again before I had a chance. This was infuriating, so I devoted the rest of the evening to finding that guy and shooting him down. I beat him, but not overwhelmingly.

  The only way to restore the cosmic balance was to completely annihilate him, so the next several times I happened to be in Santa Clara, I went back to that flight simulator facility and practiced, for hours. A few months later, we had another off-site meeting at the same place. The same guy showed up on the other team, and I waxed him to my heart’s content. I also felt good about having learned Intel’s teambuilding methods so thoroughly.

  The paintball exercises were probably the least successful and shortest lived teambuilding experience. It became abundantly clear that not only were they failing to achieve any higher goal, but they were positively counterproductive. In Israel, everyone gets military training, and the Israelis on staff were joining the same team, and applying that training with relish. One exercise ended with a VP cowering in a ditch, while several members of the other team blasted away at him. Even worse, when Intel people heard of this incident, they were first appalled, but once they learned the name of the VP in question, they thought that, overall, justice had been done.

  I learned two valuable lessons from these teambuilding exercises. It can be very hard to turn off competitiveness, and payback is, well, you know what they say about that.

  Orbiting the Bathrooms

  Intel has a formal policy called “Copy Exactly,” which led to such great results in the chip fabrication plants that the company tried it in many other corporate areas.

  One such area was building design. Intel’s Ronler Acres buildings in Oregon have the same floorplan as those in Jones Farm or the Folsom site in Sacramento. When you travel, this homogeneity is great, because it is easy to get your bearings in a strange building.

  The trouble is that one size seldom fits all, no matter what the little tag on your T-shirt says. After we had moved into the Ronler Acres buildings while designing Pentium 4, the male engineers discovered a problem, one that many women will recognize, having endured it much more frequently: not enough bathroom capacity. The building’s bathrooms were designed to handle a 50/50 mix of men and women on a fully populated floor, but they most emphatically could not accommodate a design team that was 80% male and that had compressed their offices, thereby boosting “fully populated floor” to well beyond expectation.

  This mismatch of capacity and demand led to a daily ritual, wherein the male design engineers would go into one bathroom, find a line of men waiting, and head out to the other bathroom. What they did not yet know was that the same scene was playing out at the other bathroom, generating a similar line of unhappy engineers heading toward the bathroom they themselves had just left. In effect, there was a continuous loop of uncomfortable engineers orbiting the two bathrooms instead of designing silicon.

  As a project leader, it seemed obvious to me that this was a tragic waste of human potential, stemming from a really stupid source that all buildings had to be designed the same way regardless of intended use. I brought this issue up at a divisional staff meeting, but got surprisingly little support. In fact, the finance guy, the person you would think would be most annoyed at hearing how highly paid engineers were spending substantial fractions of their day, thought the whole thing was so funny that he bought a toilet seat, spray-painted it gold, and installed it on the chair in my cubicle. I was seriously tempted to go buy the rest of the commode, install it in his cube some weekend, and put the golden toilet seat on as a finishing touch. The problem eventually seemed to subside, but I never knew why. Perhaps everyone stopped drinking caffeinated soda after the project taped out.

  MANAGEMENT BY OBJECTIVE

  From ten thousand feet up, the overall flow of a chip development project (even those as massive as Intel’s) and the technology it is developing are reasonably clear. You form a team, acquire or develop the necessary tools, conceive a design, implement it, and validate the result.

  You cannot run a project from ten thousand feet.

  But you cannot run a project from ten thousand feet. Projects have to be executed from the trenches because only from there can you see the myriad details the team must resolve. For this reas
on, and to strike a reasonable compromise between overhead and benefit, Intel mandates the use of iMBO (Intel Management By Objective). Andy Grove described the genesis of this idea in High Output Management [16], in which he points to two key questions that any management planning effort must address: What is the right target, and how can I measure my progress toward that target?

  iMBO’s basic idea is to list a set of objectives the team must accomplish over a quarter. These are things that if left undone might jeopardize the project’s overall schedule. Typically, a manager identifies four to eight objectives, some carried over from the previous quarter, especially if they were on the previous quarter’s list, but are still not complete. The manager also identifies a set of activities by which to judge that objective’s completion.

  What I found worked best was to “seed” the next quarter’s tentative iMBO list with my own ideas, and then spend 30 minutes of staff time discussing them. Almost always, the team had valuable inputs on which objectives were the best ones for the next quarter, and how those objectives could be achieved and measured. This discussion was often the most valuable aspect of the whole iMBO method.

  The other very valuable fallout of using iMBOs came during the quarterly review of how last quarter’s results should be judged. Each quarter, the team that had taken the objective assesses how well they have accomplished it, essentially “grading the quarterly sheet.” A graded quarterly key results sheet might look partially like this:

  Graded Q4/92 Objectives/Key Results, P6 Architecture

  Objective: Complete BRTL development, AMB:

  1 1. Run 95% of all Real Mode tests on BRTL, except for BBL, EBL, DCU, and MOB.

  0 2. Run BenchmarkA and BenchmarkB on full model.

  1 3. Resolve all SRTL gating issues.

  1 4. Resolve 15 simplification issues.

  And so on, for typically 4-6 objectives and 4-6 examples under each.