I recommend _Becoming a Technical Leader_ by Weinberg for a deeper take.

The software examples are dated, but the wetware observations and advice stands.

https://www.amazon.com/Becoming-Technical-Leader-Gerald-Wein...

I love the phrase "It's because that's why". For anyone interested in this kind of subject I've benefited a lot from Vanessa Van Edwards books which essentially boil down to signalling warmth and competence in the right ways for a given context. Of course, it's a giant field and no one person has all the answers, but for me it's yielded some wins.

"I'm the lead, and we are going to do it this way": avoid it for as long as you can, but do NOT hesitate to use it when it's the appropriate answer.

Take the time to listen to everyone and to form an educated decision. Explain your conclusion once, twice and even thrice. But sometimes teams can get caught in an endless futile discussion over details that don't matter for the stated goals.

In that case, it's *your duty* as the leader to play the dictator and impose order. "If you want to make everyone happy, don't be a leader. Sell ice-cream", Steve Jobs reportedly once said.

If it happens though, don't forget to re-establish trust with your team members and make sure they understand the circumstances that led you to act in that way.