The problem with big teams

 

 

If two are better than one, a small team is better than two then a big team is definitely better than a small one. No?

Intuitively it seems that the more people you have, the better.

For a software team, this is just not true and not because they are mostly introverts.

In the entry, what to consider when growing a software team, I hinted you should consider limiting your team size.

In this entry, I define a big team as one having more than 10 members. These kinds of teams come with their own set of challenges.

Communication over head

Have you ever tried to organize an unscheduled all hands meeting?

Getting schedules to match is almost impossible even with oversight into what is going on in the entire organization.

Now imagine an individual developer trying to get her blockers worked on in a 10+ person team!

What ends up happening is she spends most her time communicating with other people trying to get work done instead of you know, getting the actual work done!

This is not the perfect picture of effectiveness.

Individual effort lags

Maybe it’s because people feel less attached to others in big teams I am not sure. What is certain is less work gets done per person in teams.

It is natural to assume that someone else will do the work. In small teams, this assumption comes into sharp contrast. If you are not doing the work then who is?

Sluggish behaviour is likely to be more quickly noticed by the rest of the team.

As the Poppendiecks say:

Peer pressure is far more effective than the concept of a boss and much more powerful

In big teams, no one has the cranial capacity to keep up with what everyone else is doing so they just assume they are slacking off and do the same themselves.

Collective ownership goes down the drain

Just as there is individual skill, I believe there are also team skills which need to be nurtured.

When teams are large, the production line becomes the most effective way to organize work.

This is fine if your work can be broken down into small sub tasks which can be easily tested for completion.

Software projects are the antithesis of such work. To be successful it’s critical that all team members have a shared mental model of the product they are building and have a clear understanding of its value to the customer.

The negative effects of hand over will get to you before any Taylorian benefits flow.

There is no direct line between team and individual success

We are all the centre of our own universe. If I have pulled off several all nighters on a project (I don’t recommend this) then I want to see myself acknowledged when the product is launched or another similar success event happens.

If my individual effort will never be recognised anyway, then why bother putting in more effort than is expected?

In small teams, what each individual did can be clearly seen in the work output. This makes the work personal and meaningful with the effect that everyone is now more committed to it.

How big are the teams in your own organization? Talk to me in the comment section below or on my twitter @jchex

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Published by

jchencha

API Engineer