Is our contribution measured by what we're doing or how we're doing it? Are we providing value or are we just getting caught up in what's exciting? How do we ensure that we're seen as contributing despite appearing to be less busy? Do our efforts to automate sometimes take away from our value rather than adding?

 

Automate All of the Things!

 

Automation is based on the principle that our expertise should not be wasted on the manual execution of simple and repetitive tasks. Spending some extra time to offload these tasks and free ourselves up for more exciting undertakings just makes sense, right? Well, that depends on a few things.

 

The Human Factor (Working Hard, or Hardly Working?)

 

Perception is an easily-overlooked consideration. It's no secret that the work of IT professionals is sometimes seen as a bit arcane by our management and peers. There's a general understanding of what we do, but the details of how we get it done are often another story.

 

Are we being evaluated based on the value of the work that we do, or based on how busy we appear to be when we do it? If we minimize the daily grind, are we creating the impression that we're less valuable because we don't appear to be as busy? The answer to these questions is going to vary depending on our work environment, but it's important that we manage perception effectively from the beginning.

 

The Technical Factor (What's the Value Proposition?)

 

As IT professionals, we tend to be passionate about the work that we do, so it's really easy to get excited about coding our way out of the daily grind. When this happens, we sometimes let our excitement get the better of us and don't give due consideration to the real value of what it is that we're doing.

 

If we're spending a week to automate a task that previously wasted days each month, we have a reasonable return on our time investment. Yes, it might take a few months before we really see the benefits, but we will see them. On the other hand, if we're spending the same amount of time to address a task that only took a few minutes out of each month, we really have to start thinking about the efficient use of our time. We can be absolutely certain that our management and peers will be thinking about it if we're not.

 

The Whisper in the Wires

 

Are we approaching automation in the traditional way where we just develop a collection of scripts as we need them, or are we embracing a larger framework? At this point, I'm guessing that we have more of the former than the latter, but with a lot of push to take a more strategic approach. This is a good direction, but not if we're out of a job before we can get there because we didn't manage the expectations properly.

 

If we want to address concerns of perception and value proposition, we have to do more than script our pain away when we can. It's very difficult to manage either of these if we're addressing everything piecemeal. We need a consistent policy framework incorporated into a well-documented strategy, and we need to communicate that effectively to our peers.

 

A documented strategy addresses perception problems by providing a view into the process and setting expectations. A consistent policy framework keeps us from getting so caught up in our own custom script development that we fail to show value.