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.
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:
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.
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.
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:
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.
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:
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.
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.
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:
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.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Jim Naylor shares he views documentation as a company’s IP and how his teams should use it as a source of truth.
Act fast or play it safe? Product managers face this daily. Here’s a smarter way to balance risk, speed, and responsibility.
Emmett Ryan shares how introducing agile processes at C.H. Robinson improved accuracy of project estimations and overall qualitative feedback.
Suvrat Joshi shares the importance of viewing trade-off decisions in product management more like a balance than a compromise.
Learn more →
