As someone who has been in both tech IC (individual contributor) and higher management levels, this is often a relatively simple result of impedance mismatch (excluding bad faith individuals for now):
ICs and lower level managers are all about inputs and outputs, blocking and tackling, getting shit done.
At the higher management levels it is all about setting direction, setting the "tone", "getting the culture right".
There is just so little concerns that intersect between these groups, that communication becomes a challenge.
I think there's a level of bullshit in both views. Many orgs are absoloutly mismanaged.
- At the lower levels you're getting shit done. Maybe. And if you are that's good, but if the shit isn't revenue generative, supporting revenue, or saving costs, then your job might actually be a bullshit job.
- At the higher levels, you hopefully know where your revenue is coming from, and your job is to maintain that whilst growing more. But if you have no operational ability, you're at the mercy of the first group, and might not actually have any real impact in the direction of the company.
The mismatch and lack of empathy causes the discourse. The devs typically have limited incentive to chase revenue, the leaders have limited desire to get their hands dirty.
Successful startups / growth companies are less likely to look like this, though funding can distort the relationship.
Even mid managers have expressed similar concerns to me about finding it difficult to work with tech. E.g., a product manager has complained to me that they wanted a feature built which would have had a direct revenue impact but were stuck because the tech team wanted to "triage" which she didn't understand.
Sounds to me that we need a "tech-to-normal" language translator.
Triage isn't a word that came out of tech, though. It's a term from the medical field, specifically for trauma care, and effectively means prioritisation under pressure.
A product manager really should know and understand this, because it's not like it's impenetrable tech jargon. They should also be the ones making those prioritisation calls, albeit with a solid understanding of the real trade offs.
In a situation like this there can be multiple reasons for the mismatch, none of which have anything to do with needing a language translator. For instance, is the product manager trying to force through that feature without moving out the team's other work to match? If so, then they will obviously get the 'triage' demand and be forced to make a priority call.
I've seen that too often in my career, where from the PM/PO side a feature or improvement is 'obvious' but because they won't take on the political battle of moving out a team's other feature work that's less valuable they either force the team to work beyond their capacity or, if they have more backbone, to refuse outright.
Or is the team intransigent and inflexible, and trying to protect low value but more technically interesting work? Then that, too, is a problem and needs to be solved through incentive changes and other measures, because it's just as unhealthy.
> A product manager really should know and understand this, because it's not like it's impenetrable tech jargon.
It's not tech jargon but it's a medical term, that has to do with people possibly dying or wounded soldiers that can't be handled, and now we're using it in tech? Ignoring the ridiculous overexaggerating that is, this is exactly the kind of jargon that techies will get mad at managers for using.
Just say what you want. "We have other priorities, how does this fit with those, and what item will have lower priority now?"
Except that the semantic shift of triage to also meaning any under pressure prioritisation of too-scarce resources, including in a project sense, is decades-old and predates its usage in tech. This is a case of tech adopting business jargon, not the other way around.
Even if the product manager wasn't familiar with the term itself, they'd surely be familiar with the idea of prioritising incoming tasks by importance and value and moving out work with lower scores. A simple question should've allowed them to link the word and the concept in their heads. This is unlike true tech jargon, where both the word itself and the underlying concept might be completely unfamiliar to anyone outside of tech and difficult to understand.
You shouldn't have to explain prioritisation to a product manager.
Aren't PMs supposed to have an elevated communication skillset compared to ICs? I don't think it's too much to ask for a manager to know what the word "triage" means in a planning context, or to look it up. Particularly a product manager; understanding that stakeholders have multiple different priorities and navigating that situation is the essence of their job.
Perhaps we're misinterpreting and the team was just stonewalling. That happens sometimes with certain teams, sometimes it's because they're chronically understaffed. However, that's obviously no representative of the "tech" (i.e. software) role as a whole.
Triage is usually a non-tech word (QA/Customer Support normally). We need a human-to-human language translator, and it exists, it is called a question.
ICs and lower level managers are all about inputs and outputs, blocking and tackling, getting shit done.
At the higher management levels it is all about setting direction, setting the "tone", "getting the culture right".
There is just so little concerns that intersect between these groups, that communication becomes a challenge.