None of this was particularly alarming. After all, our recruitment process was accomplishing its basic mission of finding good technical talent. Asking it to also predict which candidates would excel at climbing the corporate ladder was beyond what we needed. But when we discussed the implications of my correlationless findings, it was still worth asking, “If a candidate’s background and training doesn’t lead to corporate success, what does?”
We concluded that no single quantifiable metric could reliably predict career success. However, we also felt that fast-trackers have identifiable qualities and show definite trends.
One quality is a whatever-it-takes attitude. All high-output engineers have a willingness to do whatever it takes to make a project succeed, especially their particular corner of it. If that means working weekends occasionally, doing extracurricular research, or rewriting tools, they do it.
Another quality is a solid, unflappable understanding of all the technologies they are using or developing. No one person can know everything, but fast-trackers have the drive to familiarize themselves with all aspects of their work, even those that are not required for their immediate task, and this gives them the necessary credibility to discuss their design with project experts, which in turn drives them up the learning curve that much faster. Finally, these high-output types seemed to innately grasp that they are members of a large team, which means that certain behaviors are very efficient while others are counterproductive. They know, for example, that the classic elbow-your-neighbor scramble up the corporate ladder does not work in a large design team that is competently managed, so they avoid that tactic. Instead, they are the ones always helping everyone else, sometimes directly and sometimes by sharing tools or tricks they have learned or developed.
When we can identify these high-output traits in an interview, maybe we will be able to confidently predict career trajectories. Until then, at least we know not to trust any of the obvious predictors, even education level.
Firing
About the least fun you can have as a manager, unless you are Donald Trump, is to fire someone. And with a team as large as the P6, despite your best efforts at hiring only people you believe will be barn-burners, every manager will eventually have to deal with an employee who simply is not getting the job done in an acceptable way.
About the least fun you can have as a manager, unless you are Donald Trump, is to fire someone.
Just as a stellar performer’s glory tends to make his manager look good, a poor performer tends to drag down everyone around him. Large companies must have a process they can use to identify underachievers and help them get back to an acceptable output level. Failing that, there must be a way to remove from the design team and the company those who are not pulling their own weight. You might think that underperformers do not enjoy their reputation and are already making plans to leave. Unfortunately, that is not so; people with that much initiative tend not to get into performance trouble in the first place.
Except in television sitcoms, the trouble is not people who simply do not show up for work, or who take three hour lunches and then leave early. People who are that far off their required output are easy to deal with. The difficult cases are those in which a formerly competent engineer has been promoted beyond his comfort zone and has not adjusted to the new expectations associated with the higher pay grade.
The difficult cases are those in which a formerly competent engineer has been promoted beyond his comfort zone.
Intel’s pay grade scheme is intended to associate an employee’s overall compensation with his or her contributions to the corporate bottom line. Intel calls this process a meritocracy and reminds every employee, including support staff, that all employees are expected to continually improve their performance and that they will be formally evaluated once a year to establish that they are keeping up with their peers [27].
As a manager, you often supervise people representing several pay grades. You have a reasonable working knowledge of what tasks are appropriate for which employees (otherwise you would not be an effective manager, which would not bode well for your own performance evaluation) but day to day, your group’s pay grades are immaterial. The focus is on allocating the required work among the group in a way that gets it done in the required time.
The surprise comes when you attend the yearly ranking-and-rating (abbreviated as R&R) session on behalf of each of your team members. Suddenly, the members’ pay grades are extremely relevant because that is the basis on which their output will be evaluated vis-a-vis their peers in other groups. Few things are as poignant as a manager’s dismay when he realizes that the person he has been giving nothing but kudos to over the year is not doing at all well relative to those of the same pay grade in other groups. The manager often feels somewhat guilty, and more than a little duplicitous, because that employee contributed valuable output toward the group’s bottom line and now will not receive the expected reward.
There is no arbitration for this. The manager must accept that he or she neglected to take the employee’s pay grade into account in assigning tasks or simply did not notice or could not tell where the norm was for that pay grade. Now, instead of a raise, the employ ee will be getting feedback that those valuable outputs simply were not up to the quality or quantity of the employee’s peers in that grade. The manager is probably thinking a root canal would be more enjoyable.’
The company’s formal process for recalibrating the employee is a three-to-six-month “recovery” plan. A lot more direct supervision is involved-daily meetings in some cases-and careful record keeping. In many cases, this direct coaching is all the employee needs to get up to snuff and improve his rating at the next R&R. But occasionally, even the direct help, which can verge on micromanagement, does not fix the problem and the manager must resignedly conclude that the employee is simply not capable of operating at the current pay grade. A strategy that works in a surprisingly large fraction of cases is to demote the employee back to the pay grade at which they were successful.
Still, there are some cases in which a demotion is not appropriate, or the employee will not accept it. That leaves firing as the only option. It is not pleasant to have to walk someone to the door-not for them and not for you as their manager. Occasionally, an employee will thank you for having gone the extra mile in trying to get them back on track, and they will have realized that they simply were not a good fit for your group and should try something else. But if my experience is any guide, most will be upset, angry, fearful, and in the mood to tell you how you could have managed them better and how this is all your fault, not theirs. Those are the days when, try as you might, you cannot remember why you ever took a management job in the first place.
I once went through this course of events with an employee, a person who worked for someone who reported to me. After we both tried hard to modify his behavior and get usable output from him, we ended up walking him to the door. On the way, he regaled us with stories of how we had screwed up his life and how his only mistake was to have had the unbelievably bad luck of getting us as managers. It took a couple of weeks for the bad taste to go away, just long enough for another manager in Intel to (believe it or not) rehire him. Apparently, this manager had seen that his new employee was newly fired, but did not see fit to call me and ask what was behind the dismissal. Although this particular employee had not generated much legitimate technical output, he was more than capable of making a hash out of our chip design database had he been revenge-minded. Fortunately, he was not, but had it been up to me, the manager who blindly rehired him would have also been walked to the door on the grounds of selfevident incompetence and unjustifiable risk taking.
POLICY WARS
From time to time, project realities clash with corporate’s idea of what the company should be doing at this particular time. During the P6, we encountered many such disruptions in the space-time continuum, and it is my fondest wish in sharing these stories that they inspire policy makers to wa
lk around the hallways and observe operations before launching company-wide edicts.
Corporate Disincentives
Chip development projects or, for that matter, any product development I have ever been part of, always feel like a log flume ride at an amusement park. These rides begin with a long uphill climb, where things happen rather slowly and the fun is minimal. Then the log-boat floats around several curves, with lots of gratuitous splashing and generally nice views, but it does not feel like you are going very fast or getting anywhere. Then you see the final drop off and time speeds up. The sense of inevitability mounts, and you have the distinct feeling that you are committed to getting to the end of the ride no matter what. (In Disneyland, animatronic bears and raccoons happily shout out that it is too late to do anything but hang on and wait for the finish, and why would you get on this ride, anyway? Chip developers everywhere will recognize that sentiment.)
In the “pre-drop-off” frenzy, key engineers are spending every waking moment working, whether at the plant or from home. Unless you can get a team to this tapeout crunch, death-march phase, you have no hope of meeting your schedule. Nature will conspire to throw obstacle after obstacle into your project’s path, and the only way to prevail is to have every hand on deck, actively resolving issues as they arise. These crunch phases typically last six months, although I have seen them go on for as long as a year. Some would argue that you can do the entire project in crunch mode, but you surely risk burnout and then you would get the exact opposite of the efficiency you are seeking.
We were in the P6 crunch phase when word came down of a new corporate initiative, effective immediately. The initiative, “Back To Intel Basics,” was an attempt to recapture Intel’s history, in which every employee was required to be at work by 8 A.M. and those arriving between 8 and 9 A.M. had to sign a late list that their supervisors would see. I never understood why highly paid professionals competing on the world stage would require such babysitting or deserve that kind of official condescension from upper management. Luckily, I had managed to miss that era because they had gotten rid of that onerous absurdity before I started in 1990.
But I was getting a chance to relive that period four years later. Thanks to the new initiative, employees who could not be at work by 8 A.M. would need to provide a written explanation to their management. And we managers were to explain this new policy to the troops.
I objected vociferously. Half our engineering team had still been on the premises at midnight the night before, yet they were expected to be back by 8 A.M.? That was obviously ridiculous, and I could easily predict their reactions. “Sure, boss, from now on I’ll be here at 8 A.M. And I’ll leave at 5 P.M. I have no problem cutting back on my hours!” I respectfully declined to participate in this management error. But I was reminded that when I accepted a management position, I also implicitly agreed to pass legitimate directions from said management to my team. So I agreed to tell my team “I have been instructed to tell you that anyone who cannot be here at 8 AM is required to give me a written statement as to why.” When I told the team that, in exactly those terms, they all looked puzzled. One finally said “If we write the memo in question, what would you do with it?” I said I would throw it away without reading it and that I trusted they were all adult and professional enough to know how to get their jobs done. I never heard another word about it.
Other corporate initiatives included a serious infatuation with Stephen Covey’s 7 Habits of Highly Effective People [33]. There were books, videos, and courses. I don’t think we were ever formally measured on whether we had taken Covey training, but it was not far short of that. The idea of a win/win did permanently enter the corporate lexicon, and I think it was a great antidote to Intel’s historical “constructive confrontation” procedure, which was sometimes wrongly interpreted as official corporate sanction to say whatever you wanted to a coworker.
A corporate initiative that I particularly disliked was, “Do chips in half the time with half the people.” Talk about an unfunded mandate! The executives could just as easily, and with the same effectiveness, have promoted an initiative for each electron to carry twice the normal charge. As goals go, at least that one would generate interesting discussion, and in that context might even have useful outputs, but as a requirement from above, this kind of wishful thinking is very dangerous. Well-run design teams that mean what they say would be unable to commit to this target, but poorly managed teams might succumb to the everpresent temptation to tell management what they want to hear. For the next few years, that second-rate team would be the darling of the company, until the day they had to deliver the new design. At that point, everyone would realize that the team did indeed achieve a design with half the labor in half the time. They just forgot to create a viable product in the process.
An Intel initiative for several years now has been “Operational Excellence,” or OpX. The basic idea is to execute well make and meet commitments, do not accept mediocrity, and strive for continuous improvements across the board. So what’s not to like about that? Plenty, but none of it is obvious, and therein lies the danger.
OpX emphasizes exactly the wrong thing. What makes companies like Intel successful is creating profitable products that compete well on the open market. The customer who plunks down hard-earned cash for an Intel machine does not ask, “How did you design this chip?” The product must stand on its own. In the final analysis, it does not matter how it was conceived and executed. You do not ask Johnson & Johnson how they made their cotton swabs, and you don’t ask Pepsi how efficiently they formulated their soda. The only thing that matters at the point of sale is how good a product is and how much it costs, and that is where a design team must focus their attention.
Richard Feynman tells the story of the “cargo cult,” a South Seas people who, in World War II, got used to having big airplanes land with lots of valuable things inside [18]. They wanted this to happen again, so they lit fires down the sides of the runway, built grass huts with bamboo sticks arranged like a radio antenna, and provided an islander to sit attentively with fake headphones on his head. But the planes did not come. The islanders had mistaken appearance for reality.
The insidious aspect of OpX is that when a team does create a world-class product, much of its development was indeed performed in ways congruent to OpX’s goals, but in spite of OpX, or independently of it, not because of it. A good design team will naturally make and meet commitments, not accept mediocrity, and strive for continuous improvements across the board in their pursuit of a world-class product. They do not need OpX to spur that thinking.
Conversely, teams that have not conceived a world-class product, or who are simply not up to that challenge, will not benefit from the distractions of constantly analyzing their execution when they ought to be thinking about how their product will fare in the open warfare of the commercial marketplace.
If you win the Superbowl, nobody is going to say, “Well, maybe you won, but then again your methods weren’t as good as the team that won last year.” (And if they do say that, flash them your Superbowl ring and ignore them.) Likewise, it will be small consolation to the losing side if they are told, “Too bad you lost, but at least your uniforms are clean.” And that is what is wrong with OpX. Teams that need it, need much more than it provides, and teams that do not need it will be hurt by its pointless distraction.
The Led Zeppelin Incident
Teams that need OpX need much more than it provides, and teams that don’t need it will be hurt by it
Security guards are an essential feature of 1 1 today’s workplace. The vast majority are professional and compassionate and try to do the best job they know how. (The exception is a woman guard I had to pass on my way out the door. Every night, she would look at my badge, with a photo from circa 1990, then at me, and say the same thing: “Oh my, how you’ve aged.” And I would grit my teeth and think, “Lady, you’re no spring chicken yourself.”)
But security guards are also agents
of company policy, whose creation and motivation was largely outside their scope of influence. Consequently, they can radically favor the letter of the law over its spirit. In an engineering environment, that is a recipe for trouble.
This particular reality hit me hard one weekend when I was on a deadline to finish a paper by Monday morning. Debug contingencies had prevented me from getting to it until that Saturday, so there I was on Sunday morning at 3 A.M., typing away, headphones plugged into Led Zeppelin’s first album with the volume cranked up as high as necessary to keep me awake. The building was empty except for me and the security guard at the front desk.
Someone tapped me on the shoulder. Startled, I turned in my chair, and found the security guard in my cubicle.
“Can I help you?” I asked somewhat warily.
“What are you listening to on those headphones?” he replied.
“Led Zeppelin’s first album. Why?”
“Is that work-related?” he continued.
“Huh?”
“Corporate policy forbids listening to music on personal CD players.”
“You’re kidding, right?” I start turning back to my paper.
“No, not at all. First of all, listening to music could annoy the others around you.”
I still thought, maybe this guy’s joking, and turned fully around and look at him. Hmmm, no smiles. Maybe he really is serious, I thought. “Uh, look around you. Do you see any other people here? You were the nearest other humanoid. Are you saying you could hear my headphones from 100 meters away?”
But the security guard did not give up easily. “Well, what if there were a fire, and the alarm went off, and you couldn’t hear it because you had the music up too high?”
The Pentium Chronicles: The People, Passion, and Politics Behind Intel's Landmark Chips (Practitioners) Page 26