Tech companies: open allocation is your only real option.

I wrote, about a month ago, about Valve’s policy of allowing employees to transfer freely within the company, symbolized by placing wheels under the desk (thereby creating a physical marker of their superior corporate culture that makes traditional tech perks look like toys) and expecting employees to self-organize. I’ve taken to calling this seemingly radical notion open allocation— employees have free rein to work on projects as they choose, without asking for permission or formal allocation– and I’m convinced that, despite seeming radical, open allocation is the only thing that actually works in software. There’s one exception. Some degree of closed allocation is probably necessary in the financial industry because of information barriers (mandated by regulators) and this might be why getting the best people to stay in finance is so expensive. It costs that much to keep good people in a company where open allocation isn’t the norm, and where the workflow is so explicitly directed and constrained by the “P&L” and by justifiable risk aversion. If you can afford to give engineers 20 to 40 percent raises every year and thereby compete with high-frequency-trading (HFT) hedge funds, you might be able to retain talent under closed allocation. If not, read on.

Closed allocation doesn’t work. What do I mean by “doesn’t work”? I mean that, as things currently go in the software industry, most projects fail. Either they don’t deliver any business value, or they deliver too little, or they deliver some value but exert long-term costs as legacy vampires. Most people also dislike their assigned projects and put minimal or even negative productivity into them. Good software is exceedingly rare, and not because software engineers are incompetent, but because when they’re micromanaged, they stop caring. Closed allocation and micromanagement provide an excuse for failure: I was on a shitty project with no upside. I was set up to fail. Open allocation blows that away: a person who has a low impact because he works on bad projects is making bad choices and has only himself to blame.

Closed allocation is the norm in software, and doesn’t necessarily entail micromanagement, but it creates the possibility for it, because of the extreme advantage it gives managers over engineers. An engineer’s power under closed allocation is minimal: his one bit of leverage is to change jobs, and that almost always entails changing companies. In a closed-allocation shop, project importance is determined prima facie by executives long before the first line of code is written, and formalized in magic numbers called “headcount” (even the word is medieval, so I wonder if people piss at the table, at these meetings, in order to show rank) that represent the hiring authority (read: political strength) of various internal factions. The intention of headcount numbers is supposed to be to prevent reckless hiring by the company on the whole, and that’s an important purpose, but their actual effect is to make internal mobility difficult, because most teams would rather save their headcount for possible “dream hires” who might apply from outside in the future, rather than risk a spot on an engineer with an average performance review history (which is what most engineers will have). Headcount bullshit makes it nearly impossible to transfer unless (a) someone likes you on a personal basis, or (b) you have a 90th-percentile performance review history (in which case you don’t need a transfer). Macroscopic hiring policies (limits, and sometimes freezes) are necessary to prevent the company from over-hiring, but internal headcount limits are one of the worst ideas ever. If people want to move, and the leads of those projects deem them qualified, there’s no reason not to allow this. It’s good for the engineers and for the projects that have more motivated people working on them.

When open allocation is in play, projects compete for engineers, and the result is better projects. When closed allocation is in force, engineers compete for projects, and the result is worse engineers. 

When you manage people like children, that’s what they become. Traditional, 20th-century management (so-called “Theory X”) is based on the principle that people are lazy and need to be intimidated into working hard, and that they’re unethical and need to be terrified of the consequences of stealing from the company, with a definition of “stealing” that includes “poaching” clients and talent, education on company time, and putting their career goals over the company’s objectives. In this mentality, the only way to get something decent out of a worker is to scare him by threatening to turn off his income– suddenly and without appeal. Micromanagement and Theory X are what I call the Aztec Syndrome: the belief in many companies that if there isn’t a continual indulgence in sacrifice and suffering, the sun will stop rising.

Psychologists have spent decades trying to answer the question, “Why does work suck?” The answer might be surprising. People aren’t lazy, and they like to work. Most people do not dislike the activity of working, but dislike the subordinate context (and closed allocation is all about subordination). For example, peoples’ minute-by-minute self-reported happiness tends to drop precipitously when they arrive at the office, and rise when they leave it, but it improves once they start actually working. They’re happier not to be at an office, but if they’re in an office, they’re much happier when working than when idle. (That’s why workplace “goofing off” is such a terrible idea; it does nothing for office stress and it lengthens the day.) People like work. It’s part of who we are. What they don’t like, and what enervates them, is the subordinate context and the culturally ingrained intimidation. This suggests the so-called “Theory Y” school of management, which is that people are intrinsically motivated to work hard and do good things, and that management’s role is to remove obstacles.

Closed allocation is all about intimidation: if you don’t have this project, you don’t have a job. Tight headcount policies and lockout periods make internal mobility extraordinarily difficult– much harder than getting hired at another company. The problem is that intimidation doesn’t produce creativity and it erodes peoples’ sense of ethics (when people are under duress, they feel less responsible for what they are doing). It also provides the wrong motivation: the goal becomes to avoid getting fired, rather than to produce excellent work.

Also, if the only way a company can motivate people to do a project is to threaten to turn off a person’s income, that company should really question whether that project’s worth doing at all.

Open allocation is not the same thing as “20% time”, and it isn’t a “free-for-all”. Open allocation does not mean “everyone gets to do what they want”. A better way to represent it is: “Lead, follow, or get out of the way” (and “get out of the way” means “leave the company”). To lead, you have to demonstrate that your product is of value to the business, and convince enough of your colleagues to join your project that it has enough effort behind it to succeed. If your project isn’t interesting and doesn’t have business value, you won’t be able to convince colleagues to bet their careers on it and the project won’t happen. This requires strong interpersonal skills and creativity. Your colleagues decide, voting with their feet, if you’re a leader, not “management”. If you aren’t able to lead, then you follow, until you have the skill and credibility to lead your own project. There should be no shame in following; that’s what most people will have to do, especially when starting out.

“20% time” (or hack days) should be exist as well, but that’s not what I’m talking about. Under open allocation, people are still expected to show that they’ve served the needs of the business during their “80% time”. Productivity standards are still set by the projects, but employees choose which projects (and sets of standards) they want to pursue. Employees unable to meet the standards of one project must find another one. 20% time is more open, because it entails permission to fail. If you want to do a small project with potentially high impact, or to prove that you have the ability to lead by starting a skunk-works project, or volunteer, take courses, or attend conferences on company time, that’s what it’s for. During their “80% time”, people are still expected to lead or follow on a project with some degree of sanction. They can’t just “do whatever they want”.

Four types of projects. The obvious question that open allocation raises is, “Who does the scut work?” The answer is simple: people do it if they will get promoted, formally or informally, for doing it, or if their project directly relies on it. In other words, the important but unpleasant work gets done, by people who volunteer to do it. I want to emphasize “gets done”. Under closed allocation, a lot of the unpleasant stuff never really gets done well, especially if unsexy projects don’t lead to promotions, because people are investing most of their energy into figuring out how to get to better projects. The roaches are swept under the carpet, and people plan their blame strategies months in advance.

If we classify projects into four categories by important vs. unimportant, and interesting vs. unpleasant, we can assess what happens under open allocation. Important and interesting projects are never hard to staff. Unimportant but interesting projects are for 20% time; they might succeed, and become important later, but they aren’t seen as critical until they’re proven to have real business value, so people are allowed to work on them but are strongly encouraged to also find and concentrate on work that’s important to the business. Important but unpleasant projects are rewarded with bonuses, promotions, and the increased credibility accorded to those who do undesirable but critical work. These bonuses should be substantial (six and occasionally even seven figures for critical legacy rescues); if the project is actually important, it’s worth it to actually pay. If it’s not, then don’t spend the money. Unimportant and unpleasant projects, under open allocation, don’t get done. That’s how it should be. This is the class of undesirable, “death march” projects that closed-allocation nurtures (they never go away, because to suggest they aren’t worth doing is an affront to the manager that sponsors them and a career-ending move) but that open allocation eliminates. Under open allocation, people who transfer away from these death marches aren’t “deserters”. It’s management’s fault if, out of a whole company, no one wants to work on the project. Either the project’s not important, or they didn’t provide enough enticement.

Closed allocation is irreducibly political. Compare two meanings of the three-word phrase, “I’m on it”. In an open-allocation shop, “I’m on it” is a promise to complete a task, or at least to try to do it. It means, “I’ve got this.” In a closed-allocation shop, “I’m on it” means “political forces outside of my control require me to work only on this project.”

People complain about the politics at their closed-allocation jobs, but they shouldn’t, because it’s inevitable that politics will eclipse the matter of actually getting work done. It happens every time, like clockwork. The metagame becomes a million times more important than actually sharpening pencils or writing code. If you have closed allocation, you’ll have a political rat’s nest. There’s no way to avoid it. In closed allocation, the stakes of project allocation are so high that people are going to calculate every move based on future mobility. Hence, politics. What tends to happen is that a four-class system emerges, resulting from the four categories of work that I developed above. The most established engineers, who have the autonomy and leverage to demand the best projects, end up in the “interesting and important” category. They get good projects the old-fashioned way: proving that they’re valuable to the company, then threatening to leave if they aren’t reassigned. Engineers who are looking for promotions into managerial roles tend to take on the unpleasant but important work, and attempt to coerce new and captive employees into doing the legwork. The upper-middle class of engineers can take the interesting but unimportant work, but it tends to slow their careers if they intend to stay at the same company (they learn a lot, but they don’t build internal credibility). The majority and the rest, who have no significant authority over what they work on, get a mix, but a lot of them get stuck with the uninteresting, unimportant work (and closed-allocation shops generate tons of that stuff) that exists for reasons rooted in managerial politics.

What are the problems with open allocation? The main issue with open allocation is that it seems harder to manage, because it requires managers to actively motivate people to do the important but unpleasant work. In closed allocation, people are told to do work “because I said so”. Either they do it, or they quit, or they get fired. It’s binary, which seems simple. There’s no appeal process when people fail projects or projects fail people– and no one ever knows which happened– and extra-hierarchical collaboration is “trimmed”, and efforts can be tracked by people who think a single spreadsheet can capture everything important about what is happening in the company. Closed-allocation shops have hierarchy and clear chains of command, and single-points-of-failure (because a person can be fired from a whole company for disagreeing with one manager) out the proverbial wazoo. They’re Soviet-style command economies that somehow ended up being implemented within supposedly “capitalist” companies, but they “appear” simple to manage, and that’s why they’re popular. The problem with closed allocation policies is that they lead to enormous project failure rates, inefficient allocation of time, talent bleeds, and unnecessary terminations. In the long term, all of this unplanned and surprising garbage work makes the manager’s job harder, more complex, and worse. When assessing the problems associated with open allocation (such as increased managerial complexity) it’s important to consider that the alternative is much worse.

How do you do it? The challenging part of open allocation is enticing people to do unpleasant projects. There needs to be a reward. Make the bounty too high, and people come in with the wrong motivations (capturing the outsized reward, rather than getting a fair reward while helping the company) and the perverse incentives can even lead to “rat farming” (creating messes in the hopes of being asked to repair them at a premium). Make it too low, and no one will do it, because no one wise likes a company well enough to risk her own career on a loser project (and part of what makes a bad project bad is that, absent recognition, it’s career-negative to do undesirable work). Make the reward too monetary and it looks bad on the balance sheet, and gossip is a risk: people will talk if they find out a 27-year-old was paid $800,00o in stock options (note: there had better be vesting applied) even if it’s justified in light of the legacy dragon being slain. Make it too career-focused and you have people getting promotions they might not deserve, because doing unpleasant work doesn’t necessarily give a person technical authority in all areas. It’s hard to get the carrot right. The appeal of closed allocation is that the stick is a much simpler tool: do this shit or I’ll fire you.

The project has to be “packaged”. It can’t be all unpleasant and menial work, and it needs to be structured to involve some of the leadership and architectural tasks necessary for the person completing it to actually deserve the promised promotion. It’s not “we’ll promote you because you did something grungy” but “if you can get together a team to do this, you’ll all get big bonuses, and you’ll get a promotion for leading it.” Management also needs to have technical insight on hand in order to do this: rather than doing grunt work as a recurring cost, kill it forever with automation.

An important notion in all this is that of a committed project. Effectively, this is what the executives should create if they spot a quantum of work that the business needs but that is difficult and does not seem to be enjoyable in the estimation of the engineers. These shouldn’t be created lightly. Substantial cash and stock bonuses (vested, over the expected duration of the project) and promotions are associated with completing these projects, and if more than 25% of the workload is committed projects, something’s being done wrong. A committed project offers high visibility (it’s damn important; we need this thing) and graduation into a leadership role. No one is “assigned” to a committed project. People “step up” and work on them because of the rewards. If you agree to work on a committed project, you’re expected to make a good-faith effort to see it through for an agreed-upon period of time (typically, a year). You do it no matter how bad it gets (unless you’re incapable) because that’s what leadership is. You should not “flake out” because you get bored. Your reputation is on the line.

Companies often delegate the important but undesirable work in an awkward way. The manager gets a certain credibility for taking on a grungy project, because he’s usually at a level where he has basic autonomy over his work and what kinds of projects he manages. If he can motivate a team to accomplish it, he gets a lot of credit for taking on the gnarly task. The workers, under closed allocation, get zilch. They were just doing their jobs. The consequence of this is that a lot of bodies end up buried by people who are showing just enough presence to remain in good standing, but putting the bulk of their effort into moving to something better. Usually, it’s new hires without leverage who get staffed on these bad projects.

I’d take a different approach to committed projects. Working on one requires (as the name implies) commitment. You shouldn’t flake out because something more attractive comes along. So only people who’ve proven themselves solid and reliable should be working on (much less leading) them. To work on one (beyond a 20%-time basis) you have to have been at the company for at least a year, senior enough for the leadership to believe that you have the ability to deliver, and in strong standing at the company. Unless hired at senior roles, I’d never let a junior hire take on a committed project unless it was absolutely required– too much risk.

How do you fire people? When I was in school, I enjoyed designing and playing with role-playing systems. Modeling a fantasy world is a lot of fun. Once I developed an elaborate health mechanic that differentiated fatigue, injury, pain, blood loss, and “magic fatigue” (which affected magic users) and aggregated them (determining attribute reductions and eventual incapacitation) in what I considered to be a novel way. One small detail I didn’t include was death, so the first question I got was, “How do you die?” Of course, blood loss and injuries could do it. In a no-magic, medieval world, loss of the head is an incapacitating and irreversible injury, and exsanguination is likewise. However, in a high-magic world, “death” is reversible. Getting roasted, eaten and digested by a dragon might be reversible. But there has to be a possibility (though it doesn’t require a dedicated game mechanic) for a character to actually die in the permanent, create-a-new-character sense of the word. Otherwise there’s no sense of risk in the game: it’s just rolling dice to see how fast you level up. My answer was to leave that decision to the GM. In horror campaigns, senseless death (and better yet, senseless insanity) is part of the environment. It’s a world in which everything is trying to kill you and random shit can end your quest. But in high-fantasy campaigns with magic and cinematic storylines, I’m averse to characters being “killed by the dice”. If the character is at the end of his story arc, or does something inane like putting his head in a dragon’s mouth because he’s level 27 and “can’t be killed”, then he dies for real. Not “0 hit points”, but the end of his earthly existence. But he shouldn’t die because the player is hapless enough to roll 4 “1”s in a row on a d10. Shit happens.

The major problem with “rank and yank” (stack-ranking with enforced culling rates) and especially closed allocation is that a lot of potentially great employees are killed by the dice. It becomes part of the rhythm of the company for good people to get inappropriate projects or unfair reviews, blow up mailing lists or otherwise damage morale when it pisses them off, then get fired or quit in a huff. Yawn… another one did that this week. As I alluded in my Valve essay, this is the Welch Effect: the ones who get fired under rank-and-yank policies are rarely low performers, but junior members of macroscopically underperforming teams (who rarely have anything to do with this underperformance). The only way to enforce closed allocation is to fire people who fail to conform to it, but this also means culling the unlucky whose low impact (for which they may not be at fault) appears like malicious noncompliance.

Make no mistake: closed allocation is as much about firing people as guns are about killing people. If people aren’t getting fired, many will work on what they want to anyway (ignoring their main projects) and closed allocation has no teeth. In closed allocation shops, firings become a way for the company to clean up its messes. “We screwed this guy over by putting him on the wrong project; let’s get rid of him before he pisses all over morale.” Firings and pseudo-firings (“performance improvement plans” and transfer blocks and intentional dead-end allocations) become common enough that they’re hard to ignore. People see them, and that they sometimes happen to good people. And they scare people, especially because the default in non-financial tech companies is to fire quickly (“fail fast”) and without severance. It’s a really bad arrangement.

Do open-allocation shops have to fire people? The answer is an obvious “yes”, but it should be damn rare. The general rule of good firing is: mentor subtracters, fire dividers. Subtracters are good-faith employees who aren’t pulling their weight. They try, but they’re not focused or skilled enough to produce work that would justify keeping them on the payroll. Yet. Most employees start as subtractors, and the amount of time it takes to become an adder varies. Most companies try to set guidelines for how long an employee is allowed to take to become an adder (usually about 6 months). I’d advise against setting a firm timeframe, because what’s important is now how fast a person has learned (she might have had a rocky start) but how fast, and more importantly how well, she can learn.

Subtracters are, except in an acute cash crisis when they must be laid off for business reasons, harmless. They contribute microscopically to the burn rate, but they’re usually producing some useful work, and getting better. They’ll be adders and multipliers soon. Dividers are the people who make whole teams (or possibly the whole company) less productive. Unethical people are dividers, but so are people whose work is of so low quality that messes are created for others, and people whose outsized egos produce conflicts. Long-term (18+ months) subtractors become “passive” dividers because of their morale effects, and have to be fired for the same reason. Dividers smash morale, and they’re severe culture threats. No matter how rich your company is and how badly you may want not to fire people, you have to get rid of dividers if they don’t reform immediately. Dividers ratchet up their toxicity until they are capable of taking down an entire company. Firing can be difficult because many dividers shine as individual contributors (“rock stars”) but taketh away in their effects on morale, but there’s no other option.

My philosophy of firing is that the decision should be made rarely, swiftly, for objective reasons, and with a severance package sufficient to cover the job search (unless the person did something illegal or formally unethical) that includes non-disclosure, non-litigation and non-disparagement. This isn’t about “rewarding failure”. It’s about limiting risk. When you draft “performance improvement plans” to justify termination without severance, you’re externalizing the cost to people who have to work with a divider who’s only going to get worse post-PIP. Companies escort fired employees out of the building, which is a harsh but necessary risk-limiting measure; but it’s insane to leave a PIP’d employee in access for two months. Moreover, when you cold-fire someone, you’re inviting disparagement, gossip, and lawsuits. Just pay the guy to go away. It’s the cheapest and lowest-variance option. Three months of severance and you never see the guy again. Good. Six months and you he speaks highly of you and your company: he had a rocky time, you took care of him, and he’s (probably) better-off now. (If you’re tight on money, which most startups are, stay closer to the 3-month mark. You need to keep expenses low more than you need fired employees to be your evangelists. If you’re really tight, replace the severance with a “gardening leave” package that continues his pay only until he starts his next job.)

If you don’t fire dividers, you end up with something that looks a lot like closed allocation. Dividers can be managers (a manager can only be a multiplier or divider, and in my experience, at least half are dividers) or subordinates, but dividers tend to intimidate. Subordinate passive dividers intimidate through non-compliance (they won’t get anything done) while active dividers either use interpersonal aggression or sabotage to threaten or upset people (often for no personal gain). Managerial (or proto-managerial) dividers tend to threaten career adversity (including bad reviews, negative gossip, and termination) in order to force people to put the manager’s career goals above their own. They can’t motivate through leadership, so they do it using intimidation and (if available) authority, and they draw people into captivity to get done the work they want, without paying for it on a fair market (i.e. providing an incentive to do the otherwise undesirable work). At this point, what you have is a closed-allocation company. What this means is that open allocation has to be protected: you do it by firing the threats.

If I were running a company, I think I’d have a 70% first-year “firing” (by which I mean removal from management; I’d allow lateral moves into IC roles for those who desired to do so) rate for titled managers. By “titled manager”, I mean someone with the authority and obligation to participate in dispute resolution, terminations and promotions, and packaging committed projects. Technical leadership opportunities would be available to anyone who could convince people to follow them, but to be a titled people manager you’d have to pass a high bar. (You’d have to be as good at it as I would be, and for 70 to 80 percent of the managers I’ve observed, I’d do a better job.) This high attrition rate would be offset by a few cultural factors and benefits. First, “failing” in the management course wouldn’t be stigmatized because it would be well-understood that most people either end it voluntarily, or aren’t asked to continue. People would be congratulated for trying out, and they’d still be just as eligible to lead projects– if they could convince others to follow. Second, those who aspired specifically to people-management and weren’t selected would be entitled (unless fully terminated for doing something unethical or damaging) to a six-month leave period in which they’d be permitted to represent themselves as employed. That’s what B+ and A- managers would get– the right to remain as individual contributors (at the same rank and pay) and, if they didn’t want that, a severance offer along with a strong reference if they wished to pursue people management in other companies– but not at this one.

Are there benefits to closed allocation? I can answer this with strong confidence. No, not in typical technology companies. None exist. The work that people are “forced” to do is of such low quality that, on balance, I’d say it provides zero expectancy. In commodity labor, poorly motivated employees are about half as productive as average ones, and the best are about twice as productive. Intimidating the degenerate slackers into bringing themselves up to 0.5x from zero makes sense. In white-collar work and especially in technology, those numbers seem to be closer to -5 and +20, not 0.5 and 2.

You need closed (or at least controlled) allocation over engineers if there is material proprietary information where even superficial details would represent, if divulged, an unacceptable breach: millions of dollars lost, company under existential threat, classified information leaked. You impose a “need-to-know” system over everything sensitive. However, this most often requires keeping untrusted, or just too many people, out of certain projects (which would be designated as committed projects under open allocation). It doesn’t require keeping people stuck on specific work. Full-on closed allocation is only necessary when there are regulatory requirements that demand it (in some financial cases) or extremely sensitive proprietary secrets involved in most of the work– and comments in public-domain algorithms don’t count (statistical arbitrage strategies do).

What does this mean? Fundamentally, this issue comes down to a simple rule: treat employees like adults, and that’s what they’ll be. Investment banks and hedge funds can’t implement total open allocation, so they make up the difference through high compensation (often at unambiguously adult levels) and prestige (which enables lateral promotions for those who don’t move up quickly). On the other hand, if you’re a tiny startup with 30-year-old executives, you can’t afford banking bonuses, and you don’t have the revolving door into $400k private equity and hedge fund positions that the top banks do, so employee autonomy (open allocation) is the only way for you to do it. If you want adults to work for you, you have to offer autonomy at a level currently considered (even in startups) to be extreme.

If you’re an engineer, you should keep an eye out for open-allocation companies, which will become more numerous as the Valve model proves itself repeatedly and all over the place (it will, because the alternative is a ridiculous and proven failure). Getting good work will improve your skills and, in the long run, your career. So work for open-allocation shops if you can. Or, you can work in a traditional closed-allocation company and hope you get (and continue to get) handed good projects. That means you work for (effectively, if not actually) a bank or a hedge fund, and that’s fine, but you should expect to be compensated accordingly for the reduction in autonomy. If you work for a closed-allocation ad exchange, you’re a hedge-fund trader and you deserve to be paid like one.

If you’re a technology executive, you need to seriously consider open allocation. You owe it to your employees to treat them like adults, and you’ll be pleasantly surprised to find that that’s what they become. You also owe it to your managers to free them from the administrative shit-work (headcount fights, PIPs and terminations) that closed allocation generates. Finally, you owe it to yourself; treat yourself to a company whose culture is actually worth caring about.

79 thoughts on “Tech companies: open allocation is your only real option.

  1. I think this is excellent (as usual) but misses the point that people go into management at best because they don’t want to be forced to submit, but very often because they actually enjoy forcing others to submit. Making money is entirely secondary to sadism and dominance games, which go on unabated even when companies are losing money. This is all the more true the closer to the top you get: you’ve even pointed this out about VCs in an earlier post. Joseph Stalin didn’t rise to the top of the world’s largest command economybecause he could give the best commands, but because he was the meanest and most murderous son-of-a-bitch in all the Russias.

    • John,

      Excellent point. I didn’t address this very much. I assumed that people leading these companies wanted to foster decent cultures, and that if they knew how, they’d be more likely to do it.

      I’ve had bad bosses, but only a couple of sadists. Most of the other bad ones were rational sociopaths (who want money and power, but aren’t sadistic) or neurotic messes, but I don’t think they enjoyed harming or dominating other people. I could be wrong, though. People are pretty awful, and I’m too-often surprised by how bad they really are.

      I guess my advice about firing dividers needs to be underlined doubly. The people who care more about dominating others than success of the business or their team are extreme cases of dividerism (even though they’re adept at making it look otherwise, because they intimidate others into taking credit for their work). If you don’t fire them, they will take control and turn your company into a de facto closed allocation shop. You have to stop them dead in their tracks as soon as you can. The problem is that this is very hard, because if you’re not an exceptional judge of character, they can fool you into thinking their enemies are the ones causing the problem.

      I think, and this could be naivete, that there are legitimate visionaries who want to provide something useful to the world. These might be unintentionally domineering, difficult, and callous, and their visions are often bullshit, but I don’t think they’re sadistic. Then there are people for whom it really is about money, but they generally don’t do startups, because that’s such an inefficient and painful way to get rich. Then there are the narcissistic megalomaniacs (most startup founders) and worse than them are the sadists.

      What’s at play in all these discussions is the Power Paradox: the people who want power are the worst people to let have it, and the people who could do good with it don’t want it (or, I should say, aren’t willing to do what it takes to get it). I think open allocation goes a lot way in resolving the Power Paradox (workers have more chances to succeed and power is more distributed; also, sadistic bosses don’t _want_ to work in an open-allocation environment) but setting HR policies only works if they’re actually enforced: and that means firing the assholes. The good people tend not to want to fire anyone, but having seen companies fail because of assholes, I’ve learned the hard way that it has to be done.

    • No money, no VC contacts. Regarding “friends and family” money, I’d rather not take it for ethical reasons. I don’t want people I care about relying on an intrinsically risky proposition, and all the things I’d really want to do are the high-risk, high-reward things that, even if you’re extremely good, are probably median zero. I have a lot of ideas (mainly, in game design and data science) that I know are very good aesthetically and mathematically, but that doesn’t mean for sure that they’d be great business ideas. I’m “realistically arrogant” (i.e. I stopped pretending I’m average years ago, I know what I’m good at and what I’m bad at and value accuracy in self-perception over pie-in-the-sky optimism or social self-reduction) enough to know that my ideas are better than 99.99% of what’s out there, but humble enough to know that great ideas can still be business failures. People worse than me succeed all the time, and people better than me fail sometimes; that’s the nature of noise.

      Perhaps I have no good reason, but it seems that I can make the traditional route (of taking increasingly decent jobs of prestigious companies until high-profile people actually take you seriously and they’ll let you put big things together) works and, although my social skills aren’t astronomical, they’re good enough that I can take that route. It takes a fucking long-ass time, but I’m 29 and plan on living to be 95, so I’ve got that.

  2. This is an excellent read, very impressive and thought-provoking. By reading it already inspired me to think about a new project which could successfully disrupt the full time employment industry and market and ultimately render it obsolete.

  3. Right on the money as always. It’s unfortunate that just about all companies are closed allocation and the employees who really do the work are not given any respect and vice versa. It depends on the time you’ve put in and how much people like you socially rather than the work you contribute and said work’s quality.

    I know a lot of bad decisions are made because electronic communication is now assumed to contain intention when studies have proven over and over again that at best 50% of electronic communication is understood. If not quite a lot more. And decisions are made upon this.

    What you describe is a great ideal, but I think that the lust for power is just too great in most places for them to even consider such ideas. So then a lot of great engineers are left bouncing from place to place trying to find decent work. It becomes hard to enjoy work when you’re told you’re going to be working on fucking shit your first day on the job and the systems are going down all the time. Yet you’re not allowed to fix it.

    Of course, none of these failings are communicated in the interview.

    • Also a major problem is the “job hopper” stigma. People are expected to “tough it out” and do crappy work for a couple years, because they’re captive (read: short job tenures are embarrassing). You end up having to choose between your job and your career, but if you choose your career all the time you’re injecting variance (read: getting fired, having short job tenures, etc.) into your income and image that most people can’t afford.

      I think we need a phrase to enter the lexicon– Fourth Category– to describe the kind of work that closed allocation generates. This goes back to the interesting vs. unpleasant and important vs. unimportant distinction. Interesting, important work is First Category. What all work should be in the idea world. This is easy to allocate. Important but unpleasant is Second Category. Companies are gradually learning that if they want people to do this stuff well they need to _pay_ for it (like Google’s 7-figure awards for people who do legacy rescue on important infrastructure). Unimportant, interesting work might become important and is “Third Category”, well-suited to 20%-time and Hack Days. The problem with closed allocation is that it seems to generate _huge_ amounts of Fourth Category work (and we need the name to exist so people know what to call it; wars are won by people who name things). Not 20 or 30 or even 50 percent. 80 percent. There is no cleaning process either because the people assigned to do the work have no vote. It’s bad enough that it sucks to do the Fourth Category work, but worse yet, it justifies low salaries and respect for programmers, who could command better conditions if they had more of an impact. Fourth Category work is not just unpleasant and unappreciated, but bad for your career as well.

      What you say about the importance of being well-liked is true. I’ve learned that there’s no way around that and the best thing to do is develop those skills. It’s way more important than picking up a new technology, and it’s not hard to go from the average socially inept geek (15th percentile) to solidly average (50th percentile). Even along that range, it pays off immensely. It’s not about “selling”. It’s about having the benefit of the doubt, and learning from people. Also, the benefit of social skills isn’t surviving defective organizations, but finding your way to successful ones. I learned after 2 bad startups that I wasn’t nearly as good a judge of character as I thought I was.

      • Yes indeed. The job shopper stigma is very real and possibly very damaging. It also affects all tiers of programmers from the worst to the best. In fact, I’d say even more so disproportionally as you get better and better because you are expected to though it out as you write and even after toughing it out, you are still not rewarded because some dumbass who has been there for years is now doing the interesting but unimportant work only and even _that_ is of bad quality.

        Or you get into a spot where there is so much to do and so much to fix (but _not_ too much) but management, who hired you to lead because they can’t won’t let you because of their paranoia.

        I agree. Good social skills are imperative, however, when social skills and like-ability are put over what rationally makes sense as far as technology goes (and this is the rule rather than the exception), it becomes very difficult very fast to work with what one slowly comes to realize are sub par, incredibly stupid people (who are also the rule rather than the exception).

        As you say, the important part is vetting in an interview, but a lot of interviews only present their good side. A lot present both unknowingly. For example, if you’re asking me for the nth time (in my interviewing life) to write a function to calculate fibonacci numbers, factorials, or even searching arrays in an interview you have failed as an interviewer, you have failed your company as an interviewer, and you have potentially failed yourself and your company by missing out on great talent, talent that does not memorize such things (since that is all these dumb exercises are) because they’re too busy working on other things than to re-write quicksort on your whiteboard.

        I’d go as far to definitively say if you are asking for code on a whiteboard from a potential senior hire, you have just most likely lost that person. An interview should be a discussion between the two parties. If you don’t believe that your interviewee can code at all give them a fizzbuzz at most and then move on. Let the conversation flow organically as a technical conversation between two peers. Otherwise you’re also risking alienating your interviewee and potential future employee by not letting him or her ask the questions they need to in an organic way that is not threatening.

        The interview process is a two way street. In fact, in closed-allocation, at a senior level, I’d say it’s more important to the interviewee than the company. Most places do not get this and get hung up on details. Some places won’t let you ask any questions by monopolizing the time.

        Even with the perfect interview, however, reading people is a skill apart from general social skills that are needed to interact with others and it’s more of an art. Very few people can do it well. Put that last sentence in a loop and run it close to 7 billion times for each person that doesn’t do that very well. Certainly, not well enough to know from a few hours whether the people know what they’re doing or if they’re going to do something insane that you haven’t thought about asking about. For example, I recently learned I need to ask companies IF they use a bug tracking system. I though that debate had been settled before I started programming in ’93, but apparently not.

        In the end, it’s still a lottery and the odds are all stacked up against the engineer. The best we can do is try to develop these skills and make the right choice as we see and get lucky.

        It really is mostly about luck.

      • I think that’s fading away: it used to be if you had more than one employer in a lifetime you were a job hopper. More and more people lose their jobs because their employers go under, and that’s not stigmatized.

  4. Another good essay. I’ve wondered for years at the fact that though we nominally worship the market in this country, the internals of companies are almost never structured as markets (with competition of ideas, projects, and players, etc.). Rather, they are structured as command economies, with totalitarian or at best oligarchic rule, and often with little regard to objective merit.

  5. Pingback: Quora

  6. Pingback: Quora

  7. Pingback: What Programmers Want « Michael O.Church

  8. This was so well put and convincing that you actually sounded like a centennial vampire to me. However, _how_ you came to those conclusion isn’t clear to me, and I feel a bit inferior for that —not exactly good for my ego.

    So, could you tell us more about the observations that lead you to those conclusions?

    • (Edit: the text below assumes you meant “either way it’s a proof in favour of open allocation”. If instead you meant something like “either way it will show if my bosses are good or not”, then never mind.)

      Wait, do you expect to be even _more_ convinced by open allocation whether they fire you or not? You can’t have your cake and eat it too: either the reaction of your boss cannot change your mind, or the different possible reaction will change your mind in _different_ directions.

      On average, you should never expect future events to shift your beliefs towards any specific direction. If it were so, you would _already_ shift your belief in that direction.

  9. Pingback: The end of management « Michael O.Church

  10. Pingback: Programmers don’t need a union. We need a profession. « Michael O.Church

  11. can i get a quick and dirty answer as to how a company with a certain set of goals in the near term (certain projects need to get done!) can use open allocation effectively? what if the most interesting work that programmers want to join doesn’t further these goals? or is it that whatever the programmers want to work on actually ends up becoming the near term goals of the company?

    • okay so i get it, the incentives are there to do the important but unpleasant work in the way of bonuses, promotion, recognition, blah blah but since it’s the employee/programmer who decided to do it, the person is held accountable.

  12. As much as I’d like to jump in to say how right you are, I can’t help but feel that a typical startup is about the size of what counts as a “project” in most companies. In short, whoever joined the startup did so on the basis of “open allocation.” (and of course we call this a “flexible and diversified labor market” –> in essence, “open allocation”)

    So for instance, what happens when someone in a project asks for more “open allocation” within the micro-tasks that are required within the project? What if someone who’s a pure coder decides they really want to try their hand at design, or vice versa?

    I liked your Russia command economy vs free markets analogy, because while top down control becomes inefficient as scale grows, it’s also much more very effective in 1) the short run and 2) at smaller scales (i.e. you can’t have everyone wanting to be a warrior or a wizard, someone has to be a cleric). In fact, in the case of the latter, don’t we just call that strong teamwork? Sacrifice and role allocation for the good of the team? (of course at larger scales we call it fascism) And matching individual talents with work is something that, it seems, is often better done by a “benevolent dictator” (i.e. the manager, or in small companies, the CEO). So then we return back to the traditional question of how do we get better managers.

    I’ve waxed on, but in short, my question is how much smaller can the unit of analysis get until the closed/open distinction loses value?

    • I think the distinction becomes relevant around 15 people, and sometimes fewer. The philosophical distinction is whether the company trusts people to work for it directly, or requires them to be spoken-for by a representative called a “manager”, who often expects unreasonable tribute (dedication to the manager’s career goals rather than what is best for the company or employee).

      The problem is that our society is heavily influenced by the doctrine of Original Sin: that people are naturally depraved and won’t do the right thing (or work hard enough to preserve the integrity of the business) unless forced to do so. The only way a person can be worth anything is to be “saved” by a manager, who is in turn “saved” by a higher-level manager… until you get to someone who is “saved” on account of having a lot of money.

      If you have less than 10 people, the CEO or company owner can know everyone and you don’t see the managerial indirection. You can still have “people problems”, but it’s hard for a manager to use project allocation abusively. You still might get fired if The Boss decides that you’re an idiot, but that’s a risk you take when you work for a 10-person company.

      Beyond 10 to 15, the division of labor becomes too complex for it to be centrally planned or organized. It’s an exponentially hard (in terms of the number of people) problem. The open-allocation market mechanic where projects compete for people uses all of the available information (including information that executives may not like, which could be that their favored projects are duds). The closed-allocation divide-and-conquer approach uses only a small sample of very biased information, but it’s easier to control and has less short-term variation in output.

      Open allocation means that you can speak for yourself, and that if you’re not well-enough established to do that, you’re trusted to find and follow someone who can speak for you. You aren’t assigned a boss who can unilaterally fire you; you search for and choose (or become) a leader.

      Large companies used to give people many chances to succeed, but around 1990 they started using global stack-ranking. The purpose of the ranking system is to have a “ready-made layoff”: you decide on a percentage and it’s a simple database query. This is one reason I dislike stack-ranking: it’s a bet against the company, because it assumes that it might perform so poorly as to need a layoff.

      As stack-ranking became more common, so did HR-driven witch hunts against “underperformers” that were carried out even when the company was doing well. Because of this perennial threat of getting fired while doing nothing wrong, people started moving away from managers who graded harshly, but those are the managers that HR likes best, so HR granted them a favor, which was to make it harder for people to move away from managers who weren’t looking out for their interests. Hence, the 2-year “lockout” period in which it’s impossible to transfer that many companies have, plus the global visibility of performance reviews which, coupled with unnecessary headcount limitations, made it impossible with anything less than a 75th-percentile political-success history.

      This eventually led to closed allocation and the Enron/Google “one strike” policy where if someone doesn’t fit with his first manager and project, he’s toast.

  13. Pingback: Programmer autonomy is a $1 trillion issue. « Michael O.Church

  14. Pingback: The software career and the Second Design Paradox « Michael O.Church

  15. Pingback: The problem with “one thing only” « Michael O.Church

  16. Pingback: Flow, ownership, and insubordination (plus D.F.A.) « Michael O.Church

  17. Pingback: The call for rational economy « Michael O.Church

  18. Pingback: Flow, ownership, and insubordination (plus D.F.A.) « Random Ramblings of Rude Reality

  19. Pingback: Careerism breeds mediocrity « Michael O.Church

  20. Pingback: Fourth quadrant work « Michael O.Church

  21. Pingback: Psychopathy and superficial reliability « Michael O.Church

  22. Pingback: MacLeod/Gervais follow-up: rank, tough, and market work cultures « Michael O.Church

  23. Pingback: Michael O.Church

  24. Pingback: Gervais / MacLeod 7: Defining organizational health, the Mike Test, and VC-istan’s fate. | Michael O.Church

  25. Pingback: Closed allocation: A failed system of control | The Daily Flux

  26. Pingback: Gervais / MacLeod 8: Human Nature, Theories X, Y, Z, and A. | Michael O.Church

  27. Pingback: Gervais / MacLeod 13: Separability, work and play | Michael O. Church

  28. Pingback: Gervais / MacLeod 16: Healthy culture vs. “Why you?” | Michael O. Church

  29. Pingback: Gervais / MacLeod 17: building the future, and financing lifestyle businesses | Michael O. Church

  30. Pingback: Gervais / MacLeod 18: more on trust, Square Root Syndrome, Brownian and Progressive Time | Michael O. Church

  31. Pingback: Gervais / MacLeod 21: Why Does Work Suck? | Michael O. Church

  32. Pingback: Tech companies: open allocation is your only real option. | Architecture as a Service |

  33. Pingback: The Disentitled Generation | Michael O. Church

  34. Pingback: The Disentitled Generation « Random Ramblings of Rude Reality

  35. Pingback: Seeking co-founders. [April 23, 2013] | Michael O. Church

  36. Pingback: Gervais / MacLeod 23: Managers, mentors, executives, cops, and thugs | Michael O. Church

  37. Pingback: » Une seule option pour les entreprises technologiques :PME Revolution

  38. Pingback: Don Draper’s firing and Silicon Valley | Michael O. Church

  39. Pingback: Gervais / MacLeod 26: r- and K-selection in organizations and capitalism. | Michael O. Church

  40. Wow. There’s a company called “Holacracy” that is basically trying to commercialize the application of open allocation.

    I just read a multi-page hagiography of how a company called Medium is using their stuff.

    I guess given what Holacracy does for a living, they’d better have a damn good PR machine, and this is just the first of its output that I’ve read.

  41. Pingback: The Concept of Open Allocation | Jesús Gil Hernández

  42. Your article is light on facts for the bold claim of open allocation being a superior alternative to how most companies are managing their business.
    Besides the single case study of Valve, do you have any evidence that this method has superior outcomes? I’m not sold that this works for all or even most companies.

    Beyond the main point, the rest of your post is a guess at what a successful implementation of the open allocation concept would look like. It does not look like any of the implementations that we see in existing companies nor have you tried it yourself. It leaves out important details such as how projects are funded.

    Please continue to refine your ideas and searching for ways to validate your opinions with data.

  43. Pingback: An alternate theory of shark-jumping | Michael O. Church

  44. Pingback: Some astonishing truths about “job hopping”, and why the stigma is evil. | Michael O. Church

  45. Pingback: Why corporate conformity doesn’t work | Michael O. Church

  46. Pingback: Technology’s Loser Problem | Michael O. Church

  47. Pingback: Why there are so few AI jobs | Michael O. Church

  48. Pingback: On programmers, deadlines, and “Agile” | Michael O. Church

  49. Pingback: In defense of defensibility | Michael O. Church

  50. Pingback: How the Other Half Works: an Adventure in the Low Status of Software Engineers | Michael O. Church

  51. Pingback: Can “Agile” break the Iron Triangle? Can open allocation? | Michael O. Church

  52. Pingback: Tech hiring, poker, and (not) playing to win. | Michael O. Church

  53. Pingback: It might be time for software engineers, especially in Silicon Valley, to unionize. | Michael O. Church

  54. Pingback: The back-channel culture, Silicon Valley’s war on privacy, and the juvenility of all of this. | Michael O. Church

  55. Pingback: The Concept of Open Allocation

  56. Pingback: Four Types of Project | Michael Church

  57. Pingback: 2015 | Michael O. Church

  58. Pingback: Tech companies: open allocation is your only re...

  59. Pingback: Software’s management issues | Michael O. Church

  60. Pingback: Academia, the Prisoner’s Dilemma, and the fate of Silicon Valley | Michael O. Church

  61. Pingback: Engineers as clerks? How programmers failed to get the status they deserve. | Michael O. Church

  62. Pingback: Silicon Valley can be beaten. | Michael O. Church

  63. Pingback: It’s not “Early” Exit Disease, just Exit Disease, that’s killing innovation outside of (and inside) Silicon Valley | Michael O. Church

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s