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

121–130 of 146 posts

Re: How to Lead in a Room Full of Experts

#121

Post by BenoitEssiambre »

mrngm wrote: post #42
fladrif wrote: post #38

Earlier quoted context omitted.

What's the alternative?

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

To add to this. There's fundamental theoretical reasons why microservices or bad. They increase the entropy of code (https://benoitessiambre.com/entropy.html) by increasing globally scoped dependencies. They are the global variables or architecture. Having lots of interconnected global variables makes for an unpredictable chaotic system.

Re: How to Lead in a Room Full of Experts

#122

Post by Etheryte »

mrngm wrote: post #42
fladrif wrote: post #38

Earlier quoted context omitted.

What's the alternative?

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

This doesn't actually answer the question in any way though. Say you've already built the thing that works and then split it up, then what?

Re: How to Lead in a Room Full of Experts

#123

Post by RankingMember »

pastapliiats wrote: post #107

The author has read the audio for the article themselves?! Amazing

Nice! Sites should highlight when the audio is a real human reading it like that (By default I ignore "Listen to this article" functions on sites like this because they're almost always AI-generated weirdness).

Re: How to Lead in a Room Full of Experts

#125

Post by smrtinsert »

Aurornis wrote: post #10
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…

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…

The know it all engs were probably right though and you just added the self imposed productivity, performance, and TCO tax that everyone else adds by default

Re: How to Lead in a Room Full of Experts

#126

Post by smrtinsert »

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…

Until the cost of storage is 0, this is all still a thing.

Re: How to Lead in a Room Full of Experts

#127

Post by redbell »

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…

Unrelated: So your name is Ahmed from Tunisia living in the Capital :)

Re: How to Lead in a Room Full of Experts

#128

Post by antonvs »

ori_b wrote: post #66
oncallthrow wrote: post #59

Earlier quoted context omitted.

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.

If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something? If they're not getting the same inputs to their decisions as you are, why are you hamstringing them? And if they're not capable of understanding the inputs to their decisions, why are you keeping them around?

> If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something?

This doesn’t seem realistic to me. Division of labor also implies division of decisions. Mature individuals and teams will acknowledge when there are decisions they’re not able to make, and will refer them to the relevant teams.

An obvious example of this is legal: it hardly ever makes sense to leave a legal decision to a software developer or development team. But similar logic can apply to product management decisions, customer success, security, etc.

Re: How to Lead in a Room Full of Experts

#129

Post by [deleted] »

antonvs wrote: post #128
ori_b wrote: post #66

Earlier quoted context omitted.

If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something? If they're not getting the same inputs to their decisions as you are, why are you hamstringing them? And if they're not capable of understanding the inputs to their decisions, why are you keeping them around?

> If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something? This doesn’t seem realistic to me. Division of labor also implies division of decisions. Mature individuals and teams will acknowledge when there are decisions they’re not able to make, and will refer them to the relev…

[deleted]

Re: How to Lead in a Room Full of Experts

#130

Post by 9rx »

antonvs wrote: post #128
ori_b wrote: post #66

Earlier quoted context omitted.

If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something? If they're not getting the same inputs to their decisions as you are, why are you hamstringing them? And if they're not capable of understanding the inputs to their decisions, why are you keeping them around?

> If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something? This doesn’t seem realistic to me. Division of labor also implies division of decisions. Mature individuals and teams will acknowledge when there are decisions they’re not able to make, and will refer them to the relev…

> An obvious example of this is legal

How is that an example? Legal is just an input. A mature individual is going to heed the advice from legal, most certainly, but legal isn't making the final decision. Legal doesn't know anything about all of the other constraints, like customer need and technical need. If they did, they wouldn't be working as legal council, they'd be doing the job we're talking about.

So, we're right back at the previous comment:

- If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something?

- If they're not getting the same inputs to their decisions as you are, why are you hamstringing them?

- And if they're not capable of understanding the inputs to their decisions, why are you keeping them around?

Post reply on HN