I will tell you my dirty secret.

Through my nearly fifteen years of leadership career, my most fulfilling periods were not when I had the most "power", leading big engineering teams in huge organisations. No. I hold my most fond memories of those magical times when my engineering organisation was somewhere between 30 - 50 people.

Large enough to tackle ambitious projects and deliver meaningful work, yet small enough that I could still know everyone's name, have a meaningful relationship with all engineers and move fast, without the need to formalise our ways of working into a rigid process.

At that scale, we moved with the agility of a startup but had the resources to build substantial products. Engineers knew each other across teams, technical decisions happened through informal collaboration rather than formal architecture reviews, ownership and accountability were the default, and everyone was passionate about the product we were creating.

Every day at work felt like an adventure with a bunch of friends. A group of passionate nerds, solving difficult problems together and creating a great product.

When there was a problem, like a nasty production incident in the legacy platform, we all jumped together to solve it. And we had a lot of fun doing it.

Good times - we were in the sweet spot. And I learned to appreciate it only after it was gone.

Beyond The 50-Engineers Threshold

Later, I learned it wasn't just me. Many people, much smarter than I, noticed this pattern as well. They've used many smart words to describe it: Scaling Inflexion Points, Ringelmann Effect, Brooks' Law, Organisational Complexity Wall. They even mention eating a pizza or two.

All those fancy terms boil down to one truth: scaling organisations is brutally hard, and crossing the 50-person threshold changes everything.

But what exactly happened when we crossed this magical threshold?

The Explosion of Complexity

The complexity of our daily work did not just grow with the number of people we were hiring. It exploded exponentially, affecting every aspect of our work.

With 10 people, we had 45 possible communication lines. At 25 people, that jumped to 300. With 50 people, we were dealing with 1,225 potential communication paths. As Stripe calculated in their Annual Report, a staggering 42% of engineering time gets lost to organisational overhead once you hit this scale.

Communication became a pain point. Suddenly, we had dozens of new people who needed to be onboarded and aligned with our plans. Tasks that used to be trivial, like finding someone for a code review or communicating an important deployment, now required a lot of effort and a formal process.

Ownership and accountability got diluted. In a small team, it's hard to hide. Your work is visible, your contribution is clear. Once the team grows, it becomes much easier to blend in with the crowd and play the "someone else's problem" card when a difficult issue occurs.

Decision-making ground to a halt. With more people involved, there are more moving parts. Suddenly, I found myself spending entire days in coordination meetings. The cognitive load was crushing. Reaching consensus became nearly impossible, so we started gravitating toward preserving the status quo and avoiding any change that required significant coordination.

Our culture of quality crumbled. With a fast-growing organisation, our culture was not preserved as well as we would wish to. New people were onboarding new people. Seniors and Tech Leads were stuck in the never-ending coordination meetings. The organic alignment and good practices we'd built over the years started fragmenting into inconsistent approaches across teams.

We lost that sense of common goal, a cohesion of culture we had before. The pride in our craft we had developed organically as a small team working on something awesome.

🎶 Our Old Ways Were Rapidly Aging 🎶

The Price of "Success"

Eventually, we fixed those issues. We scaled our processes, adjusted our team hierarchies, and fixed our culture to match the challenges of our new scale. We kept growing, bypassing the threshold of 100+ engineers.

But in retrospect, I do wonder sometimes, was it worth it? A bigger organisation, even if done well, carries the burden of additional processes and management layers.

Would it be better if we stayed smaller and leaner?

Growth at All Costs

In the business world, growth has become synonymous with success. Investors celebrate headcount increases as proof of momentum, while total employee count becomes a vanity metric regardless of actual productivity. This pressure creates a narrative where bigger automatically means better.

Within the organisations, managers are incentivised to grow their empire, not because the work demands it, but because career advancement depends on it. A director managing 80 engineers commands more respect and earns higher compensation than one managing 30, regardless of their teams' actual output.

Promotions require demonstrating the ability to "scale teams." In performance reviews, managers showcase headcount growth as leadership evidence, while those maintaining lean teams may seem to lack ambition.

This misalignment between career incentives and organisational effectiveness creates systematic bias toward bloated engineering organisations.

Fortunately, there are notable exceptions.

The Power of Small Organisations

You don't need to be big to make a difference. There are countless examples of small organisations that delivered amazing products, cashed in big time, or even revolutionised entire industries.

The founders of 37 Signals (Basecamp) are among the best-known advocates for small teams. They keep their company small to avoid layers of middle management and complex processes. David Heinemeier Hansson, the company's CTO, openly states that he would quit rather than manage a large engineering organisation because he prefers the focus and culture of small teams.

The tools that I use to create this blog, Obsidian and Ghost, are created by tiny teams, and yet they are used by millions of users, generating millions of dollars of revenue, challenging big, VC-funded competition.

WhatsApp, famously, had a team of 30 engineers, serving billions of users and getting acquired for $19B.

Instagram had 13 engineers when acquired for $1B

Stripe, in its early days, had just 10 engineers, and yet, they revolutionised online payments.

For those companies, and countless others, their lean size was an advantage. It allowed them to move fast, iterate, and experiment without the burden and rigidness of structures and processes.

Yes, they were constrained by their size. But constraints encourage looking at problems from different perspectives, forcing novel solutions and innovative creative works. They provide direction to keep projects focused and motivation to look beyond the obvious. Limited size forces you to prioritise what really matters.

As counterintuitive as it may sound, the power of the small organisation may come from its biggest limitation.

Maybe it's time to stop asking 'How can we grow bigger?' and start asking 'How can we stay small?'