DEV Community

Discussion on: How would you handle a conversation with someone who thinks "respecting an opinion" means "agreeing with it"?

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

I can't really add much on top of Molly's excellent comment, but I do want to say this: your manager is incorrect, and any project or workplace which equates "respect" with "being a yes-man" is not a healthy environment.

This sounds like a pattern I've seen all too often, although I'd withhold labeling it as this until you can actually point to multiple instances:

  1. Dev could be, to some extent or other, known on the team to have fragile feelings, and to react in defensive/hostile/toxic ways. This can be unintentional, perhaps a person never learning social skills, or intentional, as a way of seizing control of a project, team, or company. (I've been witness to two premeditated coups like this.)

  2. The Manager has come to consider Dev "irreplaceable", probably because of his/her technical knowledge or skill.

  3. In order to keep Dev at the company, then, Manager must use the full powers of their position to protect Dev's feelings above all else. This means Manager has to always take Dev's side.

  4. However, because #3 an inherently irrational action to take, Manager must justify it to himself/herself by equating "disagreement" with "disrespect"; because Dev has seniority, Manager can then believe that he/she is just enforcing respect of seniority, instead of what's actually going on.

  5. Reversal of authority achieved: Dev needs only complain to get Manager to do what he/she wants.

That may sound like an uncharitable assessment, but I've literally observed that exact pattern more times than I can keep track of. It's unfortunately common, especially in tech. I always handle such a recurring dynamic the same way: (1) address it quietly with the manager, (2) refuse to maintain the status quo in my own actions, and if all else fails (3) resign. The worst thing you can do for everyone, yourself included, is to normalize it.

But again: watch for a recurring pattern of behavior. Communication glitches and collaboration dynamic flaws exist in any team, and that can lead to isolated instances of behavior that looks like the preceding (but isn't). Only if this happens regularly do you need to be wary of such a dynamic as I've described.

Collapse
 
u8nc profile image
MiAn • Edited

Just quietly diarise what you can after his response:

Dev: uses Github's "suggestion" feature to suggest a code change that uses FunctionB instead of FunctionA
Me: That's not necessary here, because X and Y (link to language specification)

but don't make an assertive statement yet. You should ask " Is that necessary here ... ? "

and when things go pear-shaped down the track, refer to this out as evidence as WillSmart suggests. You will have more experience by this time, not only in code but in office relations.

Your manager needs to bear in mind that in a room of 100 people, 99 people saying X doesn't make it right. It can be that 1 person saying Y that produces a 'turnaround' that matches the buying public's perception of " well this is new" with dollars following.

But only if it is clear that Y is the right answer! Don't become an argumentative trailblazer either.

The close of your final statement is also telling: ".. to yield a more positive outcome". I think you did quite well given the above, including Jason's advice. But "outcome" is probably still in incubation, other dev's prediction might come true but in a change of manager, not language.

Just bide your time quietly.