Home Blog Newsletters About

From one-man band to a team

Why I’m cautious about teams?

Did you ever end up in a situation where a project failed because of the team? But not because of the incapability of team members. No project failed when the team consisted of star players.

Then management failed?

Yes, in some sense. In the past two years, I got stuck twice in a team where we were trying to get everyone up to speed and agree. As a leader of those teams, I failed to recognize how stuck we were in agreement/managerial process.

What’s the alternative?

Start small or alone. Because when you are creating something new, the idea is fragile. If everyone can influence your decisions and everyone has to agree, you won’t get anywhere.

As the saying goes:

Nothing revolutionary was ever made by a committee.

We don’t need to look further than the technology sector for a few examples.

Apple’s first computers, Apple I & II, were designed by Steve Wozniak. To refresh your memory, the other Steve co-founder of Apple.

Some of today’s most used programming languages like C++, python, JavaScript were developed and proposed by a single person. Sure today, a committee dictates the development of those languages.

But those ideas were brought to the world by a single person then further developed by a larger team.

Don’t throw bodies at the problem

Unfortunately, a lot of people have the tendency to throw bodies at the problem. But in most cases, adding extra people won’t solve your problem.

Team expansion causes communication overhead.

Most people don’t account for that when adding team members.

On the project I worked on, we had an expert for electronics. He was leading a sub-team of five. He was also the critical engineer for one of the electronics boards. At one meeting, the project boss was complaining about the lack of progress by the electronics sub-team. The expert complained that he spends 90% of his time managing the sub-team instead of using his expertise. Yet despite all of his sub-team management, his junior team members barely making any progress. The team was expended way too early.

Extra people will just increase the team complexity, add management overhead, and reduce communication efficiency. Periode.

There’s a reason why companies like SpaceX prefer one engineer who works 12h a day, over two engineers who both work 8h a day. Sure combined two engineers work 16 hours a day. Four hours more than one engineer. But combined, they spend way more than 4h to communicate with each other. We’ll at least if they are talking to each other:)

The too many tasks argument

I have to expand the team because we have a lot of tasks to complete. Spoiler alert. That mentality never works ;) Rather ask your self:

Search for alternatives. You’ll be surprised by the results.


When creating something new, be extra careful before you expand your team. In fact:

The real challenge is to figure out what’s the right time to expand or shrink your team.

If you are too early, you can add unnecessary overhead. If you are late project can stall. Tasks pile up. Sadly there’s no rule of thumb for team scaling. Just go with your gut. With experience, you’ll get better.

If certain tasks are absolutely vital for the project and un-done, I would first seek outside help. Freelancers, companies that help in such scenarios. Add experts to the team temporarily:

This allows you to manage long term risk. Your team varies on demand. Then add permanent employees only if the need for specific task execution in the house would make more sense.

Let’s say I lack expertise in a certain area. I always start by asking myself, can I learn the missing skills? If yes, then that’s my answer. If not, I’ll hire an expert for that specific job.

Team? When?

There are definitely projects I would start off with a team. When I have a clear idea and lack specific skills to finish the idea, I would build a team. But I always try to see how small the team can be.

For my freedom business I’m still convinced that the best way to go is a team of one.

Get the weekly experiment newsletter to your inbox: