Hacker News Reader

Comment by justanother | Hacker News Reader

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.

View on HN

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"

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

Bingo. Otherwise urgency has nil cost.

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

Reply on news.ycombinator.com