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

91–100 of 146 posts

Re: How to Lead in a Room Full of Experts

#91

Post by cradsoit »

bruce511 wrote: post #85
atoav wrote: post #76

Earlier quoted context omitted.

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…

You can still obtain a ton of performance by minimizing the size of right things, processor caches are relatively small still. Stuff like the order of columns in a postgres database can still at worst multiply your table size

Re: How to Lead in a Room Full of Experts

#92

Post by nvegater »

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…

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.

Re: How to Lead in a Room Full of Experts

#93

Post by 9rx »

tombert wrote: post #80
9rx wrote: post #65

Earlier quoted context omitted.

> but people with fringe beliefs tend to dig a lot deeper Do they actually, though? Or do they just look for endless superficial surface claims? I mean, if they actually dug deep they're going to encounter all kinds of information that would indicate that the moon landing was real. Which, then, if they still maintain that it was a hoax in light of that then they have to believe that the deep information is also a hoa…

There is an infinite supply of people spouting bullshit and validation of that bullshit on the internet. You can spend a lifetime reading through that bullshit, and certainly feel like you're "doing research". I am utterly fascinated by the flat earth movement, not because I believe in a flat earth, but because it's so plainly idiotic and yet people will claim they've done experiments and research and dug deep, prima…

> You can spend a lifetime reading through that bullshit, and certainly feel like you're "doing research".

I'm not sure broad and deep are the same thing, but maybe we're just getting caught up in semantics?

> It's incredible.

Does anyone truly believe in a flat earth, though, or is it just an entertaining ruse? I hate to say it, but it can actually be pretty funny watching people nonsensically fall over themselves to try and prove you wrong. I get why someone would pretend.

Re: How to Lead in a Room Full of Experts

#94

Post by 7bit »

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…

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.

Re: How to Lead in a Room Full of Experts

#95

Post by al_be_back »

SoftTalker wrote: post #25
dmos62 wrote: post #14

Earlier quoted context omitted.

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 ti…

This is what we do with juries, so there's something to be said for it.

locking people in sure achieves at least one thing, but then so does adding two zeros. Jobs locked staff in, at Google when you a book meeting room, the wifi and lights cuts off at the end - a kill-switch approach [1].

personally, I think those hacks are cute and handy, but once you recruit well, reward and empower your staff, leading becomes much easier. At google, that approach probably helped more with their ESG policies than staff productivity. In Jobs' case, probably helped "him" stay focused rather than his staff, a meditation technique of sorts lol

Re: Juries. wasn't the main reason to prevent the world outside the court from influencing their decision?

[1] I think it's on How Google Works

Re: How to Lead in a Room Full of Experts

#97

Post by antonvs »

bruce511 wrote: post #85
atoav wrote: post #76

Earlier quoted context omitted.

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…

> today memory (and disk space) are abundant.

It still has a cost though, which needs to be taken into account in many situations. At our company the cost of compute, RAM, and storage are some of the biggest ongoing concerns, which can make the difference between profitability and bankruptcy, and we’ve done a lot of work on it.

Re: How to Lead in a Room Full of Experts

#98

Post by deviation »

physicsguy wrote: post #37

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

Re: How to Lead in a Room Full of Experts

#99

Post by atoav »

bruce511 wrote: post #85
atoav wrote: post #76

Earlier quoted context omitted.

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…

I was born in the 90s so memory has been plenty for me during my programmers journey. Until I started doing more embedded signal peocessing stuff.

It is good to know how to use memory efficiently, even today. But it is also important to know that if you optimize for memory usage or speed you may be paying in another dimension. And in my experience a certain type of old programmer can have a total lack of awareness that e.g. in some cases readability, maintainability, ease of use for developers, display latency etc. can be dimensions that are priorized over another for really good reasons.

The admin equivalent of that is somebody who provisions the same hard disk space for a server today as they did in the 2000s and then have the machine run out of memory on every fourth kernel upgrade. It is good to only use the necessary resources, but not if you can't/won't handle the ugly consequences that may come with it.

Re: How to Lead in a Room Full of Experts

#100

Post by physicsguy »

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.

Or even, someone leaves and you end up with a mess of maintaining multiple services that aren't coherently seperate at all, but have no time to refactor them together to make sense. That's been my experience.
Post reply on HN