Items tagged with

Team-Sized Work and Tribe-Sized Work

I subscribe to a discussion group called “TorCamp”, which is a small slice of software people in Toronto. There is an interesting discussion ongoing about Time Magazine’s “Small is Essential” article on 37Signals, the company that makes basecamp and backpack, and one of the chief promoters of Ruby on Rails. The article implies that small companies are The Way to Go, and that we no longer need to big build organizations in order to get big things done.

My take (reposted from the discussion thread):

There is a sort of “magic” about very small groups:
- you know everyone, what they’re doing, and how your work relates to everyone else’s
- very low communication overhead
- only one leader/manager required to handle tiebreaker decisions
- incompetent people and jerks have nowhere to hide :-)
- you stay focused on the core, because there is generally not enough money, time, or skill to take on on low priority objectives

I’ve found you can keep these qualities in a team up to about 60 people in size. But that was really 60 people subdivided into several smaller groups of, say, 5 to 12 people, each with a group leader, rather than one big 60-person team with a completely flat management structure. So at the core it was still a bunch of small groups, banded together into a bigger tribe. (Anomaly: Google apparently has a 50:1 engineer-to-manager ratio, and I’m curious as to how well that works.)

At some point — a 100 person tribe, let’s say — the team members don’t all know each other, or what everyone is doing, or how it all fits together. So you resort to more communication, more managers, more reliance on formal “deliverable agreements” and architecture and tools (like basecamp) guiding the collaboration.

There’s also a correlation with the nature of the product that’s impossible to disentangle. Small groups tend to take on smaller goals, and build smaller products. Big goals and big products require more brains, i.e. tribes. You can’t argue that taking a spaceship to the moon, for instance, could have been done by a lean, mean, 8-person version of NASA. The problem space was simply too big, no matter how you sliced it. So should we not have gone to the moon? Heck no! We need to do big things too. So small teams are not a cure-all. The world needs big tribes too.

That said, if you can chunk tribe-sized work into an architecture that allows a lot of small teams work on it in parallel, with a minimal number of interdependencies, do it. And I agree 100% about the earlier comment on passion: I’d rather work with 5 people who are passionate about what they’re doing than 10 who feel it’s just a job. Life is too short for the latter.

Related: The Dunbar Number as a Limit to Group Sizes