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

figure out why, do they feel threatened or bullied? Are they headstrong? Are they trying to do something you don't get or care about? Are they actually smarter than you?

If you can adjust your behavior to compensate for what they perceive and you then want to, you can do something about it.

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

Document (preferably the whole series of incidents) and escalate. It helps if evidence is not modifiable (e.g. review comments are immutable and can't be deleted).

“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.

Tell your boss to make someone else tech lead.

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.

You describe your workplace as academically-inspired, yet experimentation and large PRs are discouraged. In you shoes, I'd double-check to make sure the "small-PRs-only" policy is in alignment with the company values before making that a real point of contention.

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."

Hard to say without more info about the relationships and company structure. It looks like this person is pushing back on your judgement with their own judgement. If you can't fall back to finding a mutual understanding then you're at battling for power. If you have the seniority you can just say "No, this is the standard that the team agreed on and we enforce, your PR is not being approved until it is fixed", and if you don't then I think you need to involve someone who is one level above you to resolve the judgement dispute.

If you're not willing or able to clash, you'll have to try find some compromises that improve the situation but make for an undesirable choice for this person. eg. In the PR example, require that large PRs require an in-person walk through.

Are any of these examples concrete/factual, or are they all exclusively opinion based?

First two of these examples may be on the religious or yak shaving end of debates, where the best practice is probably not an absolute.

1. There are code bases and PRs where coalescing many small changes into one "this changes how we do this" commit is encouraged when it's a semvar level change requiring coordinated edits to keep working, rather than a purely iterative change.

2. Most research shows universal unit test coverage is lower ROI than judicious coverage of intefaces and risks.

If many of your discussions fall in this zone, it's possible you, yourself, may be taking guidelines as too black and white.

Meanwhile ...

3. That one is just bad.

The chunk of code copied from SO is a legit legal risk for the company, not a code quality issue — you need to either revert that or escalate it quickly.

The rest of it, I’d follow Galxeagle’s advice. Lay out the standards, lay out the consequences, have empathy, do not argue with them. Humane, but firm.

> The person said things like "how would anyone find out", "what does it matter", "everyone does it"

To me, this reads as a toxic person who would try to get away with these things if they hadn't been caught, and who could lead to a massive shift in ethics and morale if allowed to proceed unchecked. That's really alarming. Imagine if a person with this attitude was in a position where they were responsible for code safeguarding PII or other sensitive data (and arguably, this may already be true, e.g. if they were to introduce a security hole in their component). It's essential that you document everything contemporaneously (or as close to that as possible), ensure the person's manager first knows your concerns in private - and if they don't take any action, give them the heads up that you'll need to escalate to your manager about potential ongoing legal risks. It will be annoying to navigate the politics, but it will be much more annoying if the wound festers.

Frankly, there's a lot of talent out there right now with great ethical compasses and experience with large codebases, and allocating headcount to a toxic person simply isn't optimal in that context. And even if you're in a situation where a dismissed team member won't be replaced e.g. due to hiring freezes... this person may very well be having a negative effect on the team. Just first make sure that they're not someone's kid... and good luck!

In the end it comes down to “don’t negotiate with terrorists”. If they disagree with the policies that’s fine, they can bring it up at a meeting. Call a meeting even, showing you’re willing to listen to their input is important. But you‘ve got to make it clear as day that there will be no going rogue if they disagree.

In the ideal world you would be their manager. Right now responsibility and accountability are separated, which is most likely causing you stress. Bring this up with your manager: tell them your plan to deal with the situation, ask for input and their backup. That way you now have a bigger mandate, and you don’t get in trouble for being tougher than you have been so far. Managing up is as important as managing down.

It might sound odd to have to lay down the law of the land, while simultaneously advising you hear them out. It isn’t. People generally want to be heard more than they want to be right. Show them you hear their concerns. Let them bring all their frustrations out. Tell them you’ll try to improve the situation for them. But also say that you cannot have somebody on the team who doesn’t abide by the policies set, and this behavior cannot continue. The content of the policies is irrelevant to that point, it’s a clear chain-of-command issue.

> 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.

I'm the most senior developer in my team. Normally I block the PR with a change request and say exactly what I want, i.e "Please commit X and Y, in a new PR" and I give exactly the commands that this developer must run. Then, after this small PR is merged, I ask the developer to rebase the huge PR with the master, and do that until the initial PR get as small as possible. If you are not the manager or not team lead, the easiest way is to lead by example, mostly by doing together. Sometimes it can be frustrating, but I'm sure I bring those stuff up when I'm negotiating my salary raises...

If this is happening consistently and the person has been told consistently but still doesn't do it, then it is time for management to step in.

If they start getting their performance reviews taken down a rung or two explicitly due to not doing what was expected of them and communicated to them (repeatedly) then they might get the message. "You didn't get a pay rise this year because you didn't do what was asked if you on <occasions>, which led to extra work for the rest of the team. This was discussed several times with you on <dates>. You can improve by following the coding standards and listening to your TL when they ask you to do something multiple times. If you don't, then we may need to think about formal pip."

Get this person off your team however you can. When the sh*t hits the fan over one of their own special exemptions (like something fails in production that should have been caught in a unit test) it will NEVER be their fault. They will point the finger at everyone else and complain about how someone else should have done something, etc. Fortunately for you, this person is probably going to leave on their own soon anyway, because they know better than everyone else how things should be done and they'll jump ship.

Short of that, manage up - tell the team manager that this person is a drag on the team by not following standards, demanding special treatment, being generally disagreeable. it hurts team morale even if the junior team members don't say so (they may not even realize it themselves, but it is a real thing).

In the shortest term, as others have said, don't engage. Pick the rules you enforce, and enforce them. Request the additional changes on the PR to meet style guidelines and don't take no for an answer. Don't get into discussions or arguments about the merits of the standards, just say "These are the standards and we're all expected to follow them." If the standards are written down (and if they're not, then they aren't really standards) then cut off any discussion on the merits of the standards with links to the written standards. Use a "chore" conventional-comment (https://conventionalcomments.org/) to indicate that it's just a thing that has to be done.

If you can, make it someone else's problem. Refer them to the standards committee or whatever senior architect is responsible for guiding the standards, and let them handle the argument.

> - 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

This one is easy to solve. Having automation or, as usual, blocking the PR with a change request and having it blocked until the necessary code get the tests needed. Again: Maybe the developer will add it, maybe you can do it in a pair programming session, or maybe you just submit the tests to the PR and lead by example. Sometimes it can be frustrating, but I'm sure to bring such proactive actions up when I'm negotiating my salary raise..

The 'large PR' issue - I've been on the 'violating' end of that, but... there are actually times when a PR touching a lot of files and making changes is called for. I got push back at the last team I was on where this was an issue, and the stated thing was "it's hard to review".

Yet... no one ever - literally - pulled down code in a PR/branch and reviewed it locally, never reviewed any tests (in 2 years I never got one question about a test as in 'you missed use case X in your tests', etc). They literally just meant "reviewing this on the screen in the github UI is hard when there's more than a handful of files - it's hard to tell where the changes are or what they effect". This is why I would also have tests and (sometimes extensive) documentation in the PR, to help a review. Never happened.

I had "large" PRs (by someone else's labelling) about 10-15% of the time. I would get pushback - "this is too much - it's too confusing".

Me: "OK... let's schedule some time to review - maybe you can help me cut it back some, or you can assist me in some way in this work?".

Others: "don't have any time for that - this is just too much work".

OK, so... complain about the work, but when I ask for help to conform to your standards... I get a refusal.

I point blank asked multiple times when this was lodged as feedback - "what steps could I take to have made this smaller?"

The only substantive thing that would have made it somewhat easier to roll out some of these "larger" changes in smaller chunks would be to have had a more comprehensive feature-flag system in place.

I put a basic flag system in over a weekend - some server side, and some hacky method to respect the flags in client side code as well. It was done over about 3 hours, and was never improved. Again - very hacky. I had an "improvement" ticket in for... about a year, begging for more than a few hours to devote to tightening up "feature flag" system to be a bit more comprehensive, documented, etc.

Every "sprint planning meeting" it was the same "there's no time for that, it's not that important, quarterly deadlines, blah blah blah". But if/when I'd do things that were 'unticketed', that was met with accusations of being passive/aggressive, or being subversive, or 'not a team player'. "If you've got time to do that, you could have been helping out people who were behind". The same people who didn't write tests or documentation, and refused to meet with me when I asked for assistance in trying to accommodate their calls for "smaller PRs".

First year on the project was good, but as it grew, policy/procedure/scrum/agile got in the way, with more process and less ability to get useful stuff done. Second year was far less productive (at least, compared to what it could have been - I'm sure some people just saw forward progress as 'good', but we were greatly slowed by more process and ceremony over time).

Bluntly, I’m not sure why this a conversation. I’m all for productive disagreements (even on small things!), but there’s not a substantive point being argued here.

Try being more blunt & concise. Instead of explaining, just say “please add unit tests and I’ll approve,” and then disengage. They’re the one who needs their PR approved - not your problem.

The key here is escalation path. He’ll have to bring it up to his manager, and then the conversation is with his manager, and then you can have a broader “he can’t just ignore every standard” conversation.

IMO of the three examples only the last one is a clear case of a company policy that can and should be followed even at the expense of productivity, and if their argument is really "how would anyone find out" you need to kick that up the management chain--this person could be putting your company at risk. For the other two your rationale is essentially "doing it the standard way makes the team more productive", but clearly comes at the cost of making this employee less productive, and your argument is empty--they are already seeking to be as productive as they think they can be. Assuming this person on net is more productive than average just assign someone else to backfill their unit tests and learn to live with the overly complex PRs.

Enforcement by means of CI is a fairly simple approach for many issues. Issues should have a minimum set of requirements including suitable testing. No colleague should approve a PR unless it ticks the necessary boxes.

Our CI does a check to see if Terraform was correctly formatted prior to push and will fail before any "init" / "plan" / "apply" step is reached.

If this is the company I think it is, privately contact opensource-licensing, or just cc them on the review.