On my first day as CIO at Longs Drug Stores, our mainframe merchandising system crashed due to a fatal DB2 database error that corrupted merchandise information and prevented us from changing prices in our 300 stores to match the next week’s advertisement. As far as we knew, it was an unrecoverable error and we were going to have to reload the database.
That’s when I learned:
Before my promotion to CIO, I had been at Longs for 11 years, most recently as systems development director. I knew how to develop systems. I didn’t know, though, how to ensure that production applications continue to run reliably, in a complex network of computers, connections, databases, software, jobs, users and customers.
When the mainframe crashed, my skills and experience as a developer were meaningless. As CIO, I was suddenly responsible for the entire information-technology shop.
I called IBM and said, “I’m in really deep trouble and I have no idea how to get myself out.” To its credit, IBM pulled out all the stops, bringing in two of its most senior DB2 experts who painstakingly reconstructed the indices needed for us to access the data.
That’s an aspect of leading I learned right away: A lot of what a CIO does is build and maintain relationships. That’s not a management task. That’s leadership.
Another lesson: You have to know or learn what everyone does, and establish the framework in which everyone operates. Then, you have to rely on others to make most daily decisions.
I delegated to people I could trust and who would compensate for my weaknesses. While grand visions excite me, details start to bore me. So I surrounded myself with people who were very good at details. When I started doing that, I got bigger assignments because I had learned how to get things done—through other people.
Longs was a roll-your-own shop until the mid-1990s. We wrote every application that we implemented. As a development manager, I was as happy as a pig in mud.
After I had been CIO for a short while, I observed what was going on in the industry and realized that our approach did not position the company for growth. We had a proprietary network and servers. We were writing applications in Cobol, and weren’t taking advantage of commercial packages that were cheaper, more flexible and didn’t require as much code writing. We had to become an integration shop, not a development shop, if we were to expand.
In 1996, we went to the board of directors and told them we needed to move to systems that relied on open standards—and the move would cost tens of millions of dollars. We switched from HP 3000 and IBM mainframe computers using Cobol to Unix machines using object-oriented or Java and relational databases. We replaced an X.25 network to one based on Internet-protocol standards from Cisco. We did it on time and on budget.
Business people don’t really understand this weird little world we call I.T. They don’t know the difference between an X.25 network and one based on Internet protocols. If you ever want to have a futile conversation, try to explain to a business executive why object orientation is so important.
Business people just want information technology to work. That’s all. They want a vision of the future where they can grow the business and information technology will be there to support them.
It’s your job to make it happen. And part of that is to know what it takes to get there, and why.
All of this you will have to learn on your own.
Brian Kilcourse was CIO of Longs Drug Stores from 1992 to 2002; he joined the company in 1983. He is now senior partner of BEK Consulting and director of strategy for Retail Systems Alert Group.
