Scaling Dev Teams For Dummies

HD Ventures
Jul 25, 2017 · 3 min read

Recently published on henriduong.com

For non-technical operators, managers, leaders. If you have never lead a tech team I highly recommend using a specialized recruitment firm (Plug: If you are in SoCal — contact my brother from another mother > Neohire by Josh Stomel) that has helped organizations at multiple stages from early to late stage in order to lower your risk of failure as you grow.
Now to the good stuff:

SCALING FROM 1–9 ENGINEERS

Most startups begin with a very small development team of 1–2 engineers working on building the MVP of a product. Generally, teams of this size don’t follow a defined process, and don’t have the systems or disciplines in place that support scaling the development team.

Once a development team grows beyond its first 2 or 3 engineers, it generally needs to start following some sort of process to have the information needed to (1) judge the performance of the engineers, (2) manage expectations of the business, (3) ensure quality standards are met.

I’ve found that a lightweight Agile process is the most effective process for this environment. This should include daily standups, weekly sprint planning meetings, and using a lightweight agile tools such as :

  • Trello / Asana (Product/Project Management)
  • Slack (Team Communications)
  • Google Docs/Sheets (Documentation)
  • Github (Repo)

The team should implement “Agile / Scrum” methodologies and use Jenkins CI for continuous integration, some form of peer code review, and a weekly (or bi-weekly) QA and release process. When following the methodology, there should be a product manager communicating the product roadmap to the business. Communicating individual bugs and features released by the team gets to be painful very quickly. The product manager should begin introducing the concept of Epics — which are high-level programs with defined business impacts that may be broken down into multiple stories or features. When updating senior management, the PM should discuss prioritization and progress on delivering epics, and the impact of these epics, and leave feature-level detail discussions to within the product-engineering team.

SIDE NOTE ON PRODUCT MANAGEMENT

In my experience, I only recommend doing this when you have a team of 4–9 engineers. To accommodate simultaneous product development, Use product “Swim Lanes” in Trello or Asana. Use the 80/20 rule and split them into teams or squads. Ideally, 80% of team velocity will continue to be focused on the original product, and 20% of team velocity should be dedicated to the new product.

If you have the cash — hire a new product manager for this new product — but regardless each swimming lane should have its own roadmap and its own priorities. In sprint planning, the team will prioritize features such that 80% of the their velocity is dedicated to features from one backlog, and 20% from the other backlog.

At this point in time, you should be moving from Trello / Asana to a more robust project management system such as JIRA or TroopWork may make sense. The engineering should also consider technical changes to the architecture to better facilitate developing multiple products and further decouple product development to avoid a single point of failure in the system architecture.

Read more: http://www.henriduong.com/articles/how-to-scale-a-development-team

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade