How to disagree with others?

Assuming there is a doc (or 1-pager) where things are being discussed, can listing out the tradeoffs, pros and cons of each approach help?

Let's say there is approach A which you want to disagree with and have an alternate proposal of an approach B which is better than A. You can drive the conversations from the data points documented on why you disagree with A and why B is a better solution. Some high level pointers I could think of:

• how A might not be as scalable and how B helps.
• how A might incur more costs to the company or how B is more efficient in this.
• how A might be adding much more complexity to the system without adding any significant value.

Having a B approach should really help see why A is inefficient. In other case, it's sometimes hard to visualize the issues with 1 approach if we don't have a relative comparison. Backing of data will make your case strong.

Moreover, setting timeline to close out on the approach may help. If there is no timeline, the discussion may go endlessly.

The main thing is to timebox it as Paras already mentioned. Set a due date and declare that "By this date, we will go with whatever the best strategy is, no questions asked".

Very senior engineers tend to love talking a lot, and if there isn't a forcing function, the discussion can easily go on forever as people's goal is to look cool and exert influence, not get anything done. By forcing a due date (you can leverage your PM and EM to further solidify it), it pushes everyone to stop beating around the bush and get to brass tacks.

On top of that, 2 tactical pieces of advice:

1. Aggregate all the discussion into a high-quality system design document - This course has a great example: [Course] System Design Masterclass: Shipping Real Features To Production
2. Hold system design meetings to force consensus - I want to make a tailored resource for this, but you can see this in the meantime (it's from the L4 -> L5 course but is applicable everywhere): https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/system-design/

It's important to remember that you'll need to be the bad guy here at least some amount. Don't be afraid to say no and push back (politely of course). If a system design meeting is veering off course, call it out and get people back on track.

Lastly, here's another excellent thread about this very topic, covering more specific tactics on how to voice disagreement: "How to maintain professionalism during disagreements?"

This is a great question. Let me start by sharing 2 ground rules of communication:

• People dislike absolutes in constructive feedback.
  • Saying things like "I wonder if your aversion is shaped by the prior work your org has done?" is a much better way of voicing a concern.
  • Think about conditioning any kind of criticism, so it's constrained to a time period or project.
• People want to feel heard.
  • Saying things like "This relates to the point you brought up earlier…" has a really powerful disarming effect on people, even if you disagree.
  • I also recommend understanding the words and terminology they use, and mirror that back. We often call something by a different name and acronym, but you can show how much you care by using the same terms.

Now to answer your question:

• There's a huge value in just being the person who presents next steps. Keeping the conversation on track (while making people feel heard) has a huge value in a heated discussion.
• Document the discussion and get buy-in 1:1 with people if you noted things down correctly. Just having a document that everyone agrees to is meaningful progress to get to resolution.

Some great related discussions:

• How to resolve conflicts between coworkers?
• How to maintain professionalism during disagreements?