The scale of a problem dictates the solution.
I’ve built a small script that automates the creation of multiple time-lapses from webcam snapshots. It works well and I don’t have any plans on fundamentally changing the code. At one point in time, I considered turning the script into a web service that would allow an unlimited number of people to have time-lapses generated from their own webcams. While thinking through what it would take to accomplish this I realized that my script (and the server it was running on) simply could not create more than a few dozen time-lapses an hour without failing. Image storage, timing, processing power, multiple instances, and bandwidth were just a few of the issues that arose when I looked at my problem on a larger scale. The solution that I identified was unfortunately out of my area of expertise, and while still captivated by the idea of a web service to create time-lapses for every cubical-sitting, cat-loving webcam owner, I’ve embraced the fact that even though I’ve solved the problem on a small scale, I can’t (within reason) solve the problem on a large scale.
The scale of the solution presents a problem of it’s own.
Take the problem of cookies. Say your going to start a business baking cookies. The task of supplying your local coffee shop with fresh-baked cookies is infinitely simpler than the task of supplying a nation-wide grocery chain with fresh-baked cookies. While the process may still be the same—identify a recipe, procure ingredients, mix, bake, deliver, and collect—the solution will be directly shaped by the scale of the problem. Are there 100 grocery stores in the chain or 10,000? Are those stores distributed across six states or 48? These questions must be answered before the question of flavor or quality can even be considered. Simply put, the problem of baking four dozen cookies is an entirely different problem than baking four thousand dozen cookies, and the person who can identify and solve problems of scalability has a much more valuable skill set than the most talented baker of cookies.
Scale is different than scalability.
During the early 2000’s, I spent several years working with a small advertising agency that frequently fluctuated in size between 40 and 50 employees. The reason for this fluctuation was that Bill, the creative director and part owner, had identified his optimum scale of operation. He knew that once the organization grew beyond about 45 employees he would have to drastically change the way he led, managed, and operated his organization. So instead of focusing on scalability, he focused on maintaining a specific scale that allowed him to be very effective.
Identify a scale or a series of scales
Most organizations don’t have a hard cap on the number of employees they hire, instead they keep their labor costs at a certain percentage of their revenue. This practice is great if you don’t plan on growing. If you do plan on growing, at what point does your scale require a fundamentally different solution to your basic business problem? At what point will your cookie business require an IT specialist, ad buyer or distribution manager? In many cases, as an organization scales there are clear phases, caps or boundaries that, once crossed, require that you reassess your business strategy because, in all reality, you’re no longer in the same business. So why not think through the next 3-5 phases ahead of time and include those in your business plan? Or at least be like Bill and put a hard cap on growth so that you can instead focus on effectiveness and optimization.
The solution you’ve found to your problem is specific to the scale of the problem. How will your solution perform when your problem changes? Will you simply try harder? Will you simply double your resources? Or will you acknowledge that you’re dealing with a fundamentally different problem and create a fundamentally different solution.