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