Live data from Hacker News

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

news.ycombinator.com

41–50 of 95 posts

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

#41
What I don't hear is what you've done to understand their p.o.v. Some questions that you should have clarity on:

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.

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

#42
> Company has lots of guidance

Does this mean its an actual standard? You can fail the PR for not following standards.

> Adding unit tests for some piece of logic

Are unit tests required? Fail the PR if it doesn't have the tests. If you decide to allow a "I'll do it later", only do so if they have a ticket, assigned to them, in the backlog.

> I discovered a chunk of code copied from Stackoverflow

Now it's a problem for HR, because they're exposing the company to legal risk.

All of these items are things that should be passed to the manager every time they happen.

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

#44
Can you just reject all their changes from being pushed to production until they meet standards?

If you are the tech lead, don't you review all his changes? Just stop letting him add anything to the production code.

Give them a warning, document the constraints and say: "I am not able to add any of your contributions to the project going forward. We will be reviewing your inputs to the code on an ongoing basis. The quality of the work is unacceptable. I am not going to be arguing with you any further. Here are the standards. Anything that doesn't follow these is going to be rejected. IF you are unable to follow these, then I recommend transferring."

Then let him take a vacation and push no code and then slap him with a PIP.

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

#48

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…

> and then disengage

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.

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

#49

Earlier quoted context omitted.

I will add to this that the OP should seek out or ask their manager to find a principal/staff level engineer that can take on the individual effort of helping the renegade engineer fall in line. That may be more in line with their responsibilities than a team lead.

Aren't lead and staff basically the same thing at a lot of places?

Not at all, at least at FAANGs I was lucky enough to observe from the inside myself.

Team lead there is essentially a middle ground between the engineering manager and IC devs. Sometimes teams do with just ICs+manager, sometimes it has that TL layer in-between (usually on larger teams, either in the number of people or the scope of work). TLs can be either senior or staff engineers (only seen seniors as TLs though). Both senior and staff engineers can be either ICs or TLs.

Often, I see TL positions being either just a stop-gap for transitioning to being an engineering manager or as a lite test-drive of whether the person would actually like being in a management position (as opposed to an IC).

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

#50
post #27

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

> If many of your discussions fall in this zone, it's possible you, yourself, may be taking guidelines as too black and white. 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 t…

If you can automate the rules, do it. If you can’t automate the rules, don’t try to enforce them, just ask why.

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.

Post reply on HN