On any team, you are going to have the need for more grizzled and grey developers and some young pups. Some reasons include:

  • Money. There are often tasks that don't require the same level of experience to deliver, so it makes sense not to pay top dollar to have those tasks fulfilled.
  • Energy. There's an energy and enthusiasm that new people can bring to a team that stops it from getting too stale and set in its ways. There's also calmness and wisdom that the more senior people can bring.
  • Knowledge transfer and career growth. Both in terms of the project and skills, it's useful and often fun to teach people and to learn new stuff. It's satisfying to help "bring on" new team members.

I realise there are some cutting edge projects where it may be important for there to be more senior people than junior, but in general, is there an ideal mix of experiences on a team, or is it totally dependent on the project?

3 Answers 3


I really like what Eric Brechner has to say on this subject

Think of your team as a river instead of a lake. A lake stagnates. There’s no energy or impetus to change. The same is true of groups that stagnate. They cultivate mediocrity and complacency; they abhor risk. A river is always running and changing with lots of great energy. You want a river.

A river depends on the flow of water, and your team depends on the flow of people and information. You can think of the people divided into three groups: new blood, new leaders, and elders ready for a new challenge. Here’s how those groups should balance and flow:

  • The largest group should be the new blood. Not all of them will become technical or organizational leaders.

  • Sometimes you’ll have more new leaders than elders, sometimes the reverse, but ideally you should maintain a balance.

  • For flow, you want a steady stream of new blood becoming your new leaders, and new leaders becoming elders.

  • The key to flow is new blood coming in and elders moving out. For this to work, you WANT your elders to transfer before they clog the stream and disrupt the flow of opportunitiesfor others.

Not all technologies flow at the same rate. Central engines, like the Windows kernel, flow slowly, while web-based services, like MSN Search, flow quickly. You need to adjust for your situation, but even the most conservative technologies do change and flow. How do you successfully encourage and maintain a healthy flow?

  • Keep a constant supply of new people.

  • Instill information sharing as a way of life.

  • Shape the organization and roles to create growth opportunities.

  • Find new challenges for your elders.

  • When we have right mix up programming becomes fun!
    – pramodc84
    Sep 6, 2010 at 5:13
  • 6
    I hope that "find new challenges for your elders" isn't a euphemism for laying them off! Sep 6, 2010 at 6:09
  • The only thing I see wrong with this is that it assumes that elders are always leaders. I've met seniors who don't want to lead or just aren't that good at it. Jan 4, 2011 at 22:21
  • 1
    @Conrad - That's the wrong quesion. The question is "Would you want senior people who are no use to the overall organization?" The answer to that is of course no. One does not have to be useful as a leader to be useful to the overall organization. Jan 5, 2011 at 1:19
  • 1
    @Jason perhaps we're disagreeing on what a leader is. To me a leader is anyone that has a role greater than a heads down developer. e.g. Taking on a design/analysis role, a PM role, a mentoring role, etc. I think someone who wants to get a pay raise every year and still be a heads down developer will over time reduce the value that they bring. Jan 5, 2011 at 16:32

I don't think there's any ideal mix- it's entirely project and environment dependent. A couple examples:

All Experienced

It might be appropriate to have all experienced team members on a critical project with a tight deadline, where there's no room for junior developers to get up to speed.

All Junior

In another example, it might be appropriate to have all Junior developers in a more R&D oriented project. There was a team at one company I worked at made up entirely of interns to whom projects that needed an innovative (but not necessarily fast or correct) solution were assigned. They were real customer problems, but they didn't have any known good solution, so they got interns who would be new and have few preconceived notions.

The point here is not that either of these approaches is often right- more that projects will run the entire gamut between them based on business needs, organizational factors, and the availability of developers.

  • 4
    I would think it would be useful to have at least one senior developer on almost all projects, even if they aren't working on it full time
    – Casebash
    Sep 3, 2010 at 23:57
  • 3
    In my experience "innovative" usually means a load of juniors burning the midnight oil writing their own, worse, version of something which already exists in the toolset. Or maybe I'm just stagnating.
    – NeedHack
    Nov 27, 2012 at 16:32

I think the ideal would be to have no specific distinction between “junior” and “senior” at all. People should be treated as individuals, not as items in a drawer. Similarly, each project should be treated as an individual problem that requires individual skills, talents, or personalities to solve. Any such classification into “junior” and “senior” only serves to turn reality into a coarser and coarser approximation of it and thus makes it less and less likely that the decision made in each individual case is in any sense “ideal”.

  • 2
    I think that it is a useful distinction to make, as long as you recognise that some people may be right on the edge of the Junior/Senior divide
    – Casebash
    Sep 4, 2010 at 22:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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