Adivce on significant change in working environment!

October 1, 2012 1:38 AM

Advice wanted: I'm moving from being the "IT guy" in 4 man company to IT managment in a large ogranisation (60k+ employees).

I've recently been hired as an IT service delivery manager in large public body organisation. Previously my roles were largely development based, and I've spent the last 9 years working largely remotely as the IT guy (read: "manager/developer/support/guru") for a tiny 4 man company.

The new place heavily follows ITIL, whereas the old company we basically did most things by the seat of our pants (for want of a better phrase). In this new role I will be responsible for managing the contractor team responsible for running a part of the network.

This new job is a huge change in working environment for me:

- office based
- many hierarchies
- beaurcratic
- office politics
- very structured technical processes
- managing contractors (as opposed to freelancers)

Whilst I am looking forward to this job (especially having some sort of a process to help you) I am also apprehensive about the scale of the change. Managing 100s servers as opposed to 4. Having binding SLAs as opposed cordial relationships with clients. Needing to "smell out trouble in the contractor team" as my interviewer said!

Also, whilst I am an introverted sort of person, I've learnt from working from home that I miss an office with other people in it - I guess I am shy, but sociable. But I do worry a little about the change in dimensions. ie from working with a few well known people all pulling in the same direction, to having to make or prove your point against a bunch of people, many of whom might not be "on your side".

I would welcome any general advice on coping with the change, books (or websites) to read and experiece from anyone who has been through a similar career move. I am particularly interested in advice on the "social/managment" aspects rather than the technical ones.

Thanks.

posted by contentedweb to work & money (10 answers total)

Get ready for change management. Every change that is made will need to be documented, planned and approved in advance. Being in management, you'll likely be approving changes and taking responsibility for them, rather than actually raising and implementing them. Change Advisory Board meetings weekly, going over every change that will be happening in the next week. Justifying *why* your teams need to perform a certain change. If something screws up due to a change, the most important issue can be "Was there a change record for that?". If not, that can cause more fallout than whatever the actual problem was.

(OK, I've said the word "change" enough now)

Oh, and if you're managing the network team (or part thereof), you'll probably find that a lot of application or user errors are initially blamed on the network, and you (or your team) will spend a lot of time just trying to prove that it's NOT a network problem. I get this a lot in my area too - storage ("The SAN's down!!!" .... No... No it's not).
posted by Diag at 3:32 AM on October 1, 2012 [1 favorite]

You wont have a hope of being able to fix all the problems getting fired at your department so you need to focus on the work that is going to make the biggest difference. You need to know what your service level agreements are so that you can identify when they are being broken (and know what your success figures are).

There will be an upcoming mountain of requests for enhancements and other development work. You need to have a hand in which requests are getting picked up to be working on - and make sure that these either have strong return on investment or a necessity to "keep the lights on". This is going to influence who you need to hire, fire and retrain as well as how your money gets spent.

My quick bet: -the contractor, or contractors, probably do not get on well with the main employer. It sounds like your job is to make that relationship work as best as it can. Make some impartial, diplomatic and careful enquiries on both sides of the fence. Expect this to be a harder problem to solve than any technical issues.

If you can arrange it that your manager judges you and your department on objective goals derived from the above points - rather than (just) on short term reactions to alarms - then that will be to your benefit.
posted by rongorongo at 4:16 AM on October 1, 2012 [1 favorite]

I totally and loudly endorse what diag says. In fact I just checked his profile to see if maybe he works in my job's IT department, too. You need to wrap your head, fast, around the idea you can't "cowboy" ANYTHING anymore - every tiny change needs to be documented, justified, and approved.

Depending on the culture in your department/company your fears w/r/t fingerpointing and rivalries may not be justified. I work in a colossal IT division and am really happy with the way different "product lead" teams work with each other to solve problems. No matter how large the impact or high the urgency of a given crisis, the knives never come out and everybody remains collegial as we work to find out whether the problem lives in the network, the software, or on the servers. You will have to take the temperature at your new place to find out how easily negativity comes to the surface.
posted by BigLankyBastard at 5:25 AM on October 1, 2012 [1 favorite]

With contractors, what you'll will need to be prepared for and will bang your head against is that, even if the individual contractors themselves are willing, they're largely not allowed to do anything that hasn't been covered by whichever SLA etc you've set up with their company. Anything outside of that is going to cost money, even when the problem you're trying to solve is caused by their own incompetence/lack of forethought.

As BigLankyBastard said, *you* can't be a cowboy anymore to solve problems, but one of the main skills you need to learn is knowing when it's okay to let your own employees cowboy, as well as how to maintain plausible deniability. You'll also need to learn the real ways in which you can get to accomplish things, who will help you and who not.

One tip: be kind and polite, but not patronising, to "service" people like secretaries and receptionists and the like, these can be surprisingly helpful and often more clued in to office gossip than more "important" people. If you have the project secretary on your side, you've won half the battle.

Taking regular smoke breaks helps a lot as well to plug into the office tamtam, as does a lot of legwork and informal meetings with key players.
posted by MartinWisse at 5:41 AM on October 1, 2012

If you're going to be over people, I can't recommend this book enough.

Managing Humans: Biting and Humorous Tales of a Software Engineering Manager

It's by the Rands in Repose guy, so if you've been around the internets a while, you've likely read some of his stuff.
posted by DigDoug at 5:54 AM on October 1, 2012 [1 favorite]

Thank you all for the great responses. Lots of good good advice here which might seem obvious with hindsight, but which I wouldn't have thought of beforehand. Such as the post by diag on "change".

re the tip for taking regular smoke breaks. What's the best way of taking these for non-smokers!? I suppose that would be a coffee break, but smoke breaks tend to happen outside and I can't help feeling that's where the real office gossip takes place...
posted by contentedweb at 7:15 AM on October 1, 2012

I'm a non-smoker, and I take my "smoke" breaks as short walks, like around the block or so. I time them to conveniently run into the pack of smokers (they tend to all go out at similar times) and stop by for a friendly hello. So my suggestion would be to just learn their timing, and show up.

It's often one of the most productive parts of my day.
posted by mrgoat at 8:06 AM on October 1, 2012

You definitely need to get used to more process and working with more teams to get something accomplished that you might have taken care of yourself or with with one other person. I will however say that you may not see the end of "cowboying" a change thru the infrastructure. The rigors of change management will likely vary depending on which internal team you are working with. It is not uncommon to see a great disparity. This is espacially true when really important, high profile efforts need changes implemented. All the lovely, pre-approved change management processes have a way of being ignored when a powerful vice president says so.
posted by mmascolino at 8:07 AM on October 1, 2012

IT Departments really vary in their cultures and processes. Some run super-strict ITIL shops that put the NO in Innovation quite nicely. Others run around with their hair on fire fixing the problem of the day. Both ends of the spectrum are dysfunctional.

Your new job as a manager is going to be a lot more about people than process at the beginning. However, all this ITIL mumbo-jumbo can be daunting to an outsider. I'll put in a plug for The Visible Ops Handbook, which can also be purchased at your fine neighborhood Amazon outlet. It's a quick and easy read on how to run a high-performing IT department. As co-author Gene Kim says:

Process frameworks, such as ITIL, are basically an exhaustive list of IT processes, given without order or priority. The problem is, organizations don’t do process frameworks: they do projects. Our goal was to describe the four projects required to implement and operatationalize the controls observed in high performing IT organizations.

And a fascinating tidbit I just learned at the link above:

When we first studied the high performing IT organizations, we noticed something unusual. The backgrounds of the people leading them typically came from one of three backgrounds. They were either a non-commissioned officer in the military (usually E-5s or E-6s), they were chemical engineers, or they were auditors. We then started asking, “what values do these three professions have in common?” And the answer became obvious. They valued rigor and discipline.

posted by troyer at 9:57 AM on October 1, 2012

The ITIL For Dummies book (no link, I suck) is actually quite readable and will help you realize a lot of the formally recommended processes are common sense, especially for managing IT with limited resources in a large organization.

You may also want to look into LISA, the Large Installation Systems Admin group of USENIX.
posted by thatdawnperson at 7:49 PM on October 1, 2012