Anyone who works in IT knows that they usually have too much work relative to the number of people available to do the work. It’s a fun mix of day-to-day operations and projects and the same pool of people to do the work. What you end up with is a never-ending juggling act of shuffling people between the latest break/fix fire and urgent project task. This is the source of the stress of the job.
Is there any way to get off this treadmill? It might be difficult for you to believe that it can happen, but I’m here to tell you that it can. I’ve done it, and it was the most rewarding achievement of my professional career. Here are the 5 steps :
- Survey the battlefield. Just like a military general, you need to get above the battle and survey the landscape. You need to take some time to think at a higher level than your normal day-to-day activities allow. You have to look at your group as a whole. Where are you spending your time? Where should you be spending your time? What are the bottlenecks? Where are you leaking time? Are you spending a lot of time on re-work? Why? Get away from work for a couple of hours and just think about these questions. You may have to spend time at home, but this is an important investment in your future, so find some quiet time to think.
- Spend time on the right activities. Stephen Covey has a time management matrix that spells this out. Check it out here if you are not familiar with it. Spend as much time as possible in the not urgent & important quadrant. This may be difficult for you if you are currently spending all of your time fighting fires. Constant fire fighting is the cause of the IT treadmill not the solution. This is a point that too many IT leaders either do not know, ignore, or have simply resigned themselves to accept as a fact of live. Do not let this describe you.
- Fix your building codes. I like to say, “if you’re spending all of your time fighting fires, you really need to change your building codes.” You are spending too much time on service interruptions or re-working failed changes. I often hear, “Testing takes time and we don’t have time to test.” How’s that working for you? How much time do you spend fixing what you build? Even if you don’t measure the time you spend on unplanned work or your change success, I bet the pain in your stomach can tell you that you spend too much time on doing work two, three, and four times.
- Write policies, standards, and procedures. No one, and I mean no one likes to hear this. I’m sorry, but this has to be done. You’ve tried everything else and it doesn’t work. You know that if you have two people build the same server they don’t build it and test it in a consistent manner – you know this so suck it up and just do it. Next time you need a server built, have the person write the procedure. Have your most junior person test the procedure and if they have to ask a question, have them update the procedure. You’ll soon have a set of solid procedures and consistent builds. Don’t tell me you don’t have time – see steps 2 & 3.
- Get buy-in. This is a critical step, and can be difficult. However, I find that people are most receptive to change when they are in pain. People don’t like coming in to fix something at 2 AM, they don’t like taking three days to build a server that should take a couple hours, they don’t like having to wait for the guy who’s out of the office to return so they can get a critical puzzle piece that is missing. Use these pain points to teach your team why they are “slowing down” to write procedures or to do pre-production and post-production testing. Use the successes to reinforce the lesson. When a server goes down and is rebuilt in an hour because you have solid procedures, use that event to remind your team how long it took to restore service before you had the procedures.
Execute these steps and you will have an entirely different work environment. You’ll be spending most of your time on the important tasks and very few on the urgent ones. You’ll have time to spend building your team. You’ll have time to improve your relationships with your customers and be able to give them better support. You’ll get to go home at night and rarely get called for an emergency.
Getting off the IT treadmill requires change, but it can happen if you and your team are committed to the spending less time on urgent activities and more time on the important ones. You are the leader. It is up to you to make the decision to change and to lead your team to a new way of working. You will find it both challenging and rewarding.
Are you ready to get off the IT treadmill? Have you started and quit? Have you succeed? Do you have suggestions to share? Leave a comment and share your experiences.
Resources
If you are serious about starting this effort, I highly recommend that you read the Visible Ops Handbook. This book was my road map from the treadmill to relative boredom.
Read my earlier articles on how I used Visible Ops to stop fighting fires.
{ 0 comments }
Subscribe (free) via RSS
LinkedIn
email
