My original suggestion was this: We create a queue of trial projects per cell. Every recruitment round, the Hiring Manager pop projects from this queue as needed by his recruitment activity (in the onboarding phase, after the candidate passed the interview). After the round, the Hiring Manager reports back projects that were not used, so they can be assigned and finished in the next sprint.
Primarily, it would be the cell Epic Owners’ responsibility to identify and assign trial projects to the trial project queue. Epic Owners are the individuals closest to the client, aware of the scope and planning, and have the best information to make the distinction of what is a good trial project and what is not, that is, projects that (a.) satisfy scope, (b.) can safely spillover to the next sprint, and (c.) can fail on budget (recruiting would be the buffer). Maybe (a.) is something that every Opencraft member can do, but Epic Owner will probably know better since he has the technical background, knows the project and the client. If we don’t have a clear definition of what is a good trial project, I think we should immediately create one before anything else.
Now, at the beginning of the recruiting round, the Hiring Manager determines the desired number of newcomers (the same process as today) minus the number of available trial projects. Once a newcomer is successful at the interviews, the first project in the queue is assigned to the newcomer, as part of his onboarding. The hiring manager finds a reviewer, which is the equivalent of the mentor. Any successful candidate, that is, candidates that have passed the interview but don’t have a trial project yet for them, wait in the Hiring Manager queue until there are more trial projects available. It’s the Hiring Manager’s responsibility to prioritize and manage the queue of candidates. It’s the Epic Owner’s responsibility to populate the cell’s Trial Project queue.
At the end of the round, I think it would be a good idea for the Epic Owner and Hiring Manager to coordinate on what projects were assigned. That means if a project was pushed to the trial project’s queue but not assigned in this round, it should be assigned to a regular core member so the customer won’t be impacted. This brings us back to the point that, trial projects are OK to fail or delay for one sprint. It is guaranteed that they will be done in the second since a core member will grab it out of the queue if not used.
(Oh, and it sounds like Epic Owners will need some budget on their own to sort out Trial Projects and assign them to the queue. I believe recruiting should be the account to log that and not use the customer’s budget.)