The Negotiability of “Severity” Levels | Hacker News Reader

The Negotiability of “Severity” Levels

adaptivecapacitylabs.com

52 pointsdi4na31 comments

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....".

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.

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.

You forgot the 4/10 times someone says "Just do both" and leaves.

How do I know this? I have tried this technique multiple times, it only works with people logical or not enough of an asshole to comply.

Our JIRA workflow unassigns you from a ticket if you're assigned a second one in the same column... some hot shot Sales guy thought he was smart assigning me to a ticket only for a massive entry in the History tab saying he had taken me off a Priority 0 Ticket... Head of Development did not approve... loudly.

My compliments to whoever came up with this workflow

I'll do both, but that naturally takes twice as long.

> You forgot the 4/10 times someone says "Just do both" and leaves.

This reminds me of the adage that nothing is impossible for the person who doesn't have to do it.

I mean, this just sounds silly. Yes, you will have to do both things, but one thing has to take priority over another, as you cannot write two different things at once simultaneously. Just like you cannot have two different entries in a queue at the same index. I am sorry you had to experience this.

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

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.

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.

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

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"

Bingo. Otherwise urgency has nil cost.

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

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.

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.

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.

New Ticket!

Priority: "Urgent (System Down)"

"My Printer is gone!"

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

Ublock #.preloader to make the page actually display.

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.

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.

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.

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

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.

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

Which severity level is that?

looks fine on iOS Safari here

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.

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

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.

Reply on news.ycombinator.com