Small teams beat Goliaths

I have been observing 37Signals lately - the company behind the popular project-management tool Basecamp - and how they approach team growth over the years. Just today, I listened to their latest podcast episode Increasing Capacity, and it gave me the final push for this blog post I've been meaning to write for a couple of years.

In that podcast episode, the founders of 37Signals share how they are now building and maintaining multiple products with a team of around 80 people. They're launching one or two products per year.

While that might not come across as extraordinary, they also shared that they had done, earlier on, the same thing with a team of only seven people. Launching one product per year with only seven people is, indeed, crazy.

Big teams - but why?

One of the biggest frustrations I've had to overcome during all these years of running MarsBased is that all of our projects have been way smaller than the ones I worked with when I was at previous companies. My first project at Deloitte had almost 20 people in it.

Now, what I've gotten wrong about this situation is that the projects weren't bigger; the teams were. This nuance led me to frustration but now I see that we've been doing the right thing all along.

A big firm like Deloitte has a baseline of 25% annual employee turnover. That means that over the course of four years, the entire company might change. While I know that isn't true, I have also seen companies with almost 50% employee turnover. Of course you need extra people to compensate for those leaving, but that is like trying to catch lightning in a bottle.

Moreover, these big firms are often known for throwing people at a problem. Instead of thinking how many people are needed to build something, they check their excel files to see how many profiles, and at which rate each, can they fit into a project budget, even if those people aren't really needed.

Small is a feature

In our case, being small is intentional. We have capped our annual headcount growth to 2-3 people per year.

While we could have sold more, to grow more, that usually comes at the expense of the quality of the output. That was something we simply didn't want to concede. That could've shrunk us to fewer people.

We have seen it in some companies similar to ours. Every single one of them reached a point where they decided to overhire, raise funds or make a strategic move with a certain client or technology and more than doubled their size in less than a year. All of them have shut down or gone back to square one. Some had 100+ employees.

Paradoxically, by growing more slowly, we've grown every year. We're bigger than the ones who grew faster. The fable of the turtle and the hare, business version.

Some examples

In the summer of 2019, one of our clients announced that he was selling the company. We had been working for them for almost two years with a part-time Rails developer. 20 hours per week for approximately 24 months, wherein we built an online CV maker with tens of thousands of users and pretty sound metrics in revenues and active users.

The funny thing is that, unbeknownst to us, our client had brought the company to be among the top 5 in the market of online CV makers, where CareerBuilder, Indeed.com and other big players rank in the hundreds of millions of dollars in revenue.

You read it right: a single developer 20h/w competed against huge companies with thousands of employees - probably dedicating multiple squads of oversized teams, working with agile methodologies, on JIRA, with product owners and scrum masters - only to end up doing the same thing.

Over the years, we've been told by multiple clients that our team was the most performant of the entire company. Usually, external dev teams aren't known for being performant. if anything, they’re seen as a necessary pain to get things done.

In 2020, I was invited to hang out at the company retreat of Spin, one of our biggest clients back then, in San Francisco. Their CTO welcomed me to the event and to my surprise, I saw something very revealing on the blackboard where they broke down their teams: MarsBased was listed as "core" of the project, unlike all of the other providers, which were listed under "external partners".

We, with our two-people team, had survived one CEO, two CTOs and several VPs of Engineering in our 5 years working for them, and contributed to many of their projects: APIs, mobile apps, IoT projects, internal tooling and the core application.

Moral of the story

While I could write ten or twenty more examples of cool things we have done with small teams for our clients, the moral of the story is the following: it's not about how many people you throw into a project - it's about who they are what you do with them.

Most products you can think of can be built with a team of three people: a frontend developer, a backend developer and someone to help them focus on the right things and also takes care of understanding the business they're in.

Most corporations throw way too many people at their projects - mainly because they already have too many employees and need to keep them productive, but also because they have to factor in employee turnover. It’s often more efficient to overstaff a project than to spend time looking for replacements and dealing with start/stop friction.

Most startups and scaleups overhire because they have more money than time left, so it's a matter of throwing money into the problem. The more people they put into trying to figure out who their customer, their product or even their target market is, the faster they might find the much-needed answers. And while they're at it, they will also play the bullshit card of "being all in the same room is essential in early stages of startups". So basically, they’re compensating for their cluelessness with an egotistical desire for micromanagement—disguised as ‘early founding team vibes'".