Healthy team

I’ve had recently a few conversations about what constitutes a great software development team and I found myself using phrase ”healthy team” a lot. It’s a rather vague expression so the goal of this blog post is to explain what I mean by it.

People

A healthy team consists of people that share the same vision (the end goal of the project) and the same basic principles (high care factor, working as a team, not leaving broken build overnight, etc.). Even one person that doesn’t share them can cause a fair amount of frustration for the rest of the team and frustration is what needs to be avoided at any price as there is nothing that kills productivity faster.

Skills

In ideal world every team would have only senior members that are highly skilled and experienced. In real life this never happens and to be honest I don’t see any problem with having junior members on a team as long as they want to learn,  are capable of learning quick and there are not too many of them. If I had to pick I would say 1 junior for every 3 to 5 senior members is more or less the right ratio.

Software development is complex and it’s unreasonable to expect software engineers to be experts in every possible technical area. That’s why I believe every team needs to have at least one expert for each significant horizontal/cross cutting concern. Such a person would ensure consistency and correctness across all vertical features. One person can drive multiple horizontals. Sample horizontals: CSS, deployment, messaging, etc..

At the same time all team members, including experts, should work on vertical end to end features and ask experts for help when they struggle with a certain horizontal concern. In this way knowledge related to horizontals flows from experts to the rest of the team. On top of that every team member can influence a horizontal with experience he’s gained working on vertical features.

This approach takes initially more time than splitting the team by skills and let people work in isolation on what they know best. But there are a few very valuable advantages of this approach in the long run. Team is more resilient to departures because knowledge is shared and the quality of the final product is higher because the product is created based on feedback from both horizontals and verticals. Obviously, there are certain specialized areas of software engineering which might not work with this approach but it should be just fine for most of us.

Leadership

I’ve worked on a few projects where there was no team leader and this always lead to the same problem. Different team members had different visions of what we were trying to achieve and how we were supposed to achieve it. I know this might be a slippery slope and be against some of Agile principles but at this stage of my career I believe that every team should have a team leader to make sure everybody is going in the same direction and that the team avoids basic/fatal mistakes.

A good team leader is experienced, trusts other team members, treats them as partners, listens to them and always is more than happy to answer their questions but at the same time should be able to make the final call when it’s needed. And no, I’m not trying to promote absolute dictatorship as way of leading teams :).

Process

A healthy team is a team that is as independent as possible and is not hindered by the process it needs to follow. On top of that the team members should be able to use tools that make them most productive and they should feel that they are in the driver’s seat.

Size

I believe that a healthy team is a small team. Ideally 5 to 7 people but no more than 10. More than that and communication becomes challenging which slows down knowledge sharing and increases frustration.

Update: I've been asked a few times if 5-7 is the initial size of the team. The short answer is no. Ideally 2-3 people form the initial team and then bring more people when they are needed and team is ready to accommodate them. I didn't write 1-3 on purpose because I think that it's always good to have someone that you can bounce your ideas off.

 

The order of paragraphs matters but all of them deal with important issues and I wouldn’t ignore any of them lightly.

The blog post has been updated on 24/01/2012 with comments about the initial size of the team.

Tags: Software