The Negotiability of “Severity” Levels

https://www.adaptivecapacitylabs.com/blog/2019/05/20/the-negotiability-of-severity-levels/

by di4na • 7 years ago

52 31 7 years ago

adaptivecapacitylabs.com

booleandilemma• 7 years ago

The site isn’t loading correctly on iphone x safari.

Which severity level is that?

falsedan• 7 years ago

looks fine on iOS Safari here

duxup3• 7 years ago

I had a conversation with a sales guy once, he was known for not listening and I had just gotten off the phone with his boss:

Sales: "Why haven't you resolved my customers problem yet!?!"

Me: "I've got 8 tickets marked as critical right now, your ticket is marked 'high'".

Sales:. "Make mine a critical!"

Me: "Ok!"

An hour passed and he calls back:

Sales: "Why haven't you resolved my customers problem yet!?!"

Me: "I've got 9 tickets marked as critical right now....".

JohnFen2• 7 years ago

Brilliant!

I once had a similar exchange, but about "#1 priority". I had multiple items that I was told were my "#1 priority", and when someone wanted to add another one, I had to tell them that their item would have to take a back seat to the other "#1 priority" items that came in first.

filoleg2• 7 years ago

Beautiful strat. If you want to go one step above, tell the person asking you to make their task your new #1 priority to negotiate with the person who owns your current #1 priority and then get back to you when they manage to convince the other stakeholder to secede their priority.

9 times out of 10 they realize that it is a waste of time leading nowhere and agree to being your priority #2. The remaining 1 out of 10 times, they successfully manage to convince the other person that their task is more important, and now you have a new #1 priority. 10 out of 10 times you win, because you didn’t have to fight anyone just to keep your sanity.

cle• 7 years ago

Ugh this is such passive aggressive behavior. Just tell him no, and why, so he can communicate clearly with his customer.

duxup3• 7 years ago

As I said I talked to his boss before the cranky sales guy called, and we already worked out with his boss how things would be handled and everyone but sales guy was on the same page.

Cranky sales guy calls and throw fits regardless of the situation, before he reads his emails from his boss or anyone else. He also was almost certainly not listening to anything I said anyway. The conversation with him was like most with him, unnecessary, but he wanted to have it.

fwip• 7 years ago

The content is good, but the number of different typographic styles made it seriously difficult for me to read. My eyes kept getting yanked around as I scrolled down the page.

lnx01• 7 years ago

I prevent all sites from loading fonts.google.com unless NOT doing so makes it unreadable to me.

justanother• 7 years ago

The problem with customer-settable severity levels on anything from tickets to emails, is (my name)'s Law: Over time, all customer-settable severity levels will tend to drift towards the highest available setting. Oh sure, you can try and mitigate this by making the highest level "Urgent (System Down)" but eventually this will lead to a lot of "Urgent (System Down)" level issues too. Another mitigation is to make their visible urgency setting a placebo, but it's not a good one as it doesn't manage expectations.

The only thing that ever really works is deferring to a mutually-respected PM and only allowing them to set severity levels. This is but one reason that truly good PMs are amazing to have around.

opportune• 7 years ago

I have noticed that internally, there is usually a good ettiquette with only marking incidents with urgent severity if they are truly urgent. Since what goes around comes around, nobody wants to set a precedent for unnecessarily making people work extra/get up in the middle of the night to fix something. And if you "own" an incident and know that it's not urgent (for example, some team in Asia producing non-prod analytics reporting creates an "urgent" incident that wakes you up because their data is ingesting slowly) you are ok with downgrading the severity and going back to bed.

Your system sounds like a good system to me for more customer-vendor types of situations. My issue with certain support contracts is that no matter what severity your issue truly is, you will get routed to a "support engineer" who will waste your time asking you whether you've tried turning it off and back on again / whether a 10% of the time transient issue is infrequent enough to mark the issue resolved, etc. It would be so nice if there were technical PMs or capable engineers who could actually forward real, breaking issues to on call engineers.

There is a certain large, well known big data company whose main product I will never recommend again due to my terrible bug/support experience with them. No triaging whatsoever and a terrible lack of skills among their employees

daurnimator• 7 years ago

Assigning cost works too. "On your current support plan, we include 2 urgent tickets per month, after which they will be handled at 'high' severity. For $X you can purchase more"

dredmorbius• 7 years ago

Bingo. Otherwise urgency has nil cost.

flukus• 7 years ago

You better have staggered billing periods because people will want to user their credit.

duxup3• 7 years ago

I used to ask if I could reset the equipment we supported. We made that option a requirement of the highest status.

If we could not do so on the spot, it wasn't critical.

That was one of the few things we could get by in from upper management and regularly enforce even with less technical management.

Kalium• 7 years ago

Allow me to broaden this a bit:

justanother's law: over time, all user-settable severity levels will tend to drift towards the highest available.

When I ran a bug bounty program, I saw this firsthand. I got a lot of reports that were had every scary-looking label the reporter could think of attached. In the vast majority of cases, none of them were justified, and it was some low-priority issue.

eridius• 7 years ago

At least in the bug bounty version there's an incentive for submitters to make their bug sound as scary as possible, which is that more severe bugs generally pay out more money.

So I guess the lesson is, people will adjust their behavior based on their incentives. If you reward people for exaggerating severity, then people will learn to exaggerate severity.

zaarn• 7 years ago

New Ticket!

Priority: "Urgent (System Down)"

"My Printer is gone!"

hinkley• 7 years ago

The first version of severity levels that I liked involved dimensions such as data loss and whether workarounds existed.

For some domains, read-only access to the data can suffice for employees to remain busy for hours. For others like an online store, being unable to check out means you are losing money.

fake-name• 7 years ago

Yay, another site with a ridiculous "loading" widget I have to adblock.

Ublock #.preloader to make the page actually display.

Spooky23• 7 years ago

This stuff imo should be a assigned based on application business value and the standard that it is built. If an app isn’t resilient, no after hours or priority response. If it’s a tier-0 or human life is impacted, it’s always critical. If it’s business critical and running on FoxPro, cap the response level.

Allow someone with juice to escalate on request to reduce the urge to escalate easily.

You also need to not suck. If a severity 4 means abandon all hope, than you suck, and severity level is just a proxy for squeaky.

thrower123• 7 years ago

Oh, this is blogspam advertising...

We all know everything is sev1. Always. All the time. It doesn't matter that it is user error, or failure to follow proper procedure that causes a hiccup. Or that it is a pie-in-the-sky feature request that is completely out of scope, or that will actively break how the product is supposed to work. It's all sev1, and we will be on daily calls until you do the needful and accomodate our demands. Which we won't offer to pay for, and by the way, we'll drag our feet on the payments that were specified in the contracts we signed already. Why aren't you responding to our HIGHEST PRIORITY emails at 3AM within minutes (when 24x7 support wasn't part of the deal...)?

I love being a vendor for TCS/Cognizant/Infosys/HCL/IBM/ATT/etc middlemen so, so, so much.

commandlinefan• 7 years ago

I refuse to mark the priority of anything higher than "normal". If somebody else decides it's critical, they can raise the priority.

AllegedAlec• 7 years ago

Not to discredit you, but I think that this is a vital skill for a developer to have. If I see a bug that could impact something severely, it's my (ethical?) obligation as a developer to report this bug under the severity that it actually is. If I underplay it by saying it's of regular severity, I could do significant damage to my company and its clients.

alkonaut• 7 years ago

Severity levels should have descriptions. And the more triage questions there are, the better. A god two-part level is a) how bad is it? and b) how many are affected? which is, how many are using the system times the probability of the error.

The worst level for the first question is "complete data loss" or "planes fall from sky" or whatever. The second question might be "every user with 100% certainty and no workaround", or it might be "every user with right to left input who use the system on a sunday in a leap year, and there is a workaround".

These numbers can be combined (e.g. multiplied) to get a proper priority.

The Negotiability of “Severity” Levels

Related Stories