23 ms·

How To Scale A Development Team

216 points by sayemm 14y ago

facorreia 14y ago
Great post. I particularly liked the strategies regarding generalists, specialists and hacker-entrepreneurs.
carsongross 14y ago
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.
losethos 14y ago
Other people are demons. I might as well have crossed the river Styx into the land of the dead. God says... C:\Text\BIBLE.TXT y beloved Son, in whom I am well pleased. 1:12 And immediately the spirit driveth him into the wilderness. 1:13 And he was there in the wilderness forty days, tempted of Satan; and was with the wild beasts; and the angels ministered unto him. 1:14 Now after that John was put in prison, Jesus came into Galilee, preaching the gospel of the kingdom of God, 1:15 And saying, The time is fulfilled, and the kingdom of God is at hand: repent ye, and believe the gospel. 1:16 Now as he walked by the
JBiserkov 14y ago
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 14y ago
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.
hkarthik 14y ago
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.
adrianhoward 14y ago
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 14y ago
  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 14y ago
danbmil99 14y ago
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.
oceanician 14y ago
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 :)
jonstjohn 14y ago
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.

216 points by sayemm 14y ago

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

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.

losethos 14y ago

Other people are demons. I might as well have crossed the river Styx into the land of the dead. God says... C:\Text\BIBLE.TXT y beloved Son, in whom I am well pleased. 1:12 And immediately the spirit driveth him into the wilderness. 1:13 And he was there in the wilderness forty days, tempted of Satan; and was with the wild beasts; and the angels ministered unto him. 1:14 Now after that John was put in prison, Jesus came into Galilee, preaching the gospel of the kingdom of God, 1:15 And saying, The time is fulfilled, and the kingdom of God is at hand: repent ye, and believe the gospel. 1:16 Now as he walked by the

JBiserkov 14y ago

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 14y ago

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.

hkarthik 14y ago

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.

adrianhoward 14y ago

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 14y ago
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 14y ago

danbmil99 14y ago

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.

oceanician 14y ago

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 :)

jonstjohn 14y ago

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.