Being in the industry and having been an entrepreneur for a few years now, my company has successfully developed and deployed multiple platforms for our customers. And people always tend to ask, "How? How could you accomplish this with a small team?" The discussion between size versus suitability has been there for decades, and the general perception is that bigger teams from established and prominent companies will provide better outcomes. The idea of just a few members managing too many exigencies can get overwhelming for the members and the leader. However, in my experience, I have come to understand that there is never a clear criterion or a 'winning formula' for successful projects. Choosing the right team is the 'make-or-break' moment in a project timeline. After all, choosing the right team and the correct leader to lead it is challenging, as it has to be the right blend of individuals strengths and weaknesses, helping them blend into a team.
In conversation with former colleagues, I remember telling them about the increase in chaos, which increased team numbers. In one such discussion, a colleague casually mentioned it's nothing but the result of the Ringelmann Effect. I pestered him to know more due to my inquisitiveness and the lack of ease of Google-ing around two decades back. He explained that the Ringelmann Effect is the tendency for a team's members to become increasingly less productive as their size increases.
The concept stuck with me, and I researched further. The idea was discovered by Maximilien Ringelmann, a French agricultural engineer who interpreted the inverse relationship that existed between the size of the group and the magnitude of group members' contribution to the completion of the tasks assigned.
Soon after, the concept started building up in my mind, and I tried to study research papers on creating smaller, agile and efficient teams. In my journey to comprehend the right size of a team, I found a study done by Quantitative Software Management (QSM), pioneers and innovators in software estimation since 1978. This study was done in the year 2005, indicating that smaller teams are dramatically more efficient than the larger ones. QSM maintains a database of more than 4000 projects and out of which they analyzed 564 information systems projects done since 2002. They adopted the data into small teams, typically less than five members and large groups, more than 20 members. As a measure of the project's size, to complete projects of 100,000 equivalent source lines of code, large teams took 8.92 months, whereas the small groups took 9.12 months. The study concludes that the time advantage was barely a week or so, but the cost disadvantage was very high. Considering you deploy more than 20 people for large teams and less than 5 for the small ones. As the workforce is the most crucial cost for an IT project, the study's numbers are atrocious. The QSM study author further claims their data for real-time embedded systems projects also showed similar results.
The research in the field and my observations have made me believe that it is not a more significant number of people that you need in your team. Still, just the correct number of people, the right skilled people and the proper structure to provide direction to the units can deliver the best results.
I have applied this formula of a small team with the right people in TTH since its inception in 2012, and it has always been successful. I felt the need to share these points to continue the debate and seek varied viewpoints and better learnings for all:
Reduced communication and coordination effort – The efforts required to coordinate and communicate way higher if the team size is bigger, especially when each member has to coordinate with all others. The effort rises by the square of the number of persons in the team.
Hire only the specific people for each type of role – Assess the number of positions required to deliver a project and bring on board the people with the right skill sets to ensure that there is neither skill gap nor skill overlap. This keeps the team size small and helps reduce internal team politics.
Foster better camaraderie – The smaller teams can gel well as each person knows the other one, not just on a professional but also personally. A better rapport increases the level of cooperation between team members and their combined passion for the project.
Increased flexibility – With a small team, each member has to take similar initiative, and collectively, the team can avoid conventional and bureaucratic procedures, processes and structures to deliver results faster.
The widely accepted optimal team size is 5, as per Katherine Klein from Wharton University. Whereas, Evan Wittenberg, the director of the Wharton Graduate Leadership Program, states that though the research on the subject is "not conclusive, it does tend to fall into the 5 to 12 range, though some say 5 to 9 is best, and the number 6 has come up a few times."
But I think the exact number does not matter, as does the correct number. So, keep the team's size small but just right to ensure that this team is built up to deliver any world-class project. I always believe, "If the attitude is right, competency can be developed".
Mrs Kamath is a Senior IT Executive with 25+ years of IT Industry Solution Management and Project Implementation experience.
She has participated extensively in System Architecture and Telco BSS Systems' design, managed multi-million dollar projects across the Asia Pacific region and been a consultant to the senior project and program managers for renowned telephone companies globally.
Recently, she worked closely as an M2M service provider in various eSIM use-cases like Device Tracking, Telematics, and Connected Cars, to name a few.
Over the last five years, the life cycle management of eSIMs has been contributing to M2M/ IoT systems and Operations, successfully handling over 100 customers.
Unit no. 202, Akshar Bluechip IT Park, MIDC Thane, Belapur Road, Turbhe, Navi Mumbai