The P6 team had those qualities. We relied heavily on Randy Steck’s excellent innate managerial instincts and constant drive to improve and a very experienced senior technical leadership who didn’t have to be told what to do next. We also had an entrepreneurial slay-the-dragons-as-they-appear resilience and a willingness to try new things. In the end, P6 turned out the way it did because an incredibly talented design and architecture team was fervently committed to making it a success.
I am not implying that we necessarily knew more than other project managers, nor am I suggesting that ours was a better approach than any project management book would propose (although I am sure it was better than some). I simply want to relate what we did, why we did it that way, and how it turned out.
The P6 team is on every page here, either directly in an anecdote or as the substance of a lesson learned-a lesson that can be passed to other determined project engineers. In the chapters that follow, I hope to show that an amazing combination of intelligence, wisdom, stubbornness, and ambition made P6 what it is, and in the computer business, or any business for that matter, excellence is a critical prerequisite to success.
2
THE CONCEPT PHASE
“On the hardware side, it’s nearly a science…. You can almost predict the timetable by which you can do developments. But on the software side, there’s so much genius and creativity that you can’t predict when it’s going to happen. “
-TV announcer, introducing Intel’s new P6 chip
The concept phase is the quintessential architect’s phase of a project. Get it right and the rest of the project has a good chance of flowing smoothly. Get it wrong in any number of ways and the project is in big trouble (and you probably won’t find that out until it’s much too late to recover in any graceful way).
Many people imagine the concept phase to be a group of brilliant people sitting around a small circular table, intently watching each other’s faces. “Did you think of anything yet? No? Neither did I…. How about now?”
This is not how it’s done.
On the other hand, people have plenty of room for pure inspiration and opportunities to simply enumerate all the ways a given task could be accomplished and hypothesize which is best. Intense brainstorming can last from days to months. Of course, not all the possibilities from a properly run brainstorm will be equally plausible, and the weeding-out process will begin immediately.
OF IMMEDIATE CONCERN
Senior engineers have very high leverage during this phase and must be careful not to accidentally or arbitrarily constrain the project’s “solution space.” They can commit any number of grievous errors, such as doing the mathematical equivalent of choosing a lo cal optimum instead of the global one their competitor found. In the worst case, they could choose an overall product approach that two years later turns out to be technically infeasible, forcing a major reset to the project and wrecking its schedule and morale. In It Sounded Good When We Started [4], Dwayne Phillips and Roy O’Bryan relate a story of an engineer who became so infatuated with using a particular handheld computer as an input device that he stuck with it tenaciously for the real product through several distinct phases:
1. It’s a cool gadget. It adds panache as a controller for the product and nobody minds the serial cable required.
2. The gadget is not as cool as new laptops that are coming out, but it’s still usable.
3. Producer switches from original handheld to new laptop, but sticks with the old MS-DOS environment because of earlier handheld choice. The cable is becoming a real hindrance.
4. The engineer is gone, the handheld is gone, and the now-hated cable is the only thing remaining.
Another error is to overlook something in the competitive landscape. Some product feature that used to be minor could now be a primary selling point, but the current design choices hinders its use. In Small Things Considered [6], Henry Petroski describes how Volvo learned that the rules concerning cupholders in cars had changed. In only a few years, cupholders went from being irrelevant curiosities to absolute requirements, and to the consternation of auto designers everywhere, their placement and usability have become important factors in the buying decision.
Fortunately, what conceptual errors we made in the P6 project turned out to be of the nongrievous variety. But we did make choices that had implications we did not fully understand at the time. For example, we chose to put the L2 cache’ into the same physical package as the P6 microprocessor itself because of the substantial performance advantage this arrangement provided. That expected performance advantage turned out to be real and was a major factor in P6’s suitability for servers and workstations, which were new markets for Intel in 1995. But at the time we chose to pursue this “two-die-inpackage” strategy, we did not fully realize how difficult it would be for Intel’s manufacturing plants to build this way. It turned out that the usual automated machinery that places bare silicon die into ceramic packages could not be used with the dual-die scheme, and human thumbs had to do the job. This would have severely limited production capacity had it become necessary for the original Pentium Pro to be shipped to volume desktops. As things turned out, we were okay-the Pentium processor held the desktop market long enough for the single-die follow-on part, the Pentium II, to become available.
SUCCESS FACTORS
There are no guarantees, but the chance of a successful concept phase is much higher if you start with clear goals, choose the project team wisely, and pay attention to the mechanics.
‘Cache is a fast memory array that the processor uses as a temporary scratchpad. For implementation reasons, it’s often efficacious to design not one large cache memory, but a hierarchy of caches: a small but fast L1, then a bigger but slower L2, and so on.
Clear Goals
If a project does not have crystal-clear goals, under no conditions should the team begin anyway in the hope that “someone will come up with something.” A team launched into the void with no compass and no map will succeed only at floundering and wasting time. To the uninitiated, the ensuing blur of activity might appear to be what a competent team does as it churns successfully toward its goal. Don’t be fooled. What you are really seeing is money being turned into useless Brownian motion at a macroscopic level.
Architects pointed toward an agreed-on goal are far more likely to get a lucrative idea. They must be able to answer these questions above all others: What constitutes project success, and what constitutes failure`? The art of all engineering is compromise, trading one thing for another. Such trades can be intelligently made only according to some weighted scoring of all major project goals. For P6, we had a schedule, target die size, target performance (on many benchmarks), and power dissipation budget. Later, we developed a clock frequency target as well.
Architects must be able to answer these questions above all others: What constitutes project success, and what constitutes failure?
When we started the P6 project, performance was our primary target. We wanted to double the P5’s performance. We guessed (correctly, as it turned out) that if we found a way to hit that target, we could engineer solutions to other targets along the way. Conversely, if we did not have enough performance to constitute a viable product, then merely hitting the schedule, power, or die size targets would not be enough.
Never assume that all team members have the same implicit goals. If there is a chance for any two people to miscommunicate, assume that they will find it. Write the goals on a giant poster in order of priority and have all team members walk past it to get to their meetings. Projects that don’t know what their goals are have no chance of hitting them. Intel general manager Pat Gelsinger believed in this so strongly that he had a habit of walking up to design team members and saying “Quick! What constitutes success for this project?” If they couldn’t simply rattle off a coherent answer, it meant they hadn’t completely internalized the project goals.
Never assume that all team members have the same implicit goa
ls.
You might feel safe in assuming that at least corporate management understands the project and its major product goals. After all, they initiated the project, they staffed its leadership positions, they established the schedule and budgets, and they have responsibility for other corporate projects that this one might affect. Besides, they hold a highly visible position in the company, which they would not have if they had not had some amount of competence, right? Right, but these assumptions can lead you to wrong conclusions. Executives have a lot on their minds, and things change rapidly across the corporate landscape as well as the competitive arena. Just as they tell you what to do, they may have their bosses telling them what to do. And the advice they’re getting and giving may be mutually inconsistent. Consider this actual dialogue: “Now that the chip performance appears to be among the best in the world, it’s time to make the chip consume the lowest power as well.” At this point, you might be tempted to reply sarcastically, “Why not a cure for cancer?” Resist, or they will add that to your list of deliverables.
Figure 2.1. The road to the project POR.
Our solution was to establish a formal project document, a project-wide plan-of-record (POR), which was our official response to what upper management and marketing were requesting of our new design. In past projects, upper management blessed the marketing document (actually a set of Powerpoint slides) and simply expected that to be the new plan-of-record. But as technology became more complicated and the tradeoffs more subtle, we found it necessary to write our own document, containing our best estimates of feasible schedules, required headcount, new tools, the competition’s likely offerings, the general direction of the project design, and so on. Some of the project-level interactions associated with POR are shown in Figure 2.1.
Marketing and management will not usually ask for a combination of features, cost, and schedule that are simultaneously realizable count on that. They will reliably ask for the impossible. They do this for several reasons. In a business as lucrative and fastmoving as microprocessor design, aggressive risk-taking is a given, virtually a requirement.’ Moore’s Law was once a farsighted prediction, but by the 1990s it had become a self-fulfilling prophecy. It’s a very short step from using Moore’s Law to check your road map to using it to dictate the road map. There are also subtle interplays between the vari ous project goals (performance, power, thermals, schedule, cost), which may not be entirely obvious even to the design team, let alone marketing or upper management.
So our Product Implementation Plan was essentially our proposal of the best compromise that we thought was feasible. After several negotiation rounds with both marketing and management, this document became the project POR, and was signed by all concerned, especially design management. The POR changed throughout the project, but it was much better to have an established, agreed-on starting point for such changes. (How to control changes to the POR is an important topic in the “Engineering Change Orders” section in Chapter 3.)
The Right People
Marketing and management will not usually ask for a combination of features, cost, and schedule that are simultaneously realizable.
The senior leadership of any design project is the single most important predictor of project success, bar none. These are the people the project will count on to keep it on track. They must routinely select a workable path from among a forest of alternatives, most of which eventually turn out to be untenable. Project leadership must constantly check the project’s progress and goals against the competition, monitor the effects of previous decisions, make repairs as necessary, and directly intervene in the actual design when only supreme technical wizardry can transcend the next roadblock.
The senior project leaders must not concern themselves only with technical issues. When they propose a block diagram at the beginning of a project, they are writing a check that the designers must be able to cash in the time allotted to the overall project. Therefore, the senior leaders ask not only, “Is this approach technically feasible? Can it be built?” but also, “Can this particular team build it?” while avoiding the trap of imagining that the whole team operates at the same intellectual and experience level as they do.
P6 Senior Leadership. The concept phase for Intel’s P6 microprocessor lasted approximately six months, from November 1990 through March 1991. Five architects drove this phase: Dave Papworth, Glenn Hinton, Michael Fetterman, Andy Glew, and I. Dave was a senior hardware architect with whom I had worked at Multiflow Computer from 1985 to 1990 and is probably the most brilliant design engineer with whom I’ve ever had the pleasure to work. Dave has an uncanny gift for identifying (frequently on the basis of scant clues) which of many possible avenues for solving a given problem are most likely to pay off. This gives a design project an enormous mechanical advantage over the possibility space, in that the team can quickly abandon less-promising choices so as to concentrate on the one that will eventually become the POR. Glenn is a genius at creating his way out of whatever corner the project has inadvertently painted itself into, a role he fulfills with aplomb and abundant good humor; he is a joy to work with. Michael was a recent college graduate (RCG, in Intel-speak), but had some industry experience and was so bright and unafraid to speak his mind in any engineering context that he fit into our team immediately. Michael also had the charming and absolutely essential ability to gracefully give suggestions to his boss (me) on how to improve my software without covert snickering or outright laughter in the process. Andy was an idea fountain; mention a problem and he’d instantly recite the seven known ways to solve it and then invent four more sponta neously (at least two of which would actually work). His intellectual energy was extremely valuable to our conceptualizing.
The composition of the concept phase team was crucial to P6’s success. The three senior engineers (Dave, Glenn, and I) kept the project pointed in promising directions and retained the confidence of Intel’s upper management so we could make the right decisions without undue corporate overhead. We also worked hard to prevent oversubscription. We wanted to push the technology as far as it could reasonably be pushed, but without burning out the design team, missing schedule deadlines, or sacrificing any success-critical features.
We CPU architects also benefited tremendously by having Gurbir Singh, who had designed the system bus for Intel’s i960 chip. We gladly delegated essentially all the systems considerations for P6 to him. While we focused on getting the out-of-order core right, Gurbir and his team handled our chip’s interface to the rest of the world. (Although this worked wonderfully at a technical level, our belief that we had the right to design our own chip interface led to later political problems. See “Another One Rides the Bus” in Chapter 3.)
The senior leadership steered an aggressive path, but also purposely worked to keep the project out of trouble. The two junior engineers (Michael and Andy) brought new insights and the latest thinking from elsewhere. Their constant questioning of the senior engineers spurred us to higher and better planning throughput and generally kept us from thinking too much inside old boxes.
Setting the Leadership Tone. Nothing is more corrosive to overall design team morale than perceived disarray in the senior project leadership. What engineers do is hard work and their intellect is generally well above average. From there, it is but a short step to an unrealistic self-image. For senior leaders to work together without debilitating ego clashes, they must strive for mutual respect. If they respect each other, they will find a workable arrangement among themselves. If they do not, the VP responsible for the project must take action because the senior leaders will not remain in a project in which they are not getting the respect they require to succeed.
Most or all decisions made at the leadership level will threaten one or more key project goals.
Project leaders must be both resilient and resourceful and they must recognize that they are not going to be given the easy questions the ones that get answered at lower levels in the project hierarchy. Most or all de
cisions made at the leadership level will threaten one or more key project goals. There will be no reliable data on the possible avenues for resolution and little time to collect much more. As the project progresses, the choices get tougher, because time is shorter and the degrees of freedom are fewer. All this argues for good judgment up front. The project leaders must reserve enough design margin (but not so much that they are “sandbagging,” which can also kill a project) in the early stages that they have room to maneuver when the surprises appear later.
One of the main reasons I enjoyed the P6 project so much was precisely because the architects naturally avoided ego clashes. I can remember only three cases in which even trivial friction arose between us. The first was very early in the project, when it became clear that a prospective senior architect was coming up short in the teamwork department and, fortunately for all of us, decided to pursue other activities. Another was when a fel low architect chose a particularly unfortunate time to stick his head in my cubicle and opine that I was driving the team too hard. He may have been right, but I had just stayed up all night working on the design and was not in the mood to consider whether it had been a pointless sacrifice. I kicked him out of my cubicle and asked him to come back when I could be rational about the issue, a process that took about a week. The other time was when our manager, for reasons I never did understand, dragged Glenn, Dave, and me into a conference room to inform us that if we ever reached an impasse on a technical issue, Dave’s vote would prevail. We all just looked at each other, shrugged our shoulders, wondered what management book had prescribed this intervention, and went back to work. The feared impasse never did arise.
The Pentium Chronicles: The People, Passion, and Politics Behind Intel's Landmark Chips (Practitioners) Page 4