by Anonymous Author

Organizing the Modern IT Department

Sep 15, 20018 mins
IT Leadership

During a board dinner a while back, I managed to get myself trapped in a predictably overheated argument about the best method for managing projects and organizing IT departments. One of the other board members (also a CIO) and I decided to entertain the rest of the committee by pointing out the various and fatal flaws in each other’s approach.

Why Don’t I Stick with Football?

There are some topics you just don’t discuss in polite company, especially these days. You know the list: politics, religion, most social issues and of course, any point of view that is liable to cause listeners to scurry for their respective corners and glare at one another. That’s why it’s never a good idea to sit down at a cocktail party. Everybody is interesting for five minutes, but after that, the conversational pickin’s for us introverts get pretty thin and it’s time to stroll to a different part of the room. Experience with things like vendors, consultants, hardware or recruiting tends to be pretty much the same, so finding common ground is easy. However, on the continuum of social missteps, expressing a point of view (no matter what it is) concerning organizational and executional strategies and tactics falls somewhere between redipping your half-eaten corn chip in the salsa bowl and shooting the Cheez Whiz directly into your mouth.

Now stand back and watch as I try not to shoot any cheese up my nose.

As I see it, IT organization charts and project execution ought to be less about managing IT and more about managing users and the needs of the company. A good CIO has to overcome her natural tendency to want to mix it up in the trenches and must be careful not to overcontrol a department, especially a big one. An effective CIO stands far enough back to observe what is going on, calibrate and refine. Get the strategy right, the saying goes, and any middle manager can work out the tactics best suited for the situation.

If you don’t agree, it may be because you’re a control nut.

Running the War from Headquarters

I haven’t changed companies as often as some of the CIOs I know, but in the arc of my narrowing career, I left three CIO positions: once for a division transfer, once for greener pastures and once for my own sanity. In each case I walked into a department populated by competent, hardworking people who had, for related reasons, lost the confidence and support of the company they serviced. All three of these organizations had in common an inadequate or misallocated budget, all were beset by covert and competing IT organizations in the field, and all were centrally (and exclusively) managed from headquarters.

I’ve had CIOs tell me they found the process of changing companies tough but very exciting. I found changing companies more distracting than exciting, and the process of orientation boring and frustrating in the extreme. The first few months of each new job was a series of “Why would we be doing that?” revelations and weirdly intimate conversations with subordinates and peers about what a jerk the last CIO was and how they were counting on me to set things right. There is no doubt in my mind that the same conversations were happening at the companies I’d just left.

As I went about the business of assessing what had been going on in each of these departments, it was clear that my predecessors were doing far more things right than wrong, and even the wrong things were pretty inconsequential, except for one. The mistake, I came to believe, was their decision to collectivize and manage IT centrally, to pass down tactics such as five-year plans like some kind of politburo and to allocate resources based primarily on grand strategies instead of local needs (local as in where the customer lives).

Centralizing IT is a “teamwork is a lot of people doing what I say” approach to managing resources and priorities, and it has brought all kinds of problems. The distrust and frustration of users in the field who are too far removed to participate in or even understand how or why development and support decisions are being made will, in the end, derail the best laid strategic plans and intentions. Pushing IT departments too far from the action probably means you’re not using your company’s most creative, capable talent to address the short-term needs of your green-money customers. A big mistake. Furthermore, nameless, faceless IT people in far-off places make for ready-made villains and highly useful scapegoats when things don’t go as planned. For IT folks, this remoteness and the sense of being only a small part of a very big project plays hell with morale, workmanship, productivity and innovation.

Winning the Battle in the Field

Please, don’t interrupt; I know what you’re thinking. Yes, there are plenty of successful organizations out there that are managing that way. It is true that in the hands of an exceptionally skilled CIO, operating within a highly autocratic headquarters structure and servicing a mature business in a mature industry, a highly centralized structure works well enough. And a Yugo will get you to work in the morning.

Centrally managed IT organizations are a holdover from (or retreat to) a far less user-centric and, frankly, far easier time when all the processing power in a company resided in the data center and the devices on desks were as dumb as a sack of rocks. The day we moved processing capacity out of our direct control, we were duty-bound to move with it, to help our users exploit that capability or suffer the consequences (which some of us have). Centralizing IT in this era of distributed capabilities is a mistake justified by, among other things, the unsubstantiated notion that it is less expensive. The pressure to recentralize functions in this slow economy as a means to eliminate redundancy is absolute nonsense, at least in the case of IT, because for every dollar saved, $2 will be spent (secretly) in uncoordinated, nonstandard, unsupportable IT efforts in the field.

Slap a handkerchief on my head and call me Gumby, I simply couldn’t figure out how to make a centralized model work. And I didn’t just decentralize the new organizations. To one extent or another, I broke the department into pieces and gave them away, budget and all, to the division and department heads they were servicing. Each of the new, smaller, faster departments were led by what amounted to a junior CIO who reported on a solid-line basis to the department head and (here’s the important part) also on a solid line to me. The department head and his team were responsible for chartering projects, establishing priorities and levels of investment, and overseeing functional requirements and implementation?the “what” of the systems development and support process. I, on the other hand, owned the “how”?how it would be developed, using which tools and which standards, and how it would integrate with other systems.

Making it work requires that you reengineer the systems architecture to mimic the Internet: standardize the presentation with a Web browser, build applications on local servers, and centralize the database design and management on universal data servers to ensure compliance with standards and uniformity of results. That takes us a half-step toward a long-predicted environment where users write the applications and we manage the platforms.

Eventually, secret IT teams (skunk works that appear when central IT is unresponsive) were absorbed into departmental IT teams, development cycles got shorter, morale went up, and solutions got more focused and timely. At one of the companies I left, the changes I made lasted only as long as I did. Slap a seed cap on his head and call him Bubba, the CIO that replaced me simply couldn’t figure out how to make a decentralized model work.

The fundamental things apply (as time goes by). Even if the pros and cons of the centralized versus decentralized approaches added up to a draw, the tiebreaker must, in the end, be systems users and green-money customers. It seems intuitively obvious to me that the closer and more directly IT people interact with end users and customers, the better the results. Filtering design requirements through “subject-matter experts,” or whatever they’re being called these days, with their associate biases and yield loss of information quality, is a waste of money and time.

If a decentralized approach (giving power away to the users) can be said to be harder to manage?and I think it is?it must then follow that CIOs choose to manage centrally in order to make it easier on IT.

Is that why we’re here?

Well, is it?