3 ms·

> If nobody steps up then it's quite likely that work never needed to get done in the first place. Seriously? Consider this: You have all people tied up in wor

> If nobody steps up then it's quite likely that work never needed to get done in the first place. Seriously? Consider this: You have all people tied up in work for one month. A customer issue comes up. Who should step up to take it? Because you're not seriously suggesting it should rot there one month, do you? It's a classical coordination problem (and that's why preemptive scheduling was invented). I, as a developer, have no idea if I should step up. I would have to asses importance of all the other work that is being done by others, just to get a boolean value out of it. So everybody has to switch context to examine the issue, and the everybody's tasks to see where it fits in the grand scheme of things. Now you can say, OK, we will have priorities on things, easy. But then you actually find out that the low priority work doesn't get done at all. OK, so you start to calculate time slices, fair scheduling, all that jazz. And all of sudden everybody is forced to execute these overcomplicated scheduling algorithms and no real work gets done. It's a bureaucratic nightmare (because people are really bad at executing algorithms correctly, and have high task switching overhead), and I have seen it. While this could be sanely done by a single responsible person, project manager, who has an idea about: (1) what is the priority (and required latency) of each work item (2) how long things are going to take (estimate) (3) what are the dependencies (4) who prefers what kind of work Furthermore, if he needs any help with these points, he doesn't need to ask the whole team. Only one person can assess importance of an issue; the others do not need to care.

YZF 11y ago
> A customer issue comes up. Who should step up to take it? Because you're not seriously suggesting it should rot there one month, do you? That's why you talk to each other. Unless the team is huge than figuring out who works on something shouldn't take a long time. > the low priority work doesn't get done at all. That's great. Low priority stuff shouldn't get done ahead of high priority stuff. IMO you're over-complicating some things and over-simplifying others. There is no mythical project manager who can tell your items 1-4 in anything but the most trivial of projects. That's why almost any complex tech project I've seen managed by Gantt charts and project managers (and I've seen lots) never meets their schedule. Once you let go of the illusion that you can actually manage technology projects that way you'll find things get a lot simpler. Here's what happens in real life with your items 1-4: (1) The priority and require latency are often misjudged by the project manager. In technology project project managers often don't have the right domain knowledge to be able to judge these. So they may prioritize some feature ahead of another in a way that makes it more difficult to build the system. (2) How long things are going to take is impossible to judge in an R&D scenario. Only projects that are very similar to ones you've done in the past can be estimated with any certainty. In practice most project managers will make an estimate that fits what he's asked to deliver on because he is anchored to that. (3) Requires domain knowledge that the project manager doesn't typically have. Even individuals in the team may not have it. The team as a whole can usually figure those out by discussion. In real world projects managed by project managers dependencies are discovered when work is blocked due to them more often than predicted. (4) This is also difficult. What tends to happen is the project manager will have some thoughts about who prefers what kind of work. Sometimes they'll be wrong. People get upset. People leave. It's easier for people to work on what they like in a less tightly managed environment. A lot of this is cultural. In some cultures and for some people being self managed is extremely difficult. I've worked with people who will stress out if they're not told what to do. However, I do believe the best teams consist of people who are more self managed.

YZF 11y ago

> A customer issue comes up. Who should step up to take it? Because you're not seriously suggesting it should rot there one month, do you? That's why you talk to each other. Unless the team is huge than figuring out who works on something shouldn't take a long time. > the low priority work doesn't get done at all. That's great. Low priority stuff shouldn't get done ahead of high priority stuff. IMO you're over-complicating some things and over-simplifying others. There is no mythical project manager who can tell your items 1-4 in anything but the most trivial of projects. That's why almost any complex tech project I've seen managed by Gantt charts and project managers (and I've seen lots) never meets their schedule. Once you let go of the illusion that you can actually manage technology projects that way you'll find things get a lot simpler. Here's what happens in real life with your items 1-4: (1) The priority and require latency are often misjudged by the project manager. In technology project project managers often don't have the right domain knowledge to be able to judge these. So they may prioritize some feature ahead of another in a way that makes it more difficult to build the system. (2) How long things are going to take is impossible to judge in an R&D scenario. Only projects that are very similar to ones you've done in the past can be estimated with any certainty. In practice most project managers will make an estimate that fits what he's asked to deliver on because he is anchored to that. (3) Requires domain knowledge that the project manager doesn't typically have. Even individuals in the team may not have it. The team as a whole can usually figure those out by discussion. In real world projects managed by project managers dependencies are discovered when work is blocked due to them more often than predicted. (4) This is also difficult. What tends to happen is the project manager will have some thoughts about who prefers what kind of work. Sometimes they'll be wrong. People get upset. People leave. It's easier for people to work on what they like in a less tightly managed environment. A lot of this is cultural. In some cultures and for some people being self managed is extremely difficult. I've worked with people who will stress out if they're not told what to do. However, I do believe the best teams consist of people who are more self managed.