back
137 comments
"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.

This is a lesson I learned the hard way. When I was a first time manager I had the naive idea that I was going to build consensus for everything and get everyone to come to an agreement naturally.

It worked at first with a good team. Then later I inherited a fragment of another team with some older know-it-all engineers who thought everything modern was garbage and we should be doing everything like they did 25 years ago. I wasted too much time letting them stonewall everything while thinking we’d eventually reach a consensus.

Then at some point you realize you have to put your foot down and pick a direction after they’ve had a chance to state their position.

It took a while to emerge but a couple years into my F50 gig we ran into a situation where we had a bus number if 3 in a domain, we all knew that solution A sounds good on paper but is a shitshow in practice, but the rest of the team was still enamored of it and our reasoned explanations just weren’t being persuasive enough.

The popular vote was going to load us up with little emergencies that were going to slow several divisions down and we ended up talking to the bosses and ignoring the vote.

In trying to smooth this over, I realized that the problem is that the people who would be dealing with the consequences of a decision wanted solution C and everyone else wanted solution A. And I think it’s something worth remembering for future indecisions, that the people with skin in the game need to be able to veto a popular vote. If you don’t want the project to lose momentum.

Generally on a large project you will have a bunch of leads all dealing with different domains, and they will reach quorum on major architectural decisions, particularly cross cutting concerns and interfaces between Conway’s Law modularizations. The boss only needs to break ties when a consensus does not emerge. And I mean NEEDS. Second worst boss I ever had refused to break ties and we had an even number of leads, so it happened half a dozen times. We wasted hours every month venting to each other about what we hated about him and one of the regular attendees just about wanted to murder him for that, and have us help him hide the body.

Steve Jobs was also known to lock teams in a room until they arrived at a common vision. It's a difficult task, to align everyone, but in my limited experience not doing it resulted in extremely inefficient execution. What's more, people feel belittled and rejected if you disregard their viewpoints. Sometimes you need to get things done regardless of what people feel or think, but you can't sustain that for a long time.
Very good point. There’s a big difference between “everyone gets heard” and “everyone gets a veto.”

Breaking ties is part of the leader’s job.

Of course if every issue requires the leader to break the tie, then perhaps there’s either a management issue, and incentive issue, or people don’t understand the strategy.

Alternatively, my preferred method: "You're the one doing the work. Tell me what your decision is."

Your job as a leader isn't necessarily to make the decision, just to be sure that the decision was made.

Make sure people understand why you're making the tradeoff you're making, and also make sure they know you're taking the fire for it if you were wrong and they were right, not them.
100%. I worked for a brilliant lead, he had a team of excellent engineers. But he was stuck on the socratic method, determined to lead by asking thoughtful questions and letting us sort it out. Important discussions would go in circles a lot, frustratingly so. Sometimes you have to be the decision maker.
“If you want to make everyone happy, don't be a leader.”

This is the most important line. You shouldnt be afraid to hurt some peoples feelings (though not intentionally and as kindly as you can of course). Absolutely nothing will get done if you want everyone to be happy

> "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.

Taking this approach with skilled people paid to think can easily be interpreted as being dictatorial and often stifles future contributions.

> Take the time to listen to everyone and to form an educated decision. Explain your conclusion once, twice and even thrice.

This implies a rigid hierarchical structure, one lacking collaboration. Again, this approach might work with assembly line workers but won't fly more than once or twice with people paid to solve problems.

> In that case, it's your duty as the leader to play the dictator and impose order.

And it will be soon your duty to find people to backfill those who have better opportunities to pursue.

> 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.

There is no "re-establishing trust with your team" when this form of "leadership" is employed. Once trust is broken, the only employees who remain are those with no better options.

There's a difference between defaulting to authority and resorting to it when needed. Consensus is great until it turns into paralysis
> "I'm the lead, and we are going to do it this way"

"Okay. Let me know when you are done with that."

Yes, and there is one trick I’ve learned instead of explicitly pulling the ‘I’m the lead’ card (which is valid, but not always the best move).

Present the decision in terms of its consequences — consequences that fall on you as the leader, not on others. You want to make clear that the accountability for the outcome rest with you and that others are "safe".

What usually happens when I do this is that the team defers to me to make the decision cause they recognize my point.

That way, you preserve alignment and authority without eroding trust, because the team sees it’s not about wielding power, but about owning the consequences no one else should or can carry.

Humans sometimes yearn for the leader to put their foot down.

The quiet ones may want the yapping voices silenced so progress can be made.

And sometimes the yapping ones get out ahead of their own skis and don't know a graceful way to back down so they're happyish to be closed down, even if they're primed to come back with an "I told you so" if the leader gets it wrong.

In my most recent role I only pulled rank twice in more than 3 years. Both times, reluctantly and deliberately. I agree you want to build a LOT of trust and legitimacy before you do this and you can still build concensus once you've dictated a direction or path. Lead, don't micro-manage.
Unrelated: So your name is Ahmed from Tunisia living in the Capital :)
Steve Jobs was an awful human being and people like him would say anything to justify their toxic behaviour. Quoting gim was the worst possible choice. You can be a leader and a decent human being. For example Gabe Newell, to name just one.
I have my claim to a minute expertise in this domain. Was assigned to lead an initiative for something that was not achieved in 3 prior attempts. I was given the 6 strongest, most genius engineers from 6 different teams. Everyone, including me, was quite opinionated and with a great explanation for their opinion. It was not an explicit credo, but I made it my position to leverage the mirror of the saying “don’t interrupt your enemy when they make a mistake”. For us it would be, “don’t interrupt your friend when they make something great” with the corollary “do something else, and make it great”. There were other important parts to that like finding the organic separation of duties and teasing or nudging directions, accepting suboptimal valleys in places, etc. But it worked, and I am as proud as I can be for being lucky. Rooms of geniuses are challenging but also such a great opportunity to learn from each other and learn how to collectively optimise the boundaries to focus on disagreement only where it makes sense.
I believe what you describe is what I have learned to be known as Servant Leadership[0]. I could be totally wrong in my interpretation of your experience and admittingly may be projecting a leadership approach I quite fancy.

Thanks for sharing your experience.

EDIT:

Removed unnecessary qualification in the last sentence.

0 - https://en.wikipedia.org/wiki/Servant_leadership

It takes real confidence (and restraint) to let strong engineers run with their ideas without feeling the need to course-correct every detail
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...

> When the product team requests a "simple" feature, I'm thinking about the 3 teams that need to be involved to update the necessary microservices.

God I hate modern web sometimes

Is the problem here the modern web? Or that this "simple" feature had its dependencies split amongst 3 microservices, instead of 1?

Seems more a system design failure to me.

What's the alternative?
There's both less and more to making decisions than ensuring they get made.

First: get others to actually decide. Jean-Louis Gassee at Apple (componentized mac's in the late 1980's) said that when dueling managers brought him a decision to make, he would always come up with a decision both of them hated, so they would scurry away and work together with an alternative they could live with.

Second: be sure to get everyone really on board - you first. This is really hard for managers who are following the wind. Law students are often careful and analytical, hedging every evaluation, but lawyers have to be assertive. Although they understand the precariousness of the legal position, it only works if you convince everyone (on your side and theirs) that this is how it will be. That transition is typically what weeds out new attorneys, and distinguishes partners from associates.

(Before you object to the attorney analogy: it's nice when you achieve collegial scientific consensus, but it can be a luxury. Then you have to figure out how to compel people do want they don't want to do, without straining authority. Usually it works to focus on picking a customer, or a definite time for results to appear; a more concrete objective/goal explains the decision and focuses follow-through.)

In my experience, you don't really want to say "I'm the lead" (it can come across insecure), but you do need to be able to confidently say "Ok, here's what we're going to do" or "Here's what I'd like you to do" once you've gathered all the relevant information and come to a decision.
At the end of the day that's the end goal of technical leadership: trust in the team ability and educated decision making
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.
Probably better to say "because it is a bikeshed not worth debate". Often there isn't a right answer but a decision is needed.
What is a lead developer in this context? An engineering manager? Is it like an architect (staff engineer/whatever)? An engineer who is in charge of a specific project?

There are different dynamics at play in each role and reading the guy's bio I'm getting the sense that he is a freelancer? or has a consulting company? which would have a whole different dynamic.

The lead developer is the person assigned to the lead developer role. I know it's cheeky but it really could be anyone. It's usually at least a senior-level individual contributor (IC). It's not uncommon for it to be a manager (that hopefully used to be an IC).

The lead's authority also tends to be varied in scope. They could be the lead of the feature, project, repo, team, initiative, or org. Depending on the context, their hierarchy might not always be the same.

So really, a lead is someone that is in or uses leadership within their scope and with others in the same position. Alternatively referred to as "politics".

In this context, they're handing the politics of development issues with the goal of getting features done.

> Leadership in technical environments isn't about being the smartest person in the room. It's about being the most effective translator.

Only if you don't make the final decision, but if you do, you better be the smartest person in the room by far. Otherwise, you're not a leader but a post turtle.

> I often get "eye rolls" when I say this to developers: You are not going to convince anyone with facts.

True in technical leadership and true in life. Engineers are especially prone to this sort of frustration, where you're technically right but socially aren't speaking the right language for your audience.

The shift from "expert with answers" to "facilitator of clarity" is something a lot of leads struggle with, especially when they get promoted because they were the smartest dev on the team
The root problem is not misunderstanding but not trusting each other. When the team implementing something says it is two weeks while the other team believes it should be just a day - in a world with full trust the second team would just accept that the first team has more expertise. But why should the teams trust each other? There is always the option that the estimation is not based on the real work required - but just an attempt to get some slack.

With translation you can show that there is a depth of arguments for that or that position - this is improving the trust.

The author has read the audio for the article themselves?! Amazing
I've been part of three software-adjacent product development teams where the Lead did exactly this and it did not go well all three times.

Having been team lead a few times myself now, I have learned that I am not there to be a field marshal. I'm there to act as a hub or conduit for all the other parts of the team. When they clash, I help resolve the conflict. When they question, I help assuage concerns. When they have ideas, I help evaluate the value of implementation. When they need resources, I approach the right people and do what I can. When they fuck up, I take the heat and rally them to help fix the problem.

It took me over a decade to learn this. I'm not the best. My name is unrecognized, for the most part, outside of some very specific circles. But I find that being part of the team rather than some imaginary demagogue to them yields consistently good results with significantly lower risk of talent loss and helps avoid over-promising/under-delivering.

The article does a nice job of pointing a few things out that I find essential in good leadership, but one thing in particular is saying "I don't know, but let's figure it out." Not only does it give your experts permission to be uncertain and helps avoid the trappings of getting defensive, as the author mentions, but it also reminds them they are not alone in this fight. That's powerful.

I'm sure many of you reading this have felt unsupported by your leaders in the past, a cog in a machine that will stress you to the point of breaking and simply replace you with another when that inevitably happens. Maybe my experience as a tech/troubleshooter colors my view here, but people, just like machines, need to be cared for if you want them to keep operating at a level that allows them to make a meaningful contribution to the team.

Thank you for the post. I was promoted to lead developer and its been year now.

I couldn't figure out my exact role and responsibility but I've been aligned with many things you mentioned in your post, that's a relief.

Coincidentally, I went through that post about "How I, a non-developer, read the tutorial" few days ago and we share the same thoughts. Hopefully am on the right direction.

“Expert” doesn’t mean much anymore. They’re more likely than not to be under the control of their employers, their funders, or even their political ideology.
"You are not going to convince anyone with facts." ... Lost me here. What kind of organization doesn't run on facts?
I thought the new way was to just say "You're absolutely right" to any objection and then rephrase your original proposal without really changing it.
It has all been described in detail over two decades ago by Michael Lopp: Managing Humans: Biting and Humorous Tales of a Software Engineering Manager
I think this nails down the job perfectly in my experience.

And the most valuable trait it's being a good translator, and not just for this job but almost anyone.

Excuse me, but I am a Tech Lead, not a people lead - now let me lead some technology, please! What in the actual ...
Apropos the impact of AI/ML on our industry - I have found that you need to treat AI like a junior dev, but also need to treat junior devs as soon-to-be senior devs.

AI is a junior dev who will do anything you tell it to, no matter how stupid.

Junior devs want to be senior devs - and we all know you do that by not doing stupid things.

I’ve brought junior devs up to senior level by having them shoulder-surf my productive interactions with AI. AI makes it much easier to become a senior dev, as should be the case. But a junior devs working alone with AI is always going to be less effective than a senior dev. Onboard human junior devs with AI and you will not just have the AI force multiplier operating in your organization, you’ll have, suddenly, a ton more senior devs.

Of course all of this depends on the humans being honest about their abilities and working to sharpen and refine their skills. AI is the lodestone upon which that can occur - it is also a blunt force instrument that will lead to loss of consciousness if you’re not careful.

The tricky part about this is, of course, that if you don’t treat AI like a junior devs and review every single thing it provides you, it will rapidly transform the senior devs to junior…

In short, it’s the humans that make the difference, even still today. AI is just another tool - and no tool is effective without proper methodology in place to prevent its weaponization against its users.

When I'm a decision maker, I tell people there are two types of conversations we could be having and it's absolutely essential that we're both clear which one we both think we're having:

1. There's a piece of information you know which, you believe, if I knew it, it would cause me to change my decision

2. We are operating from the same world of facts but if you were in my shoes, you would choose to make a different decision because of a different in priorities/values/attitude/etc.

I think "disagree and commit" has been abused to excuse a litany of absolutely heinous behaviors in tech but my most charitable interpretation of that philosophy is that if we're both in agreement that we're having conversation #2, then the only actionable steps forward are to either agree to change who the decision maker is in the moment (which should only ever be done in the rarest of circumstances) or you need to acknowledge that you've been heard, I disagree and you need to commit.

IMO, one of the more toxic but often under addressed traits for someone in the team is them wanting all of the power of a decision maker with none of the responsibility. They will spend their time endlessly dissecting how "bone headed" the choices by management are and how we're "obviously ruled by incompetents" but when asked to take on any of the mantle of responsibility to fix any of the issues they see, they instinctively shy away because they're afraid of being judged as harshly by others as they judge.

My more radical belief is that the easiest default path for any team to go down is to say that it's the leader's job to make sure everybody on the team is ok with the decision but that this is an anti-pattern and it's actually up to the subordinates to develop the emotional maturity to understand that decisions will sometimes not go their way and the course charted might be completely baffling or insane to them but if you want that never to happen, then you should be the decision maker.

But the root of making this a successful culture has to be a consistent and mature retro process which is astonishingly hard to pull off which is why it's so rare. The retro is the proper time to judge whether decision making ability is being placed in the right hands or not:

* Did the decision meet, exceed or fall short of our expectations?

* Did it fall short because something within the control of the company/team or outside of the control?

* If inside the control, was there some piece of missing information, which, when revealed in retrospect, would have changed the decision?

* Was the information obtainable at the time? Why didn't we obtain it? Are there changes to the process we should make to learn from this for next time?

The best we can hope for is not perfect decision makers, it's people who can run an effective retro process, learn from their mistakes and steadily increase the quality of their decisions over time. Inability to do that should be the primary reasons someone is removed from their decision making role.