Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Lead in a Room Full of Experts

idiallo.com

Post reply on HN
Print view View original

81–90 of 146 posts

Re: How to Lead in a Room Full of Experts

#81

Post by cgio »

cgio wrote: post #78
AdieuToLogic wrote: post #74

Earlier quoted context omitted.

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

Kind of, but with a different motivation at inception at least. In a perverse bike shedding variation, in a room of experts, disagreement will tend to root in bringing every matter under the lense of individual expertise. No one wins there, as before addressing the problem, the disagreements tend to focus on context. There is a certain art in giving ownership on the subject matter expertise, while drawing the lines o…

And to be honest, the real leader was not even in the room, it was the one who brought us together and threw us in a room to do it.

Re: How to Lead in a Room Full of Experts

#82

Post by delusional »

roughly wrote: post #40
ahmedfromtunis wrote: post #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 dut…

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.

I like that a lot. My favourite leaders haven't sought out my opinions much, but they made their intentions and basis clear. If I wanted to change something in their plan, I could do the work of making an argument from their basis. Most people aren't going to do the work of actually making an argument, so they get brushed aside. The few people who do bother to make an argument are the ones with a lot of conviction and motivation toovercome the new obstacles.

Re: How to Lead in a Room Full of Experts

#83

Post by shalmanese »

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.

Re: How to Lead in a Room Full of Experts

#84

Post by zby »

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.

Re: How to Lead in a Room Full of Experts

#85

Post by bruce511 »

atoav wrote: post #76
YZF wrote: post #73

Earlier quoted context omitted.

What are the odds that the older know-it-all engineer actually knows better than you? I would say they're pretty good. That's not to say that consensus always works. But it does mean the group needs to understand the objections and make decisions the team can live with. The most toxic of engineering situations is the manager making decisions without understanding consequences and without taking responsibility for the…

Chances based on my experience? 50:50 Old engineers will say things that are hard learned lessons like "don't reinvent the wheel, when your thing is running on a system that comes with wheels". So, good solid advice that rookies will ignore, because of course they do. But sometimes old engineers will say things that are more of the quality of: "30 years ago went deep into this topic, discovered the truth and haven't…

I'll second this. Unfortunately experience is a two-edged sword. I deal with a lot of old programmers and I continually hit the "fact" that was true in 1999 but is false today.

For example, I started in DOS (as did many older folk). Memory was severely constrained. So we developed habits to use memory (and disk space) very efficiently.

Like using bits in a byte, or a byte as an ID field. Or quibbling over the length of a Name field.

All those habits proved to be bad in the long run. And today memory (and disk space) are abundant. But these old habits are hard to break.

And that's before we talk about "modern" techniques, like version control etc.

Experience is great. I'm a fan. But all too often experience is also "there was a bug I windows 95, so that API call is unreliable ".

Re: How to Lead in a Room Full of Experts

#86

Post by sally_glance »

Rendello wrote: post #58
moffkalast wrote: post #39

Earlier quoted context omitted.

Macroservices, or several megaliths instead of one monolith, if you will.

What about going the other way and Unix-piping together hundreds of thousands of nano-services?

I think it's called serverless or FaaS today?

But why choose, just do all three at the same time! Actually you don't even have to choose, it will naturally happen when transitions are never fully completed... So before you know it you're stuck with a partially integrated legacy monolith which talks to a legion of half-baked microservices and emits events processed by arcane workflow engines orchestrating lambda execution.

Re: How to Lead in a Room Full of Experts

#87

Post by latentsea »

9rx wrote: post #47
fladrif wrote: post #38

Earlier quoted context omitted.

What's the alternative?

Funnily enough, microservices. In the macro economy you don't have to have such strict coordination with Microsoft, or OpenAI, or Google, or whomever you interface with. You just figure out how to make your solution work within the confines of the service they give you. Like it or not. Microservices is exactly the same concept except in the micro economy of a single organization. Each team is like Microsoft, OpenAI,…

Except you totally do wind up coordinating with them in practice when it's not google but a small team within your org.

Re: How to Lead in a Room Full of Experts

#88

Post by liquid_thyme »

AdieuToLogic wrote: post #67
ahmedfromtunis wrote: post #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 dut…

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

I've worked with engineers like this, who have a massive god-complex. If you think your job is to second guess your manager's knowledge and experience, why are you working under them? You should be working as a manager somewhere else. You are not a peer, you're part of a team reporting into a person that company has entrusted to lead the team.

Re: How to Lead in a Room Full of Experts

#89

Post by liquid_thyme »

atoav wrote: post #76
YZF wrote: post #73

Earlier quoted context omitted.

What are the odds that the older know-it-all engineer actually knows better than you? I would say they're pretty good. That's not to say that consensus always works. But it does mean the group needs to understand the objections and make decisions the team can live with. The most toxic of engineering situations is the manager making decisions without understanding consequences and without taking responsibility for the…

Chances based on my experience? 50:50 Old engineers will say things that are hard learned lessons like "don't reinvent the wheel, when your thing is running on a system that comes with wheels". So, good solid advice that rookies will ignore, because of course they do. But sometimes old engineers will say things that are more of the quality of: "30 years ago went deep into this topic, discovered the truth and haven't…

>Weigh all the pros/cons and make a choice.

This is sound advice when people agree on which column things belong to :)

Re: How to Lead in a Room Full of Experts

#90

Post by 9rx »

latentsea wrote: post #87
9rx wrote: post #47

Earlier quoted context omitted.

Funnily enough, microservices. In the macro economy you don't have to have such strict coordination with Microsoft, or OpenAI, or Google, or whomever you interface with. You just figure out how to make your solution work within the confines of the service they give you. Like it or not. Microservices is exactly the same concept except in the micro economy of a single organization. Each team is like Microsoft, OpenAI,…

Except you totally do wind up coordinating with them in practice when it's not google but a small team within your org.

Yes, in practice you very well might end up there, but then you are not providing microservices and would not call it as such. But it remains that microservices is the solution. Fair to say that it is the solution like not eating too many calories is the solution to losing weight — as in it is not exactly fun to have to put yourself through it, and thus most with the problem will never try to fix it/give up — but the solution all the same.
Post reply on HN