As a small organization, we have often encountered the dilemma of staying small versus expanding.
It took trial and error to understand what works. Luckily, it became clear to us that small teams can often exceed larger teams through faster decision-making, a more informal communication structure, and by having a focus on craftsmanship. This illustrates Leslie’s Law quite precisely: “When small meets large, small (almost) always wins.”
In this insight, we take a deep dive into the key advantages that small organizations have compared to bigger ones, and what we’ve observed first-hand when operating Mäd.
Both Mäd and its sister company, Blue, are small companies. They share an office, have small teams, and everybody knows each other’s names.
This is not an accident, it is by design.
The initial vision for Mäd was to employ hundreds of team members in half a dozen offices across South-East Asia.
It was attempted, twice. Aggressively scaling, pushing sales, and hiring new team members. Our founder, Manny, once had an onboarding day with eleven new people on the same day. He even bought another consultancy to add more team members.
Both times Mäd tried to scale, the company almost went bankrupt. Obviously, we now understand why — the founder 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 one person 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 exhilarating for entrepreneurs and founding teams. 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, we wondered if there was a different way to operate a startup.
Could we stay intentionally small?
There were never any major issues when the team count was kept 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 — hence this analysis of why staying small can be a great idea.
This is not something that is often promoted in the startup world. It is usually all about going big or going home. This is partly to do with the whole model of venture capital, and partly as large teams can be desirable 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 also 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. But the only true signal of success in a startup is the number of customers you have, and how happy they are.
Fortunately, Mäd (and Blue) is not backed by venture capital.
Mäd has had the opportunity to work on hundreds of projects with dozens of clients across a multitude of industries. And we have heard so many horror stories of clients spending absurd amounts of 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 nonsense, 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 even millions, of small businesses that are building innovative products or providing high-quality services.
By now, we have reached the conclusion that there is a strong inverse correlation in consulting firms between the size of the firm and the quality of the services provided.
Let’s explore why.
So if our hypothesis is true — that large consultancies are often inferior to smaller niche consultancies — why do the huge corporate clients default to buying services from them?
Well, it is actually quite understandable. It feels logical.
A larger consultancy has a bigger reputation, they may have senior partners that have received top university degrees, and often boast 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 an embarrassing or offensive thing! — are highly responsive during the sales process. In fact, most of the senior staff in these organizations 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:
But the reality is counterintuitive.
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-person 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.
We discussed the precise calculations in our thorough overview of the first principles approach to project management, and this is the equation we can apply here:
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.
Note that this is also a simplification because there are multiple available communication channels, so we can easily multiply 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 of these organizations are aware of this, so they create rules to try and fight this issue — eventually, we end up with highly formalized rituals and regulations to ensure tight-knit communication in projects.
Add in the problem that large organizations tend to have team members spread around the world, and there is the issue of different time zones, so 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.
The other problem, from a client perspective, is that large professional service firms do not suffer from key client risk. As a client, you are simply not as important to them as you would be to a small firm. Think about it: as an owner of a firm, you would want to avoid key client risk, but if you were a client, you would absolutely want to be the key risk client for a vendor.
Simply because this guarantees better service and far more responsive management.
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 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 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 who was 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” of work (whatever that happens to be) 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 simply 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 considering the massive budgets), and nobody knows why or who is responsible for this.
This may seem a strange heading. If we are arguing that small teams are better, surely it is a downside that small teams do less?
Let us explain why.
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 versus small organizations, 17,000 people can achieve a lot more than a team of 15.
When you think about it, 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 selective 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 massive advantage because the whole way to focus is by saying no to distractions — 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. For instance, 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 as there are so many moving pieces that you have to keep ensuring 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 versus 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 our 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 our experience starting and running Blue, having a small team also ensures that product features and improvements are shipped 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 also test it and provide feedback. We’ve managed to outsource our final end-to-end testing to our customers — free of charge.
The idea of having a public Beta that anyone can 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.
This article on Leslie’s Law (and the concept itself) felt applicable to our operational model, and it has helped further solidify our ideas around organizational structure and software strategy.
This is one of the key quotes from the 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.”
At first, this seems 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 propel their way up-market because there are more attractive 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.
In regards to the 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 notable criticism 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 evidently substandard compared to Slack, Windows feels awkward 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.
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 we emphasize the importance 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 it will likely be very difficult for your business to succeed, regardless of how good your product is.
It is a myth that the best product always wins: distribution undoubtedly has 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. At first glance, you might think this is because they have been innovative — and this is partially true. But in reality, 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 is 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 something valuable.
The key message is to embrace simplicity and run as fast as you can from complexity. Refuse to have overly complicated processes that require extra work just because “that is the way it is done around here.”
Complexity breeds complexity: before you know it, you have 50 people doing the same amount of work that could be done by 8.
Instead, as a leader, make sure to keep teams small — much smaller than you think possible. You should constantly be looking around and feeling 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 defining small teams, we 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 becomes 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; 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? Our advice is to 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.
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 end up paying ten times as much and getting worse results. Hire small local teams, have them come into your office often, and build long-term relationships. These teams will live and breathe your culture, becoming 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!
