Sometimes you meet a person who strikes you as an inspiring role model. Other times, you get a role model of a different sort, an example of how not to be. The CIO I had just spent an hour with was definitely the second type.
A corporal in a general’s uniform, I thought to myself. I had found out earlier that he had never actually developed any applications software in his career, and he certainly didn’t appear to know how to direct or delegate such a responsibility now. When it came to the IT framework of plan, build and run, he was quite capable of keeping things running, but he was clueless about planning and building. He probably never should have gotten his position in the first place, and it looked as if I was hired to help assure that he didn’t stay in it much longer.
This was during my consulting career. I had been engaged by the managing director of a strategic business unit of a large enterprise who was having trouble dealing with the central IT service function. There were many problems, such as IT’s failure to meet agreed-upon service levels and not seeming to care. But what had prompted his call to me was the near impossibility of getting software developed or modified. The IT function was unresponsive and bureaucratic, throwing up a stone wall by saying that it would work on applications software development only after the business unit documented the system requirements.
“I don’t know what a system requirement is or how to document one,” the managing director told me. “And the last time I got my people to try and do that, the IT function returned my write-up months later with a list of things that we’d omitted or that they thought wouldn’t work.”
His exasperation was rooted in business considerations. “We’re losing business,” he said. “We know how to address our problems with better technology, yet we’re stuck, because this IT bureaucracy is keeping anything from getting done.”
After he had filled me in on more details, I had a pretty clear picture of an IT function with a bunker mentality. It’s not a rare thing, unfortunately, perhaps because there are so many things that can contribute to it. In some cases, IT simply had a very limited budget and no way to prioritize development expenses, so they raised hurdles to bar against new ones. Other times, IT had been badly burned after diving into a big development project with inadequate specifications. Or it had insufficient resources, or had lost the talent necessary to develop new applications, or was unable to communicate with business units or become involved in business unit issues. No matter the root cause of a bunker mentality, the result was invariably a relationship that verged on adversarial with IT’s clients.
The managing director was ready, if necessary, to do an end run around the in-house IT function to get what he needed. He was confident the CEO would back him up. “Time is our competitors’ best friend now, and the CEO knows it,” he told me.
I spent some time familiarizing myself with the managing director’s system development needs, and then I met with the CIO. What I found was a politically astute, melodramatic and theatrical bully. He was darkly threatening and intent as he asked me about my qualifications, the results I had achieved and the person who had engaged my services. He became less dark when he learned that the CEO knew about my mission.
Apparently believing that he could make all this go away with some carefully phrased happy talk, he told me that his IT function and the business units it served were a team. But his body language suggested that he wanted nothing more than for this meeting to end. My guess was that he was itching to “back channel” the CEO to assess what damage had been done to his career.
I was more amused than irritated by his behavior, mostly because it was so transparent, even though he seemed certain that it was a convincing performance. I didn’t let on, though, as I said to him, “I understand that you have a strict policy that internal clients must write up their own system requirements, with no cooperation from IT. I would expect such an approach to delay results. Why do you do things that way?” For me, this was a natural question, because I really couldn’t understand how this policy could be deemed a good idea. In my experience, systems requirements are best developed jointly, with IT professionals and business specialists working together. Software can then be delivered in stages depending on priority, so as to avoid high-risk, all-or-nothing, complex implementations.
What this question prompted was amazing to see. First, the CIO questioned every assumption behind my query. Then he wanted me to name my informants and to tell him exactly what they said. Finally, he was keen to know whether he had been mentioned specifically.
I answered him with equanimity (whereas he had answered me not at all), and he then sputtered, “This is a serious issue for me and now that I’m aware of it, I will make it my top priority.” To show how serious he took the matter, he added, “When I get to the bottom of this, I may have to start over with new people!”
In short, everything had been a failure on the part of someone other than him, and he would be sure to punish the wrongdoers.
And so, I thought upon taking my leave, this little corporal is going to make sure that heads roll, to demonstrate to all that he is fully in control. It was the completely wrong response.
Options
I had an exit interview with the managing director and two other senior executives from other business units.
“The CIO called and asked me why I hadn’t informed him directly about my problems with his team,” the managing director told us, more than a little amused. “He said that if he’d known about our delays, he could have avoided all this. I told him that I’d left three messages with his secretary during the requirements-writing debacle without a return call and that I’d noticed that he had signed off on every bureaucratic and time-wasting document in that ridiculous exchange. So, I asked him, how could you not know about this situation? I also told him that he was supposed to be running a client-focused internal corporate service and that the business units were his customers. I suggested that he and his team start treating us that way.”
The other senior executives were heartened by the report of this exchange, but it was time to get down to business. The managing director turned to me and asked, “What needs to be done here?”
“I see three options,” I said. “First, the CEO could direct the CIO to provide a commercial-grade IT function that plans, builds and runs all IT services at less cost than external contractors. The second option would be to create an exception that would allow business units to make use of external developers when the internal corporate IT function can’t provide its service in a timely manner. Finally, there’s the option of leaving corporate computer operations — the ‘run’ piece of IT — centralized while moving all applications software development staff into the business units.”
I would have added that I thought the first option was clearly best, for many reasons, not the least of which was the shareholders’ viewpoint. But before I could do so, it became clear that the business managers had already agreed upon a similar course of action.
In the end, the CIO ended up reporting to a new CIO who was proficient in collaboration with the business units the IT function served.
So what?
If you are a CIO who doesn’t routinely meet with the heads of every strategic business unit you serve in order to get to know them personally and assess your IT function’s performance before there is a crisis, you are in a career-limiting position.
You need to remain aware of even the smallest ways you might improve the IT function’s contribution to the strategic intent of the enterprise and each business unit within it. You need to stay in contact so that you can be effective in dealing with issues before they become critical.
And an overbearing management style is counterproductive and ultimately short-lived, for the simple reason that no one wants to spend time with someone who employs it; they are unpleasant people, incapable of constructively exchanging knowledge and wisdom or building joint focus and momentum. I’m fond of Joel Barker’s definition of a leader: “Someone you chose to follow to a place that you would not otherwise go.” Even if you have the chops that this doomed CIO was sorely lacking, you should never rely on an overbearing management style. Those who report to managers who employ such an approach never consider them leaders.
