Getty Images/iStockphoto
A primer on core development team structure concepts
To establish the right development team size, managers must look at each member's responsibilities and communication paths, as well as know when to split teams.
While there is no exact guideline for proper software development team size, the number of team members should vary depending on context and shared responsibilities. Having too many members slows a project, while having too few puts excessive responsibilities on individuals.
Development teams have changed over time, and that changes the expected team size. This article covers the definition of a team, effectiveness of their work and practical size recommendations. Learn how to examine shared responsibilities and to make adequate team sizes to either reduce responsibilities with current members or add more people to achieve project plans.
Software development team organization
Early in my career, I belonged to a development team that followed a matrix management organizational structure. Every member of the team worked under the same application development manager but also reported to a project manager on any given project team. Although considered a team, we had work on competing projects with competing priorities. The goal was to work on projects independently but to share information like code standards, rules for code review and architecture decisions.
Scrum, a framework of project management often adopted for Agile software development, suggests teams should foster or acquire the appropriate skills needed to conceptualize certain complex features, implement them correctly and provide ongoing production support. To enhance the team's expertise, managers have two major options: slow down processes and deadlines to enable existing team members to build their skills or attempt to hire new developers who already possess the necessary skills. This requires them to weigh the financial implications of slowing down projects against making a new hire, as well as consider whether the team could or should grow any larger than it is.
Solidify communication channels
According to Fred Brooks, author of The Mythical Man-Month: Essays on Software Engineering, the number of individual communication channels that exist within a single team grows exponentially with each new member added, using N*(N-1)/2 as the equation for all conversation paths between each team member. In this equation, N equals the number of team members; the full equation adds up to the sum of every communication channel possibility within the team.
Amazon founder Jeff Bezos suggests teams focus on solving a particular problem rather than trying to address many at once. This logic encourages that teams be assigned to a single manager who is focused on one task with full authority and autonomy to get it done. For instance, a dedicated cloud services team could be as large as 10 or 15 members, provided the work is universally understood across the team so that one member can step in for another when needed.
Teams that follow this design should -- in theory -- experience minimal problems around mixed communication paths. However, it can be hard to completely avoid communication problems once the team surpasses a certain size. One way to determine how to reduce a team's size is to literally draw out all the possible structures that could result from splitting the team. Keep an eye out for places where two members possess equal skill sets and could easily live on separate teams. If the new team structures still don't work, consider whether a new hire or transfer from another department might help.
There's an adage, popularized by Harvard University psychologist George Miller, that the human capacity for memory, socializing and other tasks is limited to seven, with a plus or minus variance of two. Be careful, however, as you might find that the rigid principle of seven plus or minus two is outdated or culturally limiting and that other formations might make sense, depending on your particular project requirements and in-house skills.
Make change in development teams
Splitting a team isn't as easy as sending an email and declaring a new boss. Think about how you could reorganize your group to improve performance. Try the team-splitting exercise mentioned above to see if the existing team structure has what it needs to operate independently. From there, the next steps are to either add people or shed responsibility to enable the team to focus.
Managers and team leaders can also shape the direction of the group by establishing clear communication and expectations. Habitually observe the team, and shape it based on gaps in skills or perspectives. Doing so correctly may stop pushback from development teams and inspire a more productive workspace.
Author's note: The author would like to thank Matthew Groves for his contributions to the article.
