Earlier on at Patreon we didn't have a lot of structure like most early stage startups. No real division in teams, folks kinda floated from one project to the next. As we grew and started ramping up hiring we were just establishing an engineering management team. Much of it was folks with no previous management experience (cue "this is fine" gif). The biggest pain point was we all were still expected (possibly a self-imposed expectation to a certain extent) to still contribute a lot of code. This left little time for planning and being more strategic. To be fair though it's a shared responsibility and our product planning wasn't very mature either.
As more people ramped up we needed teams and projects to place them, but since we were hiring a bunch and didn't have enough resources to plan work we needed a way to buffer new hires before long-term assignment. We repurposed a team that wwwjim had started – The Fox Team, a reference to Metal Gear Solid/Kojima – to be a place where new engineers could learn the codebase, get warmed up while product and eng sorted out what work should be prioritized.
This team was maybe a bandaid for organizational issues and shortcomings (or this is just growth ya know that's chill too), but served a purpose nonetheless.
Tired of trying to organize these thoughts so just brain dumping now:
We had 2 fixed memebrs or 3 if you count me as an EM/Hiring Manager and coordinating a lot of this, a PM and an Eng Lead who helped with the more technical mentorship and process management for new hires (running sprints etc). Together the PM and EL worked with Customer Support to prioritize work. Could never get full alignment here, but it mostly worked I think.
Where possible we'd have more than one new hire in rotation which lasted about a month. The team served as a vehicle for new engineer cohorts so they could onboard closely and share notes since they're doing similar work. After about a week or two of general onboarding and fixing bugs there was usually a medium sized project that ideally didn't need much guidance. This rarely was the case and there was usually a lot of back and forth, projects running over or maybe even dropped (shocker!).
In the meantime engineering management worked out who would go where after rotation with consideration:
I'd say most of the time the worked well and people enjoyed the space to learn more about the product and codebase. Some folks want to jump right in to a meaty project or team instead so they may have found less value. We didn't do a lot of follow up other than general onboarding engagement serveys and didn't track how effective the team was in terms of that, but we were closing bugs, shipping helpful projects (mostly internal tooling) and having fun while doing it. Other things came from that team like defining the bug submission/lifecycle process and getting intimate with the types of issues users were hitting.
Personally I really loved that team. It felt scrapy and not perfect, but seeing new engineers get excited about their wrap up project and where they might want to focus on post rotation was really rad.