Experiencing rapid growth is different from having scalability. Growth is an aspiration or end result while scalability is a capability that may or may not get exercised. Growth can come in spurts and is most commonly thought of in terms of sales and marketing attributes. Scalability is architected in and is commonly reflected in the “back office” or the technical architecture of the product solution. In other words, not the sexy stuff but rather the “plumbing”.
It’s true that having genuine scalability can dramatically affect how your company is able to handle sustained periods of growth. In fact, this is probably the right way to think about scalability – what is needed so that we can fully exploit sustained periods of growth with minimal risk and disruption to our company? Going into an “all hands on deck” mode is one way of getting through periods of excessive growth but it comes at a cost of disrupting all sorts of things that are surely strategic and you can’t live in this mode for very long.
Here are some examples to help convert the concept into specific actions:
- Recruiting, on-boarding and training – Image the number of employees in your company needs to dramatically increase in a short period of time. During the startup phase this might mean going from 5 employees to 25 in six months. Later it might mean going from 50 employees to 200 in two years. In either case, do you have the strategy, tactics and talent to recruit, on-board and train these new employees?
- Transaction processing, customer on-boarding and support – Imagine an exponential increase in the number of new customers in a short period of time. Do you have the strategy, tactics and talent to keep your books in order while offering the new customers quick time-to-value and a positive overall experience?
These are two examples of architecting scalability into your company. And realize that it doesn’t mean that you should hire back office staff in excess of your needs. Instead, focus on implementing systems and processes that are able to scale if you suddenly turn the knobs up to 11. Also pay close attention to the leadership talent you bring into these functional areas. Do they know how to architect in scalable systems and processes? Have they worked for a company that experienced rapid growth and/or one that was at least a couple of years down the road from where you are today? I find that most of these back-office functions sit as the most strategic cogs in the scalability wheel but since they aren’t sexy or outwardly visible like the product or the website is, they take a far back seat to everything else when it comes to funding and attention.
Trying to achieve true scalability after having already hit an exponential growth curve is extremely painful. So spend a few brain cycles on this before it happens. But also be careful not to spend excessive time and money on scalability during your initial validation or MVP development phase. Instead, start to consider the things described in this article once most elements of your business plan have been validated and then progressively through your early growth phase.
To help think about the operational implications of being scalable, consider asking yourself questions like the following:
- If our business tripled next quarter, where would we break? If we could predict right now that this is going to happen what would we need to do to prepare for it (tools, processes, people, etc)?
- If we decided to dramatically expand our geographic footprint, where would we break and what would we need to do to prepare for it?