Determining the optimal number of team members required to accomplish a task can prove more intricate than what one might initially presume. Unfortunately, a straightforward response to this inquiry would have to be “it depends”. Nevertheless, it is crucial to note that determining a team’s ideal size is more of an artistic exercise than a scientific one.
Providing a conclusive response to the question stated in the title is impractical. It resembles a philosophical paradox and even if our thoughts and discussions help us gain a better perception of the subject, we are improbable to reach an agreement. However, it is a critical aspect to contemplate if you want to guarantee optimal performance of your team.
Amazon’s “Two Pizza Policy”
During an interview, Amazon’s CEO, Jeff Bezos, humorously mentioned that a meeting is too big if two pizzas can’t satisfy everyone present. Despite the light-hearted nature of this remark, the advice provided is usually sensible.
It is commonly presumed that enlarging a team will enhance its productivity. However, this is not entirely accurate, and it is known as the “team-scaling fallacy”. Frequently, managers miscalculate either positively or negatively the number of hours a bigger team might need to accomplish a project.
The reason why individuals fall trap to this error is because of the myth that collective efforts inevitably generate superior results. Although it is factual that two individuals working two hours each per day would produce a total of four hours of output, this isn’t always the scenario.
Engineers are well aware that employing nine people to complete a task within a month is an unattainable goal. It is not always accurate that augmenting the headcount of individuals dealing with a problem will produce favourable outcomes. The efficient approach to follow may diverge significantly, depending on the unique demands of the situation.
As the quantity of individuals involved in a situation escalates, regulating communication within the group can intensify. This is noticeable when playing the game “Telephone” with a large assembly of individuals, as it can be challenging to guarantee the precise transmission of messages.
Statistics show that teams comprising of 3-8 members are more productive than those composed of fewer or more individuals. Even though larger teams may be workable, breaking them into smaller groups consisting of 3-8 people might prove more advantageous.
Understanding the Requisites
Once it has been established that enlarging a current team is not invariably the most fitting resolution, determining the appropriate number of team members becomes paramount. The primary step is to recognise the original requisites to gather pertinent data.
It is crucial to concentrate on:
- Delineation of the Project’s Scope
- Specification of when events might occur
- Technology Requisites
Budgets are pivotal, as any perspicacious reader would comprehend, but we will get to that shortly.
Collaborating larger teams, in projects that involve multiple technologies, is often imperative. Even though a senior developer may possess comprehensive expertise in both backend database handling and user-facing web designing, expecting them to allocate an equal amount of attention to both SQL query management and development may not be feasible.
Employing a single proficient worker to administer both the database and other development tasks, could be cost-effective, provided that access to the database is not an often-recurring necessity. Alternatively, having multiple developers onboard might prove advantageous to ensure an optimal result.
It is imperative to contemplate the project timeline. When do we anticipate witnessing progress on this task? Smaller teams can usually undertake projects with longer deadlines, nevertheless larger teams may become necessary when timeliness is of paramount importance.
The quantity of simultaneous tasks is a crucial measure. In order to qualify as parallel, a procedure must be considerably autonomous from the remaining aspects of the project. Parallel processing facilitates a larger number of software engineers to work on a project simultaneously.
Finances can be a cause of stress within a team or group. It is crucial to contemplate the financial consequences of inadequately staffing a team, as this could culminate in greater financial losses in the long term.
To achieve this, having a budgetary goal in mind is important, but that objective should be as flexible as possible.
In order to supplement the strategic outlook that requirements provide, studying the psychology of your team could also yield tactical insights.
Distinct team sizes necessitate varying management styles. Managers who are inclined towards an authoritative approach are better suited to lead larger groups, while those who favour a more democratic style are aptly equipped to lead a compact team of highly skilled individuals.
Every Project Manager is likely to have a favoured team size. It is essential to consider their proficiency in assisting with team formation. Their expertise will be irreplaceable.
Studies have shown that agile teams tend to be most successful when comprised of between five and eleven members. If the group surpasses this size, the approach may become less adaptable. Conversely, the employment of a waterfall approach facilitates a structured setting in which teams of any size can function.
Modern Technology Toolkits
A plethora of alternatives are within reach, including management software, automation and AI, which can enable you to formulate a proficient workforce. The advent of serverless computing, combined with messaging and version control tools, has permitted the coordination of the work of hundreds of engineers from various time zones on a single project.
Additionally, operations that previously necessitated specialist engineers can now be automated, resulting in higher productivity for smaller teams.
Despite its benefits, technology cannot replace the requirement for adequate staffing. The capacity of a team to collaborate efficiently and establish relationships cannot be superseded by any level of computing power.
Starting Small is Preferable
Allow me to emphasise the most valuable advice I have ever received: it is simpler to expand a project than to downsize it. To reduce disruption, it is better to commence with a small team and incorporate additional developers if necessary. Instead of shrinking the team and escalating the workload on the remaining members, it is more effective to identify bottlenecks and hire more staff to manage the increased workload.
As emphasised at the outset of our discussion, there is no one definitive way to create a successful team. It is crucial that we determine a suitable team size for our project, and it could prove advantageous to seek advice from a consultant or specialist.