Fighting Alligators.
I’m back. Happy New Year!
I didn’t really go anywhere, to be sure, but I was sort of on hiatus from this blog. Part being “too busy fighting alligators to drain the swamp” and partly a case of writer’s block, I’ve taken the last six weeks (mostly unintentionally) away from writing.
My writer’s block notwithstanding, the former reason (being too busy fighting alligators to drain the swamp) tends to be a common reasoning as to why people in this profession get stuck. IT, if not carefully cultivated, cared for, and organized can devolve into a constant and vicious cycle of firefighting. Get to work, figure out what’s “wrong” today – and then get to fixing it. Then go home, wash, rinse, repeat.
On one hand, I’m always grateful for technical issues. Being that I chose to be in a technical field, the mere existence of these issues ensures my gainful employment. Having a wife and three kids and a mortgage, gainful employment means even more. But it’s a double-edged sword, for several reasons. Of which I’ll detail:
The “What have you done for me lately” conundrum.
It’s been my experience that troubleshooting, technical resolution, crisis remediation, and generalized “firefighting” aren’t usually considered when senior leaders (especially “Non-IT” executives) review the job performance of an IT executive. It’s a little more applicable when an IT director reviews the job function of the IT service members, but even then it can be flawed. I used to (way back when) be a system administrator for a city municipal government, and every week the IT manager would print out and display on a bulletin board the ticket metrics of the IT team.
The colored bars of the graph would indicate how many tickets were opened that week, how many were assigned to a specific technician, and how many tickets that technician closed. It became this competition, as members of the team would compare how many tickets each person closed that week. It’s been a while, but I want to say that the IT director even had incentives for the person who resolved the most amount of tickets.
Thing is – ticket counts are a horrible metric. Plug in a keyboard? Ticket. Reset a password? Ticket. Reimage 80 machines? Ticket. Some tickets could take seconds to resolve, while some could take days, months, etc. There were no guidelines as to what did and didn’t constitute a ticket, what constituted a project, etc.
As time went on, members of the service team would make everything a ticket. Move a few boxes of computers. Ticket. All that mattered was the count – that’s how senior leadership was judging.
Sidebar – years later when I had moved into the managed service space, the problem as to what is a “ticket” versus what isn’t reared its ugly head again. The company I was with sold managed service contracts to their clients, but what was covered under those agreements was ambiguous, at best. Even I, who worked for the company, didn’t always understand it. A client would want something done, but it would constitute a project and thus be subject to a different price structure and not covered under the contract. Needless to say, that company lost a lot of business.
All to say, tickets are never weighted the same, so they make for a bad metric.
I digress.
As an IT Director, or any other part of the IT leadership team the onus isn’t placed on remediation, for whatever reason. It’s just sort of expected that it’s part of the job, but it doesn’t really count as your accomplishments for the period. When asked what I’m up to, exeuctive leadership wants to know progress on tasks and projects that take the company forward, save the company money, or improve something that needed to be improved. Even though remediation is paramount, it isn’t looked upon favorably. You’re supposed to be taking us into the future, not keeping alive where we’ve been.
What have you done for me lately?
The “Perception is reality” problem:
Despite all the trendy talk at every conference or gathering of like-minded individuals about the mobile workforce and the ability to do work from anywhere, the truth of the matter is that many executives can only gauge the work by what they see. Meaning, if they don’t see you, the automatic assumption is that you aren’t working.
Most IT people in my position can probably relate to this. IT isn’t a 9-5 job – especially at this level. Computers don’t sleep, the systems that run on these computers don’t magically go home at 5pm and come back in the morning, so despite what your hours are, IT is 24/7/365. This is a particularly difficult point for my wife, though she’s learned to accept it better in recent years. I’ve been contacted for (seemingly) stupid reasons in the middle of the night, or on vacation, or during a movie, show, event, church service, or what have you, more times than I can probably count.
So the conundrum here is that there’s an expectation that as an IT Executive, you’ll be ready at a moment’s notice to execute on some major issue, but subsequently are judged on the number of hours you’re in the office. Recently I witnessed what can only be described as “a competition between rivals to determine superiority, predominance, or leadership” between two VPs at an organization. One arrives at the office prior to 6am, and leaves near 6pm, and the other arrives near 10am, but doesn’t leave the office until nearly 10pm. The first was criticizing the second for the amount of time he had to wait for the second to come in, while the second was saying things like, “You may get here early, but I close this place up by myself every day.” I, for one, couldn’t imagine what it is that they had to do in the office that required 12 hour days, every day, despite their 4 hour gap between arrivals.
Later the VP that my department reports up to made a comment about my (the IT director) schedule and how the leadership was “old school”. It wasn’t worth the chest-beating, so I just said nothing and nodded, but the truth of the matter is, is that if I, as the IT director, had to spend 12 hours in the office daily, then something was seriously wrong, and I would NOT be doing my job.
Just because you don’t see me doesn’t mean I’m not working.
This is especially frustrating, because the expectation (even if not stated) is that time be spent in the office. But also the expectation is that IT will be available any time someone else is working (whether it be a Sunday evening, 2:00am, or any other “inconvenient time”) But like the earlier example about ticket counts as a bad metric, amount of time spent in the office is a bad KPI as well. I can guarantee that I am several times more effective, efficient, and productive working remotely outside the office than I am sitting at my desk. Why? For the entire reason of this post, because when you’re in the office you tend to do more “fighting alligators” than “draining the swamp.”
But… many times, unfortunately, perception is reality. Even if it’s wrong.
Truth be told, IT more than anything else has become more about “that laptop life”, and organizations need to realize that chaining your IT department to their desks is less effective than letting them work remotely.
The IT organization I ran for 4 years a few years back called them “drive bys”, but I’m sure every IT department experiences something of the same phenomenon. As members of the organization see the IT team (any one of them) walking around, they’re quickly reminded of an issue, no matter how great or small, that they forgot to report through proper channels, and so they grab the IT person to tell them about it.
I had a former IT manager tell me he took his lunch in his car every day because if he took his lunch in the employee lunchroom, he’d be inundated with questions revolving the system, a ticket status, a technical problem someone was having, or some sort of glitch. I quickly realized all the IT team members did the same thing, or attempted to take refuge offsite, for the same reason.
The notion that perception is reality can be beneficial to IT in some cases – for instance, I always told my employees that when they walked to address a user’s issue, that they walk with speed and urgency, because lackadaisical walking gave the perception that the IT employee was not doing anything. However, using time spent in the office to make a judgement about the effectiveness of an IT executive is not a good perception. Like Obi-Wan says – “Your eyes can deceive you, don’t trust them”
The Law of Diminishing Returns
Issue remediation can buy you some short-term capital, at the cost of long-term investment. While some senior leadership can excuse a period of review filled with remediation, repeated periods of work where all that was done is issue management and remediation eventually works against the IT executive, and IT team in general.
Eventually, the organization will look at the constant problems and make the correlation that the IT executive (and by proxy, the rest of the IT team) isn’t cutting it, because the company’s problems persist and don’t seem to be getting better.
I don’t have any statistics to back this fact, but this is why IT executives tend to only be in place a few years. Like a coach or GM of a sports team, without consistent forward progress, the underlying thought is that the IT executive has lost their effectiveness, and “new blood” is brought in. Occupational hazard.
—
I think that’s why, at the end of the day, I decided to start this blog. I made the comment the other day at my work that everyone speaks English but nobody is speaking the same language. (I think I stole that from a “Calvin and Hobbes” comic strip) The same can be true for organizations and IT. I keep calling it the “chasm” between these two entities (that really should be the same), but it’s the same no matter where I go. I want to serve to bridge that gap, to help organizations understand the world of IT, and help IT relate more relevantly to the organization. Right now, I’m doing it through this blog – who knows what form this mission will take going forward.
I do know one thing, in order to keep my dream of making the “IT vs. Organization” situation a better, more productive, more seamless relationship, I need to stop being so busy fighting the alligators and start draining the swamp.