Is more headcount necessary? How and when to scale a team

In every organization I’ve encountered, leaders consistently seek ways to increase their team’s capacity and bring new members on board.

When confronted with the pressure of missed deadlines and operational challenges, our initial inclination often leans toward team expansion with the hope of expediting processes. However, more often than not, adding more people means increased waste, and the larger the organization, the more evident the problem becomes.

Picture it like building a Jenga tower. You might feel tempted to add five more blocks to increase its height, but should you? Well, you can, but only if the tower is stable and capable of supporting those additional blocks. Attempting this at the wrong moment could result in a catastrophic collapse.

So, the question arises: do you genuinely require five more people on your team?

The concise answer: perhaps. While the need may arise, it’s advisable only when you’ve established a well-optimized system and ensured it’s prepared for scalable growth.

The common misconception: More people, more productivity

There’s an intriguing phenomenon in teamwork known as the Ringelmann effect. It suggests that when you add more people to a team, each individual team member’s productivity tends to decrease.

This idea was initially observed during a simple activity — rope pulling. It makes sense when you think about it. When you’re competing in rope-pulling by yourself, you’ll likely exert your maximum effort. However, if you’re one of ten people on the same team, your personal effort might not be as intense.

This simple principle applies to various aspects of teamwork, including product development, as research has consistently shown.

There are a few primary reasons behind this phenomenon:

• Blurry sense of purpose
• Increased interdependence
• Reduced individual accountability

Blurry sense of purpose

As a team expands in size, the array of responsibilities they must manage also grows significantly. As a result, it becomes increasingly challenging for everyone to maintain a clear understanding of the team’s ultimate purpose. When team members lose sight of the big picture, their motivation can diminish.

Increased interdependence

You might add only one new person to the team. However, if you have a team of ten people, adding even one person introduces 10 new connections and interactions within the team. Without a proper system in place, this addition can lead to more frequent communication, higher overhead, and additional interruptions, all of which can hinder overall productivity.

Reduced individual accountability

In a team of 10, it’s common for each individual to bear responsibility for only a portion of the workload. This can sometimes lead some team members to presume that others will compensate if they don’t perform at their peak.

While this perception may not be universal, it tends to be prevalent among team members. This is called social loafing — the tendency of individuals to put less effort when they are part of a group:

How to scale your engineering team effectively

As a company expands and the responsibilities within the team increase, it becomes evident that greater capacity within the team is a reasonable necessity.

While it’s challenging to completely eliminate the effects of the Ringleman effect, there are numerous effective practices that can significantly reduce its impact.

To achieve this, you need to establish a solid system. Think of your team as a system comprising people, software, and processes. The flow of your product development process involves external inputs, typically in the form of requirements, and the delivery of outputs:

Growing the system means adding more people in the team, but also an increased number of input, increased software size, more data, more complex processes etc. To ensure you can handle increased complexity, an optimized system is crucial.

Build a scalable team structure

Smaller teams often outperform larger ones, and there are good reasons for that. If your product development team already consists of 10 people, introducing new members may not be the best move until you’ve revamped your team structure.

However, proceed with any redesign thoughtfully.

When executed effectively, team redesign can be a game-changer. But if mishandled, it can introduce unnecessary complexity and slow down progress.

The process of redesigning teams is unique to each organization, but here are some fundamental principles to guide you:

1. Identify subdomains — Start by categorizing all the tasks your team handles. Is there a clear overarching goal, or does it seem like a mere list of tasks? Look for smaller, manageable areas within your team that can operate independently and align with your company’s overarching objectives
2. Assess team skills — Take stock of your team members. Are there individuals naturally suited to specific subdomains you’ve identified? Do some team members possess distinct skills and career aspirations compared to others?
3. Review current processes — Dive deep into your team’s current operational procedures. What steps are followed? Where do you rely on assistance from other parts of the team? If your plan involves having a team work independently, you need to do this carefully and avoid introducing complex dependencies between the different subdomains
4. Conway’s Law and system design — Consider Conway’s Law, a concept in product development suggesting that your team’s design often reflects your system’s architecture. Ideally, each team should operate autonomously, responsible for their own tasks and code management. Making a split in the team and ending up with independent teams that maintain the same codebase would not be the most optimal solution
5. Think about the future — Where do you envision your company in a year’s time? Could your software components evolve into distinct products or even separate businesses? Do you anticipate ongoing team growth, or is the growth just a temporary phase? Each time you reconfigure your team, it’s akin to making an investment, so ensure it aligns with your future objectives
6. Avoid pursuing perfection — Don’t get caught up in the pursuit of perfection because, honestly, it’s seldom attainable. Think of these principles as your compass, not rigid rules. Achieving the ideal team structure is akin to crafting art—you aim for a balance between your current state and your desired destination. Trust your instincts to discern when it’s the right time to implement changes.

Build scalable software

The accumulation of technical debt can significantly hinder team productivity, although it often goes unnoticed.

Subpar software quality can drastically slow down your team, potentially making them two to three times less efficient. Resolving any defect becomes a headache, and implementing new functionalities can be a very time-consuming process.

Moreover, if your software isn’t designed to scale and you add more team members without a clear improvement plan, it can result in increased costs, inefficiency, and frustration.

Regrettably, addressing these issues isn’t always straightforward. While there may be some quick wins to improve developers’ productivity, enhancing software quality often necessitates a substantial investment. This may involve refactoring critical software components, migrating data, or even rebuilding the software from scratch.

When the quality of your software becomes a significant problem, it’s time to carefully consider your options. Typically, you’ll need to decide whether to invest in improvement or undertake a separate rebuilding project, even if it means temporarily slowing down or halting new development. This ensures a more sustainable and effective long-term solution.

Optimize processes and reduce waste

As your team expands, processes that may have seemed optional for small teams or startups become increasingly essential.

Larger teams naturally entail more communication, which often results in interdependencies among team members. To navigate this effectively, it’s prudent to consider implementing well-defined and somewhat formal processes.

This entails creating comprehensive documentation, outlining detailed procedures, and assigning clear responsibilities with built-in accountability. Neglecting to establish clear processes within a sizable system can lead to intricacy, disorder, and discontent among team members.

While building a software product typically centers on software development, it’s worth noting that developers often spend less than half of their time on actual coding. There are numerous supporting processes involved, such as building, testing, quality check, deployment, and monitoring. The good news is that many of these processes can be automated, presenting significant advantages in terms of both productivity and happiness for developers.

Take the time to review the entire workflow, from conceptualizing a feature to its production release. Examine the entire process, pinpoint dependencies, and identify areas that can benefit from automation and others that require comprehensive documentation.

Having an optimized process can greatly benefit your product development team. It’s entirely possible that through refining your processes, you may discover that you don’t necessarily need to bring on additional team members to manage the current workload effectively.

Final thoughts

Determining the right moment to expand your team is a decision unique to your specific situation. It requires a thorough evaluation and judgment because many factors come into play, and it’s rarely a clear-cut choice.

Here are the essential questions to address before arriving at a decision:

1. Team size — Are your teams relatively small in size?
2. Clear purpose — Does each team have a well-defined purpose that aligns with your overall strategy?
3. Bottlenecks — Have you identified and clarified the key bottlenecks within your product development process?
4. Software architecture — Does your software architecture align harmoniously with your team’s structure?
5. Processes and automation — Are there well-established processes in place, backed by extensive automation?
6. Technical debt — Is your software’s technical debt at a manageable level?
7. Strategy — Where do you want to be in one year from now?

When considering team expansion, it’s vital to thoroughly analyze these factors. You should carefully assess the situation, weigh the advantages and disadvantages, consider your broader strategy, explore various options, and ultimately choose the solution that best fits your current circumstances.

Crafting your system is a bit like an art form rather than a straightforward task. It requires careful planning, ongoing iteration and refinement and a clear vision. While your one-year-ahead predictions are probably not accurate, taking the initial step towards improvement is crucial to begin the journey. Along the way, you’ll unearth valuable insights, refine your thought process, and enhance your system step by step.

Expanding your team hinges on having a scalable system, which requires a growth mindset and ongoing enhancement.