11 ms·

The Negotiability of “Severity” Levels

52 points by di4na 7y ago

booleandilemma 7y ago
The site isn’t loading correctly on iphone x safari. Which severity level is that?
- falsedan 7y ago
  looks fine on iOS Safari here
duxup 7y 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....".
- JohnFen 7y 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.
  - filoleg 7y 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.
    - hobs 7y ago
      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.
      - WrtCdEvrydy 7y ago
        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.
        raverbashing 7y ago
        My compliments to whoever came up with this workflow
      - paulddraper 7y ago
        I'll do both, but that naturally takes twice as long.
      - JohnFen 7y ago
        > 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.
      - filoleg 7y ago
        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.
- cle 7y ago
  Ugh this is such passive aggressive behavior. Just tell him no, and why, so he can communicate clearly with his customer.
  - duxup 7y 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 7y 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 7y ago
  I prevent all sites from loading fonts.google.com unless NOT doing so makes it unreadable to me.
justanother 7y 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 7y 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 7y 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"
hinkley 7y 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 7y ago
Yay, another site with a ridiculous "loading" widget I have to adblock. Ublock #.preloader to make the page actually display.
Spooky23 7y 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 7y 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 7y 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 7y 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 7y 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.
draw_down 7y ago
It should be specific and measurable, like “25% of customers can’t access service X for more than 15 minutes”, or some service is behind its SLA for data freshness (where the SLA itself is specific and measurable), etc. Weasel words like “minor” and “major” are just asking for this to happen, for incidents to become tools used for political leverage.

52 points by di4na 7y ago

booleandilemma 7y ago

The site isn’t loading correctly on iphone x safari. Which severity level is that?

falsedan 7y ago
looks fine on iOS Safari here

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

JohnFen 7y 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.
- filoleg 7y 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.
  - hobs 7y ago
    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.
    - WrtCdEvrydy 7y ago
      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.
      - raverbashing 7y ago
        My compliments to whoever came up with this workflow
    - paulddraper 7y ago
      I'll do both, but that naturally takes twice as long.
    - JohnFen 7y ago
      > 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.
    - filoleg 7y ago
      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.
cle 7y ago
Ugh this is such passive aggressive behavior. Just tell him no, and why, so he can communicate clearly with his customer.
- duxup 7y 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 7y 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 7y ago
I prevent all sites from loading fonts.google.com unless NOT doing so makes it unreadable to me.

justanother 7y 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 7y 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 7y 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"

hinkley 7y 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 7y ago

Yay, another site with a ridiculous "loading" widget I have to adblock. Ublock #.preloader to make the page actually display.

Spooky23 7y 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 7y 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 7y 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 7y 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 7y 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.

draw_down 7y ago

It should be specific and measurable, like “25% of customers can’t access service X for more than 15 minutes”, or some service is behind its SLA for data freshness (where the SLA itself is specific and measurable), etc. Weasel words like “minor” and “major” are just asking for this to happen, for incidents to become tools used for political leverage.