Leaping Management Issues in a Single Bound? Can't Do It, IT Leaders

Ann All spoke with Robert Austin, one of three authors of "The Adventures of an IT Leader" (Harvard Business Press). He is a professor at Copenhagen Business School and at Harvard Business School, where he chairs the executive education program for CIOs with co-author Richard Nolan. You can read an excerpt of the book in IT Business Edge's Knowledge Network.

All: Why did you create a fictional protagonist to illustrate the plight of today’s CIO?
Austin: We started off writing a normal business book, but we didn’t like what we were producing. It seemed like just another business book to us. We (he and co-author Richard Nolan) have a body of knowledge we’d been wanting to put into a book for a while, because we co-chair the executive program for CIOs at Harvard. We were playing with ways to do it in an interesting way. So partly it was to amuse ourselves. We misfired a few times before we got into something we enjoyed doing.

The other reason has to do with the usefulness of the book. When you do distinct, real-life cases, one of the problems you have is trying to integrate it all into a well-organized framework. This body of knowledge originally came out of the executive program, so we did have an organized framework in mind. But real-life cases are a challenge to slot into that framework. To the extent it will be used in a teaching context, a professor who might use the book will have an easier time conveying ideas to students in an organized framework because it’s the same person and you can deal with issues over a longer interval. Some things unfold over time with the same characters in the book, so people become more invested in it.

All: Many of the difficulties the hero encounters are due to difficulty in separating management from technical issues. Why is it so important to do so?
Austin: One principle or philosophy we espouse when we teach executives in the CIO program is that information management, and generally technology management, contains all these intertwined, comingled business and technical issues. People naturally operate in a mode where one constituency or the other deals with chunks of issues that contain a mix of technical and business. So you get comments like, “That’s technical stuff. Let the techies decide.” But it’s not technical stuff. It’s a combination of technical and business stuff.

One of the real keys to sound technical management is to be able to tease apart the technical from the managerial and to be able to bring the right decision-makers to bear on the components of a problem. They can be brought to bear in a collaborative way. But the idea is, if you have a business problem, there ought to be at least some business decision-makers in there. If you’ve got a technical problem, you shouldn’t have the marketing guys figuring out which firewall to buy.

It’s not just expertise. There’s often a component of incentive. You want to get the right decision-makers with the right expertise, the right incentives, the right authority, meaning the people who have the actual ability to make decisions, and so on. You do kind of end up re-combining them in a collaborative decision process, but really it’s about getting the right people involved in the decisions.

All: That sounds like the old IT/business divide. Does that remain a consistent challenge, bringing IT and business together to collaborate on decisions?
Austin: I think it still exists. But in the same organization, it gets better and worse. That’s what we were illustrating in the book. In Chapters 10 and 11, the company has a big crisis. The guy is not a technical CEO, he’s one of the best business managers they have. But by the time he comes out the other end of this crisis, he’s starting to behave a lot like a traditional technical CEO. He’s kind of reverted to form. In some ways, it’s not a matter of who is who. It’s a matter of the roles that organizational settings cause people to lapse into. Also, it’s insufficient attention to the need to communicate in a systematic way.

Often, to get it to work, I think you have to do things that run counter to what you’d like to do most in a particular moment. The classic scenario is something goes wrong, and the reflex of the person in the technical department is to go and fix it before they come back and tell a business manager anything more about it. They want to come back with good news. The business guy is upset and doesn’t know what they are talking about, and in the worst cases, the two sides go into their opposite corners and break down at exactly the worst time. Even in a company where they’ve succeeded in eliminating the divide to a large extent, it can come back. Circumstances drive the divide back in there.

Previous Page Next Page