I’ve been on a few rural teams and seen a few more. The question I’ve run into several times regarding Rural Sourcing is…how many entry-level folks can we use and still be effective? Having led a team of WAY too many interns, this is a valid question. The tendency of management types might be to overload the team with interns to achieve the lowest blended rate… but you end up trading productivity and quality for cost, which is a losing proposition for everyone. I think there is a balance of talent with which you can achieve a lower blended rate, but still have enough expertise to maintain an effective team.

The personnel on a rural team (or any software team) generally falls into four categories, intern/entry-level, apprentice, journeyman, master. These roles are hard to define, but there is some definition for many people, and we come reasonably close to each other. I’d like to define for myself at some point my opinions on what puts people into these levels. The beauty of having an enthusiastic, talented group of folks is that team arrangements are flexible as long as you follow some guidelines:

1. Interns and entry-level developers do not need to be coached by a master. In reality, the questions they have can mostly be solved by apprentice programmers, after all, they went through the same challenges not long ago and can better appreciate the difficulty.
2. Masters have an intrinsic understanding of relatively complex concepts. As such it may be hard for them to explain such concepts. Let journeyman programmers be in charge of mentoring apprentices and interns.
3. Don’t expect anyone to spend most of their time mentoring. It is tiring and sometimes frustrating and could turn into resentment. Plus, they are too valuable to the team to not be developing, designing, etc.
4. This could be a separate topic on its own, but there is a downside to developers more than one level apart pair programming together. There are definitely exceptions, but it is usually a suboptimal use of resources. Having a journeyman pair program with an intern could be intimidating for the intern and frustrating for the journeyman. It usually ends up with the journeyman writing the code whether the keyboard is in front of him or not.
5. Do code reviews. This isn’t so much relevant to team structure, just a good idea in general. You do need to make time for them though.
6. Do not have more interns than you can mentor. Interns and entry-level developers need some type of mentoring about half of their working hours for their first project (this includes side-by-side programming, code reviews, mini-lectures, etc).
7. If someone likes to mentor, let them mentor (as long as they don’t overdo it and become a know-it-all). If someone doesn’t like to mentor, don’t make them, even if they are a master.
8. Masters are hard to find and you won’t have one on every project (I’ve only really met a few)
9. Try to have a mix of talent, it makes for a better team and better career growth.

I could go on longer, but this is a good starter set.

Now for the fake math! I love it when others do this type of pseudo-algebra because it’s such a generalization and the numbers are completely unscientific, but I’m going to do it anyway. There’s no time for a scientific study and it’s nearly impossible to take individual personalities into account so here’s my purely subjective hypothesis on what might be a “good” approach:

1. A day is 8 hours long (in case you haven’t experienced that, yes, it’s true, I saw it happen once)
2. For every intern day, try allocating 4 hours of mentorship time (by an apprentice or journeyman)
3. For every intern day, one of his mentorship hours must be performed by an journeyman.
4. For every apprentice day, you need to allocate 1 hour of mentorship time (by a journeyman or master)
5. An apprentice can only spend 2 hours per day mentoring
6. A journeyman can only spend 4 hours per day mentoring
7. A master can only spend 2 hours per day mentoring (too much other important stuff to do).

Trusting that my arbitrary premises are correct, for a 6 person project, if you wanted an optimal team, you could have a maximum of 3 entry-level folks. It’s hard to say whether a team of 3 journeymen and three interns would be the most effective configuration for 6 people, but if more than half your team is interns, you’re probably not making efficient use of your talent.