I’ve had the occasion recently to work on some projects in very small teams, just 2 or 3 others at most. This experience has rekindled in me a joy for this kind of working environment and atmosphere. There’s just something about not being lost in a sea of teammates or (even worse, leading a giant team) that really appeals to me.
As I thought through this more, I began to realize that this isn’t simply something that I enjoy, but something that has that “right” feeling about it – it just clicks. The following is a list of things that I believe are beneficial about operating in small teams and some of the things that flat out cannot be duplicated within a large team structure.
Note: Most of this will be obvious to people and I’m sure it’s all been said before, but let me have my fun and blog about it…golf claps at the end would be appreciated.
Low Tolerance for the Silo Effect
When teams are small it’s almost impossible for silos to develop. Even in the face of explicit attempts to make silos, in a small team they just don’t materialize. Whether this is a result of a smaller domain or the low communications barrier, the benefit is clear. Smaller teams have a much easier time cross training because they hardly have to do it at all, it’s a natural phenomenon that occurs when living so close to someone else’s code.
Nobody Hides Behind the Wall
On large software teams, I use the phrase “throw it over the wall” to describe the interaction that often occurs between one part of the team and another. They don’t really care who’s on the other side of that wall nor what they’re throwing for that matter. Status just needs to be reported as: We made something, and we threw it over that wall. The wall could be the one between development and QA, between the business and the BA team, or between the BAs and the developers…point is, it’s a wall, and stuff get’s chucked.
Clearly, this is a terrible way to work and it reduces overall quality because people rely on the shleps on the other side of the wall to complain before they’ll deal with their mistakes. This cannot occur in a small team because the walls are too short for you to throw something over it and still retain the comfortable anonymity that a higher wall would provide.
Sorry: Took that analogy a bit far!
We Don’t Need No Stinking Managers
While this is not strictly true all the time, my point is that with small teams the oversight tax is quite minimal. As a team grows in size the amount of overhead incurred by management rises logarithmically. By the time you have a team of 20-25 developers, you have so many tech leads, architects, and project managers installed that your 2 for 1 pizza coupons are no longer valid.
Management and oversight is important but not at the expense of agility and direct (peer) accountability. Small teams rarely have this problem and often a single manager can provide adequate oversight for more than one semi-self-governing project.
We Built [more of] That
This one is just my opinion, but when a large team builds an enormous software product the “I made that” quotient per individual is very low. When a small team builds a substantial software product for their size that same metric goes through the roof. It is profoundly more satisfying (for me anyway) to be part of a 4 person team who accomplishes the work of 7 over being part of a 23 person team who comes in over budget and delivering less scope. Again, just my opinion.
Craftsmanship and Apprenticeship <3 Small Teams
This one may be a bit controversial but I believe it’s more difficult for mentorship to occur on big teams. It can happen of course, but the ratio of highly skilled craftsman to more junior developers forces those highly skilled individuals to be spread too thin on large teams. On a team with one seasoned journeyman and two apprentices, the two junior team members will learn a lot more simply because they have more concentrated contact with their mentor…and vice-versa.
That’s it…I’m sure there are loads more benefits (and joys) that people can identify from working in small teams but these are the ones that came to mind at 1:30 in the morning. I’m very much looking forward to continuing the trend of working in smaller groups and delivering better software for it.
DevMynd is innovation firm in Chicago and San Francisco with practice areas in digital strategy, human-centered design, UI/UX, and custom mobile and web application development. The firm’s mission is to help its clients use technology to solve meaningful problems that have a profound impact on life, society, and business.
