On attempting to understand the problem

For most of my technology professional career, I have been a technology guy. For every problem someone brought me, there was a technological solution to it. That's mostly true: there's always a way to solve a problem with technology. But recently, I've found myself communicating quite differently about problems, using the following phrase more than once:

"${TECHNOLOGY} is a how, not a why".

This got me an over-breakfast high 5 from a colleague who I greatly admire, and it was like a light bulb went on in my head. I have almost completely revolutionized my thinking to reframe discussions against the "how vs why" thought process.

For those who don't know, I'm leading a fairly sizeable data center automation (DCA) initiative at my employer. The concept of "how vs why" is a key element to work stream management. I have begun to drive the automation platform beyond the narrow implementation scope that I have been charted with, and the conversation inevitably goes something like this:

PersonX: ... and that's why I want to automate task X.
Me: Ok, so you want to automate task X. Why?
PersonX: huh?
Me: Why do you want to automate task X?
PersonX: buh?
Me: I'm not getting through to you... what business value will you derive if I were to automate task X?
PersonX: snuh.
Me: I'll come back when you're feeling better.

(I kid. Mostly)

The truth of the matter is, technologists are trained to look at things as having intrinsic value. If you can save 5 minutes by automating something, why wouldn't you? But the point that is in progress of being missed is that not everything has intrinsic value. If you're going to automate a task that saves one person five minutes every year, then the cost of creating, testing, implementing and maintaining that task automation is going to exceed the business benefit by a large amount. At $50 an hour going rate for labor, five minutes of savings for one person is about $4. Take that out three years and you're at $12 of savings. Contrast that with the cost of implementing the automation - for arguments sake, let's wrap up requirements gathering, code and testing into three hours, which equates to $150 to deliver that task automation. Then let's use a five percent overhead on maintenance per year, taken out three years for $22.50, for a grand total of $172.50 of development and maintenance costs over 3 years, versus $36 of savings.

To put it in different terms, that's a four-close-to-five year ROI.

Savings to automation = $36.00
Cost to implement & maintain = $172.50

Now, this brings me to the most important lesson of all: automation delivers benefits that vary with the number of people who use that task.

If I have one person benefiting, then it's a five year ROI.
If I have two people benefiting, then it's a two and one third year ROI.
If I have ten people benefiting, then it's a negative four tenths year ROI.

That's an easy concept to grasp, but what's more important is that it refocuses the discussion into Why rather than How. Automating the task is trivial compared to measuring the benefit of automating the task to your business, and yet the value is not in the automation of the task, it's in making the people who execute that automation more efficient.


In short, want to do yourself an enormous favor? The next time you're looking for technology to solve your problem, ask yourself that question:

What business value will I derive by implementing this technology?