Minimum viable team

Minimum viable team

Management worships scaling. More is better. Large teams can churn out more features faster. Strong managers shine in huge hierarchies. Sure, it can be a bit wasteful, but if you want to build large impactful products, you’ll need large impactful teams.

Regular readers of my blog know that I don’t believe in this school of thought. I’m a big fan of small teams. Small teams make communication easier. They focus by default. Collaboration is almost friction-less. What they lose in sheer horse-power, they make up in efficiency.

There is loads of literature on what makes a large team bad. It’s clear to see when a team is too large to work.
But a question the small-team proponents like myself have to answer is: when is a team too small? At what point do you need more people to get more done?


Here are a few scenarios where scaling up makes sense.


Too small to deliver

Your team consists of a marketeer and a project manager, but you have no devs that can build the actual product. Get yourself some devs.

Too small for continuity

You have a 1 front-end and 1 back-end developer. When one is sick, the team can’t deliver. While this is definitely workable, you’ll need top level management to run this show. This means top-notch planning and focus. That also means assigning one of your best managers to a 2 person team. Adding a full-stack developer to assure continuity is often a better idea.

Too small to support

Your product is live and customers need loads of attention. Your two devs are spending the majority of their time on customer support. They’re doing two jobs now, this is a great time to scale up.

Too small for quality

You have a full-stack Javascript developer that writes high quality React, but lacks in the styling department. The code is great, but the product looks meh. At this point, adding someone with design skills is a great idea.

Too small to grow

You have a team of three senior engineers. They all know the product through and through. They might want to move on to greater things. Resist the urge to add more senior engineers to “keep the level”. This is your moment to add junior engineers and to prepare to phase out the seniors.

Too small to meet the deadline

Change the plan. We’ve been through this, really.

Increasing the size of a team should be a deliberate decision. Our gut feeling is often wrong. We need to grow slower to deliver faster. We need to add less experienced people to increase the brain size of the team. Our plan should be in function of the team and not the other way around.


Building software is hard, but don't let that stop you.

If you're building a product and feel like you could use a supportive techie in your corner, let's set up a quick chat to see if I can help you.