3 ms·

I liked what my old boss did, it's quite traditional way of doing things. He gave us a long-term task/project (order of months) to work on, that would challenge

by js8 5y ago

I liked what my old boss did, it's quite traditional way of doing things. He gave us a long-term task/project (order of months) to work on, that would challenge us enough, by patiently explaining what has to be done. He gave us complete authority of how we want to do things that have to be done (the longer perspective of the work you have, the better you can get at optimizing yourself doing it). Then he made sure that we are making steady progress (about weekly, but could be shorter), and also made sure that all other external pressures go through him, so we wouldn't be distracted from that one goal too much. I think this is the best system, and I read the top comment and that's pretty similar. The article is not a particularly good advice, nor is "agile self-managing teams". IMHO management is not a rocket science, it's just people's intuitions about how to do it right are often very wrong.

yvrev 5y ago
I find this is the best for teams with competent developers. I have seen it abused however, which I guess is why micromanagement is popular in the first place.
- js8 5y ago
  From what I saw, at least 90% of the people can work like that. They don't need to be particularly competent, unless by competent you mean "show up at work and do something". It really is a very flexible system as far as complexity and hand-holding on the tasks can go. Are you really gonna worry about 10% who are unable to learn to work in such a system? At some point, you will probably have to dismiss them anyway. I think the key point is to give people enough perspective (and stick to it if possible) so it makes sense for them to learn something in a bit of depth, new skill, new module, etc. (Sometimes "code ownership" can be good too - if you know you're gonna continue working on it in the future, you might as well do a better job now.) This is what micromanagement doesn't provide, in fact, it gets you used to the expectation of the opposite - there is no need and motivation to learn and study anything a bit deeper than to just accomplish the next small task. Micromanagement is literally motivating people not to grow, and not to think for themselves.
astura 5y ago
I guess this works if you have a team of mostly jrs or are working on something truly unique. Most software doesn't have challenging work - it's mostly basic, boring, run-of-the-mill CRUD and/or API integration. Especially when you are working on a mature product. It's been years since I've worked on a project that even had tasks that would take more than a week. You also absolutely need some constraints- "do this any way you want" can lead to "resume driven development." Too much of that and your code becomes completely unmaintainable. Which I guess is usually fine if you're a startup lighting VC money on fire, but if you are developing software for paying clients then you won't be in business long.

by js8 5y ago

yvrev 5y ago

I find this is the best for teams with competent developers. I have seen it abused however, which I guess is why micromanagement is popular in the first place.

js8 5y ago
From what I saw, at least 90% of the people can work like that. They don't need to be particularly competent, unless by competent you mean "show up at work and do something". It really is a very flexible system as far as complexity and hand-holding on the tasks can go. Are you really gonna worry about 10% who are unable to learn to work in such a system? At some point, you will probably have to dismiss them anyway. I think the key point is to give people enough perspective (and stick to it if possible) so it makes sense for them to learn something in a bit of depth, new skill, new module, etc. (Sometimes "code ownership" can be good too - if you know you're gonna continue working on it in the future, you might as well do a better job now.) This is what micromanagement doesn't provide, in fact, it gets you used to the expectation of the opposite - there is no need and motivation to learn and study anything a bit deeper than to just accomplish the next small task. Micromanagement is literally motivating people not to grow, and not to think for themselves.

astura 5y ago

I guess this works if you have a team of mostly jrs or are working on something truly unique. Most software doesn't have challenging work - it's mostly basic, boring, run-of-the-mill CRUD and/or API integration. Especially when you are working on a mature product. It's been years since I've worked on a project that even had tasks that would take more than a week. You also absolutely need some constraints- "do this any way you want" can lead to "resume driven development." Too much of that and your code becomes completely unmaintainable. Which I guess is usually fine if you're a startup lighting VC money on fire, but if you are developing software for paying clients then you won't be in business long.