I see that life as enterprise service desk hasn’t changed much. “Nobody tells me nuthin!”
Shout out to the ever under appreciated service desk folks out there.
I see that life as enterprise service desk hasn’t changed much. “Nobody tells me nuthin!”
Shout out to the ever under appreciated service desk folks out there.
"Why didn't you tell us you hired something new?"
"They work here for 2 weeks now"
"Tauch' deinen Füller nie in Firmentinte."
That's a very important advice!
Poetic
Chinese lesson two: really don't call them "not a thing".
¹: Also it's still my favourite, uh, thing that the word for a "thing" is, literally, an "east-west".
A "thing" or "stuff" in Chinese is 东西 (dōngxi). That's literally "east-west" if you pick the individual characters apart. That's what the footnote refers to.
Calling somebody 不是个东西 (bùshì ge dōngxī) means something along the lines of being good for nothing, i.e. an insult. Translating it literally, it would be calling somebody "not a thing".
Saying someone is irrelevant is likely an insult, also in English.
Not the corp in question but here is another one: https://www.thewealthmosaic.com/vendors/geissbuhler-weber-pa...
Nice Hot Fuzz reference.
You may have heard of some of them, ServiceNow is one, SAP is another, some small companies like that.
It turns out there is not a technological solution to a management problem.
I can imagine the brute-force approach:
Log every intra-company communication, and if some communication was meant to go to department X, Y, Z, and it only went to X, Y, then a flag would be immediately raised to department Z's attention and whoever sent it.
Of course the personnel in department Z might review it but ignore it anyways, but at least now there's a paper trail of who's at fault.
An Exchange system already gets you 80% of the way there if you force all on-the-record communications via email.
That's the problem right there. One of my clients had a large IT organization of over 1000+ employees, with strict change control rules, and procedures that were tracked in SN. Every time there was a change management meeting everyone who could possibly be effected would get an email from Service Now notifying them of the upcoming changes.
Pretty much engineer ignored those emails, because there was so much going on in the org you'd get dozens of emails in a week and most of them you'd only be tangentially effected by, meanwhile you had your work to do.
So the problem isn't getting the notifications out it's getting people to pay attention to them.
Individual preferences do vary, one ignores 90%, another 95%, another 100%. And the one who's ignoring 100% of them will likely eventually make a mistake that otherwise wouldn't have happened.
But it will be fairly straightforward to resolve, after all there's an extensive paper trail as the chain of custody seems clear. Assuming the "change management meeting" emails were the approved means of communication.
IMO, one of the lessons that came out of Chernobyl is that it absolutely is a problem for the organization. Exposing people to too many "alarms" that are constantly going off will cause people to start ignoring them.
Part of good design is figuring out which things are truly important, and how to communicate that to the people who are supposed to be paying attention.
The emails mentioned by the parent don't sound like alarms. Because an alarm is usually for 'drop everything and focus on this' situations.
The equivalent in email terms would be a receiving an email with a subject in ALL CAPS bolded and underlined.
Or in general intra-company communication terms, a phone call from your boss without any pleasantries and a serious voice.
If someone makes the wrong decisions because they start ignoring signals then don't promote them or give them important coordinating responsibilities. Those who are capable of filtering out a larger fraction of noise do exist.
Of course there will always be folks whose preference is to read near 0% of their emails, but that doesn't imply organizations must be designed around them.
This is simply wishful thinking. Outliers certainly exist, but the idea that there are sufficient number of them that you can just ignore human nature is a path to disaster. You'd have to somehow accurately measure not just who is opening these noisey e-mails, but what they are retaining from them, and measure it over a large period of time, knowing that the vast majority or going to fail. It's far cheaper and more reliable to fix your noisey system than to try to outwit human nature.
Can you describe this 'cheaper and more reliable fix'?
It's really weird that you think you can't decide who is responsible for dealing with a type of notification ahead of time without "endless politicking and horse-trading", but think that blasting everyone with every notification, then attempting to sort out responsibility after something has gone wrong will somehow not cause "endless politicking".
Again, this is something many businesses do already. They don't blast the whole company when a bank account balance is low, when a server's disk is full, etc, notifications are targeted to appropriate groups. The specifics about who gets what is going to vary based on your organization. I can't give you hard and fast rules that will work for every organization, but that doesn't mean it's somehow impossible or not worth doing.
It's hard to tell if your joking.
The reason for implementing restrictive organizational procedures in the first place IS because nobody behaves like a 'rational human being' in such an environment for any significant duration.
When __everything__ is highly important and #urgent#, nothing is important and urgent.
In a sufficiently large and complex organization there will always be some percentage, neither 0% nor 100%, of actually 'highly important and #urgent#' hidden among the pretenders.
The point of any such tracking system is to discover, via positive or negative selection, what is actual instead of what various flawed humans pretend.
That... doesn't sound like a great approach to me.
If no one is keeping track of who is doing well and who to replace, then fixing that first is more important.
:-)
That (probably) means that the system for dealing with planning maintenances (well, usually, "approving them") needs to have a sufficiently good understanding of what humans care about what changes.
At a previous job, the planned change tracking system was REALLY good at tracking what specific compute facility was going to be impacted by any specific change taking place in that facility. And had a really good way of allowing you to filter for "only places I have stuff running" (and I think, even some breakdown of general change types as well).
It was, however, not easy to get notification of "there will be maintenance on submarine cable C, taking it off-line for 4 hours" or "there will be maintenance at cable station CS, taking cables C1, C2, and C3 down for 3h". And as one of the things "we" (the team i worked in then) was doing was world-wide low latency replication of data, we did actually care that cable C was going to be down. But, the only way we could find out was "read all upcoming changes" and stick them in the team calendar.
Was it good? Eh, it worked. Was it the best process I've seen? Probably ,yes.
So what? How would that change anything? Service Desk would send strongly worded emails to... somebody? The Organizational Overmind was already getting warning messages. Daily. There's already a trail of emails and status reports. It wasn't a knowledge issue. It was a "there's no effective direction" problem.
Which is why I consider it a 'partial-solution' as technology cannot do everything by itself yet.
So you'd select "System Z Update Access", write a one liner of "I need update system Z to do my job supporting The Alpha Process", your manager would approve it (providing they agreed that your role did involve supporting the Alpha Process) and then someone from the System Z team would also approve it (providing they agreed that you needed that access to support that process), and then a few minutes later you'd be automatically added to the right role.
Traceable, secure, and fairly painless. Required a lot of setup for all of the roles and automation though, I believe.
Human problems require human solutions. Tooling problems require tooling solutions.
Been my favorite saying at my small business for years now when people propose technological solutions to HR issues. That isn't gonna cut it.
Or did just some clueless start-up beg to get sued into oblivion?
I am making some assumptions when discussing this topic, namely:
1. The CEO and executive leadership are actually competent, have at least average middle aged adult levels of patience, and don't have their daggers out for each other.
2. There exist more than one method of communication between each layer in the hierarchy.
3. The organization is engaged in normal business, not in the middle of an M&A deal, outside investigation, or bankruptcy proceedings.
In reality, most large organizations do have at least a semi-competent leadership team most of the time. Unlike what is commonly supposed by junior level staff expressing their frustrations.
Everyone on HN can read the comment chain and see where you joined in, and who said what... so the claims are difficult to take seriously.
Even if you focused on my alleged lack of qualifications to comment it would have not been as self-discrediting.
Though I don't get riled up by oblique insults, that might not be the case for others, especially for a topic that might be linked to negative emotions in the reader-base.
My sentence on 'junior level staff' wasn't directed towards you, it was a reflection on why it can be difficult to see the grand scheme of things when the environment might restrict that.