Live data from Hacker News

Don't Feed the Thought Leaders

earthly.dev

31–40 of 289 posts

Re: Don't Feed the Thought Leaders

#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 down then (it's not a vital part of any platform)

* told to have this run in k8s since everything runs in k8s

* other pedantic tasks by Sys Ops who think everything is a nail and love to argue their points ad exhaustium (or worse, argue why their fav stack is the golden child)

I understand the need for standards and making sure they're followed, but there really needs to be a human element of, "is this truly needed for what I'm trying to do?". So many engineering departments are all about automation, but don't truly think through how much automation is needed, rather than a 1 size fits all approach.

I appreciate that this article comes to the conclusion that the more correct an answer will be, the more complicated it tends to be. I wish more people in decision making positions would understand this.

Re: Don't Feed the Thought Leaders

#33
post #20

Found this to be a straightforward and interesting article. Not sure I've ever seen someone connect Tetlock's research to engineering planning before; I certainly hadn't made the connection myself. I also appreciated the tip that instead of saying no to something, you can just add it to a "future work" section of lower-priority but definitely-still-very-important-i-promise-really-i-mean-it tasks and everyone will end…

From How to Talk So Kids Will Listen & Listen So Kids Will Talk (1980): > My husband and I took Jason and his older sister, Leslie, to the Museum of Natural History. We really enjoyed it, and the kids were just great. Only on the way out we had to pass a gift shop. Jason, our four-year-old, went wild over the souvenirs. Most of the stuff was overpriced, but we finally bought him a little set of rocks. Then he started…

That's a great idea. I've unwittingly used similar techniques in the past. Now that I know it's a "real thing," I may have to start using it more. Thanks for sharing this!

Re: Don't Feed the Thought Leaders

#34
post #19

The "we saw this problem at X place" always brothers me. I'm old, I could come up with endless such stories that would require epic solutions, but in not sure there would be much gain. Tell me why we will hit that issue and why we can't fix it any other way... not just the vague notion of a problem someone else had for who knows what reason... And the reason I want that level of detail is because I've failed to accur…

There’s no one as dangerous as a new hire from “X,” where “X” is a well-known/esteemed company (FAANG, etc), in their first 3 months at a new firm.

Re: Don't Feed the Thought Leaders

#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 understanding of the domain (in which you can move through pitfall areas freely and see where frameworks fall short)

Hedgehogs are at stage 2. You move from stage 1 to stage 2 by adopting frameworks; hence, hedgehogs are seen as "thought leaders" because they teach the frameworks that lead MOST people to more mastery. Except when you're at stage 3, in which case frameworks lead you to more inefficiencies compared to your own understanding.

All good decisions must be made by stage 3 persons, but ironically, training is most efficiently done by stage 2 persons. Hedgehogs get more limelight because 90% of the population is at stage 1 and values the knowledge of stage 2 (and can't grasp the complexities and nuances of stage 3).

Many hedgehogs struggle to touch stage 3, and instead see stage 2 as mastery. This is compounded by the positive feedback loops of success - the frameworks save time, it gives them reputation, it allows them to save stage 1 persons from their ignorance, and it's the foundation of their current level and achievements. Frameworks are also convenient and broadly applicable to many problems; detailed domain mastery in contrast is difficult, time consuming, and highly contextualized.

All of this makes it hard to move beyond stage 2 into stage 3.

Re: Don't Feed the Thought Leaders

#38
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…

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.

Re: Don't Feed the Thought Leaders

#39

> Preventing the raising of objections was called ‘reaching alignment.’ Sounds like they had the wrong idea of what alignment means. It should mean making sure everyone knows what problem is being solved, and focuses all feedback and concerns solely towards whether or not the project is on track to solve it. See the quote later in the article: > The problem with all the bad advice was that it was unrelated to the pro…

Hmm, maybe. If someone is making a “universal” suggestion though, I think it would be hard to “wrestle objections”. These individuals probably know all the reasons why you should do X (since that’s their go to advice). Trying to get them to drop their suggestion could possibly backfire.

So when you get a suggestion from such an individual, it seems like an attractive option just to humor them and go build what you wanted to build.

Re: Don't Feed the Thought Leaders

#40

Found this to be a straightforward and interesting article. Not sure I've ever seen someone connect Tetlock's research to engineering planning before; I certainly hadn't made the connection myself. I also appreciated the tip that instead of saying no to something, you can just add it to a "future work" section of lower-priority but definitely-still-very-important-i-promise-really-i-mean-it tasks and everyone will end…

I've done this trick fairly often. Like many "tricks" in people management, it works until people figure it out, so you have to be a little careful with it. Nobody likes to feel manipulated. However, I've found that being really open and collaborative with people helps mitigate the manipulation factor by a significant margin. In other words, you get them to agree that the project is not the highest priority or the hi…

I take it one further. "Okay, let's sit down together and write out a story that fully defines what you're asking me to do".

Half the time they won't bother. -Your- effort is free, but -their- effort has a cost.

The other half of the time they will, because they care about it, and so it goes into the backlog, and they get to see what stuff takes precedence (and it's a legitimately good faith effort on my part to see it ranked appropriately, and that they feel informed as to what is coming ahead of it and why).

Post reply on HN