by Michael Schrage

IT Leaders Need to Keep Business Partners in the Loop

May 07, 20076 mins
Collaboration SoftwareIT LeadershipSmall and Medium Business

IT executives need to have business as well as technology constituents involved when setting priorities and making choices about new systems.

After a working lunch at a workshop, a senior IT manager at a global telecommunications company approached me with a problem. Over the course of several mergers, acquisitions and reorgs, his firm now had three work-order processing systems. His boss had told him to get it down to one over the next six months. He wanted advice.

So I asked, which system did the users seem to like best and why? He said he didn’t know. I suggested he organize a meeting between the three user groups to thrash out which one made the most sense for the most people. Make them pick. He hadn’t thought of that. Unfortunately, his firm’s IT culture had IT, not users, “owning” systems consolidation after reorgs. Baby-sitting interdepartmental user meetings was frowned on, he asserted.

I couldn’t help myself: I told him he was setting himself up to fail. If he unilaterally imposed a system, he would tick off the two groups whose systems lost out. Even if he were able to sell his choice internally, he’d have to understand the ins, outs and usage of each system. What’s more, while he might know the IT budget for each system, he probably didn’t know what the real business costs were for the business units. This was neither his decision nor IT’s to make, I argued. The users knew more about what they needed than he did. They should own the choice. Substituting his technical assessment of systems for their business judgment about work-order processes guaranteed infighting.

As we talked, I was shocked to discover this wasn’t some rinky-dink consolidation of a few backwater apps; these systems managed and tracked billions of dollars in equipment and servicing orders. While the need for enterprise standardization was completely understandable, the notion that IT should set those standards was not. I pleaded with him to go to his boss’s boss—­the CIO—and request that he call the users together. “Have the CIO position you as business partner,” I begged. “If you’re seen as the systems dictator, these users have a real incentive to help you fail. Please…CYA.” He said he would.

Recipes for Success and Failure

This story had a happy ending. Unfortunately, too many CIOs set their people up for failure. How so? By allowing their IT leaders to draw utterly false and dangerously misleading distinctions between their role as technologists and their responsibilities as business partners. They’re allowing their people to make the wrong decisions in the wrong way.

IT accountability doesn’t mean IT monopoly. Yes, there are infrastructure investments that truly are the sole province of IT, but even these can’t be managed by fiat. IT should always be able to articulate how its decisions reflect user needs as much as technical optimization. CIO leadership means making sure that your people know how to share accountability before they accept it. Is this a cop-out? No! The more important IT’s impact is, the more essential shared accountability becomes.

My favorite story on this theme comes courtesy of JPMorgan Chase CEO Jamie Dimon, one of the savviest executives in America. His grasp of technology’s operational role in banking is superb. Dimon heard two rival IT factions pre­sent plans on why their system should be adopted enterprisewide. Because Dimon is not a CEO snowed by IT hyperbole, both presentations were exceptionally well done.

Dimon listened carefully and offered an operational oversight that CIOs all over the world should take to heart and mind. He told his teams, in essence: I’ve heard you; I understand. Now you guys have two weeks to decide what to do and come back here to tell me. If you can’t agree on what choice to make, I’ll make the choice for you—and you won’t like it.

Needless to say, the IT teams came back with an appropriately integrated proposal the fortnight later. As CEO, Dimon inherently brought a broader perspective to the enterprise impact of a systems integration than the typical CIO.

However, Dimon also did something more CIOs need to do: He insisted that people in the best position to make the right recommendation actually agree. He made his IT people accountable for a single recommendation. He made the consequences of their failure to agree crystal clear. Yes. I’ve read the leadership literature celebrating “transformation” and “inspiration” but, frankly, the most inspirational and transformational leadership behavior the majority of CIOs could display would be to insist that their people behave as professionals. Accountability would have greater operational meaning if more C-level executives emulated Dimon’s example.

The essential principle about the link between IT leadership and IT management must be clear: If the right constituents aren’t present when priorities are set and choices are made, then IT is neither leading nor managing. A CIO whose team unilaterally imposes consolidations or apps on a business process the members don’t quite understand should hardly be surprised when “shadow apps” begin sprouting like weeds. Indeed, they should be surprised if “gray market” disintermediation doesn’t take place. IT leadership in the new millennium of software as a service means CIOs need to ask the right questions well before they start proposing the right answers.

Let me expand that: CIOs need to make sure their people ask the right questions of others before they start proffering—and imposing—the right answers.

It’s Called Leadership, Not Followship

I don’t believe in consensus—rough or otherwise. I have little but contempt for management gurus and consultants who condescendingly declare that the customer—and the user—is always “right.” That said, I’ve witnessed breathtakingly ill-considered systems implementations by IT shops that have allowed the problem at hand—or their budget—to be defined primarily on technical grounds. I’ve seen smart CIOs organizationally scalded by well-intentioned direct reports who let their accurate spreadsheet calculations overwhelm their common sense and common courtesy.

This happens for simple reasons: We interpret responsibility and accountability the wrong way. Remember how annoyed we get when HR unilaterally imposes policies that counterproductively constrain our people to do their best work in a timely manner. That’s a microcosm of the frustration people feel when IT has unilaterally made seemingly minor systems changes that everyone now has to live and work with.

My senior IT manager should become a Dimon in the rough: Get those three groups in a room and make them accountable for what they need so that he can become accountable for delivering it. If they won’t do their job, how on earth can he do his?

Michael Schrage is codirector of the MIT Media Lab’s eMarkets Initiative. He can be reached at