> 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

> 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.