How to prevent an 'operational catastrophe'
">
Developing a fast-scaling business with a supply side in the early stages requires growing with high dynamics and little resources. Operational mistakes while scaling might have an exorbitant price.
We faced it when we decided to break into edtech and launch an education app that aims to provide experts the ability to answer millions of students' requests in an online chat, almost instantly.
We started with a team of 20 people, which was enough to cover the demand in the early stages. To make the business profitable, the real race started: The marketing team had to scale the number of users, while operations had to follow their pace and grow the supply side.
We scaled demand without considering team resources.
We got up to speed quickly: 120+ experts were solving 3,000+ math tasks daily. We staked on the high pace to survive on the market, so the operations team was scaling the supply side by leaps and bounds.
We concentrated on scaling and didn't have time to think if the resources of our team were enough to keep going with such speed.
Our marketing scaled rapidly, which was a good thing. Following the need to cover the increased demand from the users' side in time, my team scaled the supply side 3x in one and a half months and 2x again two months later. Finally, we got 300+ math experts who were able to solve 10,000+ tasks daily. I was proud, thrilled, and freaking out at the same time.
I realized that in the last five months, our supply had worked on demand covering, time of service delivery, and quality of solutions. We concentrated on scaling and didn't have time to think if the resources of our team were enough to keep going with such speed.
As a leader, I had to stop and look at the bigger picture.
The five-step plan I crafted to prevent the approaching "catastrophe"
1. Noted all the key processes "as they were"
This is a first step that shouldn't be missed.
It is a common problem when there are no process notations. The work pace might be high, and people must implement tasks and solve issues immediately rather than describe the current process.
I described all the processes for that moment just as they were. It helped me understand the real point where we were at that moment. I figured out which things went out of control and might result in a big issue soon.
Afterward, all the processes were updated according to the following framework:
2. Identified all the bottlenecks
I noted two types of bottlenecks:
First: Subprocesses, which were spontaneously added to key processes while scaling.
I discovered that due to the number of updates, my team members had to do too many additional actions, which were not noted before. Thus, I reviewed everything we did and simplified the general process. We focused only on "must-do" things, which influenced the result the most and put other "nice-to-do" tasks on hold.
Second: Managers, who didn't delegate tasks in time and stuck with an enormous number of tasks.
Unfortunately, I was one of them. I was doing too many things at the same time, and they never came to an end. In my case, it happened primarily because of hiring mistakes, which appeared to be the most expensive ones.