By Jon Xavier


This is the fourth post in our ongoing series: The First 90 Days.  When you're coming into a company as the first-ever IT manager, you have  to hit the ground running. The work you do in the first 90 days is what  sets you up for success for the rest of your career, but it's also a  huge challenge. To help, we put together this advice on the process and  mindset culled from our team's extensive experience running IT for top  Silicon Valley companies.


In the last post in this series, we discussed high-level planning and how it helps you to stay focused and productive even when a certain Poison-Flying-Type Pokemon comes calling.

But the reality is that while you can and should plan, plans will be changing constantly as things come up and you react to them. So a large part of your productivity will be how you cope with those changes and roll with the punches each day.

That’s what we’ll be covering in this article: triage, day planning, and execution for the new IT manager.

Triage: because not all emergencies are equal

In your discovery and planning, you’ve probably come up with a lot of things you need to do. Welcome to IT, where if it isn’t broken, you probably haven’t looked closely enough.

Companies usually wait too long to hire an IT Manager—it’s just not top-of-mind until there are visible problems, and if there are visible problems, they’re usually symptoms of a wider dysfunction. If you’re the first IT Manager hired, you’re tasked with cleaning up this mess and putting systems into place so that it doesn’t get so messy again.

So there’s no shortage of work. But it’s not all the same kind of work. Broadly, there are three categories:

  • Something is currently on fire
  • Something will catch fire very soon
  • Fireproofing

The hard part of IT is that you will need to be doing work on all three of these categories at once. Fires can’t be ignored, but if you spend so much time on the current fire that you allow another one to start, you’ll quickly be overwhelmed. And if all you do is fight fires, you’ll only ever be a firefighter—the long term work that prevents issues from becoming emergencies is what makes your life in IT bearable.

So, ultimately, IT work is about triage. It’s not about dealing with emergencies, it’s about prioritizing emergencies. To do that well, you have to consider the context around each item to determine its impact. More importantly, you need to know the impact of NOT getting it done immediately.

Triage is about ruthlessly deferring work that is not yet critical until exactly such time as it is critical, and no longer.

How do you know what’s critical? For every job that drops in your lap, take a step back and look at it on the macro level:

  • What does it mean for the company if this doesn’t get done today in real terms?
  • If it will cause problems, who will it affect and how severe will those effects be?
  • If it won’t cause a large problem immediately, will it escalate if it’s not addressed? If so, how long will it take for the problem to become really bad?

Not every emergency presents itself as an emergency, so the thing that separates people who are good at triage from people who are bad at it is the ability to forecast future problems. You must factor ramp and lead time into your estimations. If you have a longer-term project that has a drop dead date 3 weeks from now, but you know it will take about 3 weeks to complete from an action you take today, then the action you take today is more urgent than the deadline suggests.

Day planning when your day is unpredictable

Taking this approach to triage is a good way of dealing with the various Zubats that pop up to ruin your day. But what about the things you were supposed to do before that happened? What does day planning look like when you can’t plan for what will happen each day?

There are a few schools of thought here, and what you ultimately choose is going to really depend on you and how you work. There are best practices for project management and forecasting, but day planning is idiosyncratic. The best system is the system you actually use.

Here’s some options we’ve seen people use successfully:

Time-blocking

Some people like to plan every little aspect of their day, chopping it into sections and then assigning work to each section. Sometimes they even go so far as to actually schedule this work on their calendars. This approach has its advantages—it allows you to look back at your calendar and see how you’re spending your time, particularly if you use a different color for different sorts of tasks. It helps you get the mix right, and make adjustments if you’re not. It ALSO gives you the opportunity to be very intentional about what kinds of work you schedule next to each other, which can be helpful as different kinds of work require different mindsets and there’s often a switching cost associated from moving from one to the next.

The disadvantage: this is really not reflective of most IT workflows. Time-blocking is most useful when you can defer the things that pop up unexpectedly—scheduling long blocks of time when you work on in-depth, concentration-heavy tasks and packing all your shallow tasks into shorter blocks scattered throughout the day. But in IT most of your unexpected tasks must be acknowledged immediately, even if in the triage process you decide they're not worth dropping everything to address. So for the full benefits you’ll need to also spend time adjusting the blocks on your calendar to accurately reflect your real schedule. You may not see the value from this extra work.

Daily to-do lists

Daily to-do lists are probably the most common day planning tool in use, and they’re a good fit for most IT workflows. Each day, you list the tasks you want to get finished, oftentimes with a prioritization attached, and then check them off as they’re done. This is a very flexible framework, and it takes no work at all to adjust to changing situations—as things come up, add them to the list and prioritize them. Don’t get something done? Add it to the next day.

The downside to this kind of system is it’s so in-the-moment that it can be hard to know if you’re hitting the right mix of tasks. It’s very easy to shift things around and work on sudden emergencies, but the fact that you’re focusing on such a narrow block of time can actually hide when important, planned work is being repeatedly deferred. Being successful with a daily to-do lists often means combining it with other, more extensive project planning systems that help you keep track of tasks across time and the progress of larger projects. So in practice, this “simple” system often ends up being the most complicated.

The rolling to-do list

A rolling to-do list is like a daily to-do list, except rather than limiting it to a day, you make your list for a longer time frame like a week or a sprint cycle. Surprisingly, this wider frame usually makes things more flexible. An entire day can get blocked out with emergencies or filled up with work from a non-negotiable project, but in a given week there will almost always be gaps you can claim for your fireproofing and other long-term, high-value tasks. The extra space also means you can be more intentional about your task mix. You’ll probably never intentionally schedule an entire week with a single task type, but on a day-to-day basis this is often how it goes.

The downside is that a larger rolling list can quickly become so large that it isn’t actionable. Although you can prioritize it the way you do with a daily list, the greater number of choices means a larger cognitive burden when you’re trying to decide what to work on and what to drop until the next list. You’re also less likely to ever get to 100% completion, which is demoralizing if you’re the sort of person that draws a lot of motivation from that.

General advice for day planning

Regardless of what system you choose, here’s some general advice:

  • Realize that you will not finish your to-do list each day and prioritize your work based on that assumption. Expect that you’ll be dealing with Zubats and other emergencies for a large block of time, and include that estimation in your planning. This isn’t about your beautiful vision of a world where all your projects are completed and all your dreams come true. It’s about planning so your worst case scenario is still something you can live with.

  • Focus more on getting your ongoing project mix correct than on micromanaging each individual day. Day planning in IT isn’t about finding stuff to do each day—your day will happily fill itself with work without your assistance. Rather, what you’re trying to do is ensure a balance between all of your ongoing work. Each work period you should schedule both short and long-term projects, soon-to-be-fires and fireproofing. Have a goal for this mix, and look to change that goal over time as your situation becomes more manageable. In the beginning, you might aim to spend 40% of your time on fires, 40% on soon-to-be fires, and 20% on fireproofing. As more systems are implemented and more things are systematized, there will be less emergencies and more emergencies will present themselves early. So you will be able to spend 20% on fires, 40% on soon-to-be fires, and 40% on fireproofing and other long term items. Keep track of how things are going and where you seem to be spending time, and adjust your goals over time as things change.

  • Consider blocking some of your time. You might decide that time blocking is not the right strategy for you. That’s understandable, but it can still be helpful for certain kinds of tasks like documentation or planning which require deep focus and are easy to forget about. Consider blocking out part of your day or week as a standing time for working on these things, and then guard that time zealously. You can’t go completely off the grid, but you can make yourself less available to distractions by holing up in a conference room or at a coffee shop during these focused periods.

  • Don’t neglect the work that only matters to you. IT is a service and support position, so it makes sense that a lot of the work you do is to make other people’s lives easier. If it’s a choice between working on something that impacts your customers or your coworkers, and working on something that won’t, well, that’s not really a choice much of the time. But that doesn’t mean there’s no value in work you do solely for your own benefit. IT serves the entire organization, so improvements you make to IT are often improvements to the rest of the company, too. If something will make your work more efficient, more effective, or just less aggravating, that can actually be more transformative than something that just helps a single person or division. Know your worth. Make time for yourself.

Conclusion

Ultimately, nobody can tell you the best way to work any more than they can tell you the best way to live. It’s relative—it depends on your situation and the things that keep you focused, motivated, and eager to get out of bed in the morning. So discovering the right system will take experimentation. You shouldn’t feel discouraged if what you’re doing doesn’t seem to be working. Try something else! There is a right answer out there somewhere.

But you will need some sort of system if you want to be successful long-term in IT. Not having one usually means just being led along each day by what comes up. In a role where fighting today’s fire can mean ignoring tomorrow’s conflagration, that’s not a good strategy. One of the highest-value things you can do in your first 90 days is to find a system that fits for your company and the way that you want to work.

Next time, we’ll be dealing with something nobody likes but everybody needs anyway—the green leafy vegetables of IT tasks—documenting your processes and practices.