[aq9]

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.

[ownagefool]

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.

[saimiam]

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.

[_djo_]

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.

[tdeck]

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.

[quickthrower2]

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.

[dgellow]

One of the main role of product manager is supposed to do this translation.