The Set-up

"George, you've really done a great job on that project. I think you're going places around here."

"Thank you, sir!"

"In fact, I'm doing a little reorganizing, and I have a new assignment in mind for you. You know we've been having a bit of trouble getting our infrastructure operations under control. I'd like you to clean that up for me."

"Great, boss! Sounds like a fun challenge. But tell me, who've you got in mind to take over my job of infrastructure engineering?"

"George, you did well a couple of years ago in operations, and you've done well in engineering. At this point in your career, I think you ought to be able to handle both."

"Uh-huh...."

"With the proper headcount, of course."

"Okay, boss!"

6 Months Later

"George, can I talk to you for a minute?"

"Sure, boss."

"I'm really pleased to see the way you've stabilized operations...."

"Well, thanks, boss!"

"But I've been getting a number of calls from the other VPs complaining that you've been holding up their projects. You know how I hate calls like that. I'd like to politely ask, what the #@!! is going on?"

"Well, sir, I've been working 60-hour weeks to document procedures. I've still got a ways to go; and I haven't started thinking about capacity planning, change control, disaster recovery, and security administration. Meanwhile, half the day seems to go into fire-fighting. The last thing I need right now is another major application coming on-stream!

"And, boss, every time we bring a new application into production, it disrupts operations. I think we have to slow down and ensure proper change control. I decided that a once-a-month window for installing new applications would be more than ample.

"And another thing.... I can't let the engineers put just anything into production. Then I'd be blamed if it doesn't run reliably. So I've instituted a lot more rigor around testing and quality control -- even for small projects like enhancements. I think we've made great progress stabilizing operations. Good stuff, eh boss!?"

"George, George, George.... You know we need to do more than keep existing systems running. We've got to get new applications up. We need to explore cloud computing and social media. We need innovation! What's the problem???"

What Went Wrong

The problem is simple: Invention and operations are like oil and water -- they just don't mix.

This conflict of interests isn't unique to IT. Here's another case example:

A promising executive within a telecommunications cable manufacturer was given responsibility for both business development (acquisitions) and operating acquired companies during their transition into the corporation. After the first major acquisition, the CEO was disappointed to find that little was done in the way of new deals.

Why? Running and integrating the acquired company required this executive's full attention. After the first big acquisition, he had no time for new deals. By combining invention and operations, the CEO was left without a business development function.

The term "invention" is meant to imply creating entirely new things, for example developing new ideas, products, and methods. This is a special type of innovation, beyond the marginal changes of continual improvement.

Invention is the crux of this conflict of interests. Any function can be innovative on the margin. But invention and operations are antithetical.

When one person is asked to do both, he/she is not likely to find the ideal balance. Operational issues tend to take precedence. Fire-fighting swamps invention. Short-term problems take attention away from long-term opportunities. Those who "keep things running" have little time for future-oriented invention.

It's not just a matter of having the time. Invention is not in their best interests. Major changes threaten the stability and efficiency of operations. Operations staff will pursue innovation on the margin; that is, they'll get better and better at what they currently do. But they're unlikely to pursue breakthroughs which inevitably disrupt operational stability.

This clearly is a structural problem. If an innovation function reports under an operational function, little progress will occur -- no matter who has the job of innovation.

Bottom Line

A multi-function organization such as IT is responsible both for innovation in its products (e.g., technologies) and for operational reliability and safety. Accountability for invention and operations should be separated into two groups, and the balance should be decided by a dialog between functions.

To be specific, the operations functions (Service Providers) are responsible for service delivery; they buy infrastructure from the Engineering function. Engineering should continually offer innovative proposals. Then, operations managers should decide what they will "buy" -- balancing the need for stability with their responsibility for evolving their service offerings once the market need is evident and the technologies are sufficiently mature and stable.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....