All Posts in Leadership

|In: Leadership|Last Updated:

Isaac Asimov once told the tale of the world’s greatest surfer, a legend in his own mind, if nowhere else. Tired of hearing him brag, his audience challenged him to demonstrate his skills. So, taking surfboard in hand, he ran to the water’s edge where he stood still, gazing over the waves.

“Why don’t you go in?” taunted the crowd.

His response: “We also surf who only stand and wait.”

Identifying the next big wave is a big challenge in our own industry, too, as is knowing when to start swimming. I alluded to this problem in my Jan. 12 column, talking about the need for CIOs to identify new and promising technologies and to actively search for their potential business impact. (See “If you wait for business needs to drive technology buys, you will fall behind.”) This, I think, is at least as important as responding to requests from business leaders.

This is an important idea. It isn’t, however, as original as I’d thought. I found this out by reading Clayton Christensen’s new book The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail, which told it first and better.

I find books like this annoying. Christensen came up with my idea years before I did, and had the nerve to research it extensively and develop it into a well-thought-out program for developing and implementing corporate strategy.

How’s a poor columnist supposed to maintain his reputation for original thinking, anyway?

Christensen divides innovation into two categories, sustaining and disruptive. Sustaining innovation improves service delivery to existing markets. Disruptive innovation, in contrast, is initially irrelevant to existing markets but improves faster than market requirements until it can invade a market from below. For example:

Mainframe computers experienced sustaining innovation for years, steadily improving their price-performance characteristics. Minicomputers, less capable, were a disruptive innovation. Completely incapable of handling mainframe chores at first they found entirely new markets — in scientific computing, shop floor automation, and departmental applications. Companies like Digital and Data General got their start not by competing with IBM (IBM asked, and its customers had no interest in minicomputers at the time) but by finding new markets for their products too small for IBM to care about.

Minicomputers never did overtake mainframes in capacity. They did, however, overtake the requirements of much of the mainframe marketplace, invading from below and draining away a significant share of the market.

Companies miss the opportunities presented by disruptive technologies because they listen to their customers and deliver what those customers want. Disruptive technologies appeal to entirely different (and much smaller) marketplaces at first, so listening to customers is exactly the wrong thing to do.

Now think about how IS organizations deal with disruptive technologies. That’s right, this isn’t just an academic question. This is your problem we’re talking about.

Remember when PCs started floating into the organization? The average CIO sees business executives as IS’s “customer” and delivers what they ask for. PCs held no appeal for the CIO’s “customers.” PCs were useful to analysts, clerks, and secretaries — an entirely different market too clout-free to be visible to the CIO — until it was too late.

Eventually, networks of PCs did start solving more traditional information processing tasks, and IS knew less about them than the end-user community.

Right now you’re faced with quite a few potentially disruptive technologies — personal digital assistants, intranets, and computer-telephone integration, to name just three. How do you plan to deal with them?

Here’s one plan, based on ideas from The Innovator’s Dilemma: Charter one or two small, independent groups of innovators. Detach them from IS so they aren’t sidetracked into mega-projects.

Tell them to start small and find ways to make these new technologies beneficial to the company.

And then, most importantly … leave them alone.

Comments

|In: Industry Commentary|Last Updated:

Some economist analyzed all of the leveraged buyouts of the 1980s and made a startling discovery: In about 70 percent of the cases the companies — generally profitable when acquired — did not generate enough cash to pay off the debt taken on in financing the LBO.

Everyone involved in these transactions knew they would fail, but it didn’t matter, since they all ended up wealthier than when they started.

Why do groups of people who are individually smart seem to act stupidly so often? A group is smart when its members’ personal short-term interests coincide with the group’s long-term interests. Otherwise the group will do stupid things.

That, far more than a bunch of dumb CIOs caught off-guard when a century sneaked up on them from behind, explains why we have a huge year-2000 problem.

The year 2000 is a crisis because until it reached crisis proportions, making this year’s numbers was more important than investing resources in surviving past 1999. Understanding these dynamics should change how you set IS priorities.

I remember raising the year 2000 question back in 1994. We spent exactly one sentence discussing it. Since we lacked the resources to satisfy immediate demand, the year 2000 could wait until 1995, when with luck we would all have different jobs and it would be someone else’s problem. (No, none of us actually admitted to that thought process … maybe I was the only one that shallow.)

What problems do you have with your systems architecture or applications portfolio that you could fix with little stress if you started right now? I’ll bet you have at least one.

Maybe your particular problem is an ancient system with old, fragile code nobody really knows anymore. You can fix it by rewriting modules that require maintenance instead of simply tweaking them, even though the rewrites will take twice as long.

Or maybe you operate a batch legacy environment, and you know in your bones that the company needs to operate in real time. Figure out how to switch one class of updates at a time from the batch queue to online transaction processing and incorporate this into your overall IS strategy.

Use your year-2000 crisis as a lever to sell a long-term program of technology grooming, so you never again experience this kind of difficulty. I know that right now, if you’re a typical CIO or IT director, the year-2000 problem seems like your greatest challenge and these other projects seem distant at best. And I have almost no useful advice to give you on solving your immediate problem except for these very obvious points:

  • Make sure you have enough programmers assigned to the project. Then add a few more for good luck.
  • Assign or hire the absolute best project manager you can possibly find and afford to run the project.
  • Pay more attention to testing than to any other part of the project.

The immense cost estimates for the year 2000 fix are misleading. Yes, organizations will spend huge sums. These sums will have little adverse impact on the economy, though, because for every company that spends there are others, or individual employees, who receive.

The real impact of the year-2000 problem will be to reward far-sightedness: Competitors that have already fixed the problem can now afford to invest in projects that yield a competitive advantage.

Comments