I.T. Ninjas
February 20, 2007 2:26 PM Subscribe
How do great I.T. Managers run their departments? I am looking for a playbook on how to run a steamlined I.T. department for an organization of 500-1000 people. McDonalds has a handbook on running a restaurant from soup-to-nuts. I want the same for an I.T. Department. I have searched the Web and Amazon and cannot practical, tactical information on managing an I.T. department. I can easily find literature on high-level concepts like ITIL, SOA, and 'Runnng I.T. Like a Business', but nothing practical like 'How to run a helpdesk', 'How To Keep Track of Software Licenses' or even 'What does an I.T. Manager really do?'. What are the things that your I.T. department does that make them great? How do I get a blackbelt in I.T. Management?
Blazecock's advice is also good.
I cant tell you what great managers do... but I've had plenty of experience with bad ones :)
Here's a short list of what NOT to do:
1.) Drive your people into the ground. Energy and creativity will quickly die if you are understaffed and continually driving to unrealistic deadlines. Your IT people should have minimum 1 or 2 hours a day of "play time" or "research time" or whatever you want to call it. Treat your staff like you value the quality of their work, not the quantity of work.
2.) Discard ideas. ...I was the kinda guy who was always going to my boss with crazy ideas (like 5 or more a week).. true, most of them werent perfect.. BUT.. you cannot predict when a business changing idea will come around. Foster a "thinktank" sort of atmosphere where people can throw around any crazy idea they come up with. You dont have to institute any of them.. the point is supporting inventive thinking.
Another good book I just read is--> Mavericks at Work
posted by jmnugent at 3:21 PM on February 20, 2007 [1 favorite]
I cant tell you what great managers do... but I've had plenty of experience with bad ones :)
Here's a short list of what NOT to do:
1.) Drive your people into the ground. Energy and creativity will quickly die if you are understaffed and continually driving to unrealistic deadlines. Your IT people should have minimum 1 or 2 hours a day of "play time" or "research time" or whatever you want to call it. Treat your staff like you value the quality of their work, not the quantity of work.
2.) Discard ideas. ...I was the kinda guy who was always going to my boss with crazy ideas (like 5 or more a week).. true, most of them werent perfect.. BUT.. you cannot predict when a business changing idea will come around. Foster a "thinktank" sort of atmosphere where people can throw around any crazy idea they come up with. You dont have to institute any of them.. the point is supporting inventive thinking.
Another good book I just read is--> Mavericks at Work
posted by jmnugent at 3:21 PM on February 20, 2007 [1 favorite]
At my old org - around the size you're talking about - we leased all of our computers, which made life a lot easier when replacing parts, but a lot harder when leases were up. We also depended on HR a lot regarding hiring and leasing enough new machines.
We managed our inventory in an Access database.
We didn't keep track of our Help Desk calls - we looked into a variety of software to do so, but as of when I left, we still didn't have anything.
We had a lot of basic tasks documented and on the intranet.
We kept track of software licences in an excel spreadsheet.
posted by k8t at 3:33 PM on February 20, 2007
We managed our inventory in an Access database.
We didn't keep track of our Help Desk calls - we looked into a variety of software to do so, but as of when I left, we still didn't have anything.
We had a lot of basic tasks documented and on the intranet.
We kept track of software licences in an excel spreadsheet.
posted by k8t at 3:33 PM on February 20, 2007
Oh, we also had a master Windows Ghost image with all of the drivers for our 4 or so different laptop/desktop configurations.
posted by k8t at 3:33 PM on February 20, 2007
posted by k8t at 3:33 PM on February 20, 2007
I also can't tell you what great managers do. But I can tell you that our company (1000ish employees spread over several offices and several states) got a new manager. And things have gotten way better because:
1. centralized system. If I call the IT department I might get someone in any office. This results in more help right away, instead of having to leave a message. They also now have a system where I can wait on hold instead of leaving a message, which is nice when something is going wrong RIGHT NOW.
2. email help - which I understand is managed through a ticketing system. This is great becuase if I have a quesiton that isn't related to something breaking right this minute, I can get a response as time allows.
3. flexible scheduling of the IT folks. Some of them start at 7, some work weekends, some work late. My understanding is that this is based mainly on choice. It results in better coverage, and means that upgrades and installs can be done when people aren't using their machines.
4. other simple things, like understanding that if 5 people have asked the same question, another 100 or so have the quesiton, or are frustrated with the issue. Use a FAQ, or a "tip of the day", or some other intranet way of providing this information. Company-wide emails only if its a serious problem or related to some kind of new software.
5. letting the people do what they're good at. We have one guy who is the best "explainer". He is good at it and likes it, so he should be on the phones/email all the time. Don't make him install upgrades or fix blackberries. Let the guy who isn't as good with people do that. People are not interchangable parts.
6. understanding that, in many companies, IT=help desk, even though it is, of course, much more than that. Make help desk a priority so that your "clients" trust your people. It'll make everyone's life easier, and in my experience, make it easier for you to get more people/help/money/better programs/whatever.
7. akin to 6, build a team of people who can help test new products. Find the young, tech savy people who are friends with/mentored by the old, not-tech savy people. We recently got new phones that are almost unusable in our profession. The only people who tested them were IT people and admin people. After two days, any one of us could have told them 10 reasons why these phones are awful. Not just difficult, or lacking the particular features that people like, but truly unworkable. Compose your team carefully. Our new guy has started to do this, and I'm going to be very interested to see how it works out.
posted by dpx.mfx at 3:36 PM on February 20, 2007 [1 favorite]
1. centralized system. If I call the IT department I might get someone in any office. This results in more help right away, instead of having to leave a message. They also now have a system where I can wait on hold instead of leaving a message, which is nice when something is going wrong RIGHT NOW.
2. email help - which I understand is managed through a ticketing system. This is great becuase if I have a quesiton that isn't related to something breaking right this minute, I can get a response as time allows.
3. flexible scheduling of the IT folks. Some of them start at 7, some work weekends, some work late. My understanding is that this is based mainly on choice. It results in better coverage, and means that upgrades and installs can be done when people aren't using their machines.
4. other simple things, like understanding that if 5 people have asked the same question, another 100 or so have the quesiton, or are frustrated with the issue. Use a FAQ, or a "tip of the day", or some other intranet way of providing this information. Company-wide emails only if its a serious problem or related to some kind of new software.
5. letting the people do what they're good at. We have one guy who is the best "explainer". He is good at it and likes it, so he should be on the phones/email all the time. Don't make him install upgrades or fix blackberries. Let the guy who isn't as good with people do that. People are not interchangable parts.
6. understanding that, in many companies, IT=help desk, even though it is, of course, much more than that. Make help desk a priority so that your "clients" trust your people. It'll make everyone's life easier, and in my experience, make it easier for you to get more people/help/money/better programs/whatever.
7. akin to 6, build a team of people who can help test new products. Find the young, tech savy people who are friends with/mentored by the old, not-tech savy people. We recently got new phones that are almost unusable in our profession. The only people who tested them were IT people and admin people. After two days, any one of us could have told them 10 reasons why these phones are awful. Not just difficult, or lacking the particular features that people like, but truly unworkable. Compose your team carefully. Our new guy has started to do this, and I'm going to be very interested to see how it works out.
posted by dpx.mfx at 3:36 PM on February 20, 2007 [1 favorite]
I would heartily recommend you instill in your people the idea of service...that they are there to enable the rest of the company achieve their goals. In short, train your people not to act like they are high-holy-keepers-of-the-grail or something. I don't know about others, but I've certainly endured my share of I.T. people treating workers like shit because they had the temerity to ask for assistance.
posted by Thorzdad at 3:54 PM on February 20, 2007
posted by Thorzdad at 3:54 PM on February 20, 2007
Staff Training -- Budget for training, and insist that your people actually take the courses. Make training a part of the daily schedule, so that your people don't feel like they have to train on their own time. Find out about the big industry shows that your major application vendors put on. Try to send at least one or two people to this event every year. They may seem like a waste of time at first, but they are a)fun for the employees, and b)the best way to get a firm idea on what direction your software will be heading.
Ownership -- Partner with the other departments at the company, and let them know that they are in charge of their own applications. For example, your HR department probably runs a database to track employees. Train someone in HR on how to manage access to the database so your people don't have to do it.
Whenever a new project comes up, get people from the department that will be using it involved early. Make them the evangilist for the new software. They'll end up answering the easy questions before they get to your staff.
Keep a list of who owns what application. Every year, contact that list to see how the application is working.
Metrics -- Try to measure everything that is measurable. For example, # of spam messages blocked, # of Internet message vs internal messages, average time it takes to close a trouble ticket, # of trouble tickets created by department (this one is huge, you'll generally find that one or two departments generate over 50% of your issues). Insist that every section in your department generate these stats and report them to you on a monthly basis. You'll start seeing trends emerge that can help you short-cut future problems.
End User Training -- Everything you roll out you have a complete training plan for. That includes a manual (online or printed), an FAQ, and some hands-on sessions with the end users. If you are geographically spread out, do web demos. Make sure that whoever is manning incoming calls has access to all these materials, and most importantly, knows which people to ask questions when problems pop up.
posted by Eddie Mars at 3:56 PM on February 20, 2007 [1 favorite]
Ownership -- Partner with the other departments at the company, and let them know that they are in charge of their own applications. For example, your HR department probably runs a database to track employees. Train someone in HR on how to manage access to the database so your people don't have to do it.
Whenever a new project comes up, get people from the department that will be using it involved early. Make them the evangilist for the new software. They'll end up answering the easy questions before they get to your staff.
Keep a list of who owns what application. Every year, contact that list to see how the application is working.
Metrics -- Try to measure everything that is measurable. For example, # of spam messages blocked, # of Internet message vs internal messages, average time it takes to close a trouble ticket, # of trouble tickets created by department (this one is huge, you'll generally find that one or two departments generate over 50% of your issues). Insist that every section in your department generate these stats and report them to you on a monthly basis. You'll start seeing trends emerge that can help you short-cut future problems.
End User Training -- Everything you roll out you have a complete training plan for. That includes a manual (online or printed), an FAQ, and some hands-on sessions with the end users. If you are geographically spread out, do web demos. Make sure that whoever is manning incoming calls has access to all these materials, and most importantly, knows which people to ask questions when problems pop up.
posted by Eddie Mars at 3:56 PM on February 20, 2007 [1 favorite]
When your student worker asks why we are using static IP's instead of DHCP, don't yell at him about security issues and why DHCP is inferior to logging each IP address by hand.... then switch over a month later.
Pretty much foster ideas in people, hear them out. On stuff, let them put together a linux box to test stuff with in their free time. Let them put together automated unattended installs for all the common software. Let them build new tools. Let them fix and recycle old things.
Really just LISTEN to your people any time they talk about anything that can cut down their and your work load.
posted by magikker at 4:18 PM on February 20, 2007 [1 favorite]
Pretty much foster ideas in people, hear them out. On stuff, let them put together a linux box to test stuff with in their free time. Let them put together automated unattended installs for all the common software. Let them build new tools. Let them fix and recycle old things.
Really just LISTEN to your people any time they talk about anything that can cut down their and your work load.
posted by magikker at 4:18 PM on February 20, 2007 [1 favorite]
In my experience, don't let HR do the IT hiring. They don't know what to look for. As well, being a good IT manager is about farming work out to your employees. Don't control every project like a tyrant. Give people the room to expand their horizons and they will be good, faithful employees.
Build a strong team that isn't too specialized. Make sure everyone on the help desk are at least knowledgeable about everything. Making someone a specialist burns them out. The guy who knows everything about Treos and Blackberries doesn't want to be bothered all the time about them.
Training is key. Never trust your employees to know everything, because if they sound like do, they don't.
Track Help Desk calls and use the aggregate data to write new training sessions and tip sessions.
Definitely, I agree that listening to your IT staff is a good idea. As a manager, you won't know what happens on the floor on a daily basis and they can keep you apprised of anything coming up constantly.
posted by rabbitsnake at 4:47 PM on February 20, 2007 [1 favorite]
Build a strong team that isn't too specialized. Make sure everyone on the help desk are at least knowledgeable about everything. Making someone a specialist burns them out. The guy who knows everything about Treos and Blackberries doesn't want to be bothered all the time about them.
Training is key. Never trust your employees to know everything, because if they sound like do, they don't.
Track Help Desk calls and use the aggregate data to write new training sessions and tip sessions.
Definitely, I agree that listening to your IT staff is a good idea. As a manager, you won't know what happens on the floor on a daily basis and they can keep you apprised of anything coming up constantly.
posted by rabbitsnake at 4:47 PM on February 20, 2007 [1 favorite]
In a small company, my experience has been you need one IT person for every 25 employees. When the company got bigger (~1000), economies-of-scale suggested we only needed one IT person per 100. It didn't work, but the failure was so gradual we just changed our definition of "working". I still think 1:25 was the right number. As a 'customer', I prefer a one-to-one first-name basis relationship with my IT server. If you have the numbers of IT personnel to provide that, I don't think you need a lot of infrastructure (other than great ongoing training).
posted by mediaddict at 5:02 PM on February 20, 2007
posted by mediaddict at 5:02 PM on February 20, 2007
Oh! And here is my generic advice for all things IT: Nothing that you do, nothing, is more important than backups.
Make sure that you are actively backing everything up, and actually check that you can restore from those backups.
The best company I ever worked for (IT wise) would run unscheduled pop quizes. At any time you should be able to restore an entire system, from the OS level all the way up with from your previous night's backup. If you aren't testing that, you don't really have good backups.
An example:
Our disaster recover expert came in one morning and put a sign on 4 servers. The signs read: "Fire in the Server room, this box is toast." He then announced that the people directly responsible for the boxes were killed in the fire so could not assist in restoring things. The dead people got little coffin shaped name tags to wear. That was a fun day. Nothing makes you realize how subpar your documentation is like watching someone struggle to restore your box while you're unable to help.
posted by Eddie Mars at 5:15 PM on February 20, 2007 [3 favorites]
Make sure that you are actively backing everything up, and actually check that you can restore from those backups.
The best company I ever worked for (IT wise) would run unscheduled pop quizes. At any time you should be able to restore an entire system, from the OS level all the way up with from your previous night's backup. If you aren't testing that, you don't really have good backups.
An example:
Our disaster recover expert came in one morning and put a sign on 4 servers. The signs read: "Fire in the Server room, this box is toast." He then announced that the people directly responsible for the boxes were killed in the fire so could not assist in restoring things. The dead people got little coffin shaped name tags to wear. That was a fun day. Nothing makes you realize how subpar your documentation is like watching someone struggle to restore your box while you're unable to help.
posted by Eddie Mars at 5:15 PM on February 20, 2007 [3 favorites]
If you want something like the McDonalds example you give, you might be after the IT Infrastructure Library (ITIL), a practice-oriented set of formalized best practices produced by the British government, and/or Control Objectives for Information Technology (COBIT), a heavily auditing-oriented American-originated system which fits in well with SarbOx.
My workplace (~1600 employees, worldwide markets, ~$400 million) is ramping up as an ITIL shop. You don't have to do formal ITIL to benefit from it, I don't think -- if you look through the headings of that Wikipedia article you'll get an idea of the areas that ITIL pays attention to. Sure, there are courses and exams certifications and the original library and tons of third-party materials, but even just using it as a guideline of areas to touch upon is a better start than not.
Official ITIL site; ITIL Open Guide. Official COBIT site.
Additionally, Peopleware mentioned above is an excellent and important read, but it's specifically about managing developers, which overlaps with but does not substitute for managing an IT infrastructure.
posted by mendel at 5:31 PM on February 20, 2007
My workplace (~1600 employees, worldwide markets, ~$400 million) is ramping up as an ITIL shop. You don't have to do formal ITIL to benefit from it, I don't think -- if you look through the headings of that Wikipedia article you'll get an idea of the areas that ITIL pays attention to. Sure, there are courses and exams certifications and the original library and tons of third-party materials, but even just using it as a guideline of areas to touch upon is a better start than not.
Official ITIL site; ITIL Open Guide. Official COBIT site.
Additionally, Peopleware mentioned above is an excellent and important read, but it's specifically about managing developers, which overlaps with but does not substitute for managing an IT infrastructure.
posted by mendel at 5:31 PM on February 20, 2007
Hurf, I read right over your mention of ITIL, sorry about that. But I have to disagree that ITIL is as high-level as you think it is -- there's a lot more there than you're giving it credit for, and it gives very specific recommendations for particular practices. Software licenses? Configuration management. If you're doing ITIL CM you have a CM database, release management process, etc. And with those your software licenses are being tracked.
The big thing I would say is that for a 1000-person organization, the same person is not going to be responsible for managing software licenses and managing the direction of the department. Delegate the hell out of all of those sub-areas. If you're the director of IT, then you must have someone responsible for desktop computers already; there's someone to make responsible for desktop software licensing. And then he can delegate actually keeping track of the licensing, and so on.
posted by mendel at 5:36 PM on February 20, 2007
The big thing I would say is that for a 1000-person organization, the same person is not going to be responsible for managing software licenses and managing the direction of the department. Delegate the hell out of all of those sub-areas. If you're the director of IT, then you must have someone responsible for desktop computers already; there's someone to make responsible for desktop software licensing. And then he can delegate actually keeping track of the licensing, and so on.
posted by mendel at 5:36 PM on February 20, 2007
I run a department that is about the size of the one you are talking about, I was hired into the department as the manager following a system disaster that put the company at risk of going out of business. (My interview was the most intense on the job kind as I had arrived on site for another purpose altogether and ended up managing the recovery.) The department was in utter disarray when I arrived, we literally did nothing right. We may not be great yet, but we are getting better every week. My path so far has been:
1) Risk management first. You must have a solid backup plan, offsite storage of backups, and a fully tested disaster recovery plan. To me that is just table stakes. You cannot lose your customers data. You also cannot risk company assets. This means you have to have a database of every important piece of equipment (no, I refuse to track mice and keyboards) and every software license and know where those are allocated. This should also contain support contract information for all of the above along with expiration dates and renewal dates. We have a home grown application in Access that does this. (Cheap little barcode readable asset tags make tracking equipment easier and less prone to data entry error)
2) Robust and reliable service. Some of this will happen naturally as you do the risk assesment for step one. The rest is hard work. Measure availability and performance of all your services (we use Ipmonitor http://www.ipmonitor.com/default.aspx ). Set public goals for this and measure yourself honestly. When you don't reach your goals do a root cause analysis and fix things. Post these corrective actions and the results publically. Mine (Metrics and action plans) are on our intranet, but much more importantly are on a corkboard directly outside my office. Accountability counts.
3) Establish ownership by the business. Make sure the IT department knows that they are a service department and that they live to serve the business. Establish written agreements with each process owner to refine the metrics established above, and to track the things they really care about (Ticket closure rates? Uptime? Missed backups? Jobs not run on time? Tickets reworked?) review these anually with the owners and report your metrics to them at least monthly.
4) Capture all service requests (we use OnTime http://www.axosoft.com/ ) If you aren't going to do something, tell the requester sooner rather than later. For simple requests establish due dates by impact (Urgent gets 8 hour resolution, High gets 24 hours, Medium gets 1 week, low gets 30 days, or whatever works for you). Measure, publish and correct as above. For more complex requests establish a promise date to the customer and measure your on time delivery, publish and correct as above.
5) Establish standards. Leased PCs and standard images and scripted application packages are the Bees Knees. Same for printers and peripherals. Standard work processes are great too. I shied away from this initially because I didn't want to step on people's toes. It turns out that most people in my deparment really like having standard trouble shooting flowcharts or knowing the correct format in which to deliver a report. Not only does it save time it really helps you to get to know your business. This is also the time to document every process that needs to occur daily, weekly, monthly, yearly, etc.
6) Make sure you are a team. Sit down all together and talk regularly. Talk about new projects, current challenges, upcoming vacations, whatever. I think weekly works best.
To me these get you in the game. Once accomplished you can start focusing on:
1) Offer training to your people to the limits of your budget, and then fight for more money to get some more. Encourage them to tell you what they want to be trained on, rather than vice versa.
1b) Offer training to your users regularly. Nothing has made more brownie points for us than our brown bag lunch sessions on Outlook, Excel, Powerpoint, etc. One of our marketing guys took the department to lunch after introducing him to the glory and power of pivot tables.
2) Listen to your business/Learn your business. One of the best things I have done recently was spend a few days working in several high IS usage departments (customer service, shipping, receiving, planning). Not only did I strengthen my relationships with people (Everybody loves to watch the geeky IS manager taping up shipping boxes or unloading trucks) I discovered the pain points in the transactions that they do which has allowed me to focus my projects more intelligently.
posted by tcskeptic at 5:45 PM on February 20, 2007 [7 favorites]
1) Risk management first. You must have a solid backup plan, offsite storage of backups, and a fully tested disaster recovery plan. To me that is just table stakes. You cannot lose your customers data. You also cannot risk company assets. This means you have to have a database of every important piece of equipment (no, I refuse to track mice and keyboards) and every software license and know where those are allocated. This should also contain support contract information for all of the above along with expiration dates and renewal dates. We have a home grown application in Access that does this. (Cheap little barcode readable asset tags make tracking equipment easier and less prone to data entry error)
2) Robust and reliable service. Some of this will happen naturally as you do the risk assesment for step one. The rest is hard work. Measure availability and performance of all your services (we use Ipmonitor http://www.ipmonitor.com/default.aspx ). Set public goals for this and measure yourself honestly. When you don't reach your goals do a root cause analysis and fix things. Post these corrective actions and the results publically. Mine (Metrics and action plans) are on our intranet, but much more importantly are on a corkboard directly outside my office. Accountability counts.
3) Establish ownership by the business. Make sure the IT department knows that they are a service department and that they live to serve the business. Establish written agreements with each process owner to refine the metrics established above, and to track the things they really care about (Ticket closure rates? Uptime? Missed backups? Jobs not run on time? Tickets reworked?) review these anually with the owners and report your metrics to them at least monthly.
4) Capture all service requests (we use OnTime http://www.axosoft.com/ ) If you aren't going to do something, tell the requester sooner rather than later. For simple requests establish due dates by impact (Urgent gets 8 hour resolution, High gets 24 hours, Medium gets 1 week, low gets 30 days, or whatever works for you). Measure, publish and correct as above. For more complex requests establish a promise date to the customer and measure your on time delivery, publish and correct as above.
5) Establish standards. Leased PCs and standard images and scripted application packages are the Bees Knees. Same for printers and peripherals. Standard work processes are great too. I shied away from this initially because I didn't want to step on people's toes. It turns out that most people in my deparment really like having standard trouble shooting flowcharts or knowing the correct format in which to deliver a report. Not only does it save time it really helps you to get to know your business. This is also the time to document every process that needs to occur daily, weekly, monthly, yearly, etc.
6) Make sure you are a team. Sit down all together and talk regularly. Talk about new projects, current challenges, upcoming vacations, whatever. I think weekly works best.
To me these get you in the game. Once accomplished you can start focusing on:
1) Offer training to your people to the limits of your budget, and then fight for more money to get some more. Encourage them to tell you what they want to be trained on, rather than vice versa.
1b) Offer training to your users regularly. Nothing has made more brownie points for us than our brown bag lunch sessions on Outlook, Excel, Powerpoint, etc. One of our marketing guys took the department to lunch after introducing him to the glory and power of pivot tables.
2) Listen to your business/Learn your business. One of the best things I have done recently was spend a few days working in several high IS usage departments (customer service, shipping, receiving, planning). Not only did I strengthen my relationships with people (Everybody loves to watch the geeky IS manager taping up shipping boxes or unloading trucks) I discovered the pain points in the transactions that they do which has allowed me to focus my projects more intelligently.
posted by tcskeptic at 5:45 PM on February 20, 2007 [7 favorites]
tcskeptic: Wow, that's an awesome answer.
I would expand "Capture service requests" to also include changes which originate inside the department. Having an audit trail of changes is useful a hundred times over, and having a standard process for recording changes makes it much easier to manage the communication that has to go along with those changes.
posted by mendel at 5:51 PM on February 20, 2007
I would expand "Capture service requests" to also include changes which originate inside the department. Having an audit trail of changes is useful a hundred times over, and having a standard process for recording changes makes it much easier to manage the communication that has to go along with those changes.
posted by mendel at 5:51 PM on February 20, 2007
What tcskeptic said.
I've done some time as an IT drone (field service for one of the many VARs that leases the bees-knees-PCs) and, from a "ways to be good to your staff" perspective, I can say that jmnugent and magikker are dead on -- we know the pressure to perform miracles on zero budget is intense. At the same time, know that when your IT drones hit hour 70 in their second 80-hour, 5-day workweek, they WILL be irritable and prone to errors.
On the other side of that coin, if you listen to your guys, make accurate projections of time/manpower requirements, and implement realistic strategies, you'll be paid back in better customer relations, better productivity, etc. Be open to suggestions from your staff. We're not always brilliant, but occasionally we'll have perspective on something in the trenches that isn't obvious from the corner office.
Scripts, standardized installs, images, etc, are golden. Sometimes a day or two up front by someone who knows how to write a good deployment script will save you hundreds of man-hours later.
Hire good help. If there's a squeaky wheel, oil it or replace it.
Barcodes and barcode readers are heaven-sent for inventory. Trust me, for a sizable deployment, you save more money in time spent scanning vs. manually entering than you spend on a barcode reader and a quick access DB, particularly if the hardware you're inventorying already has barcodes onboard.
Call tracking/incident management software is crucial. Some packages have inventory tracking and license tracking built in. I'm not high-level enough to know about it in detail, but I know it exists.
posted by Alterscape at 6:20 PM on February 20, 2007
I've done some time as an IT drone (field service for one of the many VARs that leases the bees-knees-PCs) and, from a "ways to be good to your staff" perspective, I can say that jmnugent and magikker are dead on -- we know the pressure to perform miracles on zero budget is intense. At the same time, know that when your IT drones hit hour 70 in their second 80-hour, 5-day workweek, they WILL be irritable and prone to errors.
On the other side of that coin, if you listen to your guys, make accurate projections of time/manpower requirements, and implement realistic strategies, you'll be paid back in better customer relations, better productivity, etc. Be open to suggestions from your staff. We're not always brilliant, but occasionally we'll have perspective on something in the trenches that isn't obvious from the corner office.
Scripts, standardized installs, images, etc, are golden. Sometimes a day or two up front by someone who knows how to write a good deployment script will save you hundreds of man-hours later.
Hire good help. If there's a squeaky wheel, oil it or replace it.
Barcodes and barcode readers are heaven-sent for inventory. Trust me, for a sizable deployment, you save more money in time spent scanning vs. manually entering than you spend on a barcode reader and a quick access DB, particularly if the hardware you're inventorying already has barcodes onboard.
Call tracking/incident management software is crucial. Some packages have inventory tracking and license tracking built in. I'm not high-level enough to know about it in detail, but I know it exists.
posted by Alterscape at 6:20 PM on February 20, 2007
2) Listen to your business/Learn your business. One of the best things I have done recently was spend a few days working in several high IS usage departments (customer service, shipping, receiving, planning). Not only did I strengthen my relationships with people (Everybody loves to watch the geeky IS manager taping up shipping boxes or unloading trucks) I discovered the pain points in the transactions that they do which has allowed me to focus my projects more intelligently.
I can not agree with this enough. I make it a habit to take a laptop and sit in various departments for a day every so often. I often overhear conversations and learn about frustrations that users have had for weeks or months that I didn't even know about. This is also a great way to catch policy breakers ("What do you mean you're all sharing the supervisor's network ID?!")
posted by saraswati at 6:39 PM on February 20, 2007
I can not agree with this enough. I make it a habit to take a laptop and sit in various departments for a day every so often. I often overhear conversations and learn about frustrations that users have had for weeks or months that I didn't even know about. This is also a great way to catch policy breakers ("What do you mean you're all sharing the supervisor's network ID?!")
posted by saraswati at 6:39 PM on February 20, 2007
Kudos to everyone who has posted so far, great stuff.
I can only offer one resource to the conversation - Rands In Repose. RiR isn't so much IT as it is software development and people management - but since people are people, a lot of it transfers to IT management pretty well. I particularly recommend Taking Time To Think, Saying No, The Truth Versus Spin, and What To Do When You're Screwed. All four have helped me get through rough patches at my current (IT) job.
posted by Remy at 8:18 PM on February 20, 2007 [2 favorites]
I can only offer one resource to the conversation - Rands In Repose. RiR isn't so much IT as it is software development and people management - but since people are people, a lot of it transfers to IT management pretty well. I particularly recommend Taking Time To Think, Saying No, The Truth Versus Spin, and What To Do When You're Screwed. All four have helped me get through rough patches at my current (IT) job.
posted by Remy at 8:18 PM on February 20, 2007 [2 favorites]
I remembered on the way in this morning that I should have recommended Monkeybagel -- specifically the Sysadmin/Business Collisions section and especially Pumas on Hoverbikes -- for a bit of IT management zen.
posted by mendel at 6:25 AM on February 21, 2007
posted by mendel at 6:25 AM on February 21, 2007
It's not enough to be reactive; to be a great IT manager, you have to be proactive. That means understanding the business you serve, and being committed not just to serving that business, but to driving down the costs of doing business, by IT.
Part of the job is risk management and ameiloration. That involves disaster recovery, network security, information security, testing, and configuration control. Those tend to be the major management responsibilities for most IT managers in 1000 person companies, but increasingly, the actual functions are either outsourced, or done by contractors, as at that volume level, it's hard to make the economic case for maintaining hot site capabilities, and the skilled personnel for ensuring security in increasingly complicated environments.
Another big part of the job, as others have discussed, is user and hardware support. User training is less and less common in many businesses, as it is too often assumed that people with sufficient PC experience can be readily hired through interview processes. And yet, most people working in accounting, sales, inventory, purchasing, manufacturing and distribution functions, in my experience, do not have an accurate understanding of how even something as basic as a PC works. So, too often, "support" is becoming a training function these days. Good documentation helps, but only if you have means by which you know it is read by new people, updated by experienced ones, and periodically agreed to be SOP by management. Hardware "support" is increasingly becoming a matter of being proactive in terms of preventative maintenance, and replacement of high hours assets. Normally, it's worth tracking hours and usage of shared network resources like servers, printers, and network attached copiers, fax machines, and similar assets, and replacing them when they fall below their targeted service levels in any 3 month period. Individual workstations are normally bought in 3 to 5 year cycles; laptops, because of their greater wear factors and flimisiness, in 2 to 3 year cycles.
If your business has a centralized accounting or ERP system in a 1000 person company, the health and management of that system is typically the primary function of an in-house IT shop. You need to work closely with the prime vendors of hardware and software, and make sure you are doing the absolute least amount of customization possible, in order to get full benefit and performance from such systems. Most ERP system problems and failures I've seen in the last 10 years have been caused by poor implementations of "customizations" that were demanded by inflexible business management. If the problem being addressed is truly unique, it may deserve custom software or procedures, but to be frank, major ERP systems are configurable for almost any legal business these days, so the chance that some valuable, proprietary business process exists, that isn't already in a best practices file of one of the major packages, is vanishingly small.
But finally, an IT department isn't serving a business if it isn't accelerating profitability. If ( and that's a big "if" according to the U.S. Federal Reserve Board's research ) IT has produced a compound 1% gain in productivity over the last 30 years, that means that any IT department that isn't supporting 2% more transactions, or cutting costs at least 2% per year, isn't pulling its own weight, once a typical 50% overhead loading is applied. Furthermore, if you are justifying an IT budget through cost savings, the costs saved have to be "hard" not "soft" dollars. In a 1000 person company, such targets can quickly seem to be draconian, because it means that if this year, your IT budget is $1 million, and next year you have the same number of users and transactions, then next year you should do the job for $975 K. The only way to justify new equipment, personnel, or improvements in pay, benefits or training of existing personnel, above that new base, is the amount that IT can contribute to the bottom line if an additional amount is spent. And if the payback criteria is stringent, as it is in some businesses where a 1 year payback rule for IT projects is the internal hurdle rule (because of risk, obsolecense, capital competition with other functions, etc.), then you really have to hustle to find projects that are compelling. So, it's generally far easier to find IT projects in building business volume, or in streamlining processes with vendors and customers, than it is in traditional internal IT operations, these days. But even in such expansion and extranet projects, much of the lowest hanging fruit has already been plucked, so it's a challenge to IT methodologies to continue to find strategic functions where IT projects can continue to push profitability.
It's therefore critical that the modern IT manager become a better businessman, as much as a better technical manager. In an era of ever more demanding performance goals, a successful IT manager has to be a better negotiator with vendors, a more resourceful shopper in the services, software and hardware marketplaces, and a more flexible manager in employing human resources. And he has to meet these goals while keeping an informed, pragmatic eye on profitability, because without profit, there's no future.
posted by paulsc at 7:33 AM on February 21, 2007 [2 favorites]
Part of the job is risk management and ameiloration. That involves disaster recovery, network security, information security, testing, and configuration control. Those tend to be the major management responsibilities for most IT managers in 1000 person companies, but increasingly, the actual functions are either outsourced, or done by contractors, as at that volume level, it's hard to make the economic case for maintaining hot site capabilities, and the skilled personnel for ensuring security in increasingly complicated environments.
Another big part of the job, as others have discussed, is user and hardware support. User training is less and less common in many businesses, as it is too often assumed that people with sufficient PC experience can be readily hired through interview processes. And yet, most people working in accounting, sales, inventory, purchasing, manufacturing and distribution functions, in my experience, do not have an accurate understanding of how even something as basic as a PC works. So, too often, "support" is becoming a training function these days. Good documentation helps, but only if you have means by which you know it is read by new people, updated by experienced ones, and periodically agreed to be SOP by management. Hardware "support" is increasingly becoming a matter of being proactive in terms of preventative maintenance, and replacement of high hours assets. Normally, it's worth tracking hours and usage of shared network resources like servers, printers, and network attached copiers, fax machines, and similar assets, and replacing them when they fall below their targeted service levels in any 3 month period. Individual workstations are normally bought in 3 to 5 year cycles; laptops, because of their greater wear factors and flimisiness, in 2 to 3 year cycles.
If your business has a centralized accounting or ERP system in a 1000 person company, the health and management of that system is typically the primary function of an in-house IT shop. You need to work closely with the prime vendors of hardware and software, and make sure you are doing the absolute least amount of customization possible, in order to get full benefit and performance from such systems. Most ERP system problems and failures I've seen in the last 10 years have been caused by poor implementations of "customizations" that were demanded by inflexible business management. If the problem being addressed is truly unique, it may deserve custom software or procedures, but to be frank, major ERP systems are configurable for almost any legal business these days, so the chance that some valuable, proprietary business process exists, that isn't already in a best practices file of one of the major packages, is vanishingly small.
But finally, an IT department isn't serving a business if it isn't accelerating profitability. If ( and that's a big "if" according to the U.S. Federal Reserve Board's research ) IT has produced a compound 1% gain in productivity over the last 30 years, that means that any IT department that isn't supporting 2% more transactions, or cutting costs at least 2% per year, isn't pulling its own weight, once a typical 50% overhead loading is applied. Furthermore, if you are justifying an IT budget through cost savings, the costs saved have to be "hard" not "soft" dollars. In a 1000 person company, such targets can quickly seem to be draconian, because it means that if this year, your IT budget is $1 million, and next year you have the same number of users and transactions, then next year you should do the job for $975 K. The only way to justify new equipment, personnel, or improvements in pay, benefits or training of existing personnel, above that new base, is the amount that IT can contribute to the bottom line if an additional amount is spent. And if the payback criteria is stringent, as it is in some businesses where a 1 year payback rule for IT projects is the internal hurdle rule (because of risk, obsolecense, capital competition with other functions, etc.), then you really have to hustle to find projects that are compelling. So, it's generally far easier to find IT projects in building business volume, or in streamlining processes with vendors and customers, than it is in traditional internal IT operations, these days. But even in such expansion and extranet projects, much of the lowest hanging fruit has already been plucked, so it's a challenge to IT methodologies to continue to find strategic functions where IT projects can continue to push profitability.
It's therefore critical that the modern IT manager become a better businessman, as much as a better technical manager. In an era of ever more demanding performance goals, a successful IT manager has to be a better negotiator with vendors, a more resourceful shopper in the services, software and hardware marketplaces, and a more flexible manager in employing human resources. And he has to meet these goals while keeping an informed, pragmatic eye on profitability, because without profit, there's no future.
posted by paulsc at 7:33 AM on February 21, 2007 [2 favorites]
I've been in that position for a small shop, and I have a few random points to add:
It's all about the money. Typically, the money you spend takes away from someone else's money that's more directly tied to profit. That makes it easier to justify taking your budget, and it makes it imperative that you are diligent about being more than just the fix-it folks. You have to "surprise and delight" them so that they can do their jobs better and bring in the revenue.
"Backup system" is a misnomer--it's a restore system. If you aren't testing restores, you should be.
There are doubtless many good magazines, but I found InfoWorld to be pretty good. Of course, they've lost a couple of good people since then, so I don't know if that still holds.
On Security: Security is important. A default "no" answer is understandable when it comes to new, or hard-to-secure, technology. But that's the wrong position to take exactly. You need to be thinking not "We can't do that" but rather "How can we do that and still maintain our security?" It's much, much easier to just say no, but your job is to enable solutions. If you don't do that, people will start going around you anyway--and that's no fun.
Write everything down. I suggest both a blog and a wiki. The blog for the "customers", to get to see your point of view. Lets people know a bit about your job, and what goes into deployments, and the various things you have to juggle, etc. The wiki is for ad-hoc documentation--it's wicked fast to add stuff and cross-reference, so the barrier to entry is very low. And, of course, it's searchable and available anywhere (internally, naturally). Anyone can add to it, and history is preserved. Highly recommended.
posted by RikiTikiTavi at 1:49 PM on February 21, 2007 [1 favorite]
It's all about the money. Typically, the money you spend takes away from someone else's money that's more directly tied to profit. That makes it easier to justify taking your budget, and it makes it imperative that you are diligent about being more than just the fix-it folks. You have to "surprise and delight" them so that they can do their jobs better and bring in the revenue.
"Backup system" is a misnomer--it's a restore system. If you aren't testing restores, you should be.
There are doubtless many good magazines, but I found InfoWorld to be pretty good. Of course, they've lost a couple of good people since then, so I don't know if that still holds.
On Security: Security is important. A default "no" answer is understandable when it comes to new, or hard-to-secure, technology. But that's the wrong position to take exactly. You need to be thinking not "We can't do that" but rather "How can we do that and still maintain our security?" It's much, much easier to just say no, but your job is to enable solutions. If you don't do that, people will start going around you anyway--and that's no fun.
Write everything down. I suggest both a blog and a wiki. The blog for the "customers", to get to see your point of view. Lets people know a bit about your job, and what goes into deployments, and the various things you have to juggle, etc. The wiki is for ad-hoc documentation--it's wicked fast to add stuff and cross-reference, so the barrier to entry is very low. And, of course, it's searchable and available anywhere (internally, naturally). Anyone can add to it, and history is preserved. Highly recommended.
posted by RikiTikiTavi at 1:49 PM on February 21, 2007 [1 favorite]
« Older what's that animated short where the people... | I know I need an attorney, but what kind? Newer »
This thread is closed to new comments.
• Micromanagement fails — there's just too much to know about technology, and it changes too quickly. Put trust in your staff to know their stuff, and encourage them to speak up when processes need to change.
• Make your staff accountable for decisions by encouraging open communication between your management and your client base. Nothing irritates end users more than feeling helpless. Once they feel they need to do end runs around help desk staff, your job becomes excessively political.
posted by Blazecock Pileon at 2:36 PM on February 20, 2007 [2 favorites]