Why Is Reaching Scale So Hard?
Reaching scale for a technology company is a right of passage and can be a really exciting journey to be a part of. But why is it so hard? And why, on closer inspection, do so many companies fail to truly reach it, even well after their ‘startup years’. The reality is often simpler than one may think and normally has much less to do with the actual technology than many believe.
Disclaimer: For those architecture fans out there, this article doesn’t address the unique challenges of scaling the technology itself. We’ll focus instead on the non-technical drivers of scale in a technical company.
What Does It Mean To Scale? (Really…)
A commonly repeated challenge in reaching scale is simply defining what it even means. If you asked ten people what they thought it meant for their company to be ‘at scale’ you would likely get ten different answers. In many of these definitions scale is falsely measured in terms of its base elements, size and throughput, rather than its output. It is an understandable misconception, but as we will explore it can prove disastrous to the end result.
So why is it wrong to view scale through the lens of throughput and size? It only seems logical that to “scale” would be to increase either and hopefully both. In simple terms these are reasonable, but companies fall into the trap of myopically focusing on just these elements alone and completely miss what it means to really achieve scale in their operations. Let’s explore each to look at why.
Throughput:
It only stands to reason that if you increase your throughput (the amount of work you produce) that you are “scaling”. But let’s consider throughput holistically in the context of our entire business with an analogy. If we represent our business as a balloon, where the size of the balloon represents the size of our company / team / etc. Now we will represent the team’s throughput as the amount of air we put in the balloon. As we continue to increase the team’s throughput (air in the balloon) what happens? As we put more and more air in the balloon the rubber stretches and accommodates. Teams do tend to do the same. They adapt and stretch to meet the increasing demands of the business, which to a point, can work very well.
But logically what happens when we reach the limit of the balloon itself? We all know what happens if we keep blowing air into the balloon. Again, teams respond in the very same manner. If we continue to ratchet up throughput without addressing the size of the team, they continue to stretch until they break. We have all seen this and many of us have worked for companies like this. Attempting to address throughput in isolation is a guaranteed recipe for burnout and high turnover. An all too common mistake.
Size:
Just like throughput, another reasonable assumption is to say that we have increased our size (resources, employees, products) so therefore we have reached “scale”. Again let's revisit our analogy. The balloon still represents the size of our organization and we are able to increase its size to our desire. But again, if size is addressed in isolation, what happens? It is like filling the balloon with a small straw. Regardless of how big the balloon itself is, we will struggle mightily to fill it. With a lot of wasted capacity (under utilized size) left on the table. Just as before this is something we have all seen. Many large “corporate” organizations fall victim to this fate where size has been increased significantly without addressing the challenge of figuring out how to match it with increased output.
1 + 1 = 0
I love the old adage of 1+1=3 when talking about complementary and additive things being brought together. Unfortunately, when it comes to size and throughput, the reality is that 1+1=0. This follows instinct though, the primary way to increase throughput in any system is through efficiency. And we all know what corporate size naturally does to efficiency. Size actually becomes a hindrance and effectiveness drops off. Is this scale? What is interesting is that size tends to fight actively against throughput. So how do we bring these in harmony? What is the definition of scale that addresses both of these concerns in a cohesive way?
An Alternate Definition Of Scale
As it turns out, scale is better regarded as something more ‘meta’ than either size or throughput. It is something that exists outside of those two measures and seeks to optimize both in perfect balance. Another way to think about it would be to consider how velocity and acceleration interact. Acceleration is defined as the rate of change in velocity. To have constant acceleration would be to have a speed that is increasing at a known rate. Scaling works the same way. To properly scale, we would be increasing (and optimizing) both our throughput and our size at a known rate.
So ‘reaching scale’ could then be defined as establishing a repeatable system with which we can optimize both size and throughput in a controlled and measured way.
Although it seems convoluted, defining scale this way orients us to the right mindset of what scaling really is. Scaling is not about adding headcount or having destructive “hustle-engineering” cultures. Scaling is really about establishing systems and processes to grow (or shrink) in a controlled way. It’s not about reaching some prescribed static level of accomplishment, but rather about having the tools in place to determine how the organization will operate at any given time and to alter it at will. With this mindset, the steps required to reach scale become that much more clear.
Building Blocks Of Scale
With our new definition in mind, it is easier to think of building scale as more of a recipe than a formula. Each company, product, market, etc. will have its own unique set of challenges that alter the approach along the way. Only your business knows what is right for you. Therefore the recipe is more about defining the base ingredients than it is a rigid definition of structure. This provides the necessary flexibility for the organization to tailor each aspect as required for their individual scenario. These key ingredients, or building blocks, will be the backbone of what makes up our scale recipe. Let’s look at each one in turn.
Process Development
Process building is one of those curious things that everyone seems to agree is necessary, but many have a bad taste in their mouth about. We all have war stories of pointless, busy-work filled processes that sucked the life out of our jobs. Often these experiences are tied to larger companies to the degree that for a lot of people, process is synonymous with ‘being corporate’.
The simple truth is that in any business, especially a tech business, we need to understand how a team operates to know how and where to add resources as we grow the team. We also need to understand the bottlenecks and roadblocks to our work so that we can adapt and maximize throughput. Without these, regardless of how many people we throw at a team or how much productivity we try to wring out of them, we will never truly be in control.
At the end of the day, building an effective process within the business is the cornerstone of establishing organizational maturity. Unfortunately, it is not uncommon for people to associate processes with slow moving, inefficient teams. This regrettably, is probably one of the biggest misnomers out there. Although I do agree that many companies fall victim to bad processes, the lack of processes is often worse. The simple reality is that everything we do has a “process” to it regardless if we acknowledge it or not. The objective is not to minimize process but rather to identify and fully optimize the processes that make up the core functions of the business. With technology companies, this often starts with a solid SDLC.
All process work in a technology company should begin with the Software Development Life Cycle (SDLC). Chances are your company has one, or claims to have one, but there is a good chance it is not where it needs to be. That’s okay. Comparatively few do. The key ingredient here is to recognize the need and get started on yours.
SDLC
Unless every member of your team can readily point to your fully documented, end-to-end SDLC you are still at square one. In a tech company your SDLC is your backbone. It is your lifeblood. It is everything. Not only does it define, in discrete terms, how your company delivers value. It also serves as the blueprint on where you need to grow the team or optimize throughput. All process development activities should begin and end with the SDLC in a technology organization. What I mean by this is that as you refine your SDLC it should become the basis for other processes in the organization. Support systems, sales flows, marketing, etc should all be developed to operate in harmony with your SDLC. Now, this is not to say that engineering should run the organization, far from it. What I am saying is that processes should be aligned and compliment each other. If the core function of a tech business is delivering value through software products, it only makes sense that the central process with which others are based would be the SDLC.
The flow should look like this:
Value Strategy -> SDLC -> Support -> Sales -> Marketing -> etc.
Okay great, so where do we start? First, with a word of caution. The world of software engineering process, methodologies and best practices is an endless sea of science as well as opinions. Everyone has an approach and the debate is heated and continuous. My take is that they are like diets. Some are mainstream, some are fringe, but in the end the most important thing to do is find the one that works for you and your situation. Then evolve. Professionally I have spent most of my career in Agile methods, but began it in successful waterfall. It is not the aim of this article to anoint a winner.
Instead, I offer the following guidance to help in evaluating your SDLC and developing your own tailored approach.
1. Start with your business, not with your tech:
This one is hard for us tech folks but it is so important to a properly aligned SDLC. Understand how your business needs to run, then build a system to deliver on that. Do you need frequent, iterative releases? Or is slow and steady with lots of validation that your users want. Understand the cadence of the business and the needs of your customers to craft a process that aligns to those requirements.
2. Map out THE ENTIRE life cycle:
This is where most SDLCs fall short. Normally the situation is that the engineering team has worked on their flow, probably instituted tools like Git and Jira and have a notional concept of QA. And that’s it. What happens next is that a culture of mistrust grows with engineering because there is no clear definition of ‘done’. Engineers speak to their isolated part of the process and the rest of the team do not have clarity on the remaining steps. Don’t make this mistake. Your SDLC should map out each step from idea creation to putting it in a customers hands and supporting it. When your SDLC actually defines this, you will be amazed in how the business responds. It changes the game.
3. Focus on tailored, incremental steps in establishing new process:
A big reason most process development work fails is because of bad change management. Tech/Product teams are always heavily burdened and overworked teams. Coming in and layering on burdensome process and training is a recipe for failure and likely the reason Agile transformations can fail so spectacularly. The preferred approach is to focus on small changes to flow that immediately add value to the process. Figure out what is not working and causing friction today and attack that first. Then iteratively optimize with the teams feedback.
4. Always support the team in transition!
More important than anything else is to focus on the team over process itself. Change management is incredibly hard and adapting the way we work can be hard for many. Be supportive, understanding and focus on coaching over correction. Understand the critical aspects of your process going in and be willing to adapt and flex on the parts that are less important. You always have opportunities to improve the process as time goes on. You really only get one or two chances to have genuine buy-in from the team. Don’t blow it by being too pedantic about your approach!
At the end of the day your processes, especially your SDLC, defines the language of your business. To establish real scale, you have to be intentional and committed to developing them for your organization. As you build scale, effective process development is how you transition from a people driven (individual focus) to a system driven (enterprise focus) organization.
Accountability & Empowerment
As your company grows in size it is only natural for inefficiencies and silos within the business to emerge. As one would expect, this has a negative impact on overall throughput and ability to build scale. Sadly, this is yet another common sign of “being too corporate.” Thankfully, both the cause and the solution for this is incredibly simple and easy to address.
When we think of a large organization, we think of the classic pyramid where teams roll up to managers and groups of managers roll up to even more managers and so on. Although this structure is easy to criticize for being overly bureaucratic, anyone who has led a team of more than five people, realizes quickly the necessity of this type of structure to maintain sanity.
The two primary concerns of such a structure jump out immediately as size increases. First, if decision making is not properly managed, the time required to take action in the business grows significantly as the round trip time gets longer and longer. Second, as teams at the base get larger and larger we can see that silos across the business increase in turn. Thankfully, we have easy to deploy tools to address both concerns.
Accountability & Empowerment
The easiest and most effective way to combat the negative effects of size are to be aggressive in establishing accountability across the organization and pushing decision making as close to the action as possible. The only way to short circuit those long cycles of action is to cut it off at the start and empower the team to drive their own efforts. This is not a passive approach. You must build accountability systems, empower the team to fully own their work and hold them fully accountable to their outcomes. Which brings us to the second tool in our tool belt.
Process Accountability
Accountability only works if there are systems and processes in place to define expectations in a less centralized environment. It’s easy to have “no process” when only a few people are making decisions. When you start to decentralize decision making, it is imperative that systems exist to standardize and communicate those actions across the organization. These processes create visibility and alignment between teams and leadership. They also establish the new structure that will become the format for increasing size even further.
Just like above, the key here is that the approach is best executed when it is targeted and incremental. When you take the time to look critically at your organization, long decision making cycles will jump out quickly. The easiest approach to start with is to walk through your SDLC, from idea to deployment, and see what stands out. Chances are there are huge opportunities sitting right under your nose to empower more of the team and breakdown silos through strategic process work.
Organizational Alignment
This is likely the most obvious but most neglected aspect of scale in technology companies. It is encountered so often, that it has become a running joke between software and sales organizations in most tech companies. The simple fact is though, having true strategic alignment across your business is the most important and foundational element in building scale. Without it, no matter how effective your process or decision making is, as you grow, misaligned silos will form and pull your organization apart. The early signs of this will be discontent and friction that will crop up between teams. As cliche as it is, it will mostly likely first appear between the engineering team and the sales team as naturally competing agendas will collide regularly.
Regrettably, as easy as it is to define, creating alignment can be challenging for even well organized businesses. The challenge lies in the fact that it requires a high level of leadership maturity to execute properly as the business grows. In the early days, Founder vision is strong and teams are small. It is relatively easy to stay aligned as the team has a focused set of objectives with likely shorter timeframes. But how does that scale? How do we increase our objectives and their scope in a predictable and controlled manner? Thankfully for us this is an area of constant study and many systems and models exist to address this at different phases of a company's growth. The real trick is having the discipline to find a system that works for you and stick to it!
On a personal note, I can’t say enough about one approach that I feel is both simple to implement at any size and sensible to follow. That system is called OKRs or Objectives and Key Results. It is a really effective approach to start with and carries as you build scale. If leadership can stay committed, this system will do wonders up and down the organization for both alignment and visibility.
A great introduction here: https://lattice.com/library/okr-101
Why Do Companies Fail To Reach Scale?
So if the path to scale is clear why do so many companies (regardless of size) appear to never reach it? In many cases it is the simple fact that they are not thinking of scale the right way and fall victim to the pitfalls of focusing on size or throughput exclusively. We’ve all seen or worked for companies that either are large and terribly inefficient or that are small and the teams are overworked and burnt out. But how did they get there? And how could they avoid that fate? The best way to answer those questions is to review the building blocks and see where things can go wrong.
Process Development
The biggest mistake most companies make in processes development is not being in tune with or simply not understanding their business at its core. Companies will attempt to “fix” things by hiring expensive consultants who will come in and force a prescribed methodology that may, or may not, be a match for the business. Change management is often shortchanged and teams feel jerked around and burdened by the whole exercise. What normally happens next is that the ‘transformation’ fails and operations fall back to the previous, unoptimized natural state. Nothing is gained and time and money have been wasted.
The key to combating this is taking the necessary time to understand and map out your business and technology in detail. Understand it thoroughly. Then start taking simple steps to define processes aligned to those realities and build small and incrementally.
Accountability & Empowerment
The major issue here is often trust. You must build an organization of trust if you ever want to establish real accountability with your team. Employees will not take up the responsibility of being accountable if they are not empowered to chart their own course. Without that real empowerment, employees will be slow to action and silos will form. Productivity will slow to a crawl as the organization increases in size.
Again, the easiest thing to do is to start small. CFOs have figured this out years ago and that is why most organizations have a system of budget approvals in place. Most managers in large companies are able to approve expenses up to a certain dollar amount. Their bosses a higher one and their bosses even higher and so on. What this does is create a balanced system where decision making can be localized and risk controlled without having the CFO approve every dollar spent. The same works for engineering and product. Create systems where decision making escalates proportional to the impact. The CTO shouldn’t need to weigh in on every line of code, feature or architectural decision. Empower employees to take action in real time and establish a system of balance to ensure that critical decisions get in front of the right people.
Organizational Alignment
If I had to pick the one thing that almost all companies I’ve encountered struggle with it is this. Having alignment across the organization is one of the simplest concepts to understand and yet is often the hardest to implement. This is because at the end of the day alignment has to come from the top and it takes an incredible amount of discipline to execute. As more resources are available to leaders (or even when they are not) there is so much temptation to constantly pivot and chase opportunities. This causes disruption and misalignment across the teams as the company grows. It takes a high level of organizational maturity and resolve for senior leaders to set the vision and stay the course.
Keeping the organization in sync maximizes the effectiveness of process and accountability by removing the wasteful strain and stress of unnecessary efforts. Even if you are not at the top of the company, you can employ these techniques with your own team. Ensure everyone across your group understands the objectives and is marching to the same plan. You’ll be amazed with the impact.
Final Thoughts
Achieving true scale is the holy grail of any tech company and incredibly impressive to see in action. But it doesn’t happen by accident. The companies that we hold in high regard for how they operate did not get there by chance. Systematic, purposeful action from everyone is required to reach the end goal.
If achieving scale is really just about growing with predictability and control, then it really is never too early to start. Look at your organization, find the critical pinch points in workflow and decision making and start building solid processes. Make change management a central part of the approach and always put your people first in the process. Ultimately they will be the ones that will make it happen.
The one great thing about building toward scale is that it becomes ingrained in your culture and will gain momentum as it goes. Small steps will add up to big improvements quickly!
