The power of small teams | Hacker News Reader

The power of small teams

a.viary.com

21 pointspsogle14 comments

The concept that smaller teams are more efficient is not new. I've been reading The Mythical Man-Month and it makes this admission right out of the gate. However, as the team gets smaller it also limits the size of the projects it can take on. To that end, what the rest of the book is more or less devoted to is how to do large projects with "small" teams by separating orthogonal tasks and more efficiently organizing the communication structure.

In other words, read the book if you haven't already. ;)

Predating this is 'A Pattern Language', by Christopher Alexander. It seems that teams of < 8 are universally more productive, with ~5 being optimal (at least in Japanese Culture). 'A Pattern Language' is intriguing and useful because it uses real data, and sociological results, to deduce a theory, and makes specific suggestions for architecture and the usage of space. For example, it's suggested that people use converted homes for workspaces, due to the large variation in room size and privacy, and the presence of places to work, think, cook, eat, play, and relax. It also points out that smaller meetings and workspaces are more productive, and supports this by showing a graph of '% of people never to say anything' or 'ideas not expressed' versus participants in a meeting).

I work for a startup now valued at around a quarter of a billion dollars that's negotiating enormous deals with some of the largest providers out there... and our entire development team can fit around a dinner table. In fact, we have significantly more products than we have programmers! Our new CTO, who previously worked at a much larger company, was utterly shocked when he found that our massive product lineup was developed by such a small team.

There's also a huge benefit we gain from using existing open-source solutions whenever possible--if you avoid NIH syndrome and stop trying to reinvent the wheel, you can regain a huge amount of productivity.

Growth is tough in general. A team getting larger forces a leader or leaders to emerge. Not everyone can lead or manage. Not everyone takes direction well. All separate skills from just being able to code or design.

Larger teams is where politics come in and where I don't want to be. Ideally I only want to work in smaller teams.

Put walls between people, and you'll need to hire more people to coordinate them. Dirt basic common sense, yet one that most organizations have a hard time with. That's a cultural issue. Everyone's allergic to working on tables.

Someone once wrote a comparison between DB2's architecture and Ingres. Both are the exact same kind of application built on similar kinds of machines at around the same time. Yet Ingres was built as 4 separate process. The Ingres team was organized in 4 separate groups.

That's a nice example of Conway's Law.

http://news.ycombinator.com/item?id=82997

I find the author's assumptions that every idea stems from one individual and must be (ineffectively) communicated to everyone else to be rather strange. I'm all about small teams, and I personally prefer to work alone, but to ignore the contributions that are offered by other members of the team is folly. The "corruption [of ideas] at multiple points" that he mentions could just as easily be interpreted as improvements on the idea.

Improvements are mutations that fill in the gaps where information is missing. Some mutations might be improvements. Most aren't.

Though the article was interesting, it's nothing that isn't said a lot: quality communication is necessary and also hard; quality communication between more people is commensurately harder.

On another note: the link to hitmeuplater.com was neat. I hadn't see it before and think it's a cool idea.

Sure, but if you attend any demo type of conferences you'll see a lot of entrepreneurs who brag about how they are growing their team out to 20 people over the next x months. There's no justification offered as to whether those people are actually needed... just the general "we're going to become a huge company". It's like the startup equivalent of a penis measuring contest is staff size (and don't get me started on funding raised).

Software development management is all about balancing "one is the ideal team size" with "this project is going to take 200 man-years." You sacrifice productivity in order to complete stuff in a reasonable time frame.

Communication is actually bad. It inherently involves a loss of information.

Sounds to me like Avi is in the business of telling rather than being in the business of doing.

Er, you mean the opposite. There is no advocating telling, only doing, in this article.

I stick by what I said.

I believe communication to be the fountainhead of motivation and inspiration in any functioning work environment.

I say that the author is in the business of telling rather than the business of doing because anyone who is doing knows that it's their relationships with those around them that keeps their limbs moving.

People were not born to be communicated to. Communication is not a one-way street. The author's strategy is optimized for telling rather than sharing, accounting in no way for the value of discussion, critique and collaboration.

A strategy of working in small teams can be great, but don't let its motivator be to cut out as many communication points of failure as possible.

Reply on news.ycombinator.com