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

Don't Feed the Thought Leaders

earthly.dev

Post reply on HN
Print view View original

61–70 of 289 posts

Re: Don't Feed the Thought Leaders

#61

Post by webel0 »

nradov wrote: post #8
Ozzie_osman wrote: post #5

Earlier quoted context omitted.

Great read. One thing I've found (as a person who advises engineering managers and startups) is that recipients of advice seem to value non-contingent advice more. They just want simple answers that don't make them think. When someone asks me a question like "how should I interview candidates?", my default answer is "it depends". Tell me about the role. The company. The culture. The product. Remote or in-person? What…

Do managers who accept contingent advice from you tend to produce better outcomes?

This is a good question. As much as I find them hard to stand, there are cases where having an ideologue in the back of your mind (or one on each shoulder) makes it easier to play out a situation in one’s mind.

In other words: I don’t need a rule per se, just an argument. I’ll work out the contingencies on my own.

Re: Don't Feed the Thought Leaders

#62

Post by _Nat_ »

The article defines "thought leader":

> Uncontingent advice is what I think of when I hear the term thought-leader - someone has a single solution that seems to fit every problem.

Apparently it's a reference to folks who always confidentially advocate the same go-to strategies, regardless of context.

Re: Don't Feed the Thought Leaders

#63

Post by AussieWog93 »

daveevad wrote: post #56
AndrewKemendo wrote: post #45

This is a bang on article and I would say that more people should be less confident in general. I also love his technology substitutions: springy search = Elastic Stoplang = Go IronOre = Rust BeetleDB = CockroachDB

Good decoding > That was our number one secret to scaling when I was at warble warble = google ?

I would think "Twitter" is a closer synonym.

Re: Don't Feed the Thought Leaders

#64

Post by psidebot »

daveevad wrote: post #56
AndrewKemendo wrote: post #45

This is a bang on article and I would say that more people should be less confident in general. I also love his technology substitutions: springy search = Elastic Stoplang = Go IronOre = Rust BeetleDB = CockroachDB

Good decoding > That was our number one secret to scaling when I was at warble warble = google ?

I would guess twitter

Re: Don't Feed the Thought Leaders

#66

Post by mmaunder »

These aren’t thought leaders. They’re insecure employees trying to justify their existence. You see it in most tech companies, particularly after employee 100 joins.

As a leader of an early stage high growth biz, it’s critical to prune the team as these folks emerge. It’s not a happy event, but not everyone is the perfect fit for their current role and sometimes tough changes need to be made.

Not making these changes leads to A players - the innovators who ship - having exactly the experience described in the post. And they tend to leave as a result.

Re: Don't Feed the Thought Leaders

#67

Post by anchpop »

SamBam wrote: post #58
catlifeonmars wrote: post #38

Earlier quoted context omitted.

The minor conclusion of this article was the more interesting (and perhaps more practical) of the two: Hide concessions to various leaders in the project roadmap. This isn’t just a “bureaucratic trick” as the OP suggested, it’s actually a way to convert unconditional advice into contingent advice, by encoding a priority.

> to convert unconditional advice into contingent advice, by encoding a priority This is one of the most important things I've learned as a developer, and one that I thought I invented myself, before I knew about agile, by keeping a whiteboard near my desk with yellow sticky notes ordered by property: "Yes, I get that it's a must-have feature, but where do you place it in relation to these other features?" The concep…

Sometimes, the features are really must-haves though. Let’s say it’s march 2020 and your boss wants you to design a mass-market covid vaccine. You have three requirements: it needs to be safe for human use, it needs to be effective at preventing covid, and it needs to be possible to manufacture. If any one of these is missing, your design is useless. I think a similar dynamic is visible in many software projects.

Re: Don't Feed the Thought Leaders

#68

Post by runawaybottle »

anw wrote: post #31

It's cathartic to read other people who have to go through this. I'm fighting red tape for my team as we build out a dashboard. Outlook is packed with 1–2 hour meetings for the next 3 months where so far I'm: * being asked to load test our system to make sure it can handle the load (of 3 people?) * being asked to integrate with various analytics platforms so we can alert some poor schmuck at 3 AM in case the API goes…

I’ll add to the list:

- Ceremonial unit tests for every little thing. The whole system is buggy as hell and we don’t have any confidence that the unit tests are truly covering critical parts of the app. But alas, test coverage, the god damn Pope that can never be bemoaned.

- I’m not making this one up: A/B testing for an internal enterprise app.

Re: Don't Feed the Thought Leaders

#69

Post by LegitGandalf »

closeparen wrote: post #51

My leadership is constantly pushing for “hedgehog” style advice to be depersonalized, encoded in policies, and handed over to bureaucrats or automation to enforce. Trying to empathize with their position, I think they think failure happens because the right hedgehogs didn’t show up to the design review that day, or forgot to harp on whatever point that time. They are never satisfied with the “it depends, there’s no h…

You are so right and I'm so sorry. It is truly miserable at so many companies for exactly what you wrote here:

"Software engineering is a thinking person’s game. I get that management wishes it weren’t, but it is."

Re: Don't Feed the Thought Leaders

#70

Post by username90 »

bombcar wrote: post #57
spyckie2 wrote: post #35

Being a hedgehog is useful on the journey to domain mastery because sticking to frameworks saves you time and headache compared to not having any frameworks at all. The 3 stages of domain mastery: Stage 1 - No knowledge or structure to approach a domain (everything is hard, pitfalls are everywhere) Stage 2 - Frameworks that are useful to approach the domain (Map to avoid pitfall areas) Stage 3 - Detailed understandin…

To be a good X you must follow the rules. To be a great X you must have followed the rules so well as to learn why they’re there and when they should be broken. Works for almost any X - writer, programmer, driving, etc.

To be great at X you have to write the rules.
Post reply on HN