I think small tasks can be good, but in a mix with large overall responsibilities. Some days you aren't so productive and that can be a good time to pick off a lot of small tasks, but your work starts to feel demoralizing and incoherent if you don't have a main thing (imo)
Little Tasks, Little Trust
61–70 of 93 posts
Re: Little Tasks, Little Trust
#62One thing I think missed in this is talking about one of the reasons to break things down into the smallest portion - it's not only the metrics, but it's to make everyone look the same to management. Each person can take any of the work, in theory. In practice, this never happens. You'd rather wait for the expert to do the work, because it will take them less time and probably produce better quality. Good people beco…
> Estimates given by the subject matter expert (the only one who could give an estimate) are way too small because it implies they will be doing the work.
If you play the pointing poker game you tell everyone on the team (of people who might have to work on it) to make an estimate, and if they're unsure then to estimate high. Then you can take the mean, or the highest estimate, or talk through the concerns and come to some consensus (the consensus includes things like "we need a lot more information before we can estimate" or "we need to break this up more").
If an individual is estimating the level of effort for work that could be given to any number of people then I think the estimation system needs improving.
I generally agree with the rest of your comment, though.
Re: Little Tasks, Little Trust
#63Well said but the fact remains it's easier to feign people management when attending to technical Tasks. Tracking Responsibility tends not to fit the mold of HR mandated performance accounting.
Re: Little Tasks, Little Trust
#64Worth it just for this line:
“I Vasco used to be pretty good at Microsoft Access, I guess I’ll be the database guy.”
Re: Little Tasks, Little Trust
#65I'm a software architect and how I handle this between my teams is: + Set an expectation for teams to raise difficult problems they don't know how to solve for guidance + Help teams meet and determine standards and contracts together + Make sure teams have the power to make bold choices within their own domains Sometimes these go a bit off the rails or a less optimal choice gets made and frankly... that's fine. Mista…
“Sometimes these go a bit off the rails or a less optimal choice gets made and frankly... that's fine. Mistakes are where we learn and letting engineers make mistakes and recover from them is part of letting engineers grow.”
So true. I often pity the young people who are starting now with complete micromanagement by JIRA, Scrum, daily stand up and pull requests. When I started out 30 years ago you could often go away and work on something for a month or more, try out stuff, screw up royally, learn from it and become a better programmer. These days it often feels like an assembly line where every step is optimized but no creativity is allowed. There is no better learning experience than to develop a system and after a few requirements changes to learn that the system was misdesigned. Good programmers will work through that and do better. Bad programmers will just shrug their shoulders.
Right now my strategy as a tech lead is to of ask mainly if something is holding people up, act on that quickly and be available for discussions, but otherwise I am trying to hold back and let people do their thing even if I don’t agree. But this takes strong nerves with line managers and project managers breathing down your neck.
Re: Little Tasks, Little Trust
#66This describes my most productive, successful work environments pretty accurately. I still believe in breaking down work into small tasks and estimating them, but that should be done by the individual (or small team) doing the work. Estimates also need to capture the level of uncertainty. I still believe in frequent status updates with the manager, but those should be informal and (often) initiated by the individual/…
Can you explain what happens when e.g. you need to merge your changes into product and your PR contains an unsuitable approach. For example, that you used multiple external libraries when none are needed?
Re: Little Tasks, Little Trust
#67This describes my most productive, successful work environments pretty accurately. I still believe in breaking down work into small tasks and estimating them, but that should be done by the individual (or small team) doing the work. Estimates also need to capture the level of uncertainty. I still believe in frequent status updates with the manager, but those should be informal and (often) initiated by the individual/…
Can you explain what happens when e.g. you need to merge your changes into product and your PR contains an unsuitable approach. For example, that you used multiple external libraries when none are needed?
Like in any engineering environment, you submit a PR for feedback from your peers, and you have a discussion about any changes that might need to be made.
Is there a reason why you did not think that would be the case?
Re: Little Tasks, Little Trust
#68This describes my most productive, successful work environments pretty accurately. I still believe in breaking down work into small tasks and estimating them, but that should be done by the individual (or small team) doing the work. Estimates also need to capture the level of uncertainty. I still believe in frequent status updates with the manager, but those should be informal and (often) initiated by the individual/…
> Estimates also need to capture the level of uncertainty. As a junior developer, I was asked to provide LOEs for tickets and tasks. I just looked at my boss. "How should I know?" "Come up with your best answer." So I did. I gave him my best guess, plus some error bars. The error bars were promptly discarded. And while when I went over estimates I didn't feel bad , there was obviously some static there from my boss w…
A manager who cannot deal in error bars is not doing their job correctly, although I would also point out that it is important to re-estimate and update your boss as soon as you think you will miss the estimate (which you may have done).
In my previous environment, we were only allowed to give estimates in terms of a range of time.
We had a series of predefined "buckets" of time ranges (e.g. less than a day, 1-2 days, 2-3 days, 3-5 days, 1-2 weeks, 2-3 weeks, 3-6 weeks). As the estimates got bigger, so did the error bars, and if a task didn't fit comfortably into one bucket then it was upgraded to the next.
We also had design discussions and poker planning for all of these tasks. Estimates were almost always accurate, even if they weren't very precise.
Re: Little Tasks, Little Trust
#69This essay is full of awful advice and is more about the author venting that their work isn't organized how they like. I would recommend they found a startup and experiment with the kind of structure they think would work best and see how it scales! >No backlog grooming meetings or burn-down charts either. Your manager simply looked at how your products were coming along. A little trust, some accountability, and a he…
If you are a technical lead as you claim and that's your reaction to developers' need for responsibility it tells a lot about you.
You seem like a control freak and a person who quickly puts down anyone without even considering new thoughts and opposing perspectives. Which can be completely hold against anyone who works as a consultant, because that's a red flag that the person is not cooperative enough.
Please post us your public profile so that we can avoid ever working with you.
Re: Little Tasks, Little Trust
#70One thing I think missed in this is talking about one of the reasons to break things down into the smallest portion - it's not only the metrics, but it's to make everyone look the same to management. Each person can take any of the work, in theory. In practice, this never happens. You'd rather wait for the expert to do the work, because it will take them less time and probably produce better quality. Good people beco…
> Estimates given by the subject matter expert (the only one who could give an estimate) are way too small because it implies they will be doing the work. If you play the pointing poker game you tell everyone on the team (of people who might have to work on it) to make an estimate, and if they're unsure then to estimate high. Then you can take the mean, or the highest estimate, or talk through the concerns and come t…
> If you play the pointing poker game you tell everyone on the team (of people who might have to work on it) to make an estimate, and if they're unsure then to estimate high.
I think this is great advice in general, and I try to follow what I call the Scottie rule. Multiply your estimates by 4. That way you're a miracle worker! Or if you're like me, you might finish it on time.
I think there's some ego stuff going on though in planning sessions, and it seems bad estimates are rarely punished. And you can't really learn from it, since you always think "this time it's different."