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.