The leadership principle is as follows:
Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.
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.
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?
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.
Makes sense - thank you 👍
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:
#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:
For the choosing between 2 frameworks angle, these resources could help:
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.