In a recent Pluralsight “IT Ops News & Talk” podcast, I talked a bit about quantifying your level of suck.
That sounds horrible.
Here’s what I said, and why:
Do you know how much you suck?
No, it’s not a rhetorical question, and I’m not implying that you do suck. I think we can both agree that when it comes to your IT environment, you and I both know that something sucks about it, right? But do you know how much?
Let me give you a non-IT example to consider. Say you’re an engineer, living in a small, riverside town at the start of the 20th century. You run to the town mayor and say, “mayor! I’d like to build an epic, three-span suspension bridge over the river! It’ll save days per trip for the carriages and wagons trying to get to the other side!”
Mister Mayor looks at you and says, “but why? We’ve always just ridden two days South, forded the river, and ridden two days back North.”
“But that’s so inefficient!” you cry. “With a sturdy iron bridge, we can turn the trip into a couple of hours!” “But,” the Mayor counters, “it’ll be so expensive. And I’ve never even been clear on what people find so alluring about the other side of the river. No, let’s just proceed as we have been.”
I know you’ve had this same conversation in your organization with regard to technology solutions. We all have. The problem here is that you know there’s some suck in the system, but you haven’t quantified it. You know you suck, but you don’t know how much you suck. The mayor gave you a clue, too: Expensive. The mayor’s unit of suck measurement is in dollars, and unless you can quantify the suck in that unit, you’ll never get the go-ahead for your bridge.
“But Mayor,” you could counter. “The wagons are heading across the river because that’s where some of our best crops are. As it is, the two day return journey results in 10% spoilage. And fording the river isn’t easy – we lose another 10% of our crops to accidents. That 20% loss is worth exactly this much money, and as you can see, the expense of building the bridge would pay for itself in under six years, just by eliminating those losses. We’d likely see other financial improvements, too, such as lowered costs for food. We could ensure that by charging a toll on the bridge, or applying a tax to the goods brought over it.”
You’ve quantified the suck in terms the mayor can understand, and can work with. And that’s what you need to learn to do in your work life. You need to first understand the units of measurement that your organization’s leadership uses, whether that’s dollars, or man-hours, or euros, or pounds of walnuts. And then you need to learn to quantify technology problems in those units of measurement. “We spend fifty bags of walnuts per quarter dealing with this problem,” for example, “but there’s a vendor that can implement a permanent solution for us, and it only costs two hundred bags. We’ll see a return in a year!”
The problem with too many IT professionals – and this truly frustrates me – is that they take very little time to understand what matters to the business. We complain about our technology problems mainly for the sake of the technology, or because – given our natural engineering mindset – we’re just frustrated by inefficiency and manual effort. But because we don’t necessarily know what drives the business conversations, we’re talking a foreign language. Business leaders see us as agitators, not problem solvers. We’re tools to them, not solutions. But if we can speak their language, and quantify the suck in terms that make sense to them, then we’ll start to make forward progress together.