2 ms·
This describes my most productive, successful work environments pretty accurately. I still believe in breaking down work into small tasks and estimating them,
by lliamander 6y ago
This 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/team.
When driven by the employees, the act of breaking down tasks, estimating, and reporting status can do a lot to build trust in the eyes of management. However, that autonomy first has to be granted by management first.
This work style isn't just for senior engineers either. The scope of responsibility should be smaller for junior engineers, but the level of autonomy over that scope should be relatively constant.
The best managers I have had hate micromanagement and generally refuse to put up with employees who require it long-term.
- eropple 6y ago> 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 when things went "over estimate". I have harbored a lot of suspicion towards the process of ticket estimation and "story pointing" and the like ever since.
- lliamander 6y agoA 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.
- eropple 6y agoI mean, I was a junior engineer. I didn't know when I was gonna miss the estimate, when you're heads-down like that you don't know if you're 25% in or 80% in until you've gotten a lot more experience. Hence the error bars in the first place. ;)
- angrais 6y agoCan 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?
- lliamander 6y agoLike 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?