Читать книгу The Race For A New Game Machine: - David Shippy - Страница 11

The first step to building a highly successful team is to recruit top talent and seed the team with true leaders. The next step is to organize the various disciplines and leaders to maximize success.

DURING MY FIRST WEEK ON THE JOB, I got a good look at the towering mountain of work ahead of us. My coworkers consisted of Chekib Akrout, Jim Kahle, one or two managers, a handful of high-powered engineers, and a few administrative assistants. That was the whole team! Woefully understaffed, we plowed through heaps of resumes, scheduled interviews, and, in between, tried to arrange office space, develop org charts, and write job descriptions. The technical work was still in its infancy. I figured I’d better get some other engineers on board quick, or I was going to be one tired puppy. I wanted some help with all that design work Kahle promised. Finding top-notch technical leads was my highest priority.

While I was head down trying to staff my team, Kahle dragged me into the politics of IBM’s latest processor war. The battle for chip development funding between the Server Group and the Microelectronics Division, where the STI Design Center resided, still raged. Great ideas, of which there is never a shortage, require significant monetary investment—top-notch salaries, employee benefits, office space, silicon test chips, lab space and equipment—in order to mature into hardware. Sharing that finite pot of gold with its sister division simply reduced either’s ability to pursue homegrown innovation. Parochialism was indeed entrenched in the IBM culture and presented a never-ending source of contention. As with the mainframe processor wars of the 1980s, the group awarded the PlayStation 3 processor would secure funding from corporate IBM to staff up a large engineering team. So it all came down to job security again.

An IBM Fellow (the highest rank on IBM’s technical career ladder), Rick Baum, drove a task force to resolve the processor roadmap for the entire IBM corporation. The words “task force” made me cringe. This method of problem solving was a relic from the old IBM culture, and I felt it was a huge waste of time and money. It’s a committee of high-level engineering experts, pulled from various disciplines within IBM for the express purpose of solving some problem du jour. They would meet on a regular basis, with each member reporting the results of their various homework assignments. Grouped into opposing camps, each side would attempt to persuade the other that their engineering position was the right one, and it was next to impossible to reach a consensus. As I met with Baum’s task force, I wondered once again if jumping back into a big corporate environment had been the right decision.

The conclusion, if there was to be one, could be very important to the STI Design Center, so I tried to stay focused. Some members of the task force lobbied for one common processor core to cover both the high-end server space as well as the high-end game space. Kahle was pushing hard for a separate game core.

Kahle presented his case to Baum and the task force: “The server requires something entirely different than the game console does. I need a small, simple core that focuses on high frequency, without all of the baggage that the server core will require.”

The Server folks presented their own arguments, though they didn’t appear to have any good technical data. They just wanted to own the core for bragging rights, and they wanted funds to sustain future engineering jobs. Kahle told me later, “Baum doesn’t really like me much, but I’ve got money coming in from Sony and Toshiba. I’ve also got some important executives backing me because I’m going to help pay for our new fabrication facilities by filling them with high-volume chips.”

The task force fizzled out, as I predicted, and Kahle got the green light to develop a new PowerPC game core. I was glad the task force didn’t last too long because I desperately needed to fill some of the key leadership positions on my team.

I called some of my old buddies from my Power4 experience. Most folks were already committed to other critical IBM server chips. However, I lucked onto one veteran engineer, David Ray, who was willing to talk to me. David and I worked together on several previous IBM microprocessor designs. He owned a small piece of property in the hill country outside of Austin, so I teasingly called him “Farmer Dave.” Everyone knew he would rather be building a barn than building computer chips. He was a quiet, crusty engineer who never seemed particularly happy and who especially hated managers; however, he was sharp and always delivered high-quality designs ahead of schedule. He earned the highest respect from his peers and from the people he led. Thankfully, David was in-between projects right then and was fairly unhappy with the Server Group management, so I invited him to meet me for lunch in the cafeteria.

As soon as we went through the food line and found a table, I jumped right in. I told him the truth: “Dave, I’ve got the deal of a lifetime for you. How’d you like to work on a start-from-scratch design for a supercomputer-on-a-chip for a game machine? It’s going to be extremely difficult work, we’re severely understaffed, so we’ll be running lean and mean for a while, and it’s all sort of top secret. How’s that sound?” I laughed, half expecting him to respond with Are you crazy?

Instead, his eyes lit up. He leaned forward, rested his elbows on the formica-topped table, and said, “When do I start?”

He looked serious, but my proposal sounded so ludicrous to my own ears, I wasn’t sure if he was just pulling my leg. “Well, you’ll be my first technical leader, so the sooner the better,” I said.

Turned out Farmer Dave was serious. The challenge hooked him as much as the start-from-scratch opportunity. Before lunch was over, he accepted the position, and we made plans for his transition from the Server Group.

David Ray also pointed me to my second technical lead, Jim Van Norstrand. David and Jim worked together on the Power3 microprocessor. Jim was another twenty-year veteran with a wealth of design and management experience under his belt. I knew I was lucky to have him on the team. He was an expert logic designer who was intimately familiar with the instruction unit, the most complex and critical subcomponent of a microprocessor. An instruction unit is responsible for handling low-level software instructions running on the processor. It fetches the instructions from memory, decodes them, and issues them to functional units, which then execute the operations specified by the instructions. The instruction unit is like the head cook in the kitchen who fetches and reads the recipe, while the kitchen staff (the functional units) executes the instructions handed down by the cook. An inefficient instruction unit could break the back of an otherwise reasonably designed processor and limit the ultimate speed it could achieve. Van Norstrand became my second in command, assuming a significant share of the technical responsibility for the entire microprocessor core.

Jim Kahle recruited Tony Truong (pronounced Trong) back into the IBM fold before I got there, so I inherited Tony as my third technical lead. We had worked together on a previous project in the Server Group, but he left IBM in the late ’90s about the same time I did. I was glad to see he had also returned, and I knew I was lucky to have him lead the design of the PowerPC’s memory subsystem. Tony’s strengths lay in his work ethic and his deep knowledge of memory subsystems. He could hone in on a troublesome area of the design that was difficult to verify, and come up with a way to test it. It might take him several grueling twenty-hour days in a row, but he would finish it, and we would end up with a stronger design because of his work. One of the things I loved about working at IBM was the cultural mixture. Tony was from Vietnam, and I could always count on him to find the best Vietnamese food in Austin.

With these strong team leaders in place to help me, I turned my focus to the organizational configuration. I created a two-in-the-box structure to lead the team. With this two-leader configuration, an IBM second-line manager and I ran the large PowerPC team together. I focused on the day-to-day technical work as well as some of the project management aspects of the project. The second-line manager focused on personnel and administrative issues as well as the remaining project management issues. It was a divide-and-conquer approach.

Previous project leaders at IBM had organized their teams around interdependent functional disciplines—for example, logic design, verification, or circuit design. Experience already taught me that this type of organization created too much of a “throw it over the wall” mentality when problems created by one team were passed on to another to solve. I wanted self-contained entities responsible for all aspects of the design from start to finish. I carved up the microprocessor core into functional units and created teams around those units. Each team was responsible for delivering a final physical piece of silicon (hardware), which was logically and physically verified and complete. Each member of that team worked toward one common goal—functional silicon. It was not acceptable for anyone to say, “Well, I did my piece”—meaning they washed their hands of any problems—because they were all responsible for the end goal. The structure created accountability for everyone on the team. I also created a two-in-the-box leadership configuration for these teams. In most cases, one leader focused on logic design and verification, while the other focused on circuit design and physical design.

I was well on my way to creating a high-performance team.

While I was elated that all three STI partners vowed to provide their very best architects and designers to meet the challenging project goals, I knew it was a promise they would find difficult to keep. Sony and Toshiba faced the larger problem of convincing their top designers to take a two-to three-year tour of duty in the United States. IBM’s problem had more to do with balancing projects and earnings. While they could draw from a vast pool of engineers, they were on the cliff’s edge of the post-dot-com technology bust and were drawing up plans to downsize. In addition, most of the top IBM microprocessor designers were committed to critical IBM server chips, the bread and butter of the company. “Not available” was the line Kahle heard over and over when he attempted to recruit his pals from former projects.

This opened up an opportunity for external hiring.

One human resources representative explained that IBM’s hiring practices moved in cycles, and she warned us it was best to take rapid action as soon as the external hiring window opened, because it could close at any moment. When Kahle pulled me through that window, no one was sure how many others were going to follow.

Microprocessor design demands a team with highly specialized skills. While Jim Kahle and others focused on luring experienced engineers away from other high-tech companies, I withdrew to my sunny new cubicle to comb through a stack of resumes from engineers who expected to graduate from college in 2001. With the shape of the current economy, I knew I could afford to be picky and select only the best and the brightest from top-notch engineering schools. The lifeblood of the project as well as that of IBM rested on hiring top college grads who would bring fresh energy and insight to the company. I liked them because they were fearless. They didn’t know the meaning of the word impossible.

Although IBMers historically conducted very polite, unobtrusive interviews, this did not always lead to finding the most qualified candidates. At Somerset, we brought young engineers before a committee of several interviewers at once and pounded the potential candidates with tough, hard-to-solve engineering problems. It was an effective method, but a bit ruthless. More than one contender left the room on the verge of tears.

For the STI candidates, I adopted a toned down version of that style. I brought each one in for a series of individual forty-five-minute interviews with four or five technical leads and managers. Some of the interviewers conducted the same old traditional polite IBM interview, smiling while they struggled to glean hints of the candidate’s technical capabilities.

I confronted my too mild fellow IBMers: “Come on! Challenge these guys! Your butts will be on the line if we hire nonperformers. We have to be looking for the cream of the crop.”

When it was my turn, I grilled each applicant with several problem-solving exercises and asked specific engineering questions. While I listened to the responses, I tried to decide if I would enjoy working with the engineer on a daily basis. Better yet, would I enjoy drinking beer with him or her? Always an important criteria.

After we completed each day’s interviews, the IBM team met for a lively discussion to sort through the results. Each one of us presented our impressions of the candidates and argued about their strengths and weaknesses.

“Don’t the schools today teach these guys anything?” one interviewer complained after interviewing an inexperienced candidate.

“Did you talk to the woman from Princeton? Or that youngster from Cal Tech?” another crowed, obviously in awe of the pedigrees.

“Oh, yeah, I did. How about the one with the Ph.D. from Duke?” responded another like-minded fan of prestigious schools.

I just wanted smart engineers who worked hard and fit in. With a thumbs-up or thumbs-down vote, we made the hiring decisions. When we disagreed, the discussions tended to drag on. Whenever I could, I shut down these arguments. “If you have any doubts about this candidate, let’s just pass,” I said, sliding the questionable resume into the trash. “Let’s move on.” There was too much other work to do.

I really didn’t care which prestigious high-browed university they attended, though I did handpick a few graduates from prestigious universities such as Duke, Purdue, Carnegie Mellon, and the University of Texas. We even hired a couple from my alma mater, the University of Kentucky. Where someone went to school is not as important as the person’s commitment to an education. You get out of it what you put into it. With the draw of the opportunity to work on the next PlayStation 3 chip, I was able to attract engineers from the very top of their classes. These young techies were born in the late 1970s or early 1980s, and they grew up playing video games. To many of the seasoned veterans on the team, these grads were just youngsters, barely older than some of their own kids. But they brought a new dynamic and energy to the team that couldn’t be created any other way. They were proud, outspoken, egotistical, very confident in their skills, and convinced that they had something unique to contribute. As lean as we were, several of these wonder kids quickly moved into critical roles, taking on far more responsibility and workload than some of their more senior colleagues. These youngsters may have held some totally unrealistic expectations of their careers—like believing they would move from junior engineer to CEO in a mere handful of years—but they remained resilient, willing to learn, and highly competitive.

In addition to college graduates, another very attractive talent pool was the significant number of experienced engineers, like me, who left IBM at the height of the technology boom of 1998–2000 to find fame and fortune in the startups. Kahle and I conspired to hunt down some key former colleagues and make offers they couldn’t refuse. It was something of an uphill battle, because even if we could entice one of our buddies to return to the ship, it was always possible that the IBM executives would reject the request for authorization to hire. Many true-blue executives flatly disagreed with the practice of rehiring former employees, believing them to have been disloyal in their previous abandonment of the company. Fortunately, Akrout was not so adamantly opposed. He couldn’t afford to be.

If we were to have any hope of filling out a team in time to meet Sony’s goal for a product launch in 2005, we were going to have to do whatever it took to bring in the talent. I leaned back in my chair and propped one sandaled foot on my desk, while I casually phoned a former IBMer, a guy I worked with several years before. We chatted for a while, bemoaning the demise of the startups, remembering the excitement and the dream we shared of the pot of gold just waiting for us to claim it. The potential certainly existed, and a few people we knew landed in startups that went public or were purchased by some bigger corporations.

My friend sighed. “Some people got lucky, but most of us just got worn out. It was hard work, long hours, and, in the end, all you wanted was your paycheck, which was two months late.” He was more than happy to come in for an interview.

The startups were drying up, innovative work was suddenly scarce in the industry, and the economy in general had tanked. Everyone was hungry for something exciting—and stable—to work on, and they recognized the game processor as a once-in-a-career opportunity. We had no trouble lining up eager engineers to interview. The promise of a new high-performance microprocessor design team allowed IBM to cherry-pick top talent from some of their competitors. Given the right incentives, good engineers were willing to go wherever the best work existed. Company loyalties didn’t have a chance against the spectrum of design work we offered.

Each new addition to the STI team, whether an internally transferred loyal IBMer or a prodigal son/daughter returning to the fold, brought with them priceless contacts with other engineers who might be interested in hearing from IBM. It was always easier to convince potential candidates to join a team of old friends.

Sony and Toshiba did not have as much luck filling out their part of the STI team and, like IBM, they were hampered by the staffing demands of other high-priority projects within their companies. Ongoing work on PlayStation 2 derivatives consumed a significant number of Sony’s workforce, while Toshiba was busy with their own products. Out of necessity, Akrout gave the order to continue bringing in IBMers to achieve the critical mass necessary for the STI team to achieve their goals.

This led to an unequal split in the team, with IBM having approximately three-fourths of the resources. Akrout predicted the occurrence of this situation, but kept a low profile in front of his Japanese peers. Since each company contributed one-third of the funding, this resulted in a lucrative deal for IBM (three-fourths of the resources, but only one-third of the salary bill), and a good means for Akrout to continue to hold onto a larger pool of talent for any future IBM needs.

While Sony and Toshiba did not contribute as many engineers as IBM, the ones they did bring into the Design Center were top notch. The problem, as might be expected with this international mix of players, was communication. My first close encounter with the Japanese engineers came at a lunchtime gathering that Tony Truong organized. Tony rounded up eight of us, and we headed off to his favorite Vietnamese noodle shop in North Austin. The place was a hole in the wall, but the food was excellent. I always deferred to Tony to order for me, and that day he chose a large bowl of rice noodles with spicy meatballs for me. I was never sure how to eat this tasty mixture of chicken broth, rice noodles, and meat. Should I use a spoon, a fork, or chopsticks? Or should I just pick up the bowl and slurp? I mostly chose the latter.

As we ate, I tried to make casual conversation with one of my Japanese lunch mates, Takeshi Yamazaki, who Tony introduced as one of Sony’s chief engineers on the project. What Tony had not told me was that Yamazaki spoke very little English. I muddled through several attempts at conversation, but Yamazaki returned only blank stares. He said nothing.

At first, I thought he was one rude fellow, but then I finally figured out the problem. I thought to myself, “This is going to be an interesting project if none of my partners can speak English!” I certainly couldn’t speak Japanese.

At just about the same time, IBM halted all external hiring, proving true the predictions of that wise human resources representative. Corporate management informed us there was a surplus of design engineers in the company who we must re-deploy before considering any more external applications. I can be as true-Blue as the next IBMer, but I knew right away that this was not going to be any easier for us than hiring off the street. In fact, it would probably be harder. As in any large family, our remote cousins were not enthused about letting us take charge of the family fortune.

First, we looked to Rochester, Minnesota, the hotbed of high-performance microprocessor design in the mid-1990s. Their AS/400 minicomputers had been popular business and accounting computers, but those machines relied on proprietary operating systems and software. They eventually lost market share to the more popular open source Unix computer systems. With this erosion in the customer base, IBM corporate offices pulled a sizeable chunk of funding from Rochester, forcing a downsizing. Despite the reductions, some top engineering talent remained in Rochester.

My first task was to figure out how to integrate a large group of engineers into my Austin-based design team and keep them motivated and happy while working remotely from Rochester. After several brainstorming sessions, I decided we needed to partition the microprocessor core in such a way that we could give the Rochester team a self-contained, “meaty” portion of the design, sort of a mini-project. This would serve two purposes: first, it would minimize the interaction required with the rest of the core team in Austin and, second, it would build pride of ownership at the Rochester site. The alternative was to give them responsibility for bits and pieces of the design work scattered throughout the core, a choice that was far more likely to complicate communications and make the Rochester team feel like hired guns.

I deployed a similar technique with a team from the Research Center in Yorktown, New York. The Yorktown folks were some of the best engineers in the company, who had made major contributions to the Power4 microprocessor design. I was counting on a similar performance from them for this new design. I gave them a self-contained piece of the design so that the Yorktown contingent could work on their own mini-project.

Since external hiring for IBM was no longer an option, we worked out a one-time good deal with Toshiba where they agreed to hire a hotshot ex-IBMer, Jack Bell, who we desperately needed for our verification team. It sounded like a great idea to everyone, and we all got what we wanted. The reality was very messy, though. Bell was looked upon by IBMers as “one of us,” so he was privy to lots of secrets that we didn’t necessarily want to share with our Japanese partners. We conveniently forgot he was in the room when we discussed IBM-only topics. Thankfully, he didn’t report everything he heard to Toshiba, because in truth, at the beginning at least, his loyalty was still to IBM. Meanwhile, Toshiba engineers didn’t fully trust Bell and probably viewed him as a spy in their Toshiba-only meetings. What an awkward situation.

As the team grew, the management structure grew, too. Eventually, there were six second-line managers and one project manager working under Jim Kahle and Chekib Akrout in the Design Center. Technology and engineering as a whole were still overwhelmingly male-dominated fields, so it was somewhat surprising when the Design Center ended up filling five of these top leadership positions with women. The STI project was not a proving ground for gender equality, nor was it a traditional engineering team where men ruled the roost. It was simply proof positive that IBM’s long-held policy of hiring, developing, and promoting women engineers was effective. It functioned exactly as intended by providing IBM with a strong, capable, and diverse workforce. The STI project’s diversity is a tribute to Chekib Akrout, who selected leaders based on capabilities, not gender or race. At STI, the two or three dozen female engineers on the team gained a real vision for their own advancement potential by looking at the good role models these women in leadership positions provided. This coalition of powerful women created a climate of cooperation in the workplace, making it a place where teamwork ruled.

Second-line managers were responsible for the technical goals, schedules, and performance for their respective teams, as well as all the personnel issues. Their teams came in sizes ranging from 30 to 240 people. Linda Van Grinsven was the first woman recruited for one of the coveted second-line management positions. She and her husband, Gene, both engineers, had been with IBM for nearly twenty years, mostly at the Rochester, Minnesota site. They relocated to Austin for a two-year temporary assignment, and Linda led the group responsible for the design of the Synergistic core, which you’ll read more about later. This core, slated to be used multiple times on the chip, was the brainchild of Ken Kutaragi and Jim Kahle. The forty-five people on Linda’s team were almost all located in Austin, but many of them were Japanese employees of Sony or Toshiba. Consequently, she tackled the language barrier early on and was instrumental in forming many of the practices that helped the Design Center function effectively in a multicultural environment. With a couple of hothead technical leads under her, Linda had her hands full keeping the peace in her team.

My co-author, Mickie Phipps, a relative newcomer to IBM, came in as a first-line manager in 1999 from Eaton Corporation. Prior to that, during her 20 years in active duty and reserve service with the United States Air Force, Mickie’s resume spanned such jobs as aircraft mechanic, intelligence officer, and research and development engineer for air-to-air missiles. She joined the STI Design Center in September 2001 as Chekib Akrout’s technical assistant. This was a period of uncertainty for her as our country recalled military reservists in great numbers to fight the war on terror. She had been expecting to retire from the Air Force that year, but the attack on the Twin Towers in New York City changed everything. Twice, Mickie received orders to report for active duty with the Air Force, and both times those orders were cancelled at the last minute. Her position with Akrout was meant to be a gap-filler while she waited for her date to report. Months later, the Air Force released Mickie from service and in the summer of 2002, Akrout promoted her to second-line manager for the PowerPC team. I knew her well from her work with Akrout and was very pleased that we were now partners. Our team, located at seven different IBM sites in time zones that stretched from Germany to California, eventually grew to 240 people. Technical complexity, size of the team, geography, and language and cultural differences presented rocky challenges that we worked through together

Kathy Papermaster led the Convergence team for a short time in late 2001 and early 2002. Her team was responsible for functions that were more global in nature or were more focused at the chip level, like design tools which had to be common throughout the team, chip verification, and chip integration. Kathy definitely had her heart set on becoming an IBM executive and soon left the Design Center to take a position as an executive assistant to a vice president, Michel Mayer. To replace her, Chekib Akrout brought out the big guns and lured former IBMer Dac Pham away from a very high-level position at Intel. Dac was high-energy, enthusiastic, and optimistic.

After more than fifteen years of service with IBM, Pam Spann had resigned (along with many others) following the infamous retirement plan debacle in 1999. In one fell swoop, IBM had adjusted their benefit plan to fit a younger, more mobile workforce, drastically altering the retirement plans for a significant number of long-term, dedicated employees. IBM’s new plan no longer offered benefits that provided retired workers with a monthly check, and instead offered a cash-balance plan that would pay employees a lump sum when they left the company. One result of this change was that many of those long-term employees no longer felt obliged to hang in there for that payout during their golden years; they could take their money (what little was offered) and run. And many did. It was, after all, a boom time in the high-tech industry. However, Pam’s gamble on one of the dot-com startup companies wasn’t altogether a pleasant experience, and she quickly accepted when STI called her home to IBM. In late 2001, Chekib Akrout rehired Pam to manage the Design Center’s business operations, including all the finances, staffing, and personnel issues. Even during the darkest of days in the Design Center, Pam would always say she was glad she had come back. She tried to encourage the team and to help them work through any problems they encountered. She knew from experience that the grass is not always greener on the other side.

Almost from day one, Keryn Mills was the project manager, responsible for the entire schedule for the design, test, and manufacture of the chips. Keryn had been with IBM for more than thirty-five years and was a formidable force, running “her” projects with an iron fist. She was like a dog on a bone. Nothing could shake her loose from something she believed in, even if it was at the expense of the morale of the team. She worked an unbelievable number of hours, often going home only for a few short hours of sleep. She was famous for her successful projects, and many executives and managers respected and trusted her, and listened to her opinions. The trick was to know when to turn her loose and when to rein her in. Most of the technical team dreaded being in her spotlight, and managers tried to shield them from her wrath. It wasn’t always easy to stay on her good side.

Over time, the team of engineers I shared with Mickie, who worked on the PowerPC core, continued to grow, expanding into a huge team justified only by the fact that we were starting our design from scratch instead of doing a derivative design based on an existing IBM microprocessor. At our home base in Austin, there were approximately twenty partners from Sony, eighty from Toshiba, and more than a hundred from IBM. The remaining IBMers were scattered across seven sites worldwide, including Raleigh, North Carolina; Rochester, Minnesota; Yorktown, New York; Endicott, New York; Boebligen, Germany; San Jose, California; and Burlington, Vermont.