111–120 of 289 posts
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…
Earlier quoted context omitted.
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…
Even a small task is usually enough to filter out requests where the requestor is basically trying to move a task from their list to your list..
Earlier quoted context omitted.
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!
(If it's customers, I just write it down)
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…
I love this comment. IMHO would be perfect addition to original article
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.
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…
"Good strategy works even when you know it's coming" - something like this from "Sanctuary for all" :) One example of that was mentioned here few times: features need money. And resources and time.
But sometimes features can be crammed into project without bigger investment - just talk to devs and and often they will find a way. Sometimes it works perfectly, when overall architecture is good or extendable. And often it make total mess in codebase. But cost nothing ! ;)
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…
Leaders rarely want the nuance. 99% the answer is always "it depends" or you have to ask follow-up scoping questions. They just want to be handed a decision without the color or limitations. Sometimes that leads to future uncomfortable conversations where they assumed they would get Capability X but you only gave a "yes" or "no" because that's the preferred level of detail, leaving the rest to assumption.
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
Nice article, very relatable to my experiences. Having been on both sides of these types of discussions, I have a few thoughts: Advice isn't always unconditionally uncontingent. An infra person saying that something should probably be done in some overly specific preachy "best practice" way is sometimes thinking of things that a product person may not. For example, maybe the data guy told you to use WebScaleDB becaus…