11 ms·
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"
- hizxy 4y agoYo. Ignore that shit. All this effort over nothing.
- superchroma 4y agofigure 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.
- christkv 4y agoStart a disciplinary process or it will only get worse over time.
- gsatic 4y agoTell your boss to make someone else tech lead.
- dottedmag 4y agoDocument (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).
- Galxeagle 4y ago“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.