Ask HN: How to work with people who push back forcefully?

I've worked at a large, famous software company with an academic-inspired workplace and culture for almost 8 years and been fairly successful.

Several times in that span, I've worked with people who push back quite forcefully on comments or feedback on topics or practices that have either explicit company standards or at least generally accepted best practices.

It seems to me that most people at the company are conflict-avoidant so that when these people push back aggressively, it's often a successful strategy. Ten minutes of arguing and wearing the other person down saves them 20 minutes of writing unit tests or fixing their code or whatever. I've seen in the past that these people effectively carve out an unspoken exemption for themselves because everyone is sick of having the same conversation.

I'm the tech lead but not manager of my current team and I'm responsible for the technical execution of the team and the success or failure on that level. There are a bunch of great people who do great work and are pleasant to work with but there's one person who is so unpleasant to work with. I hate that I have to constantly remind this person of company/team/professional standards and that it feels like every conversation is an argument (examples below). I hate that this is in my head on the weekend.

Questions:

- I try as much as possible to explain _why_ practices are what they are, the effects on our project, the team, etc. Any suggestions for these conversations in the future?

- I can't control this person's behavior but I can control my response. Suggestions for dealing with this personally so I'm not wasting my Sunday thinking/writing about it?

- Other thoughts or feedback?

Thank you so much in advance!

Some examples: - Sending a large PR that changes many files at once because their changes kept growing in scope as they were trying to figure out how to do something. Company has lots of guidance about small changes being easier to review, less bug-prone, etc and how to break them up. I try to emphasize the benefits for the team and codebase, the respect for the reviewer, etc. Generally get push-back like "What does it matter?", "It's already done.", "It would take too much time to break up.", "I'll do that next time", etc.

- Adding unit tests for some piece of logic. The benefits of unit tests are so fundamental, but I try to emphasize that there are many people working on the codebase, don't want to accidentally introduce bugs, protect that logic for the future, etc. Generally get push-back like Well it's so simple. It's not worth testing. I'll add a test later. etc

- On Friday, I discovered a chunk of code copied from Stackoverflow. It was crappy code, which is what caught my eye in the first place. Company has clear guidance that if you want to use outside code, we must verify the license and segregate it from owned code. (If you're curious why: it's hard to know where the SO code originally comes from, maybe copied from a closed-source project or one with GPL license or whatever, and even if it's original to SO, there is a license for that and it wouldn't be considered owned by the company). I was shocked to receive push-back on this. The person said things like "how would anyone find out", "what does it matter", "everyone does it", "it's so low risk, who cares"

Start a disciplinary process or it will only get worse over time.

“Never wrestle with a pig because you'll both get dirty and the pig likes it" - the source of disagreement here is about whether or not policy needs to be followed, not about the details of the policy, so stop trying to argue the policy on it's merits. You need to do a quick review of roles and authorities, clearly lay out (ideally mutually agreed upon) standards, and identify the implications of not following the policies - i.e 'if not xyz as agreed, then the PR won't be approved' or 'if sarcastic/bad attitudes in meetings, then I'll work with [the people manager] and create a PIP'.

Empathy is super effective in this situation - use the magic words 'it seems___' and get their reaction. 'It seems like you're trying to get as much code done as possible and see these policies as busy work'. 'it seems like you don't think the quality of the team's output is how you'll be measured'. Sometimes there is legitimate misunderstandings (were they told they need to write x lines this year to be promoted?), other times they're missing an implication and need a reality check.

It can be hard.

The key is to

1) not engage in conversation

2) add mechanical tools that fail the build if coverage isn’t enough!

A lot of times people argue that it’s stupid to have a “target” code coverage. I used to be one such person until I saw what happens when you leave it to people. Most people would still keep quality bar high, but one rotten fish spoils the pond and the tools that mechanically measure quality metrics are very effective in pushing back on bullshit like this.

Oh and whatever you do, don’t engage in debate on this. They /will/ wear you down.

IMO this person needs to come to Jesus or be fired.

> I'm the tech lead but not manager

You need to have a conversation with the manager. Document the violations of standards and company policy. The manager should review this with the problem employee, in writing, and the employee should sign an acknowledgement that the warning was received and understood.

If the employee does not improve he or she should be terminated. Such people are like cancers if they are allowed to remain unchanged.

Ideally the "large, famous" software company already has defined an HR process for managing situations like this.

If you can't get backing from the manager or the manager's manager then you need to think about whether you want to stay in a company that isn't giving you the support you need to be "responsible for the technical execution of the team and the success or failure on that level."