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"
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 feel like you think this policy doesn't apply here. It does and we're looking for Teamwork. These policies are for the Team, skipping them disrespect everyone (not just OP)
Then PIP and boot of you have to. The bad attitude spread and bring everyone down.
> 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."
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!
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.
I have very mixed feelings about this. On the one hand, I’m no fan of following process for the sake of it.
On the other, the way to address policies that need an update is to sit down with the lead/manager and propose changes with evidence as to why.
Deciding to just do things your way and then arguing about it is not the way.
I worked at a place where 10k LoC PRs were the norm. At my next place, I’d open a 1k PR and people would lose their shit. They’d ask for it to be broken up into smaller PRs and my response was “it’s already ridiculously small”
Personally, I’d rather see the big PR and spend time reviewing that than trying to figure out what they’re trying to set up and do. As long as the big PR is coherent and well-written. If it’s spaghetti monster, I’ll pass.
The first two are fine though as long as there is room for interpretation, but if the person is pushing back every single time that’s just obnoxious.
In short, don't play loose with software licenses. The legal system has about as much interest in debating whether a company has to follow intellectual property laws as the tax collection agency does in debating whether you have to follow tax laws.
1. Why are they pushing back on it? Have you asked them what they consider up to standard? If they don't have high enough code standards and think it's OK to push crap, then there is a clear expectation gap that you should identify to them and tell them they are not meeting the bar.
2. Did they have any say in these standards? Sometimes you can turn an enemy into an asset simply by having them own a piece of the standard (and holding them accountable if that standard doesn't hold up)
3. What do they suggest in lieu? Maybe it's a stylistic thing, maybe it's a quality thing. Maybe they don't understand the difference, or maybe their impostor syndrome is making them defensive.
My summary is that you need to ask probing questions to fully understand their perspective. THis is difficult because they sound defensive, which is reasonable - your approach sounds a little like an attack due to your frustration. I can assure you they are frustrated as well!
Finally, keep in mind to set up the right context. When the light is red, stop pushing. Find a way to have an open and constructive dialog - you will have to bear that responsibility, but once you can find that, you will probably have better luck.
And document each of these steps, in email, to the person. Then when you go to leadership, you can share what you've done. If they ultimately just don't meet the bar or expectations, they should be let go.
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.
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.
Seriously, you don't owe anyone your time to have a pointless debate. Boundaries are important, as is not wasting your own time. You explain the rules, you're done, conversation over.