Answer by Michael O. Church, New York-based Machine Learning/Functional Programmer, Writer, and Game Designer:
Open allocation means people choose what they work on. Valve made a poignant statement about this by putting wheels under employees' desks. (http://michaelochurch.wordpress....) At Valve, you don't apply to transfer through some ridiculous and corrupt bureaucratic machine and hope to hell the other team has "headcount" (knowing that your boss will probably fire you if the transfer falls through) as you would in most companies. You just move your desk and join another team. (Presumably, they have to agree that they want you on it, but they're not constrained by moronic "headcount" limitations.)
Open allocation is not a free-for-all. In fact, it increases individual accountability because no one has the excuse of being put on a bad project or landing under a shitty boss. If you fail to make an impact in an open-allocation shop, it's on you. You had the same opportunities to succeed as everyone else.
No one can force you do something, unless it's an existential issue for the company. On the flip side, you can't force other people to do things. If you have an idea that can add value to the firm and people will follow you, you can do it. You don't have to be a "manager" to start an initiative. If you're not ready to lead, you follow. There's no stigma associated with following (which most people will), and you're expected to follow if you're not ready to lead.
Open allocation seems too insane to work until you consider how terribly closed allocation works: unnecessary turnover, bad behavior resulting from a need for visibility amid a competitive transfer market, warring departments and teams, and extremely low motivation. Closed-allocation shops tend to operate at about 10-20% of their maximum productivity, if that.
Here are some of the benefits of open allocation. This list is far from exhaustive. For more, see this blog post: http://michaelochurch.wordpress....
1. When projects compete for people (open allocation) the result is better projects. When people compete (closed allocation) for projects, the result is worse people. Those twenty four words should be read by every CEO in the world. If a project is important to the firm (much less an existential issue), someone will want to do it, because even if the project is unpleasant, it builds credibility to be associated with important efforts. People voting with their feet is a great, effortless way to cut pointless projects.
2. People are lots (think, orders of magnitude) more effective and motivated. Software isn't commodity work where a highly motivated employee is worth 20 or 40 percent more than an average employee. It's more like 100 to 10,000 percent. The motivation bump that open allocation creates more than compensates for any concerns about "slackers" (who are uncommon). You're better off getting 200+ percent (of the average) out of your nine good employees and zero from your slacker, than 100 percent from the nine good ones and 25% from your slacker.
3. People take ownership of their work. Because people chose the work they did, they have a lot more pride invested in it. This makes "launch-and-flee" behaviors less common, and you have less of a legacy problem because, even when people move on, they're willing to spend a lunch or two helping someone get up to speed on the system they built four years ago.
4. Useless work doesn't get done. Closed-allocation shops are notorious for generating a lot of crap work that exists because managers need promotions, but not for any valid business reason, and it's bad enough that people have to do work that isn't enjoyable or important, but this produces a lot of legacy and complexity that ends up being maintained long after it has any useful value.
5. People behave better. Bad behavior begets more bad behavior; it's a karmic cycle. Managerial authority is often used for bad purposes, and no company has ever developed the tools to stop this from happening (except for eliminating said authority outright). If you take out that source of bad behavior (and of threat of like) then people are less inclined to nastiness. You'll still have people who feel like they deserved a promotion they didn't get, but in an open-allocation shop, the only thing not getting a promotion means is that you don't get a big raise that year.
6. The conflict of interest between people management and project leadership disappears. People managers can focus on providing guidance and options rather than being simultaneously responsible for (a) someone's career and personnel status, and (b) a project or group's status within the firm, a role conflict that results in a lot of bad behaviors, such as managers misleading subordinates about external possibilities or, worse yet, using negative performance reviews to keep them captive.
7. A more sensible hierarchy. "Hierarchy" isn't evil. It's how we organize information: tree structures. However, companies often create people hierarchies that make no sense, for political reasons, and the technical structure ends up mirroring the org-chart (see: Conway's Law) and therefore being extremely inefficient (especially as the company gets large). Since the personnel hierarchy is also an extremely sensitive matter in a typical corporation, it's slow to change, because few people can change it and the rest are afraid to speak the truth. On the other hand, a purely technical hierarchy of company assets and relations between them is much more impersonal and can be better optimized to keep the company's assets (code, documentation, systems) in working order.
8. Cross-hierarchical collaboration. People have a major career incentive to work with other teams, and that creates interdisciplinary knowledge and fosters creativity. This also means people are more likely to take responsibility for teaching others how to use the assets they create, resulting in better integration and more seamless products.
9. Software is generally smaller and, thus, better. Programmers write small, focused programs to solve problems and generally recognize that lines of code are a cost, not an asset. Managers, on the other hand, tend to want to create giant systems (promotion-oriented development) that the company might never need, and to favor premature abstraction on a massive scale. You get better software -- something closer to the Unix philosophy -- when it's programmers making decisions. You get legacy mudballs when managers make them and have the authority to force engineers to implement, and you get especially monstrous programs because the low productivity of the engineering staff is compensated by adding more people, creating "man-month" problems. (Many programmers who become managers lose sight of the small-program philosophy, so you can't get away from this problem by hiring ex-engineers as managers.)
10. You're less likely to fire good people... Closed-allocation shops have an unnecessarily competitive transfer market, because people are afraid to use up "headcount" on unproven people or people with average review histories, even though they'd normally be happy to take them on. The result of this is that no-fault lack-of-fit between an employee and the first manager, team, or project is likely to lead either to termination or stagnation (which are fast and slow varieties of the same thing).
11. ... and more likely to keep them. Right now, open allocation is rare. I hope that won't always be the case, but for now, it is. This makes it a huge advantage in retention. Once people experience an open-allocation shop, as long as they're paid a fair salary, they're not going to be likely to leave.
There are three problems with open allocation:
1. Companies have to pay for important but uninteresting work. Since no one can manage from authority, the company has to create genuine rewards (promotions, bonuses) for doing unpleasant work. It's a true market solution. This is more expensive than just threatening to fire them if they don't do it, but the upside is that the work is actually likely to get done well, which almost never happens in a closed-allocation shop.
2. It's harder to recruit executives. A lot of corporate executives are arrogant and authoritarian and less amenable to working at a company where they can't just force employees to drop everything and follow orders. I would, however, say that it's best not to hire them. I'd make the counter-argument that open allocation is a good way to hire good execs. Google (which once was very close to open allocation for engineers) was a great company destroyed by externally-hired executives. If Google had made open-allocation an inflexible pillar, it probably wouldn't have taken on so many bad execs.
3. It's harder to fire people. Generally, an open-allocation shop is only going to fire someone if they're pretty sure that the employee won't fit with any of the existing groups, which means it takes a few months to get rid of objective underperformers. On the other hand, I think this is a minor drawback when you consider the enhanced performance of the rest. In fact, I would say the difference between open and closed allocation is that, although open allocation makes it slightly harder to spot and fire underperformers, closed-allocation creates underperformers who then have to be fired. So open allocation wins yet again.
This question originally appeared on Quora. More questions on Software Engineering:
