What’s Your Suck Level?

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.

You might also like

Add comment

E-mail is already registered on the site. Please use the Login form or enter another.

You entered an incorrect username or password

Sorry, you must be logged in to post a comment.


by Newest
by Best by Newest by Oldest

As a SMB consultant for 20 years (IT college instructor for 16), my job was assigning "value" to projects and attempting to explain the return on the "investment". ROI on redundancy/fault tolerance, security, etc is hard to quantify to Mr. SMB, but rather, what could happen if aforementioned system wasn't in place. "How much would it cost Mr. SMB to be down for a day or days?" That combined with paying Mr. Consultant to triage and remediate the issue. Those discussions can be a bit more challenging and harder to sell...it's like having insurance, you hope you never have to use it. Putting together a cost/benefit analysis on a new toy (SCCM, DCS, etc) is a little easier to sell as the ROI on previous systems can be broken down by saving "person" hours thereby saving the company $$. I stress to my students they have to understand their potential employers business to understand what they measure value in...as with most, it comes down to saving money. Great post Don! I really enjoy your IT/NON IT posts. I will definitely bring the suckiness discussion to the classroom.


great insight Don. Thanks for being a positive influence in my professional career.


Another Suck level is seniors loving old technology and not willing change for the fear of creating instability the environment.Like using 1000's of 1000 line vbscripts that can be done with PowerShell in few lines.


Unfortunately that still misses the point. That sucks, but how much? What's the business impact, in monetary terms? If you only identify suck - if you can't measure it - then you can't change it.


Welll sometimes that legacy debt comes from legacy industry standards and there's nothing you can actually do about it. That's the most frustrating to me.
"It works save a ton of time and money if we built or images this way".
"That model will delay our PCI audit so no".
"But it's more secure"
"I want to see them check that box, not start a in depth discussion that may end in remediation".
Yeah I get it, but it hurts at times to be shackled by the possible ignorance of some random audit.


I would again say that this isn't measuring the suck. It's "we suck," not, "here's exactly how much we suck," which is the point. "More secure" isn't quantifiable. You win these battles if you can express yourself in business terms. "A lot of time and money" isn't a measurement, either - how MUCH time? Exactly? How MUCH money, exactly? Can you present a way that you measured that, and a way to re-measure it to validate the savings? If you can precisely quantify those savings, then it's going to make it easier to force a discussion. "The possible ignorance of a random audit is costing us $EXACT_AMOUNT, can we have a discussion?"