2

Given the scenario when you want to prepare yourself for hiring a new team, but without really knowing about the next project.

What's the ideal ratio between senior, medior and junior developers?

Having an ideal figure will help us to calibrate the recruiting process. If we would know that we need something like 1x1x1, then we would look for 2 senior developers, 2 medior developers and 2 juniors.

Can you also suggest alternatives if this doesn't feel the right approach?

  • Ideal for what? Am I interested in the long term or the short term? – Nathan Cooper May 14 at 21:22
  • Long term. For new teams, but also restructuring the existing teams. – Adrian Iftode May 14 at 21:47
  • It must depend a lot on the kind of work and on the skills you expect team members to need. Have you asked your existing team(s) what they think? – nvogel May 14 at 22:22
  • 1
    I'd say Barnaby's answer below is probably the best possible answer, but in truth, you're completely ignoring all team dynamics in your model and a great team of novice programmers will out-perform a group of experienced programmers who can't work together any day. – Daniel May 14 at 22:40
  • In the long run, hopefully your juniors will get promoted to mid-developers, and your mid-developers to senior. – Llewellyn May 15 at 16:53
11

I have seen highly effective teams full of junior developers and disastrous teams full of senior developers.

Rather than focusing on seniority and experience, I recommend:

  • Hiring highly collaborative people
  • Looking for a good mix of personality types (starters, completer-finishers, etc.)
  • Hiring people with good leadership skills - willing to step up and lead discussions and help with facilitation
  • Hiring people that value continuous improvement
  • Hiring people with humility, that don't feel they know everything and are hungry to learn
| improve this answer | |
  • 3
    This seems like an unanswerable question as it ignores all team dynamics, but I think this is the best answer possible to give. – Daniel May 14 at 22:39
2

Let me qualify my answer a little bit with this: I do not know if there are any theoretical constructs with Scrum that dictates team make-up so I am answering in a more general way around teams.

I like a lot the bullets that @Barnaby Golden (+1) provided in his answer; however, they are hard to identify during selection process and those things sort of evolve over time with some trial and error selected members. Definitely teaming objectives, but I think you achieve them through evolution and adaptation of your team over time.

A lot of these decisions are made long before you attempt to select individuals on the team because it goes to the size and cost of the team for your project. So you need to make decisions about the make-up early.

With practice and experience, you would expect capability to climb and I think it does to some degree. However, performance is not perfectly elastic and, after 10 or more years of experience, a large population of those practitioners remain mediocre in capability (Boyle, Aguinis, 2011, 2012). In contract, the marginal costs of practitioners generally climb in a more perfectly elastic way with time in seat. Therefore, stacking your team with more senior folks will cost you more but not necessarily, or likely, produce higher performance / output.

My approach, because of the Pareto distributed performance curve (I find this more credible than normal distribution of capability, YMMV), is to assume sub-average to average performance / output by the team and build a distribution that is triangularly shaped based on seniority / capability. I also do not consider a simple count of years as "seniority" so there's nuance to that. While hard to prove, I believe that structure minimizes my cost for that team and likely does not impact either favorably or unfavorably performance.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.