Is it the report's job to bend over backwards to prepare a series of easily digestible info-graphics to convince the manager that the decisions they've made are bad? Or is it the manager's job to follow up on decisions they've made to see how they turn out, and to investigate to see if reports of eye-gouging are substantiated? In theory, the person whose eyeballs were affected by your decisions already have a litany of responsibilities that do not cease to exist when someone makes decisions that rock a company to it's very core. Maybe instead of shlepping the responsibility of identifying the consequences of their actions downstream, they should exhibit a little initiative and attempt to take a role in evaluating whether the decision they've made was the right one for the team.
So my understanding is that you're right to say that the manager has a responsibility to listen keenly for the impacts of their decisions. I'd say it is one of their primary responsibilities as part of their responsibility for the health of their team. The
But my understanding is that in general communication is a 2-way street: Both people in a relationship should be listening with the intent to understand the others' perspective and to watch for misunderstandings. Up and down a larger organization, I think this communication tends to be harder because
1) It is often indirect -- multiple hops from individual contributor to CxO.
2) The communication that can possibly happen grows with the size of the organization.
3) People work on things that are more and more delegated. So the day-to-day problems of an accounts admin are very different from the day-to-day problems of the CFO. So the gap of "understand each others' perspectives" becomes wider and harder to jump.
All this doesn't diminish a leaders' responsibility: it raises it. But it also makes it that much harder to execute if the signals from people in the org are hard to interpret.
> A series of easily-digestible info-graphics
Are nice, but "I've noticed a serious problem. Here is a 30 minute screen-capture of it." is faster to produce and send to a direct manager and then you can (ideally) collaborate on how to raise that to the wider business.
------------------
All this comes with the caveat that I'm an individual-contributor-level software engineer who has never managed a team for an endeavor more complex than a care-package-drive... and I might in fact be far enough on the autistic spectrum that I massively misunderstand how any of this works. (See other comment)
Sure, you're not wrong about any of this. But in GP, the commenter was essentially saying that if the CxO was not listening, it was because they didn't come with proof and business impact explicitly outlined in a convincing presentation, while I am arguing that in an emergency software-behaving-dangerously situation, it should not necessarily be the duty of the person bringing the claim to write a full report and presentation ahead of time.
Meta question: Why are we talking about people's eyeballs being literally stabbed out?
I had assumed that this was an expression of some (unknown) level of difficulty, and that if we could shift the discussion to describing that realities of that difficulty and its impacts on business operations and morale, we could get some insight.
But am I wrong?
This is the first time I've heard about "literally shooting knives and...gouging out eyes" in an IT discussion. Is this actually a thing that results from IT procurement in a literal sense? By "literal" I mean the sense that would refer to a piece of material entering the eye-goo of another human being and causing actual pain and hospitalization.
Does anyone else find it very difficult to understand situations when you are not sure at all how seriously to interpret someone? I'm aware I'm probably on the autistic spectrum...but since we're having a discussion about engineering or technology procurement, could I ask for a bit of specificity?
Is it odd to find the idea of literal eye-gouging to be out-of-place here? That it seems really extreme and like a very black-and-white way to talk about problems? Or am I just losing my mind?
Genuine question: Does my difficulty with understanding the role of literal eye-gouging in IT procurement and UX design signal that I'm becoming unhinged from reality?
The eye gouging on this case is a metaphor to stand in for "doing awful things that the software should never, ever do" which allowed them to be less specific about the exact nature of the problem that the software was having. This is because the specific problem with the software is not a detail of interest. Rather, you are supposed to take for granted that the software problem is very serious and being ignored by the superior. People will commonly use exaggerations and ridiculous metaphors to gloss over something as an unimportant detail so you, the reader, know that isn't the point they are trying to make.
I just rolled with it because it was GGP's example.
