My favorite aunt started me on a career path
I first saw a computer in 1959 when I got a tour of a computing center at Tinker Air Force Base near Oklahoma City. My aunt, who had always wanted me to be a physician like she was, had a dear friend who worked for the Air Force. She was responsible for keeping track of spare parts, such as jet engines, for the Strategic Air Command center there. I was 17, and I was dazzled by the big IBM 702 mainframe computer with its flashing lights, spinning tape drives, and paper-spurting printers. I felt that there was something going on here that was both mysterious and exciting. There was a hidden organizing principle here that made me curious.
I was always a logical and scientifically oriented kid, and seeing that computer ultimately led to my life’s work. I followed my older brother to Cornell and majored in Engineering Physics. For my senior project, I took a formula from a 1922 paper by Theodore von Karman on how to mathematically model a certain kind of fluid flow. To make the model work, I wrote my first computer program, in a high-level language called CORC. The program got translated into machine language by a compiler program. Then my program ran in the computer. Results (or errors) got printed out.
The fatal question
In my mind, I asked what I call the fatal question: “I wonder how that works? How does information go into the machine as English, and get translated into a program that can be run by the machine?” Soon after, I began a summer job at Stanford Linear Accelerator Center (SLAC), programming in Fortran to help design magnets for the particle research center. I also got to try out a new $300,000 “minicomputer” that arrived and needed to be checked out before being installed in the research area. Just by running some of the test programs from the computer console, I found a wiring error in the computer.
The answer to the question
I began graduate school at CalTech in Pasadena, enrolling in Electrical Engineering (EE). I took my first systems programming course from an instructor who worked at the Jet Propulsion Lab. In that course, I got the answer to my question. I wrote assembly-language programs (like what’s in an operating system) to control the computer at the most-detailed level. Programs and computers were like puzzles to me, and the intricacy and logic of them hooked me.
The beginning of computer science at Stanford
The year I was in Pasadena, Stanford University opened its Computer Science (CS) Department. Having decided I was more interested in CS than EE, I came back to Stanford and visited William F. Miller, a research director at SLAC and a professor in the new Computer Science program. He invited me to into the program and became my advisor. During the next six years, I completed a PhD in Computer Science. My focus was on the interaction between hardware and software – things like computer instruction sets, microprogramming and input/output.
I was fascinated by the idea of using multiple processors in a single computer. Depending on how you interconnect them with data buses, you can get traffic jams, so I learned about bus design. In those days, there was no orderly body of knowledge about how to design buses. It turned out to be leading edge technology.
Twelve years of college was enough for me
By this time, I was ready to be away from academia and in the real world making things. I chose Digital Equipment Corp. (DEC) in Boston.
In my third week on the job, The VP of Engineering, Gordon Bell, invited some engineers to his office and posed a problem to us. DEC couldn’t connect the latest disk drives to DEC computers. In those days, disk drives were the size of a washing machine! The buses we had were too slow, impeding the transfer of data.
I became an interpreter
I became the coordinator of the Massbus project. The objective was to create a high speed bus for disks and tapes, to be used across DEC’s product lines. Some of my first patents came out of this project. There were seven development projects going on at once, each one developing a computer or a storage device connected through this common bus.
As coordinator, I figured out how to spread design information among all the teams. I wrote up the specifications based on the conversations of the core team – 5 of us. Then I fielded questions and distributed the answers to all the participants. I decided to provide three formats: English (for me), timing diagrams (for the electrical engineers) and flow charts (for the software people). Everyone working on an interface to this bus was kept up to date and we achieved compatibility across the product lines.
More projects in computer engineering
I became the project (head) engineer on a new multi-processor computer. I drew on my bus background and designed, with a few other engineers, a backplane bus that overcame a limitation on all the buses that were used before. The key was making each transfer from A to B happen without making A wait for a response from B.
The rest of my patents come from this bus design, called the Synchronous Backplane Interconnect (SBI). The SBI was used commercially in the first VAX computer (VAX-11/780).
I spent a year at DEC in the R&D Group developing a long-term plan for buses, a roadmap for evolving toward serial buses over the next 10 years.
I learn about software teams and customers
I moved to the software engineering side of DEC, managing two operating system groups for about a year and a half. I learned some of the most important lessons of my career here. I started interacting with field support engineers and customers intensively and began to develop skills that I bring to IT projects today. The software groups had not been well managed. When I walked into the office the first day, there were a lot of unhappy customers. The inbox had over 200 complaint forms (bug reports), some of them a year old.
I learned a lot from negative example – how not to manage software. Politics drove a lot of the interactions. The hardware team was disrespectful and disdainful of the software team. The software team was split across the Atlantic Ocean, and even some of the home-office managers didn’t want the product to succeed.
There were plenty of messes to clean up. I had to straighten out misunderstandings and misperceptions between people on different continents, placate the bosses, and deal with customer dissatisfaction. One of the biggest challenges was overcoming the attitude that software teams never deliver on time. By the time I left the software organization, the operating systems were stable, customers were getting used to a responsive home office, and programmers from England were a regular and accepted fixture in the company’s headquarters.
I return to California
Returning to California, I accepted a position at Tandem Computer, maker of “Non-Stop” computers using multiple processors. My role was as a one-person Advanced Development department. I studied how to connect hundreds of processors (the existing product had a maximum of 16); and I worked on how to do transaction processing safely over a distributed network of computers.
A little over a year later, I got a phone call from an engineering manager I knew through a professional society.
“You should come over to this little company called Apple.”
We made an appointment for the next day. Apple Computer was launching a new project, and they hired me on the spot. I was the 6th person on the Lisa hardware development team, working on the processor design. Later I led the design of a local area network (LAN) for Lisa, a return to my expertise in buses.
When the hardware designs were done, we were waiting for the software to be finished. To make myself useful, I put together a series of lectures at Apple by prominent people in computer engineering.
I become a consultant
After four years at Apple, I resigned to become a consultant. Apple was my first client. My focus was on troubleshooting engineering organizations, fixing people and management problems in projects to get them the back on track.
I also worked with Quantum, a maker of hard disk drives, to define a new product called HardCard – a disk drive for the IBM PC/AT; and I worked with Ricoh developing software for an optical disk drive.
Cleaning up messes as interim manager
At Quantum, I was twice hired as an interim manager, replacing or supplementing burnt out managers. In my first engagement, I took over a project that had a big order backlog and a design problem that stopped the production line. I led the team that fixed the problem, started a problem-tracking database, and hired my replacement within 3 months. In my second engagement, I managed the firmware development team while coaching the co-manager on how to be a better manager. One of the biggest lessons I learned in that job was to trust my own judgment and be steadfast in my recommendations. Not being hard headed, but insisting that action be taken when it’s needed to keep a team productive.
After ten years of consulting, Quantum hired me to build a systems engineering department. I put together a department of 27 people and 3 managers, managing them for six years. During that time, Quantum launched a strategic planning effort, envisioning the world 10 years in the future; I helped construct the strategy, including creating a Consumer Electronics Business Unit.
Some of my deepest and most relevant team management skills came from these years
Working to fill in for burnt out managers, building a new department, and rebuilding dysfunctional departments has given me a very deep understanding of what it takes to have an effective team. I’m able to figure out within a few days what is not working and what to do about it. I’m not afraid to do what needs to be done, and I always aim to do it in a compassionate way.
Where to next?
I invite you to read articles and reports that are available free on the Articles page.
Or download my free report on mistakes executives make in IT projects.