Live data from Hacker News

How to Lead in a Room Full of Experts

idiallo.com

1–10 of 146 posts

Re: How to Lead in a Room Full of Experts

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

Re: How to Lead in a Room Full of Experts

#4

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.

Re: How to Lead in a Room Full of Experts

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

Re: How to Lead in a Room Full of Experts

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

Re: How to Lead in a Room Full of Experts

#7
post #4

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.

I like to use something along the lines of "anyone in this room is capable of handling the minutia satisfactorily, there is no need to waste time on the details".

Re: How to Lead in a Room Full of Experts

#9
post #6

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

This is a difficult lesson to swallow, but must be understood. I do still retain some frustration that there does not seem to be more effort to correct for this problem locally. For instance, in general you must speak to your audience and make emotional appeals. But me, your boss, should understand how to look past that and work with the facts, at least to the degree possible.

I don't see much of that.

Re: How to Lead in a Room Full of Experts

#10

"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 dut…

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.

Post reply on HN