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

41–50 of 289 posts

Re: Don't Feed the Thought Leaders

#41

Post by etempleton »

I simply call hedgehogs ideologues. These people have a lens they see the whole world through and that tints everything a single color. It is a mental short-cut.

Some people like to call these mental models or lens, and that you should add as many as possible—switch out the green lens for a red lens and see if that makes things look better. And I agree, but I think if you have to consciously make “mental models” you are probably going to struggle to think critically about what the problems are anyway.

The truth is we probably all are a hedgehog at various times without realizing it. The only solution is to be as widely read as possible so that you do not short-cut to a few ideas that may or may not fit the challenge you are trying to solve.

Re: Don't Feed the Thought Leaders

#42

Post by etaioinshrdlu »

One thing that can happen is that you have more control and say over your own work than you realize. Not in every job, but people might be expecting you to be more authoritative than you’re behaving. You don’t have to go along with your peers ideas all the time.

It takes courage to exercise this.

Re: Don't Feed the Thought Leaders

#43

Post by catillac »

This is a really good piece. I’m sorry that my comment doesn’t add that much to the discussion, but I just wanted to say that I really enjoyed reading this and seemed to confirm or put into words things I was on the periphery of thinking.

Re: Don't Feed the Thought Leaders

#44

Post by zdragnar »

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…

Back when I was struggling to develop features in overengineered hell, I commented to my friends what a breath of fresh air updating a personal site with scp was.

They all gave sighs and shudders of disgust, but then again, they had normal programming jobs, so I suppose it seemed quite backwards to them.

Re: Don't Feed the Thought Leaders

#46

Post by lostcolony »

Ozzie_osman wrote: post #5
agbell wrote: post #2

Author here, thanks for sharing this. Let me know what you think. I'm trying to connect the dots on research on expert advice and our fields 'thought-leaders'. The connection is a bit tenuous but I think contingent advice can be shown to be better than non-contingent advice. I also think people are too confident in their opinions. Also another submission here: https://news.ycombinator.com/item?id=27462255

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…

So consider the position the people asking the questions are in. They're facing a problem; they need it solved.

All of us, when we're in that position, desire a solution. I'm not sure what differentiates those who want to fully understand the whole solution space, and all the context that dictates -why- a particular solution may be the 'best' (given a specific set of tradeoffs), but certainly, whether we are like that or not, we all desire the right solution ASAP.

I'd be super interested in how you respond to those who ask such questions; do they seem interested in explaining their problem in detail? If you, rather than say "it depends", instead immediately launch into questions, are they engaged in answering them? Can you then finish with a "given what you describe, because X, Y, and Z, I think (solution) would be the best fit for you. It has the downsides of A, B, and C, but those don't apply to you", or whatever. I.e., basically change the tone to always be focusing on solving their problem, while also allowing you to inform them, rather than "it depends" which could imply "there isn't a clear-cut solution to your problem".

Re: Don't Feed the Thought Leaders

#47

Post by megameter »

agbell wrote: post #2

Author here, thanks for sharing this. Let me know what you think. I'm trying to connect the dots on research on expert advice and our fields 'thought-leaders'. The connection is a bit tenuous but I think contingent advice can be shown to be better than non-contingent advice. I also think people are too confident in their opinions. Also another submission here: https://news.ycombinator.com/item?id=27462255

There is a very similar problem in advice-giving for technical questions, the problem of "Why do you want to do that? You should do this instead." I've seen others recommend trying to ask binary yes/no questions ("I think it's like this. Yes/no?") or to turn an open-ended question, when asked, into a set of binaries rather than guess at the intent.

The property that seems to be common in addressing both is benchmark-setting. The advice of "kick the can down the road" for less productive advice is premised on knowing that it doesn't fit your success benchmarks, but not wanting the confrontation(since a hedgehog benchmark is going to boil down to a single-issue attachment). Likewise, a battery of narrow binary questions that have a definite pass/fail characteristic constructs a form of fox knowledge - it's pragmatic in how it describes the "potential shape" of the outcome, so it makes for a better holistic benchmark than asking "what's the best way to do this?"

Re: Don't Feed the Thought Leaders

#48

Post by hedora »

zdragnar wrote: post #44
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…

Back when I was struggling to develop features in overengineered hell, I commented to my friends what a breath of fresh air updating a personal site with scp was. They all gave sighs and shudders of disgust, but then again, they had normal programming jobs, so I suppose it seemed quite backwards to them.

Oh, but scp won’t update it atomically, so you should switch to a scheme that will. Then all you need to do is set cache policies correctly, coordinate with your CDN, and maybe do a staged rollout, just in case.

/s

Seriously though, rsync is your friend. :-)

Re: Don't Feed the Thought Leaders

#49

Post by jerf »

catlifeonmars wrote: post #38
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…

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.

Yeah, that's not so much a "nifty bureaucracy hack" as a core skill to completing any project. It doesn't even have to be 20 unrelated people's feedback... it's my own priorities quite often that I mercilessly stuff on the backlog. YAGNI isn't just at the micro code level, it's a core project design skill. In fact I probably YAGNI my roadmap much harder than my code since I often have a good idea that I will in fact Need It at the microlevel after decades of experience and can save some time at that level, but at the project roadmap level anything you can trim is getting the product out generating value sooner.

(Obviously one can go too far, blah blah blah. But just as with code, we have a much larger problem in practice grabbing too much from the project feature buffet than too little.)

Re: Don't Feed the Thought Leaders

#50

Post by daveevad »

catlifeonmars wrote: post #38
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…

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.

> Create an extended product roadmap and put those items at least a year off into the future “and as long as they don’t seem relevant, you can just keep pushing them into the future.”

That actually seems to me like the root cause of all the calamity in the article, a culture of lying.

Post reply on HN