Dr. Neil's Notes
Software > Development
Scaling Development Teams
Introduction
Along with underestimating the size of projects (or maybe because of), one challenge I repeatedly see in software development teams, is underestimating the number of people needed to accomplish the desired goals. In this note the goals implicitly include a time frame, not only the deliverable outcomes.
Note: this is discussion on when, and how, to scale a development team, and does not cover the act of recruiting of people into your team.
It takes an army
Have you watched all the credits for a movie and wondered why so many people were involved ? If so, then you are getting a glimpse into the reality of creating a great product. Software (and sometimes hardware) projects can provide the illusion that a handful of smart people can deliver a billion dollar product.
Why then do companies like Microsoft, Google, Meta, and Amazon (all successful billion dollar software companies) employ thousands of developers ? If you are thinking it is because they are not as smart as your team, the chances are high you are wrong.
While it is possible to deliver a great, and successful, product with a tiny (less than 20 people) team, it is the exception, and also very very rare.
Most software projects worth doing (the product makes a noticeable dent) will require growing a larger team. However be cautious about growing too quickly.
Create a Map
Before you recruit an army to help conquer the development mountain, make sure you have a clear map to guide the new recruits in the correct direction, and to the top of, the right, mountain.
Creating a map requires a small, tight knit, team, and often takes many months. The small initial team should be doing the experimental work that validates the route, plotted in the map, can be followed, and the development project completed. This map might change several times in this process, it is highly likely that the direction, and goals, change during this first map making phase.
This, map making, is the foundational work. At some point during the map making it will become clear that the direction is now set. This is the time to scale up the development team.
Measure Output
In order to scale successfully, be careful not to measure the output of individuals, instead measure the output of the entire team. Measure the total team output and velocity.
Measuring the output of individuals will restrict growth of the team. Mentoring people, and supporting new starters, will reduce the output of individuals. The team should be focused on increasing the total output of the team over time. If the team uses Sprints, or some form of short time frame milestones (and you should), then each week, fortnight, or month, track the output from the team in terms of progress along the map, and delivered value.
Once a team is aligned to increasing the overall team output, then the dilemma of supporting new recruits dissolves away.
Capture Knowledge As Content
As new people join a team, they will ask questions, in order to understand what is being created, and how the work is being done. Capture these questions, and the answers, in a document, or wiki, that will help the next new people get going faster. As this content grows, it will become a self-serve new starters guide. This new starters guide will enable faster onboarding of new people.
Identify Mentors
As new people join the team, some of those people will be natural mentors for future new starters.
Imagine you have a small core team of ten people, five of whom are capable of mentoring new recruits. In order for the team to double in size, each of those five mentors will need to support two new starters. This will certainly slow down the output of the five mentors, and initially the entire team output. However after a couple of months the total team output, with twenty people, should be noticeably higher than with ten people.
Out of the ten new starters identify the five people most capable of mentoring the next wave of new starters. Now the team has ten mentors and could potentially recruit twenty new starters. Six months into this scaling process you could have forty people in the team, and be capable of doubling again.
Output does not scale with the team
This probably should not need to be said, however here it is; the output of a growing team will not double when you double the size of the team. An increased team size should be able to achieve more than a smaller team. The output does not scale linearly with the team size. As a team grows there is more overhead, in terms of communication costs, and alignment costs. To keep a large team aligned takes work from everyone.
A note on standards
This relates to the Agility from Diversity topic. At a small scale, ten to fifty people, having well defined standards for both the production and process, will help the team go faster. This is not the time to argue about 'tabs vs. spaces' or 'where curly braces should go', follow the standard to increase collaboration and velocity. However as a team grows, it will split into sub-teams, each sub-team will have different (albeit aligned) goals. Allowing each sub-team freedom to define their own process and standards will enable them to go faster, and be more agile. If you try to apply a single development process for thousands of developers all with different targets, scaling becomes far harder, and potentially impossible. The important point is to ensure the sub-teams are aligned with the bigger goal, and each sub-team output is measured.
Created: September 23, 2022 23:35:51