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