> support - whether external customers or internal stakeholders - is a game of hot potato

I’d like to shift this a little:

Support who’s primary metric is handle time is in a game of hot potato.

From a business perspective the managers and leaders always feel like there’s too many fires which inevitably leads to either pressure on front-lines to “go faster” and “stop doing unnecessary work” (aka “taking time away from the fires”) or some level of management that’s intentionally blocking higher-ups from seeing those fires so that they look like they are managing the department well (and in this case not only is there the same pressure on the front-lines, but there’s additional pressure about not reaching out to anyone except through that manager.

When the primary metric is handle time, the issues pile up, there’s never enough people to handle it, and the business slowly sinks as no one with a budget sees the “ounce of prevention [that can prevent a pound of cure]”.

However: If the metric is minimum number of departments an issue touches before it’s resolved it’s a whole different thing. Suddenly playing hot potato is a problem and “problem ownership” is praised. There are other metrics too that produce different support cultures (and sometimes different games), but the reason hot potato is so popular is that those other metrics all require top-level execs to be comfortable with spending now to save down the road.

This seems difficult to resolve because staff time is limited and you can’t do everything. That’s why tasks need to be prioritized. But how?

Distributed prioritization seems like a problem; you can get priority inversion if you’re not careful.

How is a question who’s edges are unique to the company but if you’re coming in to a situation like that one generally-solid approach is to accept that things will suck for a while, and might even be worse short-term, the prioritize chipping away at the underlying causes.

Something like reducing staff ticket time by 20%, then using that 20% for feedback, strategy, and structure. Some (maybe even most if you’re lucky) of the front-line staff will have enough experience and insight to be invaluable here (though it is likely they won’t have the language yet to express it in ways that make sense to management). As the company goes through the process of communication, discovery, awareness, planning, and execution (preferably with a tight feedback loop) some of the underlying causes will be addressed, the front-line pressure will ease off, the cascade effect will see ease-off in other departments as well, and that 20% can go down to 5% or even 0 (not recommended lol) which will further reduce the workload to give longer-lasting relief.

Then with staff time “out of the red” the company can start thinking about what they will do in a fire-free future.

It's a classic triage problem. But "tell them to go away" isn't a triage strategy.

> But "tell them to go away" isn't a triage strategy.

The stubbornness of large organization can be maintained for several hundred years, assuming it exists for that long, so this isn't quite true.

Exactly it. I’d like this as a tshirt that people can wear when consulting on support team management.

lol first they came up with the phone menu. Then they came up with complicated phone menus meant to confuse you and get you to give up. Then they replaced those with voice recognition menus that are straight up infuriating. Then they replaced that with AI that tries to act like it's a person.

All because telling you to GTFO isn't an option. Typical customer support is thus a proof-of-work scheme: to get it, you need to waste some significant amount of time and energy up front.

Problem is once its easier to just bypass all that and find ways to bug higher level employees whose time costs the company siginificantly more. If more people realized that then the regular support would quickly be told to actually solve customers' problems.

> There are other metrics too that produce different support cultures

Could you elaborate?

Not them, but I worked at a University in their IT dept, and our chief metric was solely 'customer satisfaction' (and 'customer' meant 'faculty'). We almost never wanted to pass tickets, because that tended to make the 'customers' upset. They wanted white glove service, and that's what they got.

It also meant that some people had "forever tickets", that were a continuous series of tacked-on asks by the same faculty member. HigherEd IT can be crazy (and crazily-laid back).

I've heard IBM used to be the same, if the customer had an unlimited expense account with them.

I feel like my experience with big cos is that the "that's another team" might go like this:

Parental controls is essentially maintenance mode and has 1 dev nominally responsible for it, maybe their workload is divided between that and a bunch of other stuff that they deem their "real" work. The way the component works means that bugs typically get assigned elsewhere in the system very far away from parental controls; you, the owner of Contacts, land a bug like "Your feature XXX has the following failure in parental controls mode." The team responsible is like ... "Why do I care about this? Why should I take a code change for this? Isn't that your problem?" Whoever is responsible for parental controls might not care, but if they do, they don't have political leverage over the owner of the Contacts app or whatever. Therefore, won't fix.

Yes, and the worst part is I don't think it's even a side effect of organizational structure because I've seen it in so many places. There is just a quirk of human psychology where "if you touch a problem it belongs to you now," and the result is a situation where everyone would be genuinely happy and eager to help but nobody (except the newbie) dares try because the consequences for trying are immediate and dire.

This seems related to what I think of as the “jurisdictional hack.” Nobody can solve every problem, so you define a realm that’s your responsibility and anything outside it is someone else’s problem.

Keeping your jurisdiction small means you can do more within that jurisdiction, by ignoring even important problems that are outside it.

But the alternative is ineffective doomscrolling because all the world’s problems are yours.

By definition Google's board, and shareholders who elected them, can 'solve every problem' within Google, since they have the authority to wind down the company.

It's just that practically nobody in the world can credibly demand Google's board, or even just upper middle management, to make a decision on small matters.

Sure, but that's because they can delegate to lower management tiers.

When a ticket reaches your average IT guy, they can't usually delegate it to a lower tier employee unless there are formal support tiers, like L1 and L2, and the ticket was sent to one of the upper layer techs (which usually doesn't happen straight away, because of how L1 and L2 support teams work).

If this is not the case, the only way out is forwarding the issue to another team.

There’s a lot you can criticize Google about, but that would have extremely disruptive worldwide effects. Google is load-bearing infrastructure. Dismantling it would require solving whole lot of new problems.

This is how we have a really urgent problem, which I can fix in the non-production environments in an afternoon, only to have people emailing me for the next month asking why this extremely important problem is not fixed in prod yet.

Sorry guys, that’s another team. They’re extremely reluctant to deploy even very important things. Separation of responsibilities means we have no other choice.

So, the future is Universal Basic Income and Open Source.

> The "that's another internal team" reply was presumably more about bounty than vulnerability itself.

Yeah, that's my read. Basically the first line of support said "parental controls and screen pinning don't count as security boundaries", and the author is upset not because of an abstract argument about impact but because they want to get paid.

Should they be security boundaries? Honestly I'm mixed on this. First because the threat mode is totally different when the attacker is your teenager (i.e. who exactly is the harmed victim? The parent?).

But mostly because the whole idea behind bug bounties is to encourage disclosure of vulnerabilities that would otherwise be sold and deployed against the public at large. That is, the bugs have "value", and we're all better off if the purchase price is borne by the software developer than the criminal. There's no market for parental controls bypasses in that sense.

> parental controls and screen pinning

Will be used in scenarios with much more at stake than someone's belligerent teenager.

Think of these features in the broadest sense you possibly can.

Are you thinking about something specific? What's the scenario where the public harm to a usage control bypass becomes more valuable to an attacker than the bug bounty?

(Edit: <sigh> than the bug bounty that the linked author desires. Really?)

Remember that both of these technologies don't allow the device to do anything it isn't able to do in its default configuration. They're essentially a form of DRM: disallowing otherwise useful activities because of the desires of the owner (and not the user). Would you demand, say, Apple pay a bug bounty for a DRM bypass that let people rip Netflix videos? Probably not, right?

> What's the scenario where the public harm to a usage control bypass becomes more valuable to an attacker than the bug bounty?

Since the bug bounty is zero. All the time?

You're totally right in the general case, but in the specific case of security vulnerabilities it makes sense for there to be an exception (even if the action taken is just to hot potato on your side).