
The Negotiability of “Severity” Levels - di4na
https://www.adaptivecapacitylabs.com/blog/2019/05/20/the-negotiability-of-severity-levels/
======
duxup
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
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
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
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
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
My compliments to whoever came up with this workflow

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

~~~
daurnimator
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"

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

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

Ublock #.preloader to make the page actually display.

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

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

------
fwip
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
I prevent all sites from loading fonts.google.com unless NOT doing so makes it
unreadable to me.

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

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

Which severity level is that?

~~~
falsedan
looks fine on iOS Safari here

------
thrower123
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
I refuse to mark the priority of anything higher than "normal". If somebody
else decides it's critical, they can raise the priority.

~~~
AllegedAlec
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.

