[HN Gopher] How to Lead in a Room Full of Experts
___________________________________________________________________
How to Lead in a Room Full of Experts
Author : jnord
Score : 224 points
Date : 2025-09-24 12:52 UTC (10 hours ago)
(HTM) web link (idiallo.com)
(TXT) w3m dump (idiallo.com)
| readthenotes1 wrote:
| 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...
| jamiecurle wrote:
| 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.
| bluGill wrote:
| Probably better to say "because it is a bikeshed not worth
| debate". Often there isn't a right answer but a decision is
| needed.
| potato3732842 wrote:
| 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".
| ahmedfromtunis wrote:
| "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.
| Aurornis wrote:
| 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.
| wahnfrieden wrote:
| You could learn from consent based decision making, a
| hallmark of sociocratic worker coops that is underrated and
| can be applied elsewhere.
|
| Hierarchy and coercion isn't necessary for avoiding decision
| paralysis in organizations. It appears to be the practical
| route but has all sorts of harmful and counterproductive
| consequences.
|
| https://www.sociocracyforall.org/consent-decision-making/
| AnimalMuppet wrote:
| Interesting. For that to work, though, it has to be true
| consent, not "it's the boss's idea and I don't dare to
| object out loud".
|
| But I guess, if that's the environment you're in, then
| you're stuck with autocratic leadership (no matter what
| label it claims for itself), and your only choice is to
| leave or not.
| wahnfrieden wrote:
| You can also try to organize your peers in those
| environments (or even from the outside if so inclined)
| cowthulhu wrote:
| I don't think that is a practical framework for situations
| where people aren't already very closely aligned. What
| happens when a few people are very vocal (and firm) in
| opposition to basically every change? Having dissenting
| views is valuable, but not when they have veto power.
| Additionally, I think that framework is vulnerable to what
| I refer to as "death by yes but" - when everyone is just
| piling on amendments and precursor conditions, oftentimes
| conflicting, that result in a decision taking months (maybe
| even years) to make or scuttle.
|
| I'm basing these comments out of experience - one example
| is a workgroup/committee operating under a similar model
| that was completely unable to do anything due to decision
| paralysis. The committee grew significantly more effective
| when we reformed the decision making process to have a
| small group of owners to handle pitching and (potentially)
| implementing the decision, then had approval be a simple
| yes/no majority vote.
| wahnfrieden wrote:
| Yes it only works when participants have a shared aim
|
| In full sociocracy, it...
|
| > honors the circle's ability to freely make decisions
| within its domain. This is key for the organization to
| remain effective. But it comes at the cost of members not
| having "consent rights" to every decision the
| organization makes. Each member will only have those
| rights for the circles they are a part of.
|
| So it's not necessary to allow people outside that
| working group to veto or require compulsory followup
| through objection
|
| There's no perfect solution to organization, everything
| is a tradeoff. I've also been part of working groups
| (made of people whose job description is to manage the
| scope of changes they're proposing) where everyone and
| the workers impacted by the decisions are in agreement
| and no impact on cost etc., but the exec decides no
| change can be made due to personal preference despite
| disastrous consequence. Or where an exec who abstains
| from checking in on a working group's efforts nonetheless
| counters it with shifting and contradictory demands
| whenever it comes time to take action, requiring going
| back to the drawing board repeatedly until people simply
| give up or leave the organization. Or where the exec asks
| for more data for a proposal, and then doesn't evaluate
| the data once gathered, leaving no recourse but to give
| up or leave the organization. We all have stories like
| this. Hierarchical organizations are also susceptible to
| paralysis.
| homeonthemtn wrote:
| It's not autocratic, it's not a form of government at all.
|
| Each role is a module to take in inputs, process them, and
| produce outputs. it is effectively a program.
|
| Define your roles, and expectations of each role, then run
| the program and edit as needed.
| DrewADesign wrote:
| Right, and some people's role is to organize people and
| orient the group's efforts by taking in big-picture
| problems and outputting direction.
|
| There's rarely a single correct answer-- lots of good
| solutions have trade-offs-- but there are often various
| wrong answers. Do the best you can to avoid the wrong
| answers, and when you inevitably run into the business
| end of one of your trade-offs, take comfort in knowing
| the other good options probably also had trade-offs, and
| tell the smug know-it-alls to cram it.
|
| People working effectively towards a non-optimal solution
| is far more useful than sitting around arguing about the
| best way to do it.
| gmfawcett wrote:
| I've often taken inspiration from RFC 2418, "IETF Working
| Group Guidelines and Procedures" [1], a rare RFC that
| defines a human protocol ("rough consensus") rather than a
| technical one.
|
| [1] https://www.rfc-editor.org/rfc/rfc2418.html
| tracerbulletx wrote:
| You can build consensus around the decision making process
| and build a culture where the outcome of that process is
| widely accepted. As long as people have the time and pathways
| to make their case and input, and understand there will be
| some verdict that may or may not align completely with their
| opinion. Then its just the decision makers duty to synthesize
| things in good faith but probably has bought themselves some
| leeway.
| brandall10 wrote:
| One thing I like to do with sr+ engineers who will feel
| burned by a decision - esp. those very publicly against it
| - is to lead with some sort of concession... maybe a
| project they expressed interest in, greenlight for a week
| to research some POC.
|
| Whatever it is, it tends to be considerably less value to
| the business than the decision itself, but it directly
| acknowledges their discontent and allows them to get
| _something_ out of the process besides platitudes,
| (perceived) public embarrassment, and frustration.
| dmos62 wrote:
| 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.
| SoftTalker wrote:
| This is what we do with juries, so there's something to be
| said for it.
| mathattack wrote:
| 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.
| hinkley wrote:
| 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.
| 9rx wrote:
| _> "I'm the lead, and we are going to do it this way"_
|
| "Okay. Let me know when you are done with that."
| roughly wrote:
| 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.
| afro88 wrote:
| 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.
| abraae wrote:
| 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.
| AznHisoka wrote:
| "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
| ori_b wrote:
| 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.
| dotancohen wrote:
| Also, to ensure that the decision made is based on logic and
| reason. Insofar as that is even possible.
| oncallthrow wrote:
| In my opinion this advice is quite fatuous, because it skips
| over the actual difficult bit, which is figuring out what to
| do when you have a problem that can't simply be decided by
| the person directly responsible for the the work, either due
| to complexity/scale of the problem, or because that person is
| not capable of making the decision.
| wavemode wrote:
| > 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.
| everdrive wrote:
| 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.
| tux3 wrote:
| There are places that have this norm, but it's exceedingly
| rare, and it's not some perfect utopia. We're all susceptible
| to emotional appeals to different degrees, and emotions
| aren't some inconvenience that you should try to eliminate in
| favor of pure cold calculations, they also have a place and a
| reason to be.
|
| People care about different things, so trying to focus just
| on facts can end up with people talking past each other,
| because they have different goals, value systems, or other
| fuzzy human feelings that can't be graphed in an Excel
| spreadsheet and compared numerically.
|
| I'm not saying that emotional appeals and sophistry are fine,
| but I find that often when people accept an emotional appeal
| over a cold purely factual argument, it's because the factual
| argument is missing the point. A more important part of the
| discussion is understanding what other people actually care
| about to make sure we're not all talking past each other, or
| spending hours arguing details that won't matter in the end.
| Herring wrote:
| You need to get a better audience. I recently met a good
| developer who still thinks Covid was a hoax. Doing my best to
| avoid him.
|
| You think you can just politely work around him -- that's how
| you get vaccine skeptics dismantling the CDC.
| floydnoel wrote:
| Why? Are they insufferable otherwise? Or is it more that you
| find it unbearable to tolerate a different opinion? I'm so
| curious, about both of you. What part does he think was a
| hoax?
| Herring wrote:
| In my experience that's usually just the tip of the
| iceberg. You've heard the expression "All happy families
| are alike; each unhappy family is unhappy in its own way"?
| It's like a link broke in a chain, and usually it's many
| links correlated. Maybe they just distrust expertise, well
| I have a phd and I assure you it'll come up later. Maybe
| he's an immigrant from Russia and he just distrusts
| everything to do with the news, well that's not really
| fixable except maybe with many years of therapy. And yes it
| will come up later too. I'm not a professional, I didn't
| want to ask the specifics or get into the weeds, I just
| have a developed nose for these things. My brother is into
| conspiracy theories.
| 9rx wrote:
| _> I have a phd and I assure you it 'll come up later._
|
| Will it? One would have to dig pretty deep into one's
| personal life to learn about that. Someone who thinks
| COVID was a hoax isn't going to be one to dig deep. And,
| well, if he really did somehow dig deep enough to find
| that information, you can just laugh it off as a hoax.
| Herring wrote:
| It's right on my linkedin, and I'm joining their team as
| a specialist/consultant.
| 9rx wrote:
| Linkedin is editable, no? Maybe he could still find it in
| a cache if he digs deep enough, but I mean, really, it is
| highly unlikely that anyone is going to put in that much
| effort unless they are on a mission. Nobody casually
| cares.
| Negitivefrags wrote:
| > Someone who thinks COVID was a hoax isn't going to be
| one to dig deep.
|
| This is kind of a side point, but people with fringe
| beliefs tend to dig a lot deeper to validate those
| opinions than those with a mainstream view.
|
| You can bet that someone who thinks that the moon landing
| was a hoax to the point that they would tell someone
| about it will know more about the moon landing than a
| random person who believes it was real.
|
| It often takes an expert in something to shoot down the
| arguments.
| DangitBobby wrote:
| It's directionally correct but not entirely accurate IMO. It
| would be more accurate to say, your audience does not have the
| experience and context necessary to turn the facts into a
| decision criteria. You need to translate your "raw data facts"
| into "refined facts" ready for consumption by the audience.
| That's what a good communicator does. The original phrasing
| makes it almost sound like the decisions are not fact-based or
| emotional, which should elicit eye-rolls.
| oncallthrow wrote:
| > It would be more accurate to say, your audience does not
| have the experience and context necessary to turn the facts
| into a decision criteria.
|
| I don't agree. Humans are fundamentally social and illogical
| creatures, and in many cases regardless of the experience or
| context they have, they will make decisions based on social
| factors regardless of hard logic.
| watwut wrote:
| I think it does deserve eye roll, because it is huge
| oversimplification on itself. The situations in which you
| convince people with facts are not exactly rare.
|
| That person is getting an eye roll, because they are just
| repeating popular phrase that is not even particularly useful.
| racl101 wrote:
| Need ethos, logos and pathos. Not just the logos.
| bilsbie wrote:
| "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.
| SoftTalker wrote:
| 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.
| gwbas1c wrote:
| That just makes you sound like a weasel and destroys your
| trust.
| illusive4080 wrote:
| It was a joke about how AI loves to tell you that you're
| right but then it regurgitates its prior plan verbatim.
| physicsguy wrote:
| > 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
| fladrif wrote:
| What's the alternative?
| moffkalast wrote:
| Macroservices, or several megaliths instead of one monolith,
| if you will.
| Rendello wrote:
| What about going the other way and Unix-piping together
| hundreds of thousands of nano-services?
| mrngm wrote:
| https://news.ycombinator.com/item?id=43925892 "Microservices
| are a tax your startup probably can't afford" (310 points,
| 263 comments).
|
| First build the thing that works, and only if it's really
| necessary, split it up in separate (networked) parts. You
| won't have to deal with unreliable network communication, or
| coordinate on a breaking API change with several teams when a
| simple search/replace on several function definitions and
| calls suffices.
| 9rx wrote:
| 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, Google, etc. You don't coordinate with
| them, you deal with what they give you. Like it or not.
|
| I expect the earlier statement confused microservices with a
| multi-process application.
| jjmarr wrote:
| A monorepo that the microservices are deployed from?
|
| Works great for Google.
|
| Or request access for the repo and make the PR yourself.
| csbrooks wrote:
| 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.
| Illniyar wrote:
| 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.
| gwbas1c wrote:
| In the aerospace world, it's called a "systems engineer."
|
| The lead:
|
| 1: Understands the _whole_ system, but not necessarily every
| detail.
|
| 2: Plans the whole project.
|
| Edit:
|
| Sometimes in the software world, the title is "architect."
|
| This is rarely the "manager," except in organizations that have
| a hard-on for hierarchy and artificial promotion for "career
| advancement." Managers are usually concerned with people,
| schedules, and resources; but don't go very deep into technical
| issues.
|
| That being said, the lead/manager may fill in for each other
| when one is on vacation, sick, quits, ect.
| kenhwang wrote:
| 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.
___________________________________________________________________
(page generated 2025-09-24 23:00 UTC)