Closed allocation: A failed system of control

A couple of years ago, I found myself boxed into a corner. I wanted to become a developer, but my workplace kept pigeonholing me into a management role, where I would break down (very important!) tasks to give to our other, more experienced developers.

Thanks to an intervention by a brutally honest friend, I found the strength to basically quit one (very important!) job internally to become a developer. I got to stay at the company, but took on an entirely new role, letting the old one languish and die. This was very scary at the time.

Then, six months later, my prior (very important!) position was eliminated and everyone else performing it was laid off. But I had left that role to become part of a central, truly indispensable team that was regarded as the engine of innovation for the company.

All the stuff that the organization told us was critical was actually of no long-term benefit, even harmful, to the company. The worst part is that we, the performers of those jobs, knew this, but couldn’t do anything to change it.

This is the curse of closed allocation.

The article: You should read it

A couple of months ago, I read an article by Michael Church that gave voice to many of my recent thoughts on company culture. It challenged me, and although I disagreed with some of its prescriptions, I believe it’s well worth your time.

It also taught me some labels for a critical distinction in corporate cultures: open allocation vs. closed allocation.

These terms help define a unified theory that pulls together the differences between older-industrial-revolution-era cultures (think Goldman Sachs or the military) and post-internet-era cultures (such as Netflix, Valve, or Github).

Open vs. closed allocation: what’s the difference?

Closed allocation is the traditional system of having organizational leaders translate a company’s mission into a specific set of priorities and projects, then creating a management layer to break these down into tasks, which are then delegated to employees.

Open allocation is a radically different system of having organizational leaders communicate the company’s mission to all employees, skipping the management layer, and offering the employees complete self-direction and self-organization.

Closed allocation relies on a scarcity philosophy and zero-sum math. There are so many things to be done, and so few hours. Employees should leave the decision-making to us and perform their tasks quickly and well.

It’s also pretty cynical: If people aren’t told what to do, they’ll do the wrong thing. If they aren’t monitored and prodded, they won’t do anything at all.

Open allocation systems operate on an abundance mindset and exponential math: If people buy into our goals and apply their passion and talent, they’ll uncover paths to success that we can’t even envision. 

Open allocation is the Trust portion of the culture triangle carried out to its maximum. If we entrust our vision to good people, they’ll focus on solving problems that are truly high-value.

What about drudge work? Doesn’t it just pile up?

The number one fear I’ve heard from people regarding open allocation is “but what about the work no one wants to do?”

First, it’s important to break these kinds of work apart.

Michael defines a matrix along two axes: A work’s importance to the business and its pleasantness.

I. Pleasant/Unimportant (R&D) Developers are all too happy to experiment with new techniques and technologies, or to rebuild an existing system from scratch. Google calls this “20% time”, and open allocation shops don’t place a limit on it. While activities in this quadrant don’t appear to have immediate value, letting developers “play” produces incredible long-term value for businesses. In fact, nearly every major innovation from Google in the last 5 years has been from this “20% time”.

II. Pleasant/Important (High-visibility projects) Shipping new features is fun, and there are plenty of intrinsic organizational rewards. Knocking out a bunch of small, quick bugs or features carries an immediate, visceral reward. Both open and closed allocation systems do this well.

III. Unpleasant/Unimportant (Junk pile) Developers, by default, will avoid unpleasant tasks that add no value to the business. It’s why they hate meetings like vampires hate sunlight. (Some developers hate sunlight too, but this is unrelated.) A huge amount of time in closed allocation systems is wasted here, and it’s virtually eliminated in open allocation.

IV. Unpleasant/Important (Maintenance) I’ve sometimes heard the term “maintenance developer” used as a pejorative. But developers doing “maintenance” are the unsung heroes. And here we are. This is what people fear losing by moving to open allocation.

First, let me attempt to unburden you of the belief that this work gets done or done well in a closed-allocation system. Most likely, this work is being picked at and pushed around like the steamed carrots on a 4-year-old’s dinner plate.

And this is where Michael and I part ways. His advice is to incentivize, which is yet another tactic that has been proven to have the opposite of its intended effect. (You’ve probably already seen this video, but it’s a great, concise explanation of why.)

What I’ve noticed is that if you have a collaborative team, the unpleasant tasks carry their own intrinsic rewards within a team. The deepest desire of many of my favorite developers is to make their work and that of other developers easier and less tedious.

Open Allocation gives you rocketships

It’s only in closed allocation systems that developers quietly accept work that comes to them on a conveyer belt. In open allocation, developers will automate the work that comes in via conveyer belt so they can go do something more interesting.

Competition between ideas, not people

When what you work on is not your choice, the only influence you have is to try and compete to get better work. People compete to avoid doomed, unpleasant, or unimportant projects and to get assigned to high-visibility, high-impact work.

In fact, management often views this as a valid mechanism of control, and actively fosters competition between teams or team members.

In a closed allocation system, people compete for the right to work on good ideas, while in an open allocation system, ideas compete for the right to have people work on them.

Competitive environments add an unnecessary layer of stress and interpersonal discord among team members. This leads to burnout, causes good people to leave, and inspires people to put their energy into “managing perceptions” rather than producing excellent work.

My experience is that the only environments that create lasting value foster a collaborative environment where the reward structure is tied to making your team better, rather than being better than the rest of the team.

Either way, a company will grind something up in the course of making progress. But it’s up to leadership to decide whether ideas or people are the grist for that mill. And grinding people instead of ideas turns out worse products. You’d think this would be an easy decision, right?

If open allocation is so great, why are so few doing it?

Closed allocation is the default for almost all companies. If open allocation is so superior, why hasn’t it immediately become the go-to organizational structure for new companies?

First off, almost every company starts with open allocation. It’s the DNA of a “startup” or “small business”. But amazingly, no one seems to notice as the open allocation inherent in a 5-person company starts closing up, management starts getting injected to wrangle the chaos, and employees start losing their voices and autonomy.

But the question stands: Why is closed allocation the dominant philosophy?

  • It’s how you manage people who don’t want to be there. If someone’s job is to sew a boot to its sole at a rate of 500 per day for minimum wage, it’s conventional wisdom that they require external motivation to stay on task at maximum efficiency (although this is debatable).
  • People are conditioned for closed allocation. Public schools, churches, and most areas of modern Western society condition people that how their time is spent is ultimately decided by those “in charge”.
  • Change is scary. Every part of every organization is highly optimized, even dependent, on closed allocation systems. Most people in closed allocation systems fear the increased responsibility of an open system, even if they’d excel in it.
  • Lots of other reasons. It’s a mechanism that provides stakeholders with a feeling of control over chaos. It protects people who make decisions, even if they themselves are unneeded. (When have you ever heard of a management team opting to lay itself off?) Maybe the company is hiding from the fact that it has no compelling vision. But ultimately, the fact is that everyone in a closed-allocation system eventually buys into it, even if they complain about it.

But how do I know who to fire?

This is the other question I’ve heard about open allocation. How do you know which employees are valuable and which are harmful without targets, measurements, or stack ranking? Michael Church’s article covers it well, but in short: you’ll fire fewer than you’d think. People will find more ways to contribute in an open allocation system than if they’re pigeonholed into a rigidly-defined role.

Open allocation systems only let go of the people who are so political, passive aggressive, or poorly-performing as to cause a serious morale drag amongst your other team members. It will be obvious who doesn’t fit in your open allocation system, because their team will share a set of concerns and will have tried everything they could think of to make them successful.

Ignoring this can cost you your best people, even your business

At most companies, try to talk about turnover, and you may be shocked to encounter a “fingers-in-ears-lalalala-can’t-hear-you” level of denial. But this makes sense in closed allocation companies.

To confront how, when, and why employees might exercise their right to leave is to realize that 100% of the control closed allocation offers is an illusion. Each human being has a limited tolerance for being treated like a puppet or a cog. And at some point, they’ll run out of tolerance and find a reason to quit or be fired.

Losing key employees is the most expensive thing that can happen a company. Finding, training, and growing talent for knowledge work is ridiculously expensive. That’s to say nothing of the fact that at smaller, wobbly-kneed startups, high turnover could sink the company.

By the time you actually start experiencing turnover, it’s already so late in the cultural decline that no one seems to know what to do. So, executives tend to go into deep denial.

I am not aware of any studies about the difference in turnover between open- and closed-allocation shops, but Github has not lost an employee yet (although they have fired about a half dozen of their 150+). I can promise that when numbers on open allocation (non-) turnover are finally run, a bunch of MBA-types are going to start taking notice.

Can’t I just use some components of open allocation?

Short answer: No.

Much like any ground-up rethink of an existing system (such as the Getting Things Done system or the Paleo diet), you can’t sample pieces to see how they work individually. It’s a package deal.

I’ve been inside multiple companies that decided to “try out” these open allocation systems. And I can promise what will happen is company leaders will quickly realize that almost every person in the building is dependent on this closed allocation ecosystem, and go back to what was comfortable. Every time.

In fact, I can’t point to a case study of a company ever converting, in part or in full, to open allocation from closed allocation. I’m not saying it’s impossible, but I can’t advocate it. What I am advocating is that high-performing people start selecting themselves into open allocation environments, and as they found companies, to build and protect an open allocation system within them.

I’m stuck in a closed allocation system, what now?

Unless you work in a 5-person startup or the government, chances are that your workplace is someplace in between these two extremes, with a strong bias toward closed allocation.

First off, you should know that you have more room than you think if you throw some elbows around and redefine your job. If you’ll take a bit of risk, you’ll find more ability to define your own job than you previously thought. If you assert yourself as someone who understands your job well, and that you understand the company’s goals, you’ll find yourself with more input into the kind of projects you work on and they way you do them.

The sad truth is that ultimately, if you are a high performer, you will find yourself out of patience with the system you’re in. If you’re not careful, you’ll let this frustration drive you into the arms of another closed-allocation system, unaware that the cycle is simply beginning anew.

But I hope you’ll break the cycle and select for open allocation cultures (or go start one yourself), rather than reacting by simply job-hopping.

Who should switch to open allocation?

Imagine your employees, highly engaged, working on the exact thing that rings their bell, finding novel solutions to your most important problems, and pushing your organization closer to its ultimate vision, automatically, without needing to oversee every detail.

This is the promise of open allocation. If your organization has a true vision and a culture of honest feedback, you stand to benefit greatly from this style of management. If you lack either… well, open allocation might not be a fit.

But if you run a shop that you’re confident has vision and feedback, you may wonder if it’s possible to try at all. You could create this type of team that reports directly to the CEO and that has full autonomy, but not without majorly disrupting the rest of the organization, which I’ve seen inspire jealousy and backbiting. It’s treacherous territory, but if you’re bold enough to try it, you’ll discover that you can attract and keep the kind of talent that does great work autonomously.

Lastly, if you run a closed-allocation shop, make note of this warning: Open allocation shops are so fast, so nimble, and have so much energy that if a competitor runs one, they’ll someday be the Muhammad Ali to your Sonny Liston.

You get to choose which to be, but make no mistake, you will be one or the other.

Ali vs. Liston by Dave Rr via Flickr

“A players” and redefining your job

credit: nettsu via Flickr

Not long ago, I engaged in a conversation on Twitter about the de-motivating effects of placing extrinsic motivators on A players.

This resulted in a fun discussion about the nature of motivation and whether the concept of an “A player” is even a useful classification.

I’ll leave the discussion of extrinsic-vs-intrinsic motiviation stuff to Dan Pink. But what I don’t see is a really coherent explanation about what it means to be an “A player”, how a person becomes one, or whether the term has entered the MBA-buzzword graveyard with “proactive” and “synergy”.

Is the term “A player” fair, or even useful?

Popularized recently by the management style of Steve Jobs, the term “A player” has come into broad usage by management types who wish to sound knowledgeable. Which, sadly, is where good business terms go to die.

That said, the term does carve out a spot in your brain to understand that not all people in an organization are equally valuable. “A player” refers to the power plants of your organization: the people who supply an abundance of high-quality output.

This means that there are “B players” and “C players” who produce less useful output and are more likely to be sort of “along for the ride” in an organization.

“A player” is a role, not a permanent label

Yes, it is dangerous to use a term that looks and feels like a classification or labeling system for people, especially one that implies a judgement as to that person’s value. But it is a hard truth that some people are more valuable to an organization than others.

That said, it’s crucial to note that “A player” refers to a role a person plays. I’ve been an A player, a B player, and a C player at various times in my career, and sometimes even at the same job.

Identifying an A player

Whether you’re looking to hire and keep A players or trying to figure out if you are one, here are some observations I’ve made about people I’ve seen as A players:

Has a trail of accomplishments: A players leave behind visible, tangible results of their work, as they are results-oriented. A players ship.

Seeks out feedback: They don’t reject criticism outright, and actually seek feedback, since their ego is less valuable than getting something done.

Has confidence in own abilities: They’re not confident as in boastful, but as in the opposite of insecure. A players rarely shy from a challenge, knowing that it is a matter of patience and work to see something through.

Not big on seeking permission: They tend to choose the work they think will have the biggest impact and go for it, steamrolling obstacles in their way.

Self-evaluating and self-correcting: A players tend to introspect, are driven to improve themselves, and correct mistakes quickly.

Not interested in gossip: A players view “office drama” as a needless source of distraction rather than fodder for conversation.

Helps others succeed: A players are inspired, rather than threatened, by the success of their peers. They actively seek to help others become successful.

By this definition, B and C players are often insecure, complaining about office politics or “playing the game” against their successful peers. They hide their work, rarely shipping, in fear of criticism. They tend to wait for permission to move forward. They tend to wait for a lot of things to be in place before moving forward.

Redefining your role: How to become an A player

I believe that A players are generally B players who figured out that they alone are in charge of when they ship, what they ship, and the quality of their work.

The most important factor in becoming an A player is whether you can attach to a goal that is larger than your ego and insecurities. One that is worth risking failure for. One that is worth breaking the cycle of permission-seeking for. Preferably one that can be accomplished in a matter of a few weeks, lest you burn out before completing the goal.

With this goal burned into your brain, you’ll pull together the resources you need to accomplish it. You’ll naturally find someone to help you with gaps in your skills, because you’ll want to see this through.

You won’t have to work very hard to eliminate distractions, because the distractions that seemed so sweet and tempting before will taste bitter to you now. The desire to ask permission will be gone.

And once you’ve accomplished it, you’ll never want to go back to B-player-style work again. You simply won’t be able to tolerate it. It’ll drive you crazy.

Then, the work begins again of finding the next goal that is similarly motivating.

Yes, finding that goal is easier said than done, but I’ll bet you can find it if you pay attention to what is around you.

How to lose your A players

Many organizations don’t actively identify their A players until they start to leave, and management staff, in a panic, begins some misguided effort to get the remaining A players to stay.

Steve Jobs famously said “A players like to work with A players. B players hire C players.” This, of course, comes back to the fact that B and C players aren’t confident in their abilities, and need to hire people that won’t show them up.

A players form ad-hoc alliances whose goal is to ship, while B and C players tend to form committees whose goal is to prevent things from being done wrong.

A players don’t react well to committees, forms, or bureaucratic processes that add friction to the act of building and shipping.

Each point of friction adds up until A players realize that they aren’t able to operate at their full capacity. They may even verbally warn their management (who often aren’t receptive, or make empty promises of change). And being high-value employees, they know they can succeed somewhere else that promises less friction.

It’s a lifelong process

Some of the A players I’ve met seem as if they were born that way, but for most of us, it’s a lifelong process of self-refinement. A lot of my struggle is to subjugate my ego long enough to really seek and apply feedback.

But to individuals, I can promise that the benefits of developing yourself into an A player are abundant. No one has the world in front of them quite like high-performing individuals.

And to organizations, the benefits of cultivating an environment that rewards A-player behavior are even greater. If you’ll identify and reward your A players, they will drive a culture of results and shipping that defines the best companies in the world.


After posting this, I realized that people may take the wrong message from all this. If you’re reading this, you’re probably an introspective person. If you’re introspective, you have a leg up on 95% of the population. You’re well on your way and very well could be an A player already. Just because there’s still room to grow doesn’t mean you aren’t amazing already.

So take any self-criticism with a grain of salt, and realize that the fact that you’re even evaluating yourself puts you in the category of people I’ve defined above as A players.

Stone soup and software projects

by Cyron via Flickr
Lately, I’ve discovered that processes are not the key to successful projects. But good metaphors lead you to communication shortcuts that sometimes are keys to success.

Specifically, I’ve drawn a lot of value from the story of Stone Soup.

The story

For the unfamiliar, it’s a very old story of a tramp who travels to a town in search of some food. Hungry and destitute, he knows better than to ask the townfolk for a handout. Instead, he offers the villagers the best soup they’ve ever had, “Stone Soup.”

Having intrigued the villagers, he drops his “soup stone” in a large pot and brings it a boil. He tastes it, adding that it just needs a bit of barley and salt to be complete. Then, the story goes, he gradually asks other villagers for more ingredients to make it “just right”: chicken stock, celery, flour, and so on. Everyone shares in the soup, and the stone is extracted, ready to earn a free meal for its owner in the next town.

Starting with nothing

Most projects (especially software projects) are astonishingly like this story.

If you’re building software for a customer or group of customers, you must start with only a stone and a promise of soup to come. That’s probably a familiar feeling to many developers.

Unless you’re writing software to an exact set of specs (in which case, you’re doomed, sorry to say), your customers don’t know exactly what they want. They also don’t want to provide you with the tools, data, and requirements you literally can’t move forward without.

Making matters worse, their expectations are that you’ll magically appear with the project, after reading their minds, overcoming all obstacles, and satisfying all dependencies.

Stone soup is how you show them some of this magic.

Some see the tramp in this story as a charlatan, but I am going to use the term “instigator”: the guy or gal with the guts to set up a pot of boiling water and throw in the stone. The instigator goes out on a limb to make things happen.

Here’s how you can start making some soup:

Find your stone

You are now the keeper of the stone. You’re the instigator. Why you? Because you are probably the only person that knows there’s even supposed to be a stone.

In my experience, throwing the stone into the pot involves skipping a lengthy requirements phase and taking that risky first stab at the product.

There are arguments for building low-fi mockups and some for high-fi, functioning prototypes. As I’ve gotten better at building products, I’ve found high-fidelity prototypes to extract more valuable feedback.

I’ve also heard this called a “straw man”. The point is to start the conversation by putting something in a customer’s hands to either love or hate.

Adding ingredients

Projects often grind to a halt when people fail to deliver on their part of the bargain. This is where I’ve watched projects languish and then die.

Momentum is everything in this phase. No, you won’t get all the ingredients you think you need for your soup. But you do need ingredients of some kind or the boil dies down, interest is lost, and everyone goes home with empty stomachs.

So if one person or group isn’t delivering and is holding things up, it’s time to get creative. What can you put in that would move the conversation forward? Can you get data from a different source that would still be valuable? Can you show a reasonable facsimile of this feature using only the tools you have on hand?

This ingenuity both helps solidify the product and creates a vacuum for the actual item you need, pointing a spotlight on the reason it’s being held up.

The finished product

Actually, that’s kind of a misnomer. The product is never finished.

But after a few iterations on the original concept, you have something worth sharing, even if it’s not perfect. You may never have all the ingredients you’d planned on, but just getting the wheels unstuck generated an outcome that would never have existed otherwise.

At a micro level, the instigator never knew how the soup was going to turn out. The ingredients and tools on hand vary wildly. But at a macro level, he or she knew enough about the process to guide the participants to a shared goal: making something great.

Want to change the world? Be an instigator.

To be successful as an instigator, you must have a decent mental picture of how the soup gets made. If it’s a software project, you’d better have a working knowledge of the parts of the process, from servers, to data, to code.

Once armed with this knowledge, developing a habit of making stone soup is what sets leaders apart from those who are led. It gives you the ability to know that you’ll be able to deliver a result, even without a sure knowledge of exactly how you’ll do it.

Most people aren’t wired to want to be instigators. It’s scary and the risk of failure or embarrassment seems high. But it’s a skill that can be learned, and whether you’re a coder, a manager, or an entrepreneur, it’s required if you want to help lead successful projects and create great products.