Jelled Software Teams

A truly jelled software development team is a beautiful thing to see in action. They talk to each other, not around each other.  They hold each other accountable.  They push towards a goal together.  They deliver very cool product that they are passionate about getting right.  They take pride in their work. They occasionally goof-off together. They have one goal, and they all know what that goal is.

If the team is functioning right, they care more about getting the product right for the customer than what an internal stake holder (like the CTO) thinks. They are willing to fight and standup for what they believe the right thing is to do. Like I said, it really is cool to watch these people in action.

But, here is the thing: not everyone recognizes that software development is a team sport, and as a result teams are often mismanaged.  Computer Science and Engineering degrees teach the discipline as a solo effort.  In college, you work on projects by yourself and rarely collaborate - and then when you get into private industry, you are thrown into a team to work on a product. Stake holders and senior management in many companies come from sales backgrounds, where they rise through the ranks competing against other people in their own teams, and generally struggle with what it means to build a well-functioning team.  People with accounting and liberal arts backgrounds might not get it get it either. Heck, a lot of technology leadership struggles with this too.

I could write a book on what it takes to build great software development teams (and some day I might), but if I could give someone some quick advise there two things: form small teams and lose the command-and-control leadership style.

Any software team with more than 3-5 people on it makes it difficult to jell. Meetings take forever, you loose track on who is working on what, and use loose some of the closeness that comes from working with a small group of people.  This small team is not a "chief surgeon model", where one person is the principle and everyone else is there to help him or her.  This is a team of peers where everyone has an equal voice at the table.

The right sized team is about 5 people and consists of 2-3 developers, 1 QA person and a product person.  A technology group may consist of many of these kind of small teams all working on different tracks during a release cycle to get something out the door.

To have strong jelled teams, you really have allow them function as peers to technology leadership.  In the 21st century, especially when dealing with knowledge workers like technology people, it isn't unusual for an someone to know more than their boss about something.  And, that is OK.  It shouldn't come as a challenge to authority, but should be encouraged. Mistakes will happen, but a good team will recover quickly and learn from them.

Some great benefits from jelled teams: they are happier, enjoy working together and deliver better product. Turn over and discontent also go down. People stop complaining to their manager and start talking to each other to solve problems.

It is worth the effort focus on teams.  Like I mentioned in a previous post, most teams have people problems not technology problems, and having jelled teams goes a long way to solving them.