Scalability. It’s one of those buzzwords we hear all the time in business settings;
“Will this scale well?”
“This doesn’t seem scalable.”
But what does this word and related concept actually entail? This article aims to explore it in more depth and hopefully give it some definition and structure that it lacks in everyday conversation. We’ll start out simple and then work into a more nuanced view of scalability.
A basic definition of scalability
A good way to approach the meaning of scalability is through a slightly mathematical definition. This doesn’t mean digging into derivatives or complex numbers, which we’ve all long since forgotten, but applying some basic mathematical ideas to the concept;
The basic idea of scalability is this:
A product or service X is considered scalable, if: Delivering 20 of X is either…
- no more costly or difficult than, or
- only incrementally more costly or difficult than
… delivering 10 of X.
And the corollary:
A product or service X is considered not scalable if: Delivering 20 of X is double or even more costly or difficult than delivering 10 of X.
Or, it could be re-worded of this way:
If Y is the effort required to deliver 10 X, then:
- if delivering 20 X requires ~2Y or more, then X is not a scalable product or service.
- if delivering 20 X requires Y or only a bit more than Y, then X is a scalable product or service.
This is the heart of the idea of scalability. It’s the difference between a linear and an exponential relationship between costs, revenue and product delivery.
Naturally, these numbers are not hard and fast, and in reality business is generally much more complex, however the basic concept remains the same.
Simple examples to illustrate
Maybe some simple examples will make the concept clearer. These will be intentionally over-simplified to fit into a binary model;
Example 1: Manually washing cars: not scalable
Imagine that I wash cars for a living. Delivering the washing of a car involves a few basic variables (let’s assume I already have the tools for the job):
- Selling the car wash to a person (convincing them that they should get their car washed by me) == Y1 == ~10 minutes
- Actually washing the car == Y2 == 1 hour
Y1 and Y2 are my “costs”, together they are the Y from the definition above. Together they take about an hour of my time.
Now, it’s easy to see that if I am manually washing cars one by one, then my business model is not scalable. Because, washing 20 cars is pretty much double the effort of washing 10 cars. Simple.
Example 2: Teaching students: scalable
Imagine I am a teacher of Chinese history. Delivering the education of Chinese history involves one basic variable; my time in the classroom (again, assuming I have the knowedge and expertise to teach) :
- It takes me 1 hour to deliver a lecture on Chinese history == Y
However, let’s imagine that in one class I have 10 students, and in the other class I have 20. By all accounts, in the classroom with 20 students, I am “delivering” more education, in theory, exactly double. But teaching 20 students was no more difficult than teaching 10 students. I delivered exactly the same lecture, however in the second case, twice the number of students attended. In this simple model, teaching Chinese history is a scalable exercise!
These two examples are, of course, oversimplifications. But the essence of the idea of scalability is accurate. In example 1, the business model was less scalable than example 2.
Naturally the real world involves many more variables. In the case of the car wash, I might have an advertisement sign outside that does my selling for me and so selling doesn’t cost me any of my time. In the case of the teaching, the model breaks down as we keep adding students (we can only fit so many students into one of my lectures; the model scales only so much, then I have to break it out into two classes). But these variables can be plotted out and understood and ultimately fit into the model of scalability.
Real life scalability
In the oversimplified examples above, scalability was treated like a binary property; either something is scalable or not. However, real life is, naturally, a lot more involved. Let’s play with the concept a bit more by defining some limits to it and talking about additional variables:
Upper limit: nothing is infinitely scalable
Something would be infinitely scalable if the costs Y, of delivering product X, are not at all increased no matter how much of X we deliver. In the real world, this is simply not possible.
There are some products in reality that are highly scalable. One such area is something like a website. Imagine for instance this blog article. It’s going to take me a certain amount of time to write it (our Y) — and if 10 people read it (10X) or 20 people read it (20X) the time it took me to write it is completely unaffected. Digital content is highly scalable. Imagine if 1000 people read this article — still, it only took me Y effort to produce it. What about 10 000? 100 000? Still, it only took me Y effort to produce it.
However, eventually my server can’t handle the load. So I have to pay for a better server to host my content, and my Y has increased. Digital content is highly scalable, but not infinitely — nothing really is.
Lower limit: increased efficiency as the genesis of scalability
Let’s return to the car example from above. Imagine I’m the guy out there washing the cars every day. Eventually I wake up and realise that I’m never going to scale my business very well. So I start thinking; how can I scale this up?
Let’s say I start to learn how to wash two cars in a little less than double the time it takes to wash one. For instance, I reclaim and re-use the water somehow, so I don’t have to wait for the hosepipe for as much time. Or maybe I rinse and dry both cars at the same time side by side. Either way, I am finding ways to cut down the time usage.
Increased efficiency lies close to the genesis of scalability, but is not entirely the same thing. Increasing efficiency means reducing Y for the delivery of 10 X, which ultimately does mean delivering 20 X takes less effort, however it is still 2 Y, even if Y itself is less.
Scalability is about increasing the efficiency of multiple deliveries of a product or service, not just a single delivery.
Individual scalability vs. business scalability
Now we break up the idea of a business and an individual being scalable, and start thinking about scalability in terms of personal time usage. Imagine, the car washer business owner realises something;
I’m very good at washing cars, but my business will never scale as long as I keep washing cars one by one by hand. I need to scale.
Instead of washing cars myself, I am going to hire some juniors and teach them how to wash cars. Then I will spend more time on the marketing and administration of the business.
Now, the business owner is making his own time scalable. Think about it this way, if he is not personally washing the cars, but his employees are, then washing 10 cars and washing 20 cars is the same amount of effort and time, for him. Sure, the employee takes double the time, but the business owner doesn’t 🙂
And there we have the big secret as to why people start businesses and become business owners.
Of course, it’s not all that easy. He now has to cover his own salary and that of his employees from washing those 20 cars. He has to hire at least several car washers to make this work out. What if the car washing demand dies down during the winter? He has to think about all of these variables.
Scalable and non-scalable components of an overall process
In real life the process of delivering a product or service is not usually entirely scalable or non-scalable. Often, there are components or parts of the overall process that are scalable to varying degrees.
This example illustrates this idea quite nicely:
There are some guys in Dominoes pizza making some pizzas for customers. The creation of a pizza involves several steps. The chefs have to prepare the dough, put on the proper ingredients, and cook the pizza in the oven.
Interestingly, preparing the pizza is a non-scalable activity. A chef, no matter how good, can’t prepare two pizzas for exactly the same effort as it takes to prepare one. Yes, perhaps he can work on ways to do it quicker, but he can’t scale the preparation well.
However, two pizzas can be cooked in the oven at the same time. In fact, ten or even twenty pizzas can (assuming the oven to be quite big).
So, preparing the pizza is a non-scalable activity, but cooking the pizza is a more scalable activity.
So the delivery of the pizza to the customer involves both scalable and non-scalable parts of the process. Imagine further an even more nuanced scenario, also in our pizza story:
The pizza delivery driver is going to deliver two pizzas. Luckily, both customers are on the same street. So, delivering two pizzas took only a little more time than delivering one would have.
In fact, delivering 10 pizzas to the same street, assuming the distance from the pizza store to the street is way larger than the distance from the one house to the next on the same street, is almost the same effort as delivering 5.
But, what if, in another scenario:
The pizza driver is going to deliver two pizzas. Unfortunately, both customer’s houses are equidistant from the pizza store, and each other. Assuming the main cost of delivering a pizza is the time to drive to a location and the petrol associated with the driving, delivering two pizzas literally took double the effort than delivering one did.
And so we see that in the case of delivering pizzas, the scalability or non-scalability of an activity can depend on entirely random variables. Sure, we can look into optimising our pizza delivery routes, but ultimately that can only go so far.
Scalability; the way the rich get richer
Finally, some thoughts about the economics of scalability.
Returning to the car wash owner who wants to scale his business, he has two primary routes (or some combination of the two) that he can choose from:
- Scale his personal time by hiring understudies
- Scale his personal time by automating the entire car washing process through technology
As he learns to scale his time and business — his costs crow linearly, but revenue grows exponentially. Washing 10 cars earns him $500, costs him $200 ($300 profit), but washing 20 cars earns him $1000 while only costing $250 ($750 profit). Naturally, these numbers are exaggerated, but the idea holds true.
If revenue grows linearly with costs, the the potential for a business to make money is diminished. If revenue grows exponentially while costs remain linear, then a business can scale well and make more profit.
Who benefits from business that scale well? One word; stakeholders. Shareholders, business owners, etc. These are the people on the “benefiting” side of the scalability equation. On a personal level, everyone else is “not scaling”.
Trading time for money — not scalable
Now we come to the ultimate takeaway for our own life, career and employment. If we return to the idea of “personal scalability” — how do you fare?
For most people in the world (including myself), employment is a simple equation — a linear trade between time and money.
Your time is the Y. It is the cost. In a weird kind of double-bind, your service and your cost ARE BOTH your time. X is Y, Y is X. Delivering 10 hours takes 10 hours, delivering 20 hours takes 20 hours. Delivering 10 hours will earn you $X x 10 (X == your hourly rate) and cost you Y x 10 (Y = 1 hour of your time), delivering 20 hours will earn you $X x 20, and take Y x 20.
And so it is. The way that most people in the world earn money is not scalable. It’s a difficult trap to get out of. It’s probably part of the equation of what separates the upper-class from the middle and lower classes. The main beneficiaries of the system and the economics of scalability are the people at the top; owners and stakeholders. They are generally happy to buy other people’s time, because with other people’s time they can scale their own.
This is, ultimately, “just the way it is”. I doubt it will change anytime soon. Perhaps in the perfect society all would benefit from scalability.
But for now the question is: What is the next step you can do to take a step up the scalability ladder, getting closer to the ability to properly scale your time?