

How To Scale A Development Team - sayemm
http://adam.heroku.com/past/2011/4/28/scaling_a_development_team/

======
adrianhoward
Nice post - and a fairly good match for what I've seen when small teams get
large.

One thing I'd do different is the breaking into teams part. My reading of the
authors post is to split the team on architectural lines, and place team
members based on their technical interest.

I've generally found that you get the best results by breaking into teams
based on who likes working with who, and on products / sets of customer-facing
features.

When you look at a 10-15 person team you'll usually see some natural breaks
where some folk get on better within certain subgroups. I've found that
breaking down based on social groups rather than technical knowledge leads to
a much better initial fit.

I'd also tend to avoid breaking down on technical architecture - because I
live in fear of an anti-pattern I've seen many times where developers get out
of touch with how their work affects the end-user.

If at all possible I prefer to break-down into teams based on slices of end-
to-end functionality. So you end up with teams responsible for Product A and
Product B, or CustomerFeatureSetA and CustomerFeatureSetB rather than
"database layer" or "scaling infrastructure".

Personal I'm happy to trade of more communication between teams (because team
A and team B will often both need to build infrastructure C) to get
_everybody_ focussed on delivering features that customers use.

(I also have to admit that I'm confused by saying Scrum is a heavy-handed
process.... There are things I don't like about Scrum, but it's one of the
most light-weight frameworks out there.)

I'm also surprised the teams end up so small. Not that there's anything bad in
that - I'm just surprised. I worked with teams of 6-9 folk where people avoid
stepping on toes so I'd be interesting in finding out the pressures that made
pairs/triples work so well for them.

I'm wondering how the teams work together physically. Are folk co-located?
Team per-office? All teams in one room? Something else? Looking forward to the
"cohesion and strategy" followup :)

~~~
makeramen
Depending on your product and your talent, I think 2-3 engineers is plenty.
I've worked with larger teams, but at that point it becomes a more committee-
like and less self-directed.

At that point, you're probably better of splitting into even smaller, more
self-directed teams.

~~~
adrianhoward
I've certainly experienced larger teams that have gone committee-like and are
less self-directed.

I've also worked with larger teams (4-12) that are _not_ committee-like and
are _very_ self-organised and self-directed. So I don't think it's inevitable.
I'm interested in teasing out the reasons some teams go one way and some
another.

Bigger than 12 or so - then the committee-like stuff seems to become more
unavoidable.

(Just read this rather interesting bit on how the process at TargetProcess
<http://www.targetprocess.com/articles/agile50months/> evolved. They have a
mini-team per-epic - which sounds a bit like the best of both worlds to me)

~~~
j_baker
I'd posit that the only way to get > 4 teammates to work together is if they
think in mostly the same way. Sometimes that may be desirable, but more often
than not you want a team that is made of people who think differently from
each other.

~~~
adrianhoward
Well - that depends on what you mean by "think differently".

If you mean that they've all got to mutually agree on some working practices
that are going to enable them to work together effectively - then yes. If you
mean have the same outlook or skill set - then it _certainly_ doesn't seem to
be true in my experience :-)

In fact, I'd say the opposite is true if anything. If everybody has the same
outlook and skill set the group tends to more rapidly moves into a committee
like non-self directive setup from what I've seen. I'm guessing that's because
they don't have to come up with techniques for handling dissenting opinion as
much.

------
hkarthik
This is a really interesting post and makes a lot of sense.

I've now worked in a couple startups that raised enough money to hire for
Stage 2 or 3 before they launched an MVP. In fact, raising early actually put
more pressure to hire since Stage 3 looks better for investors.

This brought too much process and too many specialists early on. The early
designs became too ambitious, the products became too complicated, and the
launch dates ended up way later than they should have been. Ultimately, it all
led to the market fit being really hard to find and a lot of the early stage
team members leaving.

------
carsongross
Thanks to Heroku, the reach with stage 1 is now much, much larger: you can
scale out an app to millions of users with a few reasonably talented
developers, rather than a god-like dev-ops team.

Really, an amazing company.

------
JBiserkov
The article is disappointing in a good way: I was expecting a sales pitch to
sneek in, but none that I can see so far. I should probably reread it now that
I know that.

I disagree that the article is long: we need more well-thought in-depth
analysis and commentary.

------
rmATinnovafy
Posts like these are the reason my MVP's are going up on heroku.

They just keep improving so much. Their new pricing, plus all the options now
available.. Its just one of things that make sense to use.

------
facorreia
Great post. I particularly liked the strategies regarding generalists,
specialists and hacker-entrepreneurs.

------
oceanician
Really interested to see generalists highly valued. I've always felt that it
was the specialists, that everyone was being forced toward. It's good to try
different elements, and keeps it lively & interesting :)

------
danbmil99
This post really hits the mark on all major points. The transition from 4-6 to
15-20 is a huge phase change that can completely disrupt a startup's culture
and flow.

------
jonstjohn
We currently have 7 developers and two teams, but have not yet divided the
teams along specializations. I suspect this is probably a good direction to
go, though, especially as we continue to grow. I find that developers really
like ownership over a particular area and continuity on the work they are
doing.

