How to scale a development team

Adam Wiggins talking about development team scaling at Heroku

As hackers, we’re familiar with the need to scale web servers, databases, and other software systems. An equally important challenge in a growing business is scaling your development team.

Most technology companies hit a wall with dev team scalability somewhere around ten developers. Having navigated this process fairly successfully over the last few years at Heroku, this post will present what I see as the stages of life in a development team, and the problems and potential solutions at each stage.

Stage 1: Homebrewing

Stage 2: The first hires

Crisis on the brink of Stage 3

Grow to 10 - 15 developers, and you’re on the verge of a major team structure change. I’ve been told that many promising startups have been killed by failing to weather the transition between these stages.

With this many developers, iteration planning, standups, or any other kind of development-team meeting has become so big that the attendees spend most of their time bored. Any individual developer will find it difficult to find a sense of purpose or shared direction in the midst of trudging through laundry lists of details on other people’s work.

In programming, when a class or sourcefile gets to big, the solution is to break it down into smaller pieces. The same principle holds for scaling a development organization. You need to break into targeted teams.

Stage 3: Breaking into teams

Specialization

Heroku's first teams

Heroku’s initial team breakdown looked like this:

• API - Owns our user-facing web app and the matching Heroku client gem.
• Data - Builds and runs our PostgreSQL-as-a-service database product.
• Ops - Shepherds and protects availability of the production system.
• Routing - Manages everything necessary to get HTTP requests routed to user web processes.
• Runtime - Handles packaging code for deploy and starting/stopping/managing user processes.

Team size and roles

Cohesion

In the earlier stages, you should avoid attacking on multiple battlefronts, and instead keep all developers focused around a single goal for the company. With creation of fiefdoms for each team, this has changed. Now you can and should attack on multiple battlefronts. Each team should be executing independently against its own goals, and not worrying too much about what other teams are doing.

…

But now you have a new problem: lack of cohesion. Your decentralized teams are setting their own roadmaps and deciding on features independently. But to avoid fragmentation in your product, someone needs to decide an overall direction and set of product values. More succinctly: you need a strategy.