The second you find product-market fit, the conversation immediately shifts to scalability. It spawns conversations of unit economics, gross margins, automations, team structures, and repeatable processes.
In the early stages of a company, it’s easy to confuse scalability with growth. Of course, growth is the objective, but it’s inextricably tethered to scalability. Growth is what we want; scalability is how we achieve it in a sustainable way.
The Complexity of Scale
To scale successfully, we need sub-linear growth across our business dimensions.
As a simple example, imagine today it takes 5 customer support representatives to manage 1,000 customers. Linear scale would mean that when we reach 2,000 customers, 10 support representatives are required.
Our goal is to decouple the ratio — to get more from less.
On paper, the objective is straightforward. Optimize inputs (x1, x2, x3) to maximize the output (y). In reality, each input is dynamic and connected to dozens of other hidden inputs. On the other side of the equation, the output (y) is barely stable. It’s influenced by a range of external factors: competition, regulations, market dynamics, unit economics, etc. Some of these we can control and some we can’t; most, we can only influence to some degree.
Then, enter people: personalities, strengths, weaknesses, egos, motivations, etc. Any math we could rely on is quickly suffocated by the unpredictability of human behavior. Good and bad.
Scale is complex and difficult.
How then, do we approach such a chaotic system? By looking closely at what permeates every component of the system: knowledge.
Choosing Knowledge
Why should our journey towards scalability start with knowledge management? First, knowledge is unique in that it serves as the “connective tissue” between every component of the organization; it’s ubiquitous. Second, knowledge is emergent, fairly unstable, and constantly changing.
This is not to say that there aren’t dozens of other important aspects of scale. Rather, it’s to emphasize how knowledge can serve as a common, grounded mechanism for facilitating all other aspects of scale.
Let’s think about these dependencies in context:
We have a system we want to scale; in our case, an organization.
This system is made up of many components (departments, functions, roles, processes, etc) — each with a purpose.
Its purpose is achieved by having the knowledge necessary to meet its objectives.
The knowledge it relies on is de facto missing, aimless, stale, wrong, or otherwise difficult to control.
We start with knowledge because of its sheer influence over the system and its tendency to be unreliable when left unchecked. Our challenge becomes:
How do we give knowledge both structure and purpose, such that it can reliably serve as the connective tissue across our system, allowing us to meet our objectives?
Giving Knowledge Purpose & Structure
If knowledge is emergent, our first goal should be to direct it towards a stable structure; a place for it to reliably live, evolve, and thrive. The diagram in Figure 1 demonstrates how we might think about knowledge progressing through a set of defined structures, each with a purpose.
As we walk through each of these structures, consider their purpose from two contexts:
Micro: A single piece of knowledge entering the organization and how it progresses through the system.
Macro: The organization’s own holistic journey towards knowledge maturity and its ability to actually implement and act on these structures.
1. Fragmentation
Despite the operational maturity of an organization, when knowledge is conceived, it’s typically in a state of fragmentation.
The immediate goal is to capture that knowledge as documentation. Otherwise, we risk it being tied indefinitely to the individual(s) from which it originated, who inevitably forget things, change roles, or leave the organization.
But, this is easier said than done. In fact, it’s perhaps the most difficult step. When we begin to ask questions about incoming knowledge, the magnitude of the problem becomes clear:
Is the knowledge relevant?
Do we have data to back up its claims?
Can we replicate it?
Did it originate from a subject-matter expert?
Does it relate to an existing process or procedure?
Does it impact upstream or downstream processes?
Does it conflict with existing knowledge?
Will it remain true over time or is it tethered to mutable variables?
Rather than attempting to plan every contingency, our knowledge framework should focus on training people and enabling systems to capture, triage, and evaluate knowledge as it emerges.
In the early stages of an organization, this process can be extraordinarily simple. The process of triaging and evaluating knowledge can be distilled down to a simple question of prioritization:
P0: What cannot go wrong?
P1: What shouldn’t go wrong, but won’t kill us in the short term?
P2: What can we generally ignore for now?
Insist on P0; aim for P1, and backlog P2.
In later stages and as standardization is introduced (see phase 3), the process of capturing, triaging, and evaluating emergent knowledge can become more nuanced to match the appropriate level of rigor of the organization.
2. Documentation
Right around ~20 employees, most organizations start to realize the necessity of documentation. This is largely driven by the need to repeat processes consistently, independent of the person or system actually completing the work; a key tenet of scalability.
In our previous step, we captured, triaged, and evaluated emergent knowledge. Now, our job is to ensure the knowledge is documented with a structural foundation. This is key for three reasons:
Most importantly, it makes the knowledge useful and that’s our primary objective.
Secondly, it creates a stable dependency loop for future emergent knowledge. If knowledge is well organized, we can reliably ask questions like: Does this conflict with existing knowledge? Does it affect upstream or downstream processes?
Finally, it prepares knowledge for standardization, which is a non-negotiable prerequisite for productization and automation.
What does this look like in practice? It can be as simple as:
A. Establish a System of Record
Find a tool and make it your home for Standard Operating Procedures (SOP). The system should be flexible, support access controls, maintain a history or audit trail, and be easily accessible by team members.
B. Enforce Basic Structures
Establish two dimensions of categorization: organizational structure and knowledge categorization. For example:
Knowledge will be categorized based on our organizational structure which includes Departments → Functions → Processes.
Knowledge itself will be categorized as either an Operating Procedure, Guidance, or Governance Policy.
These types of basic structures are simple, but extraordinarily powerful. Now, when capturing emergent knowledge, it’s final “home” is clear. Just as importantly, when knowledge needs to be retrieved, humans and systems have an index to reference.
For example:
How does the Customer Success department think about customer Segmentation?
Customer Success → Guidance → Customer Segmentation
How does the Security function enforce multi-factor authentication?
Security → Governance Policies → Authentication
3. Standardization
So far, we’re capturing and documenting knowledge into structures that can be easily navigated. If we stopped here, we’d be in pretty good shape. But, as the organization scales, we risk the ability to maintain these structures long-term. Why? The sheer number of inputs, leadership preferences, competing priorities, and knowledge entropy.
The third phase of standardization is about unifying knowledge across all components of the business to create reliability and consistency.
It’s important not to overthink this.
Our goal should simply be that any one person or system, despite their role, can navigate our knowledge with a high degree of certainty and understanding.
We can liken this to driving in the United States. Whatever state you’re in, there are consistent standards and rules for operating a vehicle. Speed limits will vary, sometimes you can turn right on red, etc. But, for the most part, you can make it from California to Florida without issue.
How an organization chooses to standardize their knowledge will vary greatly, but considering these 5 components is a great place to start:
Structure: Have we implemented standard structures for organizing knowledge?
Semantics: Have we established a unified vocabulary and glossary for core terminology?
Governance: Does each piece of knowledge establish levels of ownership, responsibility, accountability, etc? Have we established the ways in which cross-functional teams and processes interface?
Lifecycle: Have we established methods for continuous maintenance and scheduled audits of knowledge?
Interoperability: How is our knowledge connected to other tools and systems?
4. Productization
Productization is the process of observing our knowledge and identifying what processes are good candidates for internal tooling. Largely, this is about enabling strong relationships between function stakeholders and product managers. Together, these teams can routinely propose process candidates that are stable and ready for productization.
See our article on Flywheel Tooling — Leveraging AI-Driven Development to Fix the “Dusty Corners” of your Organization
Why is this important? It ensures that as knowledge and processes mature, the associated work (output) is filtered back to our objective of scalability. The process itself is likely still assigned to a particular role, but the operational steps have been greatly simplified. Our goal wasn’t to build a library of knowledge, but rather, to transform that knowledge into scalable operational machinery.
There’s a major risk to productization that is often overlooked. When knowledge is transferred from written form to logic/code, it risks being obfuscated for the larger organization. Suddenly, what was known by all is relegated to a small group of engineers. To avoid this trap, organizations must establish clear parity between knowledge and product documentation, ensuring the what is productized but the how remains clear.
5. Automation
The transition from productization to automation is subtle. It’s the process of further reducing the work associated with an already productized process. Let’s examine this in context.
Early on, a team member may have been responsible for collecting data, creating a report, and adjusting operational variables to reflect their findings.
When this process was productized, we eliminated the first two steps entirely. The data and final report were made available to the team member in real time, eliminating the majority of their manual work. Still, they were responsible for interpreting and adjusting the operational variables.
By automating this final step, we can further reduce the manual work. For example, we may implement machine learning to automatically adjust the operational variables. Or, at the very least, present the team member with the proposed adjustments and rationale behind each.
In Summary
Scaling an organization is extraordinarily difficult. There are infinite, dynamic, interacting inputs contributing to and detracting from our goal of scalability. The single thread between all of these inputs is knowledge. Giving knowledge purpose and structure is an excellent way to stabilize these inputs and guide them towards operational scalability.
If you do nothing else, capture and document knowledge early and often. How you use it and what it looks like at scale will take shape over time.
About the Author
Erik Smith is an entrepreneur, investor, and builder. He serves as the Chief Technology Officer at Rx Redefined, a venture-backed Series B healthcare technology company. His work centers on supporting leaders and teams across Product, Engineering, Data, AI, Business Intelligence, Security & Compliance, and IT/Infrastructure functions. He has a passion for helping to bridge the “curiosity gap” between technology, business, and operations. Erik lives in Northern California with his wife and two bunnies, Poppy and Bubbles.