Little Tasks, Little Trust • Hacker News Board

Re: Little Tasks, Little Trust

#91

Post by tonyarkles » Fri, Dec 11, 2020, 11:53 PM UTC

treis wrote: post #17

monkeybutton wrote: post #6

At the same time, how many of us have been burnt when delegation goes wrong? I think managers have a "fool me once shame on you, fool me twice shame on me" attitude that inevitably leads to small tasks and less delegation of responsibility after a few bad experiences with developers wandering off in the woods and building what they want and not what is needed.

The bigger problem is that if you delegate A and B to Vincent as the article suggests is that often it becomes King Vincent lord and ruler of A and B. They are the only one allowed to touch A and B, and worse may be the only one's capable of touching A and B. You can end up with a bunch of these little fiefdoms and getting anything done quickly becomes an issue of appeasing a few petty despots. That's a little bit ex…

The author has another article about that. They’re allowed to be the lord and ruler of A and B, but also responsible for them. A and B are the consistent bottleneck to release? Maybe B should belong to someone else. Petty despots don’t get to keep their toys.

Re: Little Tasks, Little Trust

#92

Post by emeraldd » Wed, Dec 16, 2020, 2:16 AM UTC

curryst wrote: post #90

emeraldd wrote: post #81

Earlier quoted context omitted.

Honestly, I've never found story pointing exercises to result in anything resembling reality. Maybe if it's a task you've already done a hundred times and everyone knows "oh it's just doing that ...". Anytime you move into creating something new, you're basically hosed. Especially if you have heterogeneous work streams in the same sprint. That just any hope of planning things that much harder.

> Honestly, I've never found story pointing exercises to result in anything resembling reality. I've never found story pointing exercises to provide anything meaningful. Goodhart's law in action; you either ignore the story points, making them useless, or you use them to estimate productivity, causing people to game them. I understand that gauging velocity and individual contributions is important, I just think story…

This is actually kind of disturbing to me... I didn't think story points were supposed to be used as this kind of metric. Linking performance to story points seems like a complete misapplication of something that is supposedly meant to help determine how much work can be put in a sprint.

Re: Little Tasks, Little Trust

#93

Post by dgreensp » Sat, Dec 19, 2020, 7:28 AM UTC

herval wrote: post #77

dgreensp wrote: post #22

The first section had me screaming, YES, YES, YES... Now I don't have to write this very article about the difference between actually trusting and empowering your engineers and giving them little tasks to do. A lot of the rest applies to big companies. However, I would change the conclusion, because the thing is, the culture of "little tasks, little trust" has taken hold even where there is no bureaucracy and no spe…

How do you make people collaborate, in a scenario like that, where each person has 1-2 projects of their own? How do you prevent these projects from becoming “niches”, and expand in complexity to take the entire time of each said developer?

The way to go about a collaboration depends on the reason for the collaboration, and why it's a better idea than not collaborating. I don't think there's a general answer to how you "make" people collaborate.

The question about project scope and resource allocation is also hard to answer in a general way, as I'm not sure why it would be harder in the world I'm suggesting.