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?
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!
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.
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 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.
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.
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).