4 ms·

If nobody steps up then it's quite likely that work never needed to get done in the first place. win-win as long as it's a learning experience for all involved

by YZF 11y ago

If nobody steps up then it's quite likely that work never needed to get done in the first place. win-win as long as it's a learning experience for all involved. It's definitely a problem if you force a team or a person into a certain pattern and then change the rules without telling. For example you may have punished someone for taking the initiative in the past and now you try to intentionally create a vacuum. In the real world there is always vacuum and always stuff people think needs to get done that doesn't really need to get done. The illusion is that the manager is omnipotent and can see all the vacuum and inefficiency. A good manager works with the team to understand those.

asgard1024 11y ago
> 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.
dingaling 11y ago
> If nobody steps up then it's quite likely that work never needed to get done in the first place. Or it's a really grotty compliance issue, requiring tedious reworking of existing code against a deadline imposed by an external authority under threat of penalty. No-one wants to work on those issues. If you screw it up, the company is fined and you're probably on a shortlist for the next RIF. If you manage to do it right under pressure and stress, the company isn't fined and you're back looking at a list of upcoming work items. Why take that on as an employee if there's an option to dodge it?
eitally 11y ago
As a reasonably experienced manager, I think holocracy can sort of work in the context of largely repeatable units of work, and areas that don't require a lot of focused independent thinking by single individuals. But if you're working on a biz dev strategy, for example, that's just not something a random employee can successfully do and by definition that means it has a dependency on the person/people who can. There are loads of functions at all medium++ sized companies like that.

by YZF 11y ago

asgard1024 11y ago

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

dingaling 11y ago

> If nobody steps up then it's quite likely that work never needed to get done in the first place. Or it's a really grotty compliance issue, requiring tedious reworking of existing code against a deadline imposed by an external authority under threat of penalty. No-one wants to work on those issues. If you screw it up, the company is fined and you're probably on a shortlist for the next RIF. If you manage to do it right under pressure and stress, the company isn't fined and you're back looking at a list of upcoming work items. Why take that on as an employee if there's an option to dodge it?

eitally 11y ago

As a reasonably experienced manager, I think holocracy can sort of work in the context of largely repeatable units of work, and areas that don't require a lot of focused independent thinking by single individuals. But if you're working on a biz dev strategy, for example, that's just not something a random employee can successfully do and by definition that means it has a dependency on the person/people who can. There are loads of functions at all medium++ sized companies like that.