The Advantages of Small Organizations.
This essay is an explanation of the key advantages that small organizations have compared to bigger ones. Small teams can often run circles around larger teams through faster decision-making, a more informal communication structure, and by having a focus on craftsmanship. We also review Leslies’ Law — “When small meets large, small (almost) always wins.”
Introduction.
Both of my organizations, Mäd and Blue, are small companies. They share an office, have small teams, and I know everyone’s name.
This is not an accident, it is by design.
My initial vision for Mäd was to employ hundreds of team members in half a dozen offices across South-East Asia.
I tried it, twice. Aggressively scaling, pushing sales, and hiring new team members. I once had an onboarding day with eleven new people on the same day. I bought another consultancy to add more team members.
I recall this time in my life as the most stressful, as well as the most educational. As a first-time founder, I had to understand and learn all the core functions of running a company. Everything that went wrong was my fault, and lack of knowledge was not an excuse.
Both times I tried to scale, the company almost went bankrupt. I now understand why — I didn’t know enough about finances, hiring talented team members, or project management to be effective at that scale. The company was too big and unwieldy for me to have full visibility and control.
Large organizations look good on paper, with their long lists of clients, impressive resumes of team members, and glossy marketing collateral. They signal success, which can be intoxicating for founders. The problem is that size doesn’t necessarily equate to effectiveness. In fact, large organizations often suffer from a number of issues that make them slower, less nimble, and less effective than their smaller counterparts.
Instead of trying a third time, I wondered if there was a different way to operate a startup.
Could we stay intentionally small?
I never ran into any major issues when I kept the team count below 25, but both times it went above this, everything seemed to fall apart.
Could we focus on quality, instead of quantity?
Could we grow by raising our prices, instead of our headcount? The answer turned out to be yes, and today’s essay is an analysis of why staying small can be a great idea.
This is not something that is often promoted in the startup world. It is all about going big, or going home. This is partly to do with the whole model of venture capital, and partly to do with CEO and leadership teams wanting to grow their ego by having their own departments and lots of team members.
Large teams can be intoxicating for startup founders because they signal success. Larger teams also have more resources and are often seen as being more stable. However, large teams can often be less effective than smaller ones due to slower decision-making, a more complex communication structure, and a focus on quantity over quality.
Team size becomes a proxy for success, the same way the amount of venture capital raised becomes a proxy for momentum. The only true signal of success in a startup is the number of customers you have, and how happy they are.
Fortunately, Mäd (or Blue!) are not backed by venture capital, and I managed to somewhat deflate my own ego over the years. 😉
I have had the opportunity to work on hundreds of projects with dozens of clients across a multitude of industries. I have heard so many horror stories of clients spending crazy money and time working with large consultancies, with very little to show for it. Once they work with Mäd, it is like a breath of fresh air — no bullshit, just a focus on the work at hand. Often for a fraction of the price of the large consultancies.
We often hear the news of large companies releasing new products, but what does not often get much press is the thousands, perhaps millions, of small businesses that are building innovative products or providing high-quality services.
I have reached the conclusion strong inverse correlation in consulting firms between the size of the firm and the quality of the service.
Let’s explore why!
Big Organizations Look Good, On Paper.
So if my hypothesis is true, that large consultancies suck compared to smaller and more niche consultancies, why do the huge corporate clients mostly keep buying services from the large consultancies?
Well, it is actually quite understandable why large corporations keep buying services from large consultancies. It feels logical.
A larger consultancy has a bigger reputation, they may have senior partners that have had top university degrees, and often they have a very respectable client list and case studies. Their Account Managers — and it is interesting to note how in modern society we cloak the job of the salesperson with titles such as Account Managers, almost as if being in sales is a dirty or offensive thing! — are highly responsive during the sales process. In fact, most of the senior staff in these organisations will focus exclusively on new business development, not working on the projects that they sell to clients. They also have a diverse set of experiences with previous projects, and they have a larger pool of potential expertise and talent that they can match to a client’s specific project.
However, what these corporations don’t realize is that they are actually shooting themselves in the foot by doing this. Here’s why:
1. Large consultancies are less nimble and agile. Because they are so big, it is much harder for them to change direction quickly or pivot when necessary. They are also more bureaucratic, with more layers of management that need to sign off on decisions. This can make them very slow and unresponsive, which can be a huge disadvantage compared to smaller organizations.
2. Large consultancies often have a “one size fits all” approach. They tend to offer the same solutions to all of their clients, regardless of the specific needs of those clients. This “cookie cutter” approach is not ideal, since it doesn’t allow for customization or tailoring of solutions to meet the unique needs of each client.
3. Large consultancies can be inflexible and inflexible. They often have very rigid processes and procedures in place, which can make them very difficult to work with. This can be a major frustration for clients who need more flexibility and agility from their service providers.
4. Large consultancies tend to be more expensive. Because they have more overhead and higher costs, large consultancies typically charge more for their services than smaller organizations. This can be a major deterrent for clients who are looking to save money.
5. Large consultancies often have difficulty attracting and retaining top talent. The best and brightest employees often prefer to work for smaller, more nimble organizations where they can have a greater impact and make more of a difference. As a result, large consultancies can have difficulty attracting and retaining top talent, which can make it harder for them to provide the best possible service to their clients.
But the reality is counterintuitive.
Teamwork Doesn’t Scale.
The reason why the above hypothesis doesn’t work out, in reality, is because they ignore a fundamental truth about collaboration and management:
It doesn’t scale.
There is no 50,000+ employee organization in the world that is made up of a 50,000 team working harmoniously together. An organization of 50,000 is actually made up of, give or take, 2,000 teams of 25 people each.
The communication overhead alone is incredible as organizations scale up.
Let’s run the maths.
I discussed the precise calculations in my blog post on the first principles approach to project management, and this is the equation I use:
n(n-1)/2 = The Number of Possible Communication Threads
Where “n” is the number of people that need to be involved in the project.
Plugging in the numbers, at 50,000 employees there are 1,249,975,000 possible direct communications threads.
But, let’s be generous and assume that it is just the teams that need to coordinate, not each individual.
So, we have 2,000 teams and using our equation we get 1,999,000 possible direct communications threads.
And this is also a simplification because there are multiple available communication channels, so we can easily multiple the above numbers by five.
Ok, but so what?
Well, the result is that this incredible overhead in communication means that in large organizations, the left hand doesn’t know what the right hand is doing. And the members in these organizations are not stupid, they are aware of this, and so they create rules to try and fight this issue, and we end up with highly formalized rituals and rules to ensure tight-nit communication in projects.
Add in the problem that large organizations tend to have team members spread around the world, and then you can have the issues of different time zones, and we can see where this is heading.
Lots of bureaucracy, and far less work done. Lots of discussions and alignment meetings, not much deep work by individuals. More management, fewer actual doers.
I discussed this in a related essay about how remote work enables larger meetings, and how this is not a great thing. You can read that here.
The other problem, from a client perspective, is that large professional service firms do not suffer from key client risk. You are simply not as important to them as you would be to a small firm. As an owner of a firm, I want to avoid key client risk, but if I was a client, I would absolutely want to be the key risk client for a vendor.
It provides me with better service and far more responsive management.
Small Teams Encourage Craftsmanship.
Great work is achieved through people who care. Without care, one does not get the details right. Without the small details, the quality of the work suffers.
The end consumer of our work, they will be able to tell the difference. They may not be able to express it precisely, but the particular product will intuitively “feel” better than the competition. There is a qualitative difference that cannot be copied, because everyone else is just rushing their products out of the door, without a focus on quality.
People care about their work when they can clearly understand how their contribution is meaningful compared to the whole finished product.
I’m a dying breed. A laborer. Strictly muscle work . . . pick it up, put it down, pick it up, put it down. . . It’s hard to take pride in a bridge you’re never gonna cross, in a door you’re never gonna open. You’re mass-producing things and you never see the end result of it. (Muses) I worked for a trucker one time. And I got this tiny satisfaction when I loaded a truck. At least I could see the truck depart loaded. In a steel mill, forget it. You don’t see where nothing goes.
Terkel, Studs. Working: People Talk About What They Do All Day and How They Feel About What They Do (p. 40). The New Press. Kindle Edition.
This sums up the feelings of a steelworker, interviewed about his mechanical job creating an undifferentiated product. He would never see where the product would end up, or what it would be part of.
He continues:
I would like to see a building, say, the Empire State, I would like to see on one side of it a foot-wide strip from top to bottom with the name of every bricklayer, the name of every electrician, with all the names. So when a guy walked by, he could take his son and say, “See, that’s me over there on the forty-fifth floor. I put the steel beam in.” Picasso can point to a painting. What can I point to? A writer can point to a book. Everybody should have something to point to.
Terkel, Studs. Working: People Talk About What They Do All Day and How They Feel About What They Do (p. 41). The New Press. Kindle Edition.
This reminds me of how Steve Jobs insisted that the original Macintosh team signed their work and that reproduction was included inside each machine. Customers would never see it, but the team working on the product would know that their name was on every machine that would ship out.
Cal Newport takes this further in his book Deep Work.
Ric Furrer is a master craftsman whose work requires him to spend most of his day in a state of depth — even a small slip in concentration can ruin dozens of hours of effort. He’s also who clearly finds great meaning in his profession. This connection between deep work and a good life is familiar and widely accepted when considering the world of craftsmen.
Newport creates a direct link between the amount of time that an individual spends in concentrated deep work and the quality of their overall life.
This may then hint that small teams are not just good for the end product because they enable individuals to tackle their work as a craft, but it is good for the individual themselves!
That said, having small teams does not automatically mean that care and attention to detail will prevail. This is something that has to come from the structure of the work and the culture of the organization. Ensuring that individuals are empowered to start and complete an entire “unit” (whatever that happens to be) of work is important.
It is more efficient to split the different steps and processes of work across different team members. Each individual can then specialize, and this can then lead to productivity improvements. But, this is short-term thinking.
This is because of two key problems:
Firstly, individuals that do the same task over and over again will become bored, and the work itself will feel meaningless. So, after an initial spurt of increased productivity due to becoming familiar with the repetitive work, there will actually be a slump in productivity. Eventually, this person will leave — especially in highly competitive fields such as knowledge work and software engineering.
Secondly, this stops any one individual from claiming ownership of the complete unit of work. Problems can be tossed across the proverbial garden fence for someone else to deal with. This is hardly conducive to creating a high-quality final output.
Instead, have the same person responsible for the entire process. If you have a software engineer, get them to work on the entire feature, don’t split up the database design, the backend development, the front-end development, and finally the testing across multiple individuals. You’ll write higher quality software, and you’ll have happier developers. This can work across a surprisingly different array of industries and verticals.
At Mäd, for instance, we do not have dedicated salespeople. A potential client will speak to a partner in the business, and likely it is that very same partner who will then manage their project. This creates a forcing function where, during the sales process, there is no incentive to over-promise only to under-deliver later. This is because the person over-promising will have to deal with the consequences — there is no one else to deal with it!
This is quite the opposite of what happens in conglomerates with large teams. Projects are late, the quality is awful (especially when you consider the massive budgets), and nobody knows why or who is responsible for this.
Small Teams Do Less.
This may seem a strange heading. If I am arguing that small teams are better, surely it is a downside that small teams do less?
Well, hear me out…
While individual team members in a small team are more efficient than their counterparts in large teams, large teams do have an advantage — there are a lot more people! Even if productivity is reduced by 50% or 75% in large organizations vs small organizations, 17,000 people can achieve a lot more than a team of 15.
I always say that in large organizations, you can do pretty much everything wrong and you can still be carried along by the general organizational momentum.
But, there is actually a very large, yet counterintuitive benefit to doing less. If you are doing less, you are going to be far more rigorous in what you say “yes” to. Potential projects and ideas have to go through a rigorous analysis before you just start to work on them because resources are scarce.
This is a huge advantage because the whole way to focus is by saying no to distractions, to the endless shiny objects in the distance that take you away from your predetermined path.
And make no mistake about it — running a small team is not easy. If you’re a team of five, you can easily lose 40% of your capacity by having one person on holiday and another off sick. So productivity does matter, and each individual is far more important to the overall direction of the organization.
So instead of doing many things, small teams have to be smart and have a clear way to define what they are going to work on next.
The key question that each team member should be asking themselves is:
Am I working on the thing that is most likely to drive our organization towards our stated goals as quickly as possible?
And when evaluating work, small teams have to think far more about the long-term implications of the work. How much overhead and maintenance will this project require in the future? These concerns are important because it is easy to build up inertia over time because they are so many moving pieces that you have to keep ensuring that are working — regardless of what industry you’re in.
Small teams also do less because they are far more likely to employ strategies such as outsourcing (especially some types of on-demand work vs long-term contracts) and automation.
For instance, instead of hiring a full-time graphic designer, a small team may use an online service for task-based design work. A bigger organization would likely hire a full-time designer or put a large contract out to bidding for various agencies, and then have to spend time interviewing various agencies, doing the selection process, and so on.
With regards to automation, this is linked to my earlier point that each person in a small team has to take full responsibility for the work that they are doing, and so they will likely want to avoid as much rote work as possible. In larger teams, you may have an abundance of junior team members or interns that you can throw at any problem, so automation is less important than it should be.
With my experience running Blue, having a small team also ensures that we ship product features and improvements in an incremental manner, instead of thinking in terms of large feature releases. This is because there is typically just one person working on a feature, and we don’t want to wait six months for everything to be perfect before we get it into customers’ hands. So, the best idea is to review the full scope, cut it down significantly, call it a v1, work on that and ship it. Then, we get into the great cycle of having real customers using the new feature, getting feedback, and then iterating based on that.
In fact, we don’t have a single dedicated software tester at Mäd. The person who builds the feature is responsible for the testing, and then the entire team tests the feature as well. Then, we ship it to a public Beta version of Blue that is used by hundreds of customers, and they test it and provide feedback. That’s right, we’ve managed to outsource our final end-to-end testing to our customers — free of charge.
The idea of just having a public Beta that anyone could access just by changing the URL of our web application was a good one because that saved us growing our team by 10-20% to include testers.
Analysis of Leslie’s Law.
I came across this article quite a few years ago, and it helped solidify my ideas around organizational structure and software strategy.
This is one of the key quotes from the entire text:
There’s always the temptation to over-feature your product, to build in bells and whistles because server space is cheap and you have the funding and talent to do it. Resisting this urge is your real competitive advantage.
You would think that this is easy to resist, but in reality, it is extremely difficult. Get funding, and suddenly you’re going to hire, and if you hire too many engineers, they will want to build something, and that something will get built — regardless if it is truly useful for the end customers or not.
Everyone is constantly trying to chew their way up-market because there are juicer ARRs (Annual Recurring Revenue) numbers with larger customers. But, these customers have needs, and so features get built. Repeat this with ten customers, one hundred, a thousand, and your product is completely different, and potentially rather bloated.
Your core customer base that you started with, someone else is going to come along with a nimbler solution that can serve their needs, and this will accelerate your transition to going up-market.
One criticism I have of this law is that large companies do have one distinct advantage: distribution.
This is, essentially, why Microsoft is still with us today. Each of their offerings has a competitor that has a better product. Teams is a pile of crap compared to Slack, Windows is absurd once you’ve been using Mac for a while, and let’s not forget Internet Explorer (RIP).
But, they have incredible distribution. Most companies in the world already use Microsoft technologies, so if they add a new product, it is trivial for this to be adopted by millions of businesses across the world.
Microsoft also has a large partner network across most of their products in each country in the world, and this means that customers can speak to a representative, or that representative can reach out and directly sell the solution.
I think that this is an important caveat to Leslie’s Law. If you have a product that has a better mousetrap, but no one knows about it, or no one can easily buy it, then you will struggle. This is why I think that it’s so important for startups to focus on not just building a great product, but also on distribution. How are you going to get your product in front of people? How are you going to make it easy for them to buy it? If you can’t answer those two questions, then I think it will be very difficult for you to succeed, regardless of how good your product is.
It is a myth that the best product always wins, distribution does have a lot to do with it, and this is why we have seen technology companies such as Apple, Microsoft, and Oracle survive for so many years. You would think that this is because they have been innovative, and this is partially true. But, a lot of it has to do with the fact that they have been able to get their products in front of people and make it easy for them to buy.
That said, Peter Thiel makes the counterintuitive point that if you want to bet on the future of search, you should not invest in Google. This seems strange, surely Google are the leader in search in the world?
Well, yes and no. Yes, they have the most popular search engine in the world, but it is built from a 20-year-old core. There is some startup, somewhere, that is crafting a bullet in a garage that will one day kill Google. We probably have to wait for a paradigm shift, but this small team has insight, has something.
Conclusion.
The key message today is to embrace simplicity and run as fast as you can from complexity. Refuse to have overly complex processes that require extra work just because “that is the way it is done around here.”
Complexity breeds complexity, and before you know it, you’ve got 50 people doing the same work that could be done by 8.
Make sure to keep teams small, much smaller than you think possible. You should constantly be looking around and be surprised at how much your team is achieving. This should be a shock to outsiders as well. You should hear things along the lines of “Oh, you only have x people on your team, that’s amazing!”.
With regards to how we define small teams, I’d like to lean on Jeff Bezos’ Two Pizza Rule. If you cannot feed the entire team with two pizzas, it is too big. Split some team members off and create a separate team, or rethink how you are doing things.
And when teams are small, hiring because ridiculously important. You don’t have time for fakers, time wasters, and pedantic individuals. You need to be surrounded by A team players. Hire slowly, and every hire you do make should be increasing the overall average of the team. You should constantly be looking to improve the average, not just fill a seat.
But how do you find these individuals? Look for people that have achieved greatness in their field. People that have done more with less. If they’ve already proved themselves in other areas of life, there is a very good chance they will excel working with you. These are individuals that have already shown they can overcome adversity and achieve the impossible. The world is constantly moving faster, and this pace is only going to increase. The companies that will survive are those that can move quickly and efficiently. Those that have a bias towards action, and those that embrace change. Change is the only constant in the world, and those that can adapt will be the ones that succeed.
You should get the feeling that the people you hired a few years ago, if they had not improved since then, probably would not be hired today. The quality bar needs to keep rising each and every year. That said, don’t ignore those with unusual backgrounds. Just because someone does not have the right degree or specific experience, does not necessarily mean that they are not a great hire. In fact, sometimes these people turn out to be the best hires of all.
Finally, if you work in a corporate environment, hire small vendors where possible. Don’t bring in one of the big four consultancies or Infosys, you’ll pay ten times as much as getting worse results. Hire small local teams, have them come into your office often, and build a long-term relationship. These teams will live and breathe your culture, and become an extension of your own team.
The world is moving too fast for bloated organizations with hierarchies and politics. The future belongs to those that are nimble, those that embrace change, and those that have the courage to bet on themselves. So, go out there and build something — with a small team!
