The biggest mistake a business can make is trying to scale the organization too soon. At the same time, the final nail in the coffin for most small businesses is not ever scaling the business. Scaling the business is an exciting time of change. In the build stage the first wheel in being designed and created. In the scaling stage the business is duplicating the same wheel over and over again. The problems of scale are much different than the problems of build. The modern network architect needs to consider scale in every aspect and during every business stage in order to allow the business to grow.
“The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.” Bill Gates
The rule in scaling for business follows pretty closely the rules of automation. During the build phase a business model is created. During the scaling phase that business model is duplicated over and over and over again. The efficiencies of that business model will be magnified as will the inefficiencies of that model. Each business system (accounting, marketing, account management, production etc) will be magnified and inefficiencies will show. No department will feel the brunt of these business inefficiencies more than the technology group.
As a Seattle IT Consultant I walk into IT groups who are focused on solving a problem with an inefficient solution. In the build stage these types of inefficiency are easier to get away with. In the scaling stage, these inefficiencies can bring business growth into a screeching halt. One simple technical solution can suddenly become the weakest link in a growing the business. If that link is not easily scalable, the growth of the business slows or even stops.
An example can be as simple as a spread sheet. In the build stage a scheduling person uses a spread sheet to schedule 5 sales people. As the business grows the business now there are 100 sales people and 6 schedulers. Nobody realized how critical that spreadsheet for tracking sales people was until multiple schedules tried to use the same spreadsheet. Spreadsheets of course, are not designed to have multiple users entering data on the same spreadsheet. One scheduler forgets to save their entries on the master spread sheet, then overwrites the changes of the other five.
The question was probably asked by management, “Can we have more than one person using the same spread sheet?” The answer of course is yes. Technically you can have more than one person using the same spread sheet. If that’s as far as the conversation goes, a ticking time bomb is waiting to explode.
Scaling businesses run into this problem. Nobody thought about the effect of the problem after the business began to scale. The build stage is the stage where these types of problems are anticipated and planned for. To the question,
“Can we do <insert question>?”
The experienced architected will say,
“Well it depends. Why would you want to do that?”
The experienced architect has been asked these type of “Can we do this…” types of questions before. The wrong answer will not scale with the business. The spreadsheet example has a simple answer. There are technical dead ends that will require re-engineering the entire process. In a world where technology changes quickly, these technology dead ends may be impossible to recover from. Some of the technical mistakes that derail the scaling process include:
- Ignoring the lifecycle of the hardware within the organization
- Disaster recovery planning
- System Redundancy planning
- End to End system flow failures
- Manual processes mixed with automated processes
- Tribal knowledge requirements for employees
- Inconsistent hardware and software platforms
- Plans that circumvent software license fees
- Incompatible data systems
- Home grown solutions
During the build process short cuts taken in any of these areas and many more, come back to haunt the business trying to scale. There is a rule that says for every dollar spent in planning for contingency, ten dollars is save in failure costs and $100 dollars is saved in repair costs. I don’t think this rule takes into account the hourly lost in workplace productivity (statistically around $7400 / hour that the system is down)
I am often accused as an IT consultant by others that my thinking in too enterprise. Meaning I think about small business problems as if I was working for a Fortune 500 company. Having worked at the Fortune 500 level, but preferring the small and medium size businesses, I have to disagree. I understand that a small business is not a large business. I also understand that all small businesses that become larger businesses will need to go through this scaling stage. By anticipating this in earlier stages of the business we actually save our clients in headaches and lost resources.