The Fallacy of “Just Getting it Done”: Economics and the Use of Automation

TL;DR Work smarter not harder by calculating opportunity costs.

Yeah I know. Another opinion post. I know you want more technical posts. And for the record, I have at least one technical post coming up on Tanzu Kubernetes Grid. I have another on Ansible coming up. So, I promise I will get back to some technical posts in the very near future.

But I keep coming up with other ideas that I can’t help but share!

This post is loosely related to a post I made last June called Documenting Your Value: Considerations for Estimating Cost Savings for the Automation You Build.

But here I talk about the economics of using IT Automation and I challenge the idea of the, “just get it done” work ethic. This one goes out to all you manager types out there, and this is something to think about if you are a Junior-level engineer as well.

I feel compelled to say that there is nothing inherently wrong with the “just get it done” work ethic. It has its place: “all bets are off” outage remediation and impending deadlines come to mind. But outside of these circumstances, “just getting it done” is arguably a euphemism for working harder, not smarter. And as you will see, it could waste a lot of money.

I am probably going to get hate-tweets for this one.

. . . ** cracks knuckles ** . . .

Here we go.

Econ 101: Opportunity Cost

There is an idea in Economics called “Opportunity Cost“. I have linked its official definition, but let’s give it some IT context for our discussion:

Opportunity cost means that for a given a list of tasks to be completed by a single human, spending time on any single task in the list is always at the expense of the others.

Furthermore, the implication is that the more efficiently you can complete each task, the less time it will take (and less money it will cost) overall. I know this seems obvious, but I think some people are blinded by the “just get it done” work ethic.

Let’s take a list of tasks for a single engineer, only one of which can be automated, the others can not be automated (they’re KLO, for example):

1. Install a new software agent across 200 machines. This can be done using SSH easily and is a handful of commands, but does require a stop drain and reboot. It is currently manual, but can be automated through Ansible in let’s say about an hour. A different engineer is building the automation for it, but has other priorities, therefore it will be 2 working days before the automation is ready for use. Approximate manual time frame: 70 man-hours. No immediate deadline.
2. Support Call about a potential firmware install that is not mission-critical. Approximate Time frame: 12 man hours. No immediate deadline.
3. Documentation of a new process for creating a VM template. Approximate Time Frame: 8 man hours. No immediate deadline.
4. Calculate capacity requirements for new infrastructure. 4 Man-hours. No immediate deadline.

Let’s not forget about any backlog tasks, so there may be more on the task list to choose from.

But they all need to be done.

Time for Some Maths

Ready for a math word problem, gang? Be sure to circle your answer. Partial credit for showing your work.

Here we go:

You are the individual performing these tasks. You are not building the automation for task 1, someone else is, and the automation he or she is creating for task 1 will be ready in 16 man-hours. Therefore, what is the best use of your time?

1. “Just get it done” by starting on Task 1 manually for the next 16 hours, then complete the rest using the automation.
2. Work on tasks 2-4 while you wait for the automation to be ready, then complete task 1 using the automated approach that is now ready.
3. Immediately begin binge drinking and start your usual crying in the fetal position on the kitchen floor.

If you’ve been paying attention, you will know #2 is the answer.

If you chose #1, you just cost the company 15 man hours worth of labor and your CFO should be there at your cubicle (or house) shortly.

You may not think that’s a lot, but that adds up over time if you don’t adopt a more efficient strategy long term.

If you chose #3, then you got nothing done and destroyed some of your liver. But at least it was cathartic, right?

What About Other Options?

OK. Let’s walk through them:

What about having 2 people do task 1? BWAAAAAAAAAAH! (That’s my “you got it wrong” buzzer sound). WRONG. Same wasted cost:

1 x 70 man hours = 70
2 x 35 man hours = 70

The man-hour cost is the same. Nice try though.

What about re-assigning Task 1 to the automator? Well, it depends on the opportunity cost of the task list for the automator . . . . ahhh, didn’t see that one coming did you? Some considerations:

1. How efficient is the automation itself?
2. Does the automation need to be monitored? Manually verified?
3. How long overall would it take for the automator to complete the task? It should be less than doing it manually, but let’s say including automation, it will take 16 hours overall instead of 70. That’s better, but it’s 2 days worth of work. Therefore . . .
4. Is there another project that is mission-critical for this person that 2 days will be too interruptive?

The additional takeaway from this is that everyone is interconnected. Again, I know that seems obvious, but there’s a ripple effect across the team that may not be obvious on the surface.

Rising Tides and Boats and What Not

There is another saying from economics that I am going to steal and appropriate to the context of automation:

“A rising tide lifts all boats.”

Within the context of automation, it means that automation is supposed to benefit everyone.

But. There is one problem with this saying . . .

It assumes everyone knows how to operate a boat.

Send your hate-tweets to @RussianLitGuy, and your hate-mail to bryansullins@thinkingoutcloud.org.