My thoughts on Open Allocation, from Michael O. Church.

gistfile1.md

Original Post

Evaluating Team Members

If people want to move, and the leads of those projects deem them qualified, there’s no reason not to allow this.

Deeming someone qualified is a pretty nuanced and difficult process. I wouldn’t expect all or even most temporary tech leads to get it right (or even be close) for a long time.

Rewards for “Committed Projects”

Software engineers already command good salaries. It will be difficult from a business perspective to justify spending more on project bonuses, etc., especially when the business value of open vs. closed allocation will never be cut-and-dry on a balance sheet.

Bootstrapping Open Allocation

If your team is largely composed of junior engineers, there may be a lack of natural leaders to take or even identify high-business-value projects. Getting engineers to a senior enough level to start acting as tech leads may require a more hands-on managerial approach if this is your situation.

Project Management

I think this model also assumes that tech project leads are also effective project managers, with the ability to self-organize and maintain their team’s trajectory toward their shared project goal. In my experience, most engineers are not good at project management or even assessing the status of projects in which they are entrenched. I could see a specific Project Manager role fitting in relatively well with the open allocation scheme, though, so maybe that’s a potential solution.

Work Style / Structure

It seems like open allocation is only half of the story with regard to getting work done: first you get people together into a team to tackle a project. Great. But now how does that team work on that project? It seems to me that there will be methods and styles of work more conducive to open allocation (e.g. short evaluation cycles for risky projects) such that the well-intentioned team doesn’t end up off in the weeds.

This may mean that there are certain off-the-shelf default conventions for projects that every team starts with. Ideally the organization as a whole is learning something from the experience and performance of individual teams, and this would be one conduit for funneling it back.

Explicit Tradeoff: Project Business Value Experience

I’m also realizing that there is a tradeoff for forcing individual engineers to pick projects: [good] tech managers and executives often bring experience of a potential project’s business value to the table. If engineers are the ones choosing and self-allocating to projects, each lead (and to a lesser extent, each engineer) is being asked to accrue the experience necessary to judge high-value projects from low ones. This is likely to be a long learning process and one arguably orthogonal to their primary job—designing systems and writing code.

You make some excellent points here. Don't get me wrong on this: open allocation has some problems and a lot of uncertainty. It's not a panacea that will make software perfect or workplaces politics-free because such a thing doesn't exist. I do believe, however, that's it's superior to the alternative, which is a corrupt bureaucracy that allocates "headcount" and, by interfering with internal mobility, brings organizational efficiency way down.

Senior vs. junior developers.

For senior developers, closed-allocation babysitting just ruins them. On the other hand, can one really make open allocation work with a bunch of entry-level developers? I'm not sure, but my personal opinion is that you shouldn't be in that "only juniors" situation anyway. Putting managers over such a situation might preserve a sort of structural integrity, but if there aren't senior developers to mentor them, you're not in good shape. Closed or open allocation, that will result in some bad software.

Here's a scale I use to represent individual software skill: The Trajectory of a Software Engineer . The gist of it is that 1.0 represents a reliable adder who can solve business problems, and 2.0 is a multiplier who can tackle almost any infrastructural problems, and the decimal points interpolate using a logistic model (a 2.0 is 95% reliable at "level 2" or multiplicative projects; 1.5 is 50% reliable, 1.0 is 5%). The average software engineer is about 1.2, and 1.5 would be recognized as seriously good or "senior" in most companies. I'm only about 1.7-1.8, and the scale goes up to 3.0. See also: The Unbearable B-ness of Software.

I, personally, blame closed allocation and the paucity of interesting work in our industry for the low quality of software engineers out there. I don't think they're intrinsically stupid. I think an industry that manages people like children or drones turns them into such. Few software engineers get to 1.5, much less 2.0, because they don't have enough autonomy in their work to attempt 1.5-level problems unless they have a lot of spare time for personal projects.

Can sub-1.5 engineers thrive in an open-allocation environment without some mentorship? Probably not. The 1.3's and 1.4's can get there after some lost time to failed experiments, but that might take months. The 1.1-1.2's still need regular guidance, which means you can't have many of them. I don't see that this is more of a problem with an open allocation environment, though. The closed-allocation regime seems to bring up the productivity of the 1.1-1.2 engineers somewhat, but at the expense of (a) reducing the enthusiasm and impact of the 1.5+, and (b) making it rare for people to improve. I can't see this as a winning trade unless you have a huge number of mediocre developers and very few good ones.

I've come to the conclusion, however, that you can't easily have rapid growth (100+ percent per year) and open allocation. With closed allocation, you can hire a bunch of people, invest nothing into training them, and fire the ones who don't figure out a way to swim. With OA, you actually need to give people time to adapt to the culture, and you need to mentor the junior (1.2-1.4) engineers. I think rapid growth is more of a threat to OA than gross size (cf. Dunbar's number). Anything good can "scale" given enough time to reach scale.

When companies grow too fast, they get into an anti-pattern of hiring before they trust, and they become a two-class company that splits between Real Xers and "bozos" (as in "bozo bit"). This delineation may or may not mirror the management hierarchy. At Google, it doesn't. Staff SWEs and some Senior SWEs are Real Googlers even if not in managerial roles.

Economics

You make a very strong point with regard to the fact that this concept of a "committed project" is going to be unappealing to executives. From their standpoint, it sounds like they're paying people "extra" to do their jobs.

I don't know what the best approach to rewarding important-but-not-desired projects is. Large bonuses are usually a sign of something broken, and "performance-based bonuses" turn after entitlements in peoples' minds after one year. Promotions for citizenship are a good idea, but how does one define promotions without creating the sort of power dynamic that open allocation is supposed to prevent?

I think the ultimate answer involves ownership, which is more than just notional equity. People will do the grungy work associated with something they own. Bonuses aren't real ownership, because there's no guarantee of another one. Nor am I talking about equity, which has its own issues (largely rooted in VCs being stingy and setting ~0.1% caps on engineer grants). To make OA work, you probably need a culture where people are encouraged to take ownership-- not behave like an employee. Very few corporate cultures actually exist like that. In most companies, an ownership attitude gets you fired.

Project management and collaboration

I suspect that open allocation will, in general, lead to smaller and more modular software projects. Instead of having the Bigass Single Program that 10 people work on and none of whom have ever run the damn thing in production, you get a lot of targeted smaller programs designed to solve specific problems. You need some senior, mature people, probably in the 1.6+ range, to figure out which modules can be turned into general-purpose libraries, and to direct this work toward big-picture project goals.

If someone wants to be "just a programmer" and doesn't care about making his work useful to other people, that person's not suitable for an open-allocation company, which mandates that people be part PM (and, possibly, part manager/mentor) in addition to being an engineer. People who want to sit back and say, "That's not in my job description" don't belong in an OA company. With the freedom to pick one's own projects comes the obligation to do one's best to make them work, even if some of the day-to-day tasks are boring. (It's called work for a reason. It shouldn't be unpleasant, but even the best of it is mostly mundane.) You do them anyway, because you're expected to own.

That's what I like most about OA. It's an excuse-minimization framework. You can no longer blame a wasted year or shitty performance on being assigned a bad project. It's on you to find (or start) a good project. Good-faith failure is okay-- explain what happened, for posterity-- but there's no excuse for not trying your best.

Length of learning process.

I think that on-boarding people into an open-allocation company will be easier in some ways and harder in other ways. The open-allocation culture is more different and expects more of people, so there's an uptake of that form; on the other hand, I think people will improve faster (and be more motivated to improve their skills) in an open allocation regime. With decent mentorship and appropriate projects, you could probably get a 1.3 engineer to 1.5 inside of a year.

Additionally, as open-allocation becomes more common, it will be extremely difficult to get a 1.7-2.2 engineer to stick around at a closed-allocation shop. (2.3+ can get their own OA, even at a closed shop, but that's about 1 in 500.) You'll have to pay hedge fund money if you want that. Google is already close to banking comp.

What I see as dangerous is open allocation without a culture of mentorship. Under OA, everyone needs to be either (a) very good, or (b) talented and furiously working toward getting good. If nothing else, persistently mediocre people are a culture threat, because at some point there will be a desire to get rid of them, which means "low-performer" witch hunts, which means bye-bye to open allocation and your culture. That seems to be what happened to Google in the mid-2000s (although I wasn't there then).

I love these thoughts; thanks for being thoughtful and sharing.

Senior vs. junior developers

I agree on the general ideal ratio of junior vs. senior engineers. I think you're right too that OA imposes certain limitations on the makeup of your team, which may mean that there is transitional work to be done on that front if you're an existing company trying to move to OA.

I also echo your concerns about team growth velocity. This may impose a filter on the types of companies, or at least the types of approaches to building companies that can be successful with OA. In other words, American Airlines may not be able to transition their software division to OA—ever. Maybe an entirely new company / independent business unit would have to be formed with OA as a first principle and built up from there.

Economics

You hit upon some concerns I was discussing with @therealadam about the economics of rewards. People are strange about money due to structures and incentives in Western society at large that are not likely to change soon. People who are faced with large monetary (or potentially monetary—equity) rewards may change their behavior in unexpected, uncontrolled and inconsistent ways.

I like your concept of "ownership" here. I wonder if that could be translated to a meaningful system of reputation within a company, somewhat along the lines of the RPG concepts you touched on before. If a Level 24 engineer with a ⭐⭐⭐⭐ peer rating was recognizably and significantly better than those of lower levels or ratings, that might create an alternate reputation economy capable of upholding the values that the company seeks, through committed projects and OA in general.

Project management and collaboration

I agree that OA is likely to lead to smaller projects in general, and I agree that this is likely a Good Thing™ for the software, the engineers and the business. I also like the point about senior engineers observing the systems at a meta level to look for abstractions and efficiencies. That could be another incentivized role, if necessary.

On the role expansion—everyone has broader job descriptions—I agree in theory that this is powerful and desirable. I worry a little bit about this pushing OA into Elite-Squads-Only status, though. It may be true that OA only works for teams composed entirely of Elite Squad Engineers (or their junior potentials)—an eventual 1.6+ on your scale—but I have broader hope for it. The question is: Can teams with average or slightly above average engineers embrace OA along with its role expansion, especially into project management, and be successful?

I think Valve is your dangerous red herring case here, because they focus very intensely on hiring only extremely high-potential people. “Hiring is more important than breathing” is something I seem to remember from their handbook. It's a great philosophy if you have the ability to implement it sustainably, but the reality is that most businesses will have mostly or all non-Elite-Squad engineers by definition. I don't know yet where that leaves OA.

Roles are pretty orthogonal to projects. Open allocation doesn't explicitly oppose assining roles to engineers. Programmer Anarchy(advocated by Fred George) looks similar to open allocation but stays away from assigning roles to people.

It may be possible to specify roles generally expected from people at each level.
If you do it, you may not have to hire only elite engineers.

1.2 - You should be able to add small features solidly in a maintainable manner. You should rise up to 1.5 in 18 months after being hired, or you'll be offered a generous severance package(at least 3 months of salary) and a good reference. Low performance should be tolerated for up to the first 18 months as well unless it's severe. Your progress will be checked once a month, which means people can't poke you more often than once a month.

1.5 - You should be able to lead a project, and you're expected to do it if necessary. Your contributions are usually checked once per two months.

1.6 - In addition to project leadership, you should be able to mentor people at 1.2 and turn modules into general purpose libraries if you think it's necessary. You should be able to decide on your own to write new libraries from scratch if you think off-the-shelf open source libraries fail to meet the business needs.

2.0+ - It's ok for you to not engage in daily operations. But, you should be able to mentor others or do some researches to make new algorithms and so forth. In other words, you should be able to do either mentorship or research if you don't engage in daily operations. You will be checked once a year, which means no one is allowed to measure you more often than once a year except when the company is under existential threats.

If you had a software system that calculates or helps calculate engineer level, measuring engineer level won't probably become politically corrupt. Reputation system seems to be a start in this evaluation process. At least, reputation system can't be rigged by a single manager in an open allocation company.

It's a mixture of guild system and open allocation. It's possible because open allocation is not mutually exclusive of mentorship.