Documenting Your Value: Considerations for Estimating Cost Savings for the Automation You Build

I was late with my previous post last week, so I figure I “owed you one,” you 8 loyal readers of my blog. Hence, here you go, an early-release post this week no less . . .

Also, I will get back to technical posts as well . . . I try to mix it up as best I can . . . I have at least two in the hopper . . . In the meantime, I had to get this one out there:

A Few Words on the “Automating Your Job Away” Myth

Let me start off with dispelling the myth of “automating your job away,” or anyone’s job for that matter.

I am not saying layoffs don’t happen as a result of automation in the world of IT. It certainly can happen. But that is usually in cases where the company has, over time, over-hired and has lots of manpower bloat. In those cases layoffs may be long overdue.

In any case, what does this mean for you? Well, keep these things in mind:

1. Be the one who creates the robots – Don’t wait for management to start automation projects. Start doing it now. There is a Sales tactic called “Always be Closing” or “ABC”. In automation it’s “Always be Automating” or “ABA”.
2. Automation needs to be maintained over time – Rarely do you rollout automation that does not need to be changed over time. A lot of people forget this, even people who should know better.
3. On that note, Automation is a constant process and as new features/services get added, they should be automated on Day 1. If and when you can “get your head above water,” there will arise multiple new features, hardware, software, etc. that will need automation. “OK, we’re done automating all the things!” . . . . said no one ever.
4. Good organizations realize the value of freeing people up for more important things.
5. If you can continue to prove your value through automation, then you increase your “job security”. Job security is in quotes, because in my humble opinion, there is no such thing as “Job Security”. Job Insurance in the form of up-to-date and in-demand resume items, yes. But Job Security? I think not.

This last item is the topic for this week’s post: proving your value.

Let’s Do Some Maths

A few more fun facts about me: (1) I have an old-school physical stopwatch I use to time my automation, and (2) I also have an old-school physical SHARP EL-531TG scientific calculator for all the maths. Both are on my desk within reach.

Yes, I know there are apps for both of those, but I have a flair for the dramatic and I stop paying attention to the app versions pretty quickly. They bore me.

Although, I must say since I switched to Oh My Zsh with PowerLevel10K (I highly recommend both), my stopwatch is not as useful as it used to be with the time-stamping for command execution.

Why am I so focused on these tools? Because time is money.

As I revealed previously, I was a public school teacher in the late 90’s. The advice I got there was to, “make friends with the Janitor.” In the world of IT, my advice would be to “make friends with the CFO.” I would recommend highly that you should at least be able to calculate a Return on Investment (ROI).

Therefore, the best advice I have for you is to discuss what algorithm to use to calculate cost-savings with your CFO, or whomever is in charge of employee costs to the company. I do have a simple starting algorithm later in this post, however.

One additional piece of advice is to use man-hours. This means that you want to calculate all the time together as a single block of time. So, let’s say you would have ordinarily spent 24 hours on a manual task in week 1, then 10 hours in week 2, then 12 hours in week 3. Don’t calculate it by week, unless your CFO tells you to. Instead, that’s just straight 46 man-hours.

One easy formula to figure out cost savings to automate these tasks would be to:

1. Break your salary down to hourly.
2. Estimate the time it took to build and test the automation.
3. Estimate how long it would take you to perform the task(s) manually, also broken down to being hourly.
4. Time the automated method for performing these the task(s), plus the time to build the automation.
5. Subtract the difference.

So a “starting point” formula looks like this:

CostSavings = (HourlySalary x ManualTime) - [HourlySalary x (TimetoBuildAutomation + AutomatedTime)]

But, there are some additional considerations/variables that will tweak this formula:

1. Someone else at a different salary performing tasks manually. You don’t usually know that hourly amount.
2. The actual hourly employees costs, like benefits, and so on.
3. One-off automation events versus automation that runs long-term on a schedule.
4. Other costs that are saved as a result of your automation, such as automation that delays or eliminates hardware costs . . . if you automate auto-scaling, for example.
5. To get really nit-picky: what about automation that allows for you to do other things while it runs, versus having to monitor the automation as it runs?

These are all factors to consider that can certainly tweak those numbers. I think what I have shown is a good place to start; the rest are variables you can inject into the formula above.

An Example: Patching

People who are just getting into Automation ask me all the time, “What should we automate first?” . . . OK, so it was like one guy who asked me that . . .

My answer is patching – it is usually the easiest to accomplish, especially within the realm of firmware, and the tasks associated with patching can have the biggest payoff. Why?

Well, first of all, yes, patching has to be done; it’s part of our job description. But patching is not “moving forward”. Patching means you spend your time just maintaining the infrastructure, rather than automating other things and/or making things better, and/or providing new features or services.

The other reason is because automated patching can take orders of magnitude less time than if they would take if they are manual, especially if you can stage the updates with automation, which is a common practice amongst us automators.

When I first signed on to my current job, firmware patching was done manually and I didn’t have the time to automate it. It was literally, “Welcome aboard new guy . . . time to patch!”

However, during the second patch cycle months later, I was able to automate the patching using HPE’s Smart Update Manager, among other things.

Using the formula above:

1. Manual patching took 220 man-hours – that’s 5.5 weeks. A CFO would say that you might as well put someone on vacation for that long. I used an hourly salary of $48/hour, which worked out to: $10,576.
2. Automated patch installation, with the time it took to automate the process took 56 man-hours. With the same hourly salary, that’s $2600.

Therefore, we saved $7,976.00. That may not seem like a lot, but again, you should be doing more than one patch cycle per year, so you can at least double that. Additionally, the automation only had to be built once, therefore it should take less time the next time. Maybe you save $9000 on the next round. Saving ~$17,000 per year is not nothing, I don’t care how big the company is.

And that’s just on that one thing!

I recommend highly that you keep tabs on this throughout the year and then you can list that as your value-add to the company. Last year I saved the company I work for just over $32,000. This year should be a lot more, but my goal is to automate an amount equal to my salary. I have a ways to go. . . .

Questions? Hit me up on twitter @RussianLitGuy or email me at bryansullins@thinkingoutcloud.org. I would love to hear from you.