“Disagree and commit” is an Amazon leadership principle. How do I do that while still maintaining my relationships?

For the choosing between 2 frameworks angle, these resources could help:

• "How do I choose between 2 technical approaches for my project?"
• System Design Masterclass: Taro Playlists

On a final note, I largely believe that Amazon's approach here is correct, but I do think there's some cases where compromising for the sake of social cohesion is worth it. The scenario I'm thinking about is when all options are equally good.

As a software engineer (especially when you're a tech lead), you need to learn how to pick your battles. Let's say there's a technical decision to be made and you deeply believe that every option is a 6/10 after all the discussion. Then I think you can "extract" some value from the situation by using it to build social capital and going with whatever has the most traction amongst your team.

You don't need a horse in every race.

I love this question! This is a great Amazon LP as it covers a very important balance great engineers must strike: Championing your principles while continuing to build bridges.

How do I stay firm in the decision while keeping others positive?

I personally love hearing other people's well-thought out ideas, especially when they're different from mine as it forces me to learn and expand my world view. Since you're at one of the best tech companies in the world at Amazon, I'm sure almost all ideas presented to you will be well-thought out and coming from talented people acting in good faith.

My advice is to channel this enthusiasm when you're participating in these discussions with conflicting ideas. My process is pretty much:

1. A teammate presents an idea I haven't heard of before
2. I say something like "Oh wow, I've never thought of it that way before..." or "That's a super creative way of looking at it!". Make sure to have welcoming and positive body language when saying this.
3. I think for a bit about how I want to incorporate the idea.
4. I then respond with 1 of the following 3 options:
   1. Respectfully disagree - Stay the course and continue having an engaging principles-oriented discussion.
   2. Agree - It turns out their idea is way better than mine, which is awesome as I got to learn something better!
   3. Compromise - Figure out a way to incorporate parts of each of our ideas into one cohesive strategy.

#2 is the most important here - The goal is to really show the appreciation and respect you have for your teammate and their perspective. When others know that you genuinely care about them as a person, everything becomes way easier!

Here's some other wonderful resources about this:

• Effective Communication Guide [Part 4] - Resolving Disagreements - This video is part of my 9-part Effective Communication series.
• "How to Maintain Professionalism During Disagreements?"
• "How to resolve conflicts between coworkers?"

Sometimes the answer is not that important, it’s about making people feel heard in the decision making process. So a good tech lead will create a process where there are clear boundaries around idea generation, debate, and decision making.

Having a clear decision maker is also important, and make sure that is broadcasted well ahead of the decision actually being made.

Finally, after the decision is made and some time has passed, do a retrospective (either group or 1:1) to ask for feedback around what could have gone better. This acknowledges that the decision was tough, but you're extending an olive branch to keep improving things.

The decision maker should ideally be the person who is going to do the actual work (the person closest to the feature). In many cases, though, if the person doing the work is junior, lacking context, or hasn't yet earned the trust of the team, the Tech Lead could make the decision.

In these scenarios, I'd make sure the feature owner is closely tracking the decision process and they feel heard by the Tech Lead, since they'll be the ones living through the consequences.

Would the decision maker always be the Tech lead (formally designated / acting) or would that be the person who is the owner for the feature related to which the decision needs to be made?

Makes sense - thank you 👍