08/11/03
pages 129 - 153
But how much trouble should the task be in before the manager takes action? That's not an easy question to answer. If you jump in too quickly, you undercut the people whom you desperately need to help you. If you wait too long, the damage to the task may be so bad that it is nearly impossible to fix.
The particular problem that West was frustrated about was debugging of the Eagle - it was far behind schedule. The pressure intensified when West learned that the North Carolina group had fallen far behind schedule for producing the 32-bit FHP machine. All along, West had justified the Eagle project as a back-up to the North Carolina project. It had been a convenient subterfuge through which the Eagle could compete with the FHP project without being eliminated as unnecessary and undesirable duplication of effort. But now, it looked as if the company would need the Eagle team to produce a 32-bit machine on the unrealistic schedule that they had proposed. If they did not, Data General would not have a 32-bit machine on the market in time to be a serious competitor. In particular, many of the Eclipse customers might begin to jump ship for the machines of other vendors, especially DEC.
In this light, the upward software compatibility issue became especially important: the customers might wait a little longer to jump to another vendor if the wait would mean that they could continue to use their old software while they added newer 32-bit software. To 16 bit Eclipse users, the ability to use their old software on a new 32-bit Eclipse, even if it was delayed, might be a faster upgrade path than changing to completely new software on an already available 32-bit machine, the DEC VAX 11-780.
The slowness of the debugging was the main apparent holdup in producing the Eagle, the 32-bit Eclipse. West, of course, had done an outstanding job of the debugging of the old 16-bit Eclipse and assumed that debugging the Eagle would be similar. He started going into the labs on Sunday mornings when no one was supposed to be there. Probably, he was thinking of trying to debug Eagle himself. But the Sunday morning visits soon stopped and later he said "We're way beyond what any one person can do. It's too complex." West finally understood that it was impossible for him to debug the Eagle by himself. Eventually, he seemed to trust Rasala, the leader of the hardware team (the Hardy Boys) to solve the problems. This episode is an example of how hard it is for managers to delegate tasks and resist the temptation to meddle afterwards.
His first job was with Raytheon, a large electronics company. There he became known as doing average or routine work, which reflected his ambition at the time. Other things, such as softball, karate and games of hearts at lunch, were more important to him than work. Eventually, he decided that work could be fun, but to get really interesting projects, he felt he had to start over at another company to escape his lackluster image. He said that he went to work at Data General to see what he was worth.
Rasala was tired from working extremely hard on a recent version of the 16-bit Eclipse and was not at all eager to "sign up" so quickly afterward on the Eagle project. He wanted more time to recover. But gradually he assumed the responsibility for building and debugging the Eagle hardware. He just couldn't resist the opportunity to be where the action was, working on a machine that was so important to the company.
According to an article entitled O, Engineers! in the December, 2000, issue of Wired, Ed Rasala is program manager for Compaq's industry standard server group in Silicon Valley.