What is the best way to divide a development team?

Question

I lead a medium sized team of developers whose skill, age & time in the company vary for quite a bit. Some of the youngest in the team are considered profficient while some of the most seniors (age-wise) are outranked by a large part of the team. Plus, we have new people with less than 2 months in the project, while others have been for more than 3 years.

The problem I have is that we have a new project coming up everyone wants to get into, but everyone is unfamiliar with the skillset required for it and I have to divide my team in two for at least the first couple of months: some of them will stay in the current project, while others will get to work on the "cool" project.

In the long term I have already made it clear everyone will get their time on the new project by scheduling rotations, however everyone is eager to get in there first.

I have some concerns with this:

• If the experience on the skillset required for the new project is basically the same among all of the devs (quite low), based on what should I choose who moves and who doesn't? Experience is really not a factor i can rely on.
• How can I justify the desicions I make (or even, should I try to justify them?)
• What's the best way to keep morale up for those that don't get moved into the cool project (repeating "you'll get your chance soon" at some point will not be enough)

I have thought of doing small quizes so that I can pickup who's in the best shape or have at least the most knowledge needed for the "cool" project (which kinda gives me some justifications for my actions), however I also think I should just go with those I believe who can get the job right (basically a hunch which would led me to pick those I already have worked with, which practically gets the new guys out of the game).

Any advice would be highly appreciated.

Answer 1

Experience is a weak indicator for future success (Hunter & Hunter, 1984). So feel free to remove time in chair as it will not hurt you. Age is a zero indicator for success (same study) so definitely remove that from the equation. Your best predictor is cognitive ability, to be able to think critically, to be able to analyze. Since all of your developers have the basic skill and knowledge set, take the ones that have shown their ability to analyze, the ones that have exhibited intelligence above all others.

Develop a structured interview, a set of questions delivered to each candidate that will expose their ability to think, to ask the right questions, to theorize, to get into the abstract. Choose the ones who scored best.

In all cases, remove your gut feeling. You're biased like the rest of us and likely your gut will have little to no validity of future success. I know that reads very counter-intuitively; we all tend to rely on it, and experience, and that is why our selection process is about 50/50 in terms of being successful. That's a coin toss and you cannot run a business with a coin.

Answer 2

Some points from my side to add to the ideas already expressed:

• don't promise anything you will not be able to honor, or make it clear that is your intention and may be subject to changes. Even when this could seem very basic when dealing with mature adults, it can be surprising how not meeting these kind of expectations can demotivate someone.

• consider not only the needs of your new project, but also how to guarantee that the old one will have an smooth end.

• if your group is new to the technology or sector, you should start by moving in the people who are better self-learners/self-starters and will definitely include some seniors that could guide the process. This can help for the project to get some quick wins that will help you to gain some credibility in front of your management or customer. Also these starters will help others to come onboard easily.

• about explaining your decisions, do as usual or you will be questioned. In general, I prefer the more openness that the topic allows but you must stick to your style.

• avoid converting the assignment into a prize/penalty thing, you have other important drivers to take the decision in this case and the best motivator scenario may not be the best business one. As Corleone said: "It's only business"

Answer 3

I did some experiments in the past and it seemed that those teams were successful, where the members where able to work together before. This setup were way better than the setup when the team setup was based on the necessary skill sets.

My suggestion would be to setup teams based on the existing "small groups". People with the same understanding learn more and faster. There will be some storming, but it won't hurt that much. The most common mistake I see today is that the line managers search for developers with the necessary skill set - handling them like resources - to start a project, and ignore the ideas of team dynamics. Their argument is that people learn to work together faster than learning something new. I see this argument valid under special circumstances, but I don't support it.

What's the best way to keep morale up for those that don't get moved into the cool project

My problem with this part is that the old project is considered not cool. If I were you I worked on this issue and find out why the old project is not cool, and how to make it cool. Usually, the old not cool projects keep a company alive, so maybe you can use this argument to sell the team separation.

To sum up: try to find the small groups in your current team by face-to-face or small group conversations and find out what is cool in the old project and sell that idea. Their might be somebody who'll love it. Talk to them and find out.

Answer 4

If there are truly no advantages in people's existing skillsets, then you have to look at other factors. You need a good mix of solid developers and more wisened developers to ensure success, especially since this is out of everyone's comfort zone.

I would first look at your more senior (company-wise) developers and chose the ones who are some of your more productive and hard-working developers. This should be seen as a reward to some extent if everyone really wants to work on it.

Once you have a core group, I would look at your senior (experience-wise) developers and chose at least one (maybe two depending on the size of the project) to get things off to a start. Again, since this is out of everyone's expertise, you need to pick people you have been able to rely on. These more experienced developers should help you be able to identify project risks even if this isn't in their wheel house. And you need people looking out for risks (technological, schedule, and otherwise) because this is a brand new project using a technology that you aren't experienced with.

As for justifications, everyone can't work on the new project. The developers know who the better and more hard-working developers in the group are, and the people who put in less effort can't really complain about being excluded from the start of the project. Good people have the option to leave you. Don't give them a reason. Then you need some experienced people to help mitigate project risks. Again, if you chose the one(s) who have proven themselves in the past, the others can't really argue.

You're the manager. You can't be everyone's buddy. Sometimes you have to make unpopular decisions. Try to be unemotional like Mr. Spock in presenting your reasoning. And you may want to announce the bad news to people individually or in small groups if you are really concerned about reactions. This will give people a chance to vent (on you) without creating a huge wave of negativity. Make your decision and announce it to everyone (individually or in small groups) as quickly as possible. It's bad news. Get it out and get over with it quickly so the rumor mill doesn't have time to spin up.

You may be able to spin some of it as a chance to learn/manage new parts of the system for the folks staying on the old software. But that's not going to get you very far so don't oversell it.

Answer 5

Until you are better able to judge who will be most suitable to lead aspects of the project why don't you use a rotating leadership chair? The approach could work similar to having everyone rotate roles and a team rotation (Junior Dev, DBA, Lead dev, Architect, etc.) every 2 (or n) weeks.

To kick things off you could get everyone to cast an anonymous vote as to which team and which role they feel one other team member should have (obviously the voter cannot vote for themselves).

Pros of the approach

• Allows you time to responsibly evaluate team members.
• Gives everyone on a team a sense of fairness in joining the cool project.
• Give you a time frame to transition out undesirable resources.
• Lets people who may not "get along" to be split into two separate groups.

Cons of the approach

• May add risk to the project a rotating lead will most likely lead to a lack of cohesive consistency in the code base.
• The team may feel there is too much chopping & changing within the project, which in turn may damage morale.