Ask HN: I get defensive when engineers critique my decisions, help | Hacker News Reader

Ask HN: I get defensive when engineers critique my decisions, help

12 pointshaburka10 comments

I tend to be the lead on projects I run and I have a lot of experience in my field, and I try very hard to make technical decisions that are well justified and correct given the constraints and conditions of the project.

Generally I’m fine when most engineers give advice or opinions but sometimes people will say things that I strongly disagree with and it seems that I need to spend time explaining why they’re wrong, which can be a bit difficult in a meeting. I find myself getting a bit overwhelmed and defensive if someone says something with a lot of conviction and it’s something I disagree with.

I would much rather be indifferent and calmly consider their perspective and come up with some kind of appreciative response but its hard to be indifferent when I know I’ll have to build the outcome of this decision.

Any advice?

View on HN

A few tips that have worked for my teams in the past (used to be an engineering manager, and what you're describing isn't uncommon): 1. Shift perspective: try to believe that everyone is trying to help, and wants what's best for the project and for you. Even if that may not always be true in every circumstance, it helps to believe that, because it makes others' input feel less attacking.

2. Change tactics: try to have some design discussions async (for e.g. by getting comments on a doc ahead of time). This gives you time to process their feedback, and the meeting can be a place to discuss it.

Ultimately the outcome may still be the same in terms of the technical decisions, but I have found perspective and tactics can affect how the team feels about them, and also creates space for good ideas you may not have considered to be heard constructively.

Hope this helps!

Its not really possible to tell from your post on how technically competent you are. You could be very technically competent and dealing with insecure engineers who will try to find any hole regardless of whether its correct or not in the hopes of making themselves look smart, OR you could be dealing with people that have experience and are trying to guide you into the right direction and you are being too defensive about.

Slow down the process.

Rather than debate live, take notes on what someone is saying. Schedule a follow up after you've prepared & better mapped out the issues.

In our architecture reviews, we try to have everyone already done their reviewing. The meeting is to go over any unresolved comments, to go through still open points, but after everyone's already raised their points. This generally has had the desired effects of reducing a lot of the chaos our tech meetings sometimes used to have.

It’s probably a therapy-addressable issue. Getting defensive or appreciating it doesn’t mean by itself you’re doing it wrong or right.

You have two conflicting inner responses here. The first is clear, “I‘ve dealt with unweighted (unjustified, stereotypical) decisions before and outcomes were bad”. The second is vague.

It may be based on some social issue like (blind guess examples ahead) fear of being viewed as incompetent, authoritarian, insecure, etc. If you find what it is, you can work on it. Objective reality — like what’s actually better or worse or if they’re right — doesn’t matter here. People who are open to advices don’t accept them blindly, they also think. The key difference is they don’t get anxious either way. You should stop getting emotional first, and only then consider genuine appreciation or rejection of their advice. Find and kill the second response, it doesn’t do any good regardless of what’s objectively correct in each particular case.

If they are stakeholders (e.g. devs that will be downstream of the decision), involve them in your decision making.

If they are non-stakeholders (e.g. another dev just poking their nose in), inform them that the decision went through a decision making process and the stakeholders have accepted it.

Explain your reasoning why you disagree, clearly, in a neutral tone, and concisely with data and example observations - if management ignores you having done so anyways and drives into walls, you can sleep easy knowing you’ve at least done your part.

The problem is not you, it's their "opinionated opinions".

Normally, the hidden rule is: If you can't prove your opinion, don't say them.

If you really need to say something, there're two strategies:

- Spoil why current approach is not good (with proof).

- Give suggestions on how to improve (with proof).

Actually, things sometimes got tricky with "proof", because it depends.

For example, code style.

Normally i always go with simple functions (instead of adding bunch of class methods). Because i found it simpler to test, debug,... The team might disagree and i just don't care much, because everyone should respect how a developer is productive.

I have a lot of technical discussions and arguments and usually do the following:

1. State the disagreement clearly and politely

2. Show the willingness to engage in as-objective-as-possible argument (in a smaller group, if feasible)

3. Always remember that ideas are produced by personalities, with all the background going with it. F.e. if I feel strongly against something but cannot effortlessly explain why, disentanglement work is on my side (in between p.1 and p.2 above).

Let me congratulate you for knowing about this issue and wanting to fix it. It’s a huge plus. My advice would be to try to find out why you get defensive. I would expect to be related to some insecurities or fears, but this is just guessing. Once you find out, it’s gonna be easier to address them.

Agree with everyone and then do what you think is right anyways.

Reply on news.ycombinator.com