Stoa Daily Challenge #16
While all premium users flock to the Apple Watch, Noise, a homegrown brand, has captured the Indian market for smartwatches by storm in the last two years. Much of their growth has been a result of marketing magic.
In today's challenge, step into the shoes of Yash Goel, a content marketer from the company, and help him improve email conversions with your copywriting skills.
Now, to today's issue.
Say you were to order the entire Harry Potter collection of 8 movies as a DVD set from Amazon.
At the same time, you decide to download the whole collection digitally on your computer to check which process happens faster.
As the delivery was fulfilled by Amazon Prime and you have a decent enough internet connection, the download completes a good hour and a half before the DVDs get physically delivered to your doorstep the next day.
Not bad. Downloading wins by a small but real margin. It's faster.
But now, let's say you wanted to order multiple collections like the Lord of The Rings Trilogy, The Dark Night Trilogy, The SAW series, and The Harry Potter collection, all at once.
Which method would be faster?
This time, the delivery takes the same time as before: one day.
But the download takes a whole week.
So, what changed here?
For online shopping, the number of items purchased (n) doesn't increase delivery time. It will take the same amount of time for Amazon to ship 10 movie sets as it takes to ship 1.
In programming parlance, we say that this process has a time complexity of 1, i.e., it takes a constant amount of time to complete, regardless of n.
(Well, to a decent enough degree at least. Of course, if you were to order an entire warehouse of movies, it would take longer.)
And it is denoted by a notation called the Big O Notation.
For online shopping, the time complexity of the process for a single user is O(1), meaning it takes a constant amount of time for all n ranging from 1-100 or even 1000.
For downloading, however, the download time is directly proportional to the size of the movie, and hence, the number of movies. In other words, the time complexity for this process scales linearly with n.
Let's assume for simplicity that all movies are 10 GB in size. If downloading one movie takes you 2 hours, downloading 10 movies will take you 2 x n = 2 x 10 = 10 hours.
In Big O Notation, the time complexity for downloading is O(n).
Online shopping scales better than downloading.
If you wanted to download a 25 MB audio file, of course downloading would be faster with even a measly download rate of 256 Kbps. But if that 25 MB is now 25 TB, things start looking different.
You'd rather have a person travel to you and deliver you a 25 TB hard drive than download all the data yourself, which would take months, if not years.
For shipping large volumes of data, physical shipping is still a much faster way to ship than downloading it from the internet.
In fact, there is actually a term for this counterintuitive insight: Sneaker net.
"Sneakernet, also called sneaker net, is an informal term for the transfer of electronic information by physically moving media such as magnetic tape, floppy disks, optical discs, USB flash drives or external hard drives between computers, rather than transmitting it over a computer network. The term, a tongue-in-cheek play on net(work) as in Internet or Ethernet, refers to walking in sneakers as the transport mechanism."
The Hubble Space Telescope has generated over 120 TB of imagery data over its lifetime of operation. Guess how they got Google to archive that data in their data centers?
SneakerNet. A person physically travelled to Google's datacentres and had them store it.
But this essay isn't about SneakerNet. Nor is it about time complexity.
It is about how processes that might look good and convenient today will not scale well beyond a point.
Let's take a more practical example to illustrate the point.
Let's say you are running a course and 100 people are interested in signing up for it, but they all have their questions, mostly the same, some different.
If you were to do a 1:1 with each one, you will be repeating answers to the same questions over and over again.
This process scales linearly with time, the more the number of people, the more hours you will have to put into answering their questions.
So, you decide to optimize this process by adding the most frequently asked questions in the form of an FAQ on the website. Now, even a 1000 people can read that FAQ without you having to go on a 1000 different calls. You just reduced the time complexity of the process to a fraction of what it was before.
Your calls will be shorter, you won't have to answer the same questions over and over again. This is of course assuming people read the FAQ, which is a bad assumption to make in a country like India, but for the sake of the explanation let's just assume it, okay.
Now, you realize that an FAQ is a static piece of information and not really dynamic enough to handle additional questions. But you don't wish to entertain a thousand calls.
So, you decide to make a Discord or Telegram group instead where people can have a conversation with you in a public group and one conversation can benefit 100 other people who are on the same group.
This process cuts down the interaction from a few hundred separate video calls to just a few conversations over group chat where all the new questions can be answered once and for all to benefit from. You can even have group Q&A sessions every week instead of a 24x7 group chat.
So, now you have the FAQ and the group chat, and the number of 1:1 calls you have to go on has reduced significantly. Hurray, you just made your system more scalable.
The same goes for documentation in a company. Instead of communicating with all stakeholders individually, you make a common Notion document that everyone can read and come up to speed. You have to create the document once, post which you benefit from its fruits for a long time.
This is about making processes more efficient, more closer to O(1), so that with the same effort, they can scale with increasing users, customers, company size, etc.
But that's not all. The Big O notation also shows you how to manage increasing complexity and overheads at scale.
Let's say you have a team of 5 members. Every member is communicating and collaborating with everyone else in the team, which leads to a total of 10 interactions or relationships to maintain. Let's say we add another member to the team. Now the interactions suddenly go up by 5, to 15. Let's say we add another one. Now the interactions go up by 6 to 21. For every new member added to the team, the number of interactions go up by n-1.
And generally, in any group of "n" people (like your team), the number of possible relationships (R) = [ n x (n-1) / 2 ].
So, the complexity of the engagement increases by a factor of (n-1) / 2 for every n + 1.
At scale, when you're working with large n, the complexity with each added part grows significantly. Each part or member comes with its own dependencies, overheads, maintenance, and general upkeep.
This is why many companies like Gojek prefer to not have teams of over 5 engineers working together. Because as the number of engineers in a team goes up, the interactions and communicational overheads start overshadowing the increased productivity gained from adding one new member.
And this is also why Tesla is getting rid of its LIDAR sensors.
“The best part is no part. The best process is no process. It weighs nothing. Costs nothing. Can’t go wrong.”
— Elon Musk
Elon Musk wants the team to simplify the system to the minimum number of parts possible. And the way to do this is to let the engineering teams at Tesla focus purely on self-driving using just the cameras and computer vision, so that they do not have to rely on secondary LIDAR sensors for the self-driving to work.
Because every additional part creates its own dependencies. And if your product depends on some part so heavily that its unavailability can pause production, that is a huge long-term risk to undertake at the scale Tesla wants to manufacture cars at. The lead times for sourcing sensors at scale can go up to a year or more than a year and unavailability of a crucial part not only pauses production but also exposes you to wholesale transfer pricing risk, where a scarce supplier of the part can increase prices and eat into your profit margins while you cannot do anything about it.
Even in SpaceX, the metric the engineering team at the company uses to determine the reliability of its electronics is Mean-Time-Between-Failure (MTBF).
The part with the lowest MTBF in the system determines the MTBF of the whole system. It's basically a rephrasing of, "A chain is as strong as its weakest link."
Hence, SpaceX prioritizes specialized proprietary parts over commercial parts (as it is difficult to estimate their MTBF), and it designs for fewer parts than more parts. The company has chosen to keep a lot of parts between its engines similar so that they can be reused for other engines, instead of making 6 totally different engines with parts that aren't interchangeable.
SpaceX also tests its engines a lot, to ensure that they maintain a high “Mean-Time-Between-Failure”. Once the engine components meet their MTBF expectations, it is cheaper to build thousands of them versus just 20.
If you think about it, this also the very reasoning on which reusable rockets were invented in the first place!
Reusable rockets just scale very well. You make a rocket once and you can use the same rocket many times. In fact, company officials have previously said that reusing a first-stage at least ten times significantly reduces the cost of spaceflight. A Falcon 9 booster can be re-flown up to 100 times with refurbishment and maintenance in between flights.
Fewer parts allow you to obtain higher levels of optimization per part. And it's better to be dependent on the availability of just 40 parts versus 400.
Google's Site Reliability Engine (SRE) book has an interesting definition of "toil" in the context of processes and operations:
“The kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.”
Process optimization at scale is about mitigating toil.
And mitigating toil is about removing repetitive aspects of your work so that time and effort complexity of processes stays constant even with increased scale.
It's like building an async online course or writing a bestseller.
Once you build it, you can sell one hundred to one hundred thousand copies of the same software, recording, or book with zero effort.
1:1 coaching and service businesses are O(n), while product businesses like SaaS are O(1). You build the latter once, and sell them forever.
How can you use this understanding of scaling processes and the philosophy of using fewer parts in your own daily work? Do let me know.
In some ways, an MBA degree is also perceived by many as a O(1) process. You have to invest once to reap the benefits of the credential and the value it adds to your profile throughout your professional career. It's plain systems thinking at work.
But if this initial upfront investment of time and money is holding you back, do consider Stoa.
What you really want with an MBA is credibility and a change in your career path.
With Stoa, you can apply for the Stoa Charter – India's first professional Charter, specifically for business talent. Being a Charter-holder, you get all the benefits of an MBA without the time and cost involved in pursuing a traditional MBA.
Some of the roles we have seen Stoans transition to are Founders’ Office, Chief of Staff, Category Manager, Growth Manager, Product Manager, Customer Success Manager, Customer Service Manager, and Product Marketing Manager, amongst others, at India's top startups.
It's truly the place for anyone who wants to create the most impact in their career in the least amount of time. And if the Stoa Daily is any proof, you can be sure whatever you learn in the program, you will be able to apply at your workplace to do better. 10x better.
If you're intrigued, I'm sure you have more questions. For that, I encourage you to schedule an InfoSession to find out how you can enroll in the Stoa Program and apply for the Charter examination.
Our Admissions Lead will help you with all your queries regarding the Program, Charter, and the next steps. I look forward to having you as a part of the Stoa Community.