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

This is an anonymous post sent in by a member who does not want their name disclosed. Please be thoughtful with your responses, as these are usually tough posts to write. Email [e-mail] if you'd like to leave an anonymous comment.

This isn't meant to sound like some scenario-based interview question, though perhaps it would make a good one 😄

I want to share an experience I had earlier in 2019, and ask how you would have handled it: my approach did not go so well.

All of this happened via textual communication, so even though I'm redacting some of the details, I can still present an accurate reenactment of how it went.

---

Earlier this year, a more senior dev on my team gave me some feedback on a code review, and the short conversation went something like this:

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)

Dev: No, even if X and Y, we should avoid using FunctionA. I know the spec, but have a strong opinion on this. Please always use FunctionB, and never FunctionA: it is a well-known anti-pattern to use FunctionA.

Me: I've researched this further, and still don't agree: the anti-pattern opinion seems to come from a lack of understanding of our tools, not from any problem with this particular tool.
FunctionA seems to be best when F and G.
FunctionB seems to be best when X and Y.
Since X and Y are true, and there are no technical downsides of FunctionB over FunctionA, I prefer to use FunctionB here because it fits the situation better and communicates the situation more clearly.

Dev: Thanks for your perspective. I have more to say, but I think we're getting into the philosophy of tool use and this PR is not the right place for that. Let's agree to disagree, but please use my suggestion in this case anyways because it is a convention of this project.

Other Dev enters conversation: If it's a convention, we should look into using a tool that helps us enforce it.

Other Dev: I'd also like to point out that if the language implementation ever changes, Y might not hold true anymore, and could cause FunctionA to give unexpected results, but FunctionB would be unaffected. But it doesn't matter too much in this case.

Me: Okay, let's agree to disagree! Maybe my opinion will change as I learn more. I'll change this to FunctionB since it solves the technical problem just as well and better aligns with our team practices.

Me: That's a fair point, Other Dev, but that situation is unlikely, and if it happened I would expect us to make larger changes to the project to compensate, to avoid breaking uses of this tool.

I thought we handled that situation well by presenting our thoughts to each other and coming to a resolution quickly even though we still were not in agreement by the end. Indeed, later on we had a longer discussion elsewhere in which we each learned a thing or two. It was great 😄

I brought this up in a retrospective with my manager as an example of a positive part of the sprint, but my manager surprised me by saying something like,

This sounds to me like you didn't respect Dev and Other Dev if you still were not in agreement by the end.

I asked for clarification:

I'm not sure I understand you: do you think that respecting someone means you have to agree with them?

My manager responded:

I meant "respect" in terms of the group opinion. The fact that Other Dev supported Dev's suggestion, and both of them have more experience than you, should have been enough to convince you that the suggested path was the right one, and the disagreement should have been resolved.

This seemed like flawed reasoning to me, and I said so.

I listened to their opinions respectfully and presented my own, and in the end we came to a quick resolution despite disagreeing. I recognize that experience and popular adoption can give more weight to an opinion, but that doesn't make it right or appropriate to every situation, and there are a lot of reasons I still might not agree even if it was. I said as much in the discussion: "Maybe my opinion will change as I learn more."

My manager responded:

Would someone else please explain this to Me?

No one did, the topic was dropped, life moved on, and it didn't seem to cause any lasting tension in our working relationship.

But I still don't understand what I could have done differently to yield a more positive outcome. What do you think?

Comments

[willsmart]

IMO your personal view of what is correct, true, best-practice, an anti-pattern, etc.. in programming (as in many other parts of life) should be evidence-based, not to enable a consensus.
Your actions within a company (commits/merges/standards/etc..) should aim to find a quick consensus, but there's no obligation to personally agree with that consensus. There is an obligation to contribute as best you can to making it a good one.

I mean, change your mind because you were wrong, not because you were told to or "everyone else here does it this way". But make your actions within the company swift and social enough to avoid losing it time and money while you choose between two semi-equivalent functions within an unrelated PR.

People disagree for good reasons, there is often no right way, this is fine.

It sounds like you did the right thing (other than possibly being a bit weak with a manager that sounds like they're a bit more used to nice, friendly groupthink. I think you can get a pass for that though.)

The code is better for your input.

[Monica Macomber]

Doesn't seem that bad to me, I think you handled it well. Your manager may have some "follow orders without question" kind of thinking going on here:

both of them have more experience than you, [that] should have been enough to convince you that the suggested path was the right one

That could have been a better point to let it go. I agree that a senior dev's opinion should carry some weight but I'd disregard his advice to be convinced and stop thinking for yourself, that's a little goofy 🙃 Seniors and juniors can always learn from each other.

You had a honest discussion, listened to the senior dev and agreed to do what he asked even if wasn't your first choice. No problemo.

[José Daniel Cañizares]

Respect their opinion, without agreeing with it.

[Daniel Brady]

Yeah I think this might come across poorly 🤔 So how would you claim that a more senior dev's understanding of their tools has a gap, without making them feel undermined? (Not assuming the OP is right or wrong here, just brainstorming better ways for them to voice that feedback)

[Daniel Brady]

The "asking why" approach that others are suggesting might be good here. So instead of just stating their opinion is misguided, maybe asking Dev leading questions based on your own understanding to encourage deeper thoughts from everyone, and see if they come to the same conclusion as you.

I think any dev worth their salt should be eager to revise an opinion in the face of better understanding, but also able to articulate their position effectively to more junior devs so they can learn from you.

[Jean-Michel 🕵🏻‍♂️ Fayard]

Wow that's bad!

I have some options

• Ask: Why is this important right now for the project?. Because it's almost never important enough to justify anyone being exhausted by arguing.
• Have Backbone; Disagree and Commit (stealing this one from Matt Tyler)
• Try to make everybody read: How to Use a Code Review to Execute Someone’s Soul
• If nothing works, leave this team or this company

[leob]

100% agree, it's all about the way you communicate something. Saying "a lack of understanding" is negative phrasing, that's something to be avoided.

[leob]

I think you and the other devs (the senior and "the other dev") handled this well by concluding "Let's agree to disagree" and then moving on. The intervention by the manager was totally unnecessary. A manager's job is to facilitate and enable, not to police or to micro-manage, or to belittle juniors vis-a-vis seniors.

And yes, saying (being forced to say) "yes I agree" when in fact you don't is totally wrong, that's what they do in a dictatorship with yes-men and servants, it just ain't right.

[Monica Macomber]

See, I thought the devs' discussion went well too. I'm surprised at all the comments critiquing it 🤷‍♀️

I suppose it could have been more tactful, but tact can get in the way of clarity and clarity's important in a discussion about coding practices.

[JWP]

Get out as soon as possible. It's a toxic environment with huge egos.

[Matt Tyler]

I think what you did is a good example of one of the Amazon Leadership Principles - Disagree and Commit

Have Backbone; Disagree and Commit

Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.

amazon.jobs/en/principles

[Jason C. McDonald]

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.

[MiAn]

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.