There was a manager I worked with recently who was having serious trouble with their onboarding process.
Working with several teams of between 5 and 8 developers, the business was growing fast and recruiting at all levels. Some of the recruited developers were straight out of a code academy, with minimal experience of working in a team, on a regular release schedule, or with production code.
These less experienced developers were their primary challenge. The one they thought could release most value. But how do you get a developer enough experience to graduate them to being part of a team? How many of these developers can you put into a 5 to 8 person team and the team support their learning and progression so they might become independent? How do you introduce them to the team? What does the average day look like for one of these developers while they learn the ropes?
The solution that was in place at the time was adding 5 to 8 of these new starters to their own team, and either giving them tasks which were also being completed in parallel by a team working on production code, or to give them dummy tasks which would allow them to learn and progress.
The trouble with those solutions is that they never expose the new starters to real life scenarios, methods or code, so although the individuals will become more experienced, it isn’t the exposure they need to allow them to then progress to other existing teams.
The answer to the problem was immediately obvious to me, but this choice often needs justification, validation and comparison to alternatives to convince others.
Working with another developer in a navigator / driver scenario is beneficial to both those sat in front of the screen. In larger groups it can be powerful to help solve more challenging problems, or refactor complex code. In a pairs you naturally find yourself explaining and justifying as you go, improving your own awareness and decision making.
The answer to ‘How many less experienced developers can a 5 to 8 person team support at one time?’ is actually ‘How many developers with enough experience to develop on their own does the team have?’
Any developer in a strong team can pair code. All pair coding is beneficial for learning, understanding and team building.
Instead of putting less experienced developers on irrelevant tasks which add no value to the business, instead put them in a team, and in mutually beneficial relationships where they can become knowledgable about the codebases, processes and best practice that the team work with.
In a team where safety is primary, they’ll feel confident enough to ask those stupid questions that you need to ask to progress. They’ll likely ask questions which result in improvements to how the team functions.
In a large enough business, where multiple teams are in play, with sickness, holidays, retirements and career changes, you have to grow your teams in all directions.
A useful analogy might be a professional football team. The club will use transfers to bring in more experienced players who are immediately ready for first team exposure, but it doesn’t stop the team also having an academy where they nurture great players with limited experience. Players of all abilities train together using the same methods.
Hire for potential. Use the teams to grow more teams. Invest in relationships as well as focusing on output.