Building Project Teams: Quality vs Quantity

In business, everyone strives for success. The real question is: how do you achieve it? What’s the secret formula?

Quite often, I see organizations building large development teams, based on the belief that scale equals value. This approach makes me wonder: do we really want to have teams that are too large to manage, potentially lowering quality and having to redo things, just to pick the cheaper (at first) option? Or would we be better off with smaller, highly skilled teams that have the time and space to thoughtfully tackle problems and develop effective solutions?

Which of these approaches is truly more cost-effective in the long run?

This “quality vs quantity” conundrum reminds me of a story. Some time ago, I had a very important and seemingly very large project to conduct. We needed a way to migrate a vast amount of on-premises resources to the cloud and manage the new environment.

After analyzing the requirements, we saw that it would take 100-200 people to complete quickly. Thankfully, we decided not to rush into anything and rethought the approach.

I teamed up with a single engineer who really knew his stuff, to test an idea. Within a week, that engineer came back with automation that formed the basis of the entire migration process. One week, one person, and a working solution that was not only effective but scalable.

Eventually, we brought in just five more people to scale out the automation. That software managed the entire cloud migration end-to-end, and we didn’t need a group of 100 or 200 to get it done. What we needed were a few people who could think first and do the job second.

Some time later, the company developed this software even further to sell it as a complete product.

This experience really shows that the first idea isn’t always the best. We need to weigh the cost and effort of the solution against what will be the most effective and valuable for the end user.

Do we want to hire 100 people to work on a project for a year and pay them low rates so our budget doesn’t explode? Or should we have 5-6 people at slightly higher (but reasonable) rates who understand the business goal and work together in an agile way for a few months?

As I pointed out last time, software teams have in many cases become too bloated and stuck in their own way of doing things. Instead of simplifying, we’re complicating. When something doesn’t work, we don’t look for better solutions. Instead, we add more people to create new workarounds.

That’s when things start to spiral. You’ve got companies managing hundreds of apps, with separate teams and roadmaps for each one, and one person trying to oversee it all.

Then, when something urgent comes up, nothing moves quickly because this huge chain of people needs to give approval, feedback, permissions… none of which make the problem go away.

When organizing project teams, we need to be smart about it. Every team should be a small, cross-functional group with all the skills needed to deliver value in each sprint.

Agile teams are self-managing, meaning they decide who does what, when, and how. This setup keeps teams nimble, allowing them to complete significant work, usually with ten or fewer members. If and when the project grows in scope or complexity, then we should add more equally small teams, all working under one Product Owner towards a common goal.

This agile approach empowers teams to handle everything – from collaborating with stakeholders to product development and maintenance – while working at a sustainable pace to ensure focus and consistency.

That’s how you run projects efficiently. There are fewer people involved, but they have a solid understanding of the business and take full accountability for their work.

This is the cooperation model we apply at Scalo. Our teams are typically made up of:

• a Technical Team Leader,
• a couple of Developers,
• one or two QA specialists, and
• (when needed) a Business Analyst.

This setup ensures we cover all aspects of a project while delivering business value and managing the product end-to-end.

We also place a strong emphasis on the role of the Product Owner on the client side. I find that when projects fail, it’s often because the Product Owner wasn’t fully involved (because they didn’t have enough time or capacity) or didn’t have the authority to make key decisions. Too many layers of approval just slow everything down.

We’re well aware that no company has time to wait two years for a project to finish. That’s why we work fast and deliver value every sprint rather than waiting for a long, drawn-out completion. We move quickly, test if something works, and if it does, we scale it. If it doesn’t, we keep refining.

Maybe hiring hundreds of people at a time for a single project is not the default for everyone but I’ve seen it enough times to know it’s often the go-to idea. However, pausing to think and look for a smart solution is typically way more effective than going for what’s quick and cheap, no matter the scale.

As always, and I repeat it over and over again – the most important part is understanding the business objective. Everyone on the team needs to be aligned with that goal to make smart decisions. This alignment is much easier to achieve with fewer people.

And to answer the dilemma – the key to success is simplicity. Small, agile teams (of real experts) empowered to make decisions and work fast. That’s how you get things done.

Get in touch if you’d like to discuss it in more detail – and stay tuned for my next article.