A Case Study on Leadership and Integrity

I was a manager and then executive in IBM software product development from the late ‘60’s through the early ‘90’s. The change in IBM’s organizational culture over that period was dramatic. During the ‘60’s, IBM embarked on a international, multi-product development effort that resulted in the System/360 – a product line with several new software operating systems and at least 8 different hardware systems along with a new line of peripherals. The development of these products spanned the globe and took place in more than 30 groups in approximately 15 different locations from Europe to North America to Japan. There were countless interdependencies among these groups and, as might be expected, rivalries and conflicting priorities among them. But a few, relatively small, central groups in upstate New York were successful in managing the interfaces and interdependencies between the many components of the various hardware and software systems, the schedules and the budgets.

Bob O. Evans was the overall executive in charge of development in those days. He was a man of impeccable integrity – his word was his bond, and he insisted on the same kind of behavior throughout his organizations. Failing to give your word to provide a necessary component on schedule was unacceptable. Not honoring a commitment was inexcusable. The System 360 project was sometimes referred to as a “bet-your-company” effort, and its success set the growth path for IBM for the next 25 years.

A few years later, in the early ‘70’s, when Evans was the president of the product development division, I managed the creation of the first version of the MVS operating system which was, up to that point, the largest single software project IBM had ever attempted. Twenty different groups in 12 locations were involved – a total of nearly 3,000 people at its peak. Each of the groups reported to geographic executives that often had other conflicting priorities – their own pet projects, non-software products that they were also responsible for, budget and headcount constraints, and so on. Even so, it all worked.

When we had to add a critical feature in the midst of the project, we recruited what became the 20th group in the 12th location to do the work. We never thought it would be a problem, and it wasn’t. Despite numerous breakdowns, very few people even tried to renege on their commitments (and no one ever succeeded), and the project was successful. Today MVS remains IBM’s primary mainframe operating system.

Ten years later, after Evans had been moved out of line management to direct the corporate technical staff, things had changed. I was on the management team of a project that spanned eight groups in six locations, all of whom reported to the same executive. The project lurched and finally sputtered out of existence because virtually every breakdown was resolved by backing off from the commitments, that is, people not honoring their word. This experience was repeated several times on other projects all over IBM.

Around this time, most IBM product development people concluded that creating projects that spanned multiple locations and business interests was not feasible within IBM. The consequences of this shift were enormous.  As a result, projects were designed to avoid dependencies on other groups.  Where such dependencies were unavoidable, one group would wait until a dependency was completely satisfied before they would embark on a project.  Thus, parallel development in multiple groups became rarer and rarer, and complex projects had elongated schedules.

When IBM’s first personal computer was being developed in the early ‘80’s in

Boca Raton, FL, the management of the project refused to work with or depend on other IBM groups because they perceived them as undependable and self-serving. The term “bureaucracy” was often used; and it referred to the fact that if a group no longer wanted to do something they had committed to, they could throw up a myriad of procedural barriers to anyone trying to get them to honor their word. As a result, even though superior technologies to make PC’s were available within IBM, those technologies were spurned in favor of using outside suppliers.

Specifically, IBM Research had already developed a software operating system for a microprocessor, and the IBM Components Division had superior chip design and manufacturing capabilities to provide microprocessor chips. Because of the lack of trust inside of IBM and the fact that IBM top management did not see the personal computer or software as important future businesses, the PC project was allowed to contract outside the company for operating system and chip solutions for the new personal computer.[1]

The rest, as they say, is history – those outside suppliers are today’s household names: Microsoft and Intel, and today the market capitalization of these two companies totals $332 billion, more than 1.6 times the current $205 billion of IBM.[2] Further, IBM is no longer in the personal computer business having sold it to a Chinese company.

Thus, this failure of leadership, integrity and therefore workability within the company cost IBM the equivalent of 1.6 IBM’s of today.

In their seminal paper on integrity, Erhard, Jensen, and Zaffron[3] say that to the degree that integrity in an individual or organization is lacking, workability is reduced.  The IBM story told above is a good example.  We would welcome other examples or counter-examples.  As always, we also welcome your comments and questions.