Who Says Elephants Can't Dance?: Leading a Great Enterprise through Dramatic Change (24 page)

“What we could make” was the starting point, not “what they need.”

But as time progressed, businesspeople began to understand the importance of information technology and how it related to everything they wanted to do. I know, because I was one of them.

As business strategy began setting the technology agenda rather than the other way around, more and more investments that customers made in IT were being driven by line-of-business managers, not CIOs. Our industry, and IBM in particular, needed to adjust. We needed to open the window to the outside world. And IBM now had competition. UNIX systems and the PC allowed hundreds of competitors to pick away at IBM’s franchise. We could no longer run our business like the Roman Empire, confident in our hegemony, certain that those barbarians massing on the borders were no real threat.

And yet I was shocked to find so little customer and competitive information when I arrived. There was no disciplined marketing intelligence capability. What market share data we had was highly questionable, mostly because IBM defined the market, unsurprisingly, in its own image.

We may not have known much about customers, but there was WHO SAYS ELEPHANTS CAN’T DANCE? / 191

one group to which we paid plenty of attention: ourselves. In the IBM culture, the organization, and how one fit into the organization, was considered a very important subject. Kremlinology—whereby you judge who was in and out and up and down according to the lineup of leaders atop Lenin’s tomb on May Day—was a fine art.

For instance, I noticed early on that in any presentation, regardless of subject, the first chart (“foil”) invariably depicted the internal organization, including a box showing where the speaker fit on the chart (quite close to the CEO most of the time).

Organization announcements were big deals. When you got promoted, you had a press release, a written internal announcement on our electronic bulletin board, and your boss had a conference call with all of his or her direct reports to announce the good news, with you sitting beside the boss, presumably beaming. Each evening I’d look through my mail and e-mail and find dozens of seemingly minor and innocuous organization announcements, like this one: The following changes have been announced in the corporate manufacturing and development organization:

• Continuing to report to Patrick A. Toole, IBM senior vice president, manufacturing and development, is Jean-Pierre Briant, IBM director of manufacturing and logistics. Reporting to Mr. Briant are:

• Jean-Pierre Briant, (acting) IBM director of manufacturing;

• Lars G. Ljungdahl, who has been named IBM director of logistics and procurement. He was IBM director of logistics processes.

• Reporting to Mr. Ljungdahl are:

• Lars G. Ljungdahl, (acting) director of IBM order process. His organization remains unchanged.

• Lars G. Ljungdahl, (acting) director of corporate procurement.

The remainder of Mr. Ljungdahl’s organization is unchanged.

192 / LOUIS V. GERSTNER, JR.

I wanted people to focus on customers and the marketplace, not on internal status. A company fighting for survival doesn’t need a published caste system with broad readership. So I ended the practice of having a separate category of “IBM” vice presidents v. plain old vice presidents and “IBM” directors, and I banned all press releases about organization.

We had some very enterprising people, however, particularly in our personal computer company. You could always tell when the PC company was about to announce a reorganization, because executives would call the media ahead of time to leak the news and, in the process, make sure reporters understood how well that executive fared in the reorganization. One time
The Wall Street Journal
called and asked that we tell PC company executives to stop calling to leak reorganizations, because the flood of calls was overfilling reporters’

telephone mailboxes.

A Culture of “No”

I think the aspect of IBM’s culture that was the most remarkable to me was the ability of any individual, any team, any division to block agreement or action. “Respect for the individual” had devolved into a pervasive institutional support system for nonaction.

You saw it at the individual level. One of the most extraordinary manifestations of this “no” culture was IBM’s infamous nonconcur system. IBMers, when they disagreed with a position taken by their colleagues, could announce that they were “nonconcurring.”

Think about it: At any level of the organization, even after a cross-unit team had labored mightily to come up with a companywide solution, if some executive felt that solution diminished his or her portion of the company—or ran counter to the executive’s view of the world—a nonconcur spanner was thrown into the works. The net effect was unconscionable delay in reaching key decisions; duplicate ef

WHO SAYS ELEPHANTS CAN’T DANCE? / 193

fort, as units continued to focus on their pet approaches; and bitter personal contention, as hours and hours of good work would be jeopardized or scuttled by lone dissenters. Years later I heard it described as a culture in which no one
would
say yes, but everyone
could
say no.

The situation got even worse, because at least a public nonconsent has to be defended among one’s peers. More often than not, the nonconcur was silent. It would appear that a decision had been made, but individual units, used to the nonconsent philosophy, would simply go back to their labs or offices and do whatever in the world they pleased!

Here is an internal memo sent to many IBM people in 1994: The nonconcur process takes place throughout the year with added emphasis on the Spring (strategic) and the Fall (commitment) plan cycles. This note is the official E/ME/A “Kick-Off”

of the nonconcur process for this year.

To insure the success of the process I need to know the name of the person in your Division/Industry who will be your Nonconcur Coordinator for the remainder of this year. I will send the detailed Instructions and Guidelines to your coordinator as soon as you identify him/her, and their VNET ID, to me. It would be a great help if you could do this by COB Friday, May 20, 1994.

It is particularly important to be prepared for the issue cycle this year as we are expecting E/ME/A to issue a large number of Nonconcurs during the Spring cycle that are NLS related.

Please note that your Product/Industry Managers should be gearing up for issues to reach me, through your coordinator, for the Spring cycle, by Friday, June 3, 1994. (FYI, the Spring Plan has been published by M&D.) Note that I encourage you to get your issues to me prior to the due date, if possible.

Please note that I will not enter any nonconcur into NCMS

(Nonconcur Management System) unless you have the timely approval of Bill—, Bob—, or their designee, as applicable.

194 / LOUIS V. GERSTNER, JR.

This also means that you must be prepared to help—/—escal-ate, if necessary, through the management chain to Gerstner, if necessary.

Thanks for your help and consideration.

This validation of game-stopping disagreement also manifested itself at the divisional level. Interdivisional rivalries at times seemed more important, more heated, than the battle with external competitors. Early in my IBM career I was shocked when an IBM hardware division struck a deal with Oracle—a company that is an archrival of the IBM software unit—without even telling our software unit in advance.

Don’t get me wrong. I’m all for a pragmatic, opportunistic response to complex market realities. I’ve discussed earlier the need for “coopetition”—whereby we both cooperate and compete with the same companies. But to accomplish that, it takes a mature awareness of who you are as a company, where your deep interests lie, and where they don’t. This wasn’t that sort of sophisticated am-bidextrousness. IBM product salespeople were legendary for going to customers and denigrating another IBM product that might serve in equal capacity in a customer solution. In fact, IBM divisions would bid against one another, and a customer often got multiple IBM bids.

Research-and-development units would hide projects they were working on, so other parts of the company would not learn of them and try to take advantage of their knowledge. It went on and on in a staggering array of internal competition. Teamwork was not valued, sought, or rewarded.

This unique brew of rigidity and hostility often landed on my own doorstep. I discovered that just because I asked someone to do something, that didn’t mean the task got done. When I discovered this days or weeks later, I’d ask why. One executive said, “It seemed like a soft request.” Or: “I didn’t agree with you.”

Ironically, at the same time, some people were handing out or WHO SAYS ELEPHANTS CAN’T DANCE? / 195

ders in my name: “Lou said that you should…” or “Lou wants you to…” Then they followed up on the order so often, so persistently, and so loudly that the tasks actually got done. Unfortunately, many were things I knew nothing about and sometimes
didn’t
want done.

It got to the point where I had to hold a special meeting with everyone who had access to me for the specific purpose of banning

“Lou said” orders on any subject.

Bureaucracy That Hurts

The word “bureaucracy” has taken on a negative connotation in most institutions today. The truth is that no large enterprise can work without bureaucracy. Bureaucrats, or staff people, provide coordination among disparate line organizations; establish and enforce corporatewide strategies that allow the enterprise to avoid duplication, confusion, and conflict; and provide highly specialized skills that cannot be duplicated because of cost or simply the shortage of available resources.

These functions were all critical to an organization like IBM. Coordination was critical because we had a four-way matrix at IBM: geography, product, customer, and solutions. We also desperately needed corporatewide standards for many aspects of the company—e.g., commonality of products around the world for customers who operate globally; and common HR processes so we could move talent quickly and effectively whenever it was needed. And, given the complexity of a highly technical, global company, we clearly needed specialized resources that served the entire company—e.g., branding specialists and intellectual property lawyers.

The problem at IBM was not the presence of bureaucracy but its size and how it was used.

In IBM’s culture of “no”—a multiphased conflict in which units competed with one another, hid things from one another, and wanted 196 / LOUIS V. GERSTNER, JR.

to control access to their territory from other IBMers—the foot soldiers were IBM staff people. Instead of facilitating coordination, they manned the barricades and protected the borders.

For example, huge staffs spent countless hours debating and managing transfer pricing terms between IBM units instead of facilitating a seamless transfer of products to customers. Staff units were duplicated at every level of the organization because no managers trusted any cross-unit colleagues to carry out the work. Meetings to decide issues that cut across units were attended by throngs of people, because everyone needed to be present to protect his or her turf.

The net result of all this jockeying for position was a very powerful bureaucracy working at all levels of the company—tens of thousands trying to protect the prerogatives, resources, and profits of their units; and thousands more trying to bestow order and standards on the mob.

IBM Lingo

I’m a strong believer in the power of language. The way an organization speaks to its various audiences says a lot about how it sees itself. Everywhere I’ve worked I’ve devoted a good deal of personal attention to the organization’s “voice”—to the conversations it maintains with all of its important constituencies, both inside and outside the company. And I have chosen my own words—whether in written, electronic, or face-to-face communications—very carefully.

The truth is, you can learn a great deal about a place simply by listening to how it talks. Ordinary discourse at IBM in the early 1990s spoke volumes about the culture’s insularity—volumes that were often pretty funny, in a rueful sort of way.

There was a special vocabulary inside IBM—words and phrases used only by IBMers. Also, like the federal government and other bu WHO SAYS ELEPHANTS CAN’T DANCE? / 197

reaucracies, we just
loved
creating and using acronyms, like MDQ, FSD, GPD, and SAA.

As a result, in the early days I would sit through meetings and frequently have no idea what a presenter was talking about. I didn’t pretend that I did, however. I’d stop the speaker and ask for a plain-English translation. It was jarring, but people quickly got the point.

Here are some of the most frequently used and colorful IBMisms I heard:

CRISP UP, TWEAK, AND SWIZZLE
—Things one had to do to improve a foil presentation

BOIL THE OCEAN
—To use all means and options available to get something done

DOWN-LEVEL
—Describes a document that has since been improved (or tweaked and swizzled); used most frequently with me when I complained about something: “Lou, you’re working from a down-level version.”

LEVEL-SET
—What you do at the beginning of a meeting to get everyone working from the same facts

TAKE IT OFF-LINE
—What two or more people do with an issue that bogs down a meeting—namely, discuss it after the meeting
HARD STOP
—A time at which a meeting must end no matter what (I grew to like this expression and use it to this day.)
ONE-PERFORMER
—An employee with the company’s highest performance rating

MANAGEMENT-INITIATED SEPARATION
—Getting fired; commonly used in acronym form: “I’ve been MISed.”

LEFT THE BUSINESS
—What an employee who was fired has done

MEASURED MILE
—Where a manager puts an employee who, within a year, will most likely leave the business 198 / LOUIS V. GERSTNER, JR.

PUSHBACK
—What you run into when someone doesn’t agree with you

NONCONCUR
—What people do just before pushback
LOBS
—Lines of business, or business units (pronounced like what you might do with a tennis ball)