Time Magazine on 37Signals "Small is Essential"
clickryan
In short they talk about their philosophy that "Small is Essential" -
no longer do we need to build huge companies (many employees) with
high burn rates monthly.
I'm a huge fan of the simplistic software as a service and their easy
to use interfaces.
http://tinyurl.com/279jj4
Photo of the team > http://tinyurl.com/34k2fu
I'd be interested to know what other people's thoughts are about size
of Dev teams & what you think of 37Signals software. I'm a huge
BaseCamp fan, recently started using HighRise (thin CRM tool) and I'm
thinking about using backpack and campfire.
Thoughts ?
Brill
I've seen smaller teams of say 6-8 developers (including QA) succeed
where larger teams often fail.
I've actually been thinking about why that is recently and my
conclusion is that it's much easer to manager and cut out cruft (both
for the managers and the developers) that just isn't needed
By having a small team, particularly if you use good agile practices
you get a team of experts in a particular product. Fewer people does
mean fewer resources to burn, but most products really don't need
larger teams unless the product is not very good in the first place
and it takes developers too long to implement features (which is an
indication of other problems and doesn't really mean you need a bigger
team, but that you need to pay attention to how you organize and what
work you do)..
I think that good project management is essential for keeping those
small teams running smoothly. I think every manager has wanted more
people but there seems to be a limit on the team size (although I
don't know what's optimum) before you risk losing of control of the
flow of work, at which point things that will slow you down get
introduced into the project and/or codebase.
Communication between the development team starts to break down as
well, so you lose your team of experts that know all parts of the
system... and when that happens you start having to break the work
into small teams that you now have to keep running smoothly in
parallel; which of course get more and more inefficient and causes you
to add more people which continues the cycle.
One author (can't remember the name of who I'm paraphrasing) said that
there is simply a limit as to how fast you can write software, and I
think that carries over into or is manifested in the size of the team
(although I'm sure not the only manifestation).
As with anything, that is likely a balance for you project that is
above or below that 6-8 people and its up to you as a manager to
figgure out what you really need.
Ok, now to go read the article and see if they agree with me :)
- Brill Pappin
Stephen van Egmond
> where larger teams often fail.
I've been on teams of 6-8 that succeeded and teams of 20 that got
nothing done.
My own perspective is that in many efforts there are people who are
passionate about what's being done, and have an exciting picture in
their mind (others might call it "vision"). Then there are people
who are there for the effort is a paycheck and kind of don't care
what pops out of the process.
Most people have been one or the other at some point in their
careers. I sure have.
The most number of people I've seen excited about any given specific
project is 2 or 3. On a team of six, that's half the team. You'll
get amazing results. On a team of 20, that's 10% of the team. They
will never be heard.
I'm not dissagreeing with you, Brill, that good practices like
project management and personal organization are important; but
passion is like a +4 bonus. You can have slightly worse project
management and it won't matter.
That was identified a long time ago why open source is (generally)
pretty good: everyone involved cares enough to fire cvs or svn, roll
up their sleeves and dive into x0,000 lines of code. If you have
ever programmed, you know that takes some serious commitment.
Bottom line (literally): If you don't give a damn, the result is
gonna suck.
Brill
have discarded it... anyone else having trouble with the forum
software?
- Brill Pappin
Oshoma Momoh
I do think 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, on 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
osh
Oshoma Momoh
I just read this:
4. What is the management structure like (hierarchy)?
There are front-line developers, and then their manager. My manager had over 100 direct reports and is the common case for managers at Google. Managers quasi-own products and their employees tend to work on their projects, but not always. It's possible for a developer on your product to actually work for a manager in research (a completely different division). This makes it really interesting at review time. Oh and conflict resolution between team members is very complex - the product's manager isn't involved day-to-day, probably doesn't actually manage all of the peers who are trying to resolve a conflict, and likely hasn't spent any time with their employees anyway.
The overall structure is:
tons (a hundred or more) of individual contributors report to
a middle manager who reports to
a division v.p. who reports to
the management team (Larry, Sergie, etc.)
Here's the source blog post. It reads like it's legit.The huge range of comments in response to the post is also telling. This one particularly resonated for me:
...
Both are probably great places to work, especially if you can reconcile yourself to a nice, comfortable, interesting career, and you have the willpower to prioritize family over work and work email. For those who aspire to more, you'll need to innoculate yourself against the sedating effect of the benefits and 'industry influence', get it [sic], build up some experience and a network, and get out.
osh