Making the move from IT operations to the applications group

Dear Bob …

I’m either being promoted or punished. I’m not sure which.

[ Also on InfoWorld: In the fast-moving world of high-tech, you have to weigh the pros and cons of making a tech career change. | Get sage advice on IT careers and management from Bob Lewis in InfoWorld’s Advice Line newsletter. ]

Through the end of the week, I’m managing IT operations — a team of about 20 system administrators, network admins, and so on. Monday I start my new position, managing the applications side of the house.

Our IT organization has the normal level of rivalry between ops and apps. The good news is that there’s no overt hostility between the two groups. The bad news is that the outgoing head of applications was popular with the staff but not with the rest of the company.

The bad news and good news are closely related. He was everyone’s buddy (including mine — I liked the guy), which meant he didn’t hold anyone’s feet to the fire. The result was a poor track record of delivery, which is why he’s no longer with the company, though the CIO didn’t publicize that tidbit, of course.

Do you have any advice to give me, so when I step into his shoes I don’t step in anything else?

– Switching Sides

Dear Switching …

First, the basics: You’re leaving a world in which invisibility is the measure of success and entering one in which both successes and failures have bright spotlights aimed at them. In case this point isn’t clear:

• The IT operations team succeeds when all systems are available and performing within acceptable boundaries. When they are, nobody notices, and they go about their work. It’s when they’re slow, out of capacity, or entirely unavailable that people notice, which is why invisibility is the highest aspiration of IT operations.
• Application development succeeds when it delivers working software on time and within the planned budget — software that doesn’t just meet the specifications and “requirements” (a term that’s outlived its usefulness) but that enables and supports a planned business change. Whether the software delivery is a small enhancement or the result of a large, multiproject initiative, it gets attention because it changes an element in the business that somebody cares about.

Given this level of visibility, whoever heads up the applications side of the IT house had better devote a lot of time, energy, and attention developing and managing interpersonal relationships throughout the business. You want every executive and middle manager to know who you are, like you, and trust you. If they do, they’ll forgive the occasional bump in the road and work with you to fix it. If they don’t, every problem will be magnified. Worse, every problem will be “your problem” rather than “our problem,” which means they’ll become unfixable.

Your internal challenges will be equally interesting. As is also the case with IT operations staff, developers tend to assess their managers’ credibility in terms of their technical chops. This isn’t entirely unfair, either; leaders are responsible for setting direction, after all — for articulating a compelling account of a future state that’s superior to the current situation. They’re also on the hook for the more prosaic job of knowing what good performance looks like when employees do and don’t deliver it.

You’ll find it tempting to address this challenge through the rhetorical ploy of “pre-emptive deprecation” — by starting sentences with “You know more than I do about,” whatever it is. While superior to the pretense that high-level trade-press articles provide enough knowledge to lead technical experts, it’s still a poor approach; if you use it, you’ll be focusing everyone’s attention on what your job isn’t.

Instead, make sure everyone is clear on what your job is and what does qualify you to lead the applications group. This will include such responsibilities as making sure everyone is in agreement regarding what success looks like; removing barriers and obstacles; preventing oversubscription (chartering more projects than can be fully staffed); and identifying problem areas and making sure the right people are given responsibility for fixing them.

Somewhere in the mix should be a responsibility or two that leverage your operations knowledge. You might, for example, explain that an ongoing problem has been software that’s passed all tests but turned out not to be production-ready. This is bad for everyone, but because you come from the operations side of the house, you’re in an excellent position to help the group figure out how to make software production-ready on the first try — an outcome that will free up developer time while reducing a source of constant aggravation.

Finally, you have the same challenge every manager has when taking on a new role: getting to know everyone so that each of you becomes a person to the other. Technical chops notwithstanding, one of the best ways to get tagged as a bad boss is to give the impression you consider the men and women who report to you to be nothing more than interchangeable collections of organic molecules.

Internally as well as externally, if they like you and trust you it will take you a long, long way.

– Bob

This story, “Making the move from IT operations to the applications group,” was originally published at InfoWorld.com. Read more of Bob Lewis’s Advice Line blog on InfoWorld.com.