For over a decade, Thoughtworks has been working with startups to scale them from early stages through hypergrowth, tricky acquisitions and on to successful IPOs. Through this, we’ve learned about a series of typical challenges and how to overcome them. And while this isn’t the complete picture, these strategies will get you a long way there. There were two key research points. First, the scaling strategy should intentionally change over the scaling journey, and second, there are common bottlenecks all scaleups will encounter.
What is a scaleup?
Growth in startups can be measured by a number of ways such as user growth, revenue, customer acquisition cost, customer retention, the measures a company picks will depend on their business domain and model. This makes it difficult to identify a scaleup. The best common indicator for scaling up is headcount growth.
The OCED uses this definition for high-growth enterprises: “All enterprises with average annualized growth greater than 20% per annum, over a three-year period, and with ten or more employees at the beginning of the observation period. Growth is thus measured by the number of employees and by turnover.”
We aren’t strict about this definition, rather that the company is experiencing a transitional period to a new way of operating due its increased size.
Technology scaling strategy changes dramatically
Starting a company and scaling it is a bumpy path — you'll need to apply dramatically different strategies throughout the journey. What got you to a critical milestone won’t necessarily get you to the next one. We’ve created four scaleup phases to illustrate this.
At the outset, the business goal is to find product-market fit, experimenting with different approaches and products.
The next phase is doubling down on the initial indicators and traction from early adopters to capitalize on successes, while also focusing on how to pitch the company to investors.
As the startup moves into the high growth period (ideally hypergrowth), the business concern turns into keeping up with the many demands from users, employees and investors. The high growth phase is the critical period that will make or break the startup. Finally, once the platform is scaled and the organization is of sufficient size, the scaling strategy shifts to optimizing — putting processes and structures in place to scale further with less stress and effort.
The types of capabilities and initiatives a scaleup company focuses on change through the phases, even down to the way developers code and how product managers make small decisions. It’s important to be intentional about these strategy changes or risk introducing growth bottlenecks. These are example initiatives a scaleup might prioritize.
There are many different aspects to a scaling strategy that have to come together.
For example take talent management, startups begin with a small trusted team, hired from friends and personal networks. As you grow, you have to look wider to acquire different skills, more diverse backgrounds and alternative ways of thinking. The startup needs a hiring team, a modern recruitment toolset and to seed a hiring pipeline, all of which takes time. If not done soon enough, talent will constrain the company. But, just adding people isn’t the solution — you have to make the best use of their skills and experience. To do this, welcome them warmly, give them a clear goal and provide them with an effective working environment so they can thrive. Without this, we see employees becoming frustrated and leaving quickly.
Experimentation at the beginning is easy. Being small and nimble, it's easy to shift the organization with product pivots. But companies tend to lose this ability with an expanded scale. So to continue delivery at speed, the product teams should keep the experimental mindset. The best way to do this is to create a culture where employees are enabled to try different ideas quickly— and sometimes, fail. Teams need to be empowered, aligned to business priorities and dependencies minimized. The wrong organizational structure can introduce friction. A common problem is too many managerial layers and no clear ownership.
Technology strategy also changes. In the beginning, you take a lot of shortcuts and take on technical debt — this is healthy. Only once a product-market fit is proven should teams rebuild services to be higher quality and scalable. Further growth introduces many team changes, so architectures and code should be easy to work on for technologists who didn’t build them. With added traffic and infrastructure, costs can easily creep up and become a bottleneck — they can quickly run up in ways you wouldn’t expect.
Scaling strategy influences funding
While scaling their product delivery and organization, scaleups also construct a story for investors. In both established organizational M&A and scale-up funding, the value of a company can be measured in multiple ways. An easy assumption to make is that willingness to invest in a company will be based upon the market potential of a product. While it's true that a superior product provides an edge in the market, it is only one factor in market success. It's also true that superior products don't always dominate their respective markets.
Additionally, when looking at acquisition targets for larger companies, what's often kept post-transaction are high performing teams over products, which are often shuttered. Does that mean they weren't valuable? No, but in that scenario, a successful team that has proven their ability to scale products is more valuable.
In applying decision-making rationale to investments in a company, investors (and acquirers) will be paying close attention to the foundational setup of the team, their potential to scale their team and business model, and whether their strategy has adequate potential to scale beyond their current (often founder-based or led) model. Being able to show this and satisfy the criteria of experienced investors should be a significant factor in a scaling strategy.
There are common scaling bottlenecks
We've identified 12 common scaling bottlenecks collected from the types of problems Thoughtworks teams are solving, and the strategies successful scaleup leaders have employed.
Through experience at working for companies that are scaling up, we have identified these common bottlenecks:
Accumulation of tech debt; experiments and shortcuts are core components
Cost of serving traffic is too high
Current organization structure doesn’t support current scale
Cannot find the next product evolution to delight existing and new customers
- Complicated internal team and partner dependencies
Legacy technology from integration partners or acquired companies
Overcomplicated distributed architecture (microservices)
Built without resilience and observability in mind
Developer productivity has dropped as organization grows
Inability to find talent; Hard to attract and no efficient process to onboard and upskill new team members
Building out extensive rules based system, instead of leveraging ML/AI
It's hard to spot impending danger when you're in the midst of hypergrowth. So we've started creating a series of tangible signs to look out for that serve as early indicators that a strategy change is needed. The research is published in a series on bottlenecks on martinfowler.com.
Examples of signs taken from the articles:
Accumulation of Technical Debt:
Long development lead time
Low engineering satisfaction
Ability to onboard new developers
Degradation in non-functional measures
Constraints by Talent Bottleneck:
Frustrations from employees
Stretching to hit deadlines, quality is slipping
Key dependency on people
Underperforming recruiting
New employees’ expectations aren't being met
Underestimating growth
Premature Scaling
A common cause of failure at startup is trying to scale too early. The startup genome report on premature scaling listed common reasons such as “Spending too much on customer acquisition before product/ market fit and a repeatable scalable business model”, “Hiring too many people too early” and “Having more than 1 level of hierarchy”. This aligns with our findings. We often find teams that are building expensive complex architectures and platforms, when the product and the business model hasn’t been proven enough. They end up making it more difficult for the company to pivot easily. Another problem we see is a extensive hiring, before the company has addressed the opportunities to increase productivity by making product delivery process more effective.
Foundational Scaling Capabilities
After describing the types of problems (which should not be new to any scaleup leader), what is the scaling solution? Of course, we don’t have a magic wand, but there is a set of capabilities common for successful scaleups, that we believe scaling companies should master. We’ve split the capabilities into two areas: scaling product delivery and preparing your organization for scale.
Scaling Product Delivery
The core principle is to maximize product delivery effectiveness so that we can incrementally deliver value to customers.
Prudent technical debt
To have fast delivery, high-growth organizations take on technical debt in places where they’re experimenting. However, once a product’s value is proven, paying down the technical debt and rebuilding the product in a scalable way is vital. Our teams often help make those decisions, and pay down accrued technical debt. Ideally, tech debt should be measured and quantified to prevent future problems. To establish a quality bar, we can check for problems regularly with automation.
The KPIs we look at are the effect of the debt on non-functional requirements such as operating cost, performance and availability, along with other measures such as code quality and engineer satisfaction.
Experimentation Culture
The lean startup approach, the ability to try multiple ideas and pivot quickly, often gets lost with scale and its added bureaucracy. We believe that product development at all stages should use an experimental approach, where instead of lengthy specifications of feature requirements, we focus on ideas that are a hypothesis of value. The product delivery goal is to cheaply demonstrate that the idea is useful to customers before expanding the feature set and scalability.
This is accomplished with a combination of mindset shift and tooling improvements. Mindset shift involves writing requirements as hypotheses, changing how you track progress, frequent user feedback and incremental development. Tooling improvements cover behavioral and business analytics, feature toggles and fast, reliable continuous delivery infrastructure.
To support that is a series of process changes. To be nimble and experimental, we don’t recommend a rigid set of practice and rituals but rather a set of principals and a good starting point that can be continuously improved as you refine for your context.
The outcome of this approach should be to increase the amount of experiments, shorten the time it takes to validate an idea and improve the quality of the idea e.g., revenue increase, and customer satisfaction.
Continuous Delivery Infrastructure
We believe (and the industry agrees) that deploying to production quickly and often improves product delivery, performance and ultimately, business growth. It is a key foundational capability for any startup. We recommend establishing a platform engineering team with clear objectives and embed a technical product manager to build the capability. That team creates CD pipelines, automated testing infra, feature toggles and blue-green environments. The investments are tracked through improvements to the 4 key metrics (lead time, MTTR, deployment frequency, change failure rate) and availability. A key metric is the feedback and adoption from the customer — the development teams.
Another critical capability is fitness functions — automated checks on your tech debt, architecture, compliance and security. This is a form of lightweight governance, giving your engineering leaders and teams quantifiable insights into the current state of the technical landscape.
Domain Oriented Microservices
We recommend a well-factored monolith during the early stages of growth. As you grow, onboarding additional users and employees, splitting into independent services and decoupling product teams are important techniques to utilize. Thoughtworks teams employ domain-driven design techniques to find the boundaries of services. It’s important not to introduce too fast— you’ll need to build supporting infrastructure and teams will have to learn to work with the increased distribution. It’s also important to have a measurable, achievable outcome rather than just doing microservices for the sake of it.. This is typically to expand capacity and increase development throughput.
Developer experience
Reducing the amount of friction in the day-to-day life of a developer has a compound effect on product delivery. It also improves engineering happiness. One way to do this is to improve repeated tasks like building, compiling and testing time, or finding quality technical documentation and API schema. Our teams often utilize a developer portal to aggregate information and provide access to starter kits. Measuring success occurs through a series of leading and lagging metrics and engineering satisfaction improvements.
Preparing your organization for scale
In addition to optimizing delivery, there are many key business functions needing optimization for the increased stress that scaling brings with scaling. There are some key business processes our teams look at when scaling organizations.
Hiring and attracting talent: Improving your engineering brand, reducing friction in the hiring process, becoming more data-driven to hire for trends rather than reacting to problems
Onboarding: Improving time to productivity of new employees, from orientation through their first year
Lean portfolio management: Transparency of the initiatives (bets) being worked on, their status and objectives, so that the leaders can decide when to double down or pivot
Compliance and security: Designing processes and automation around a devops culture
Value stream aligned teams: Ensuring teams are oriented around core capabilities and product bets and their dependencies are minimized
Technical Decision Making: Creating the right amount of oversight and peer input into changes, using expert opinion and metrics to make decisions
Data Strategy: Depending on the use and quantity of data at your organization, this could be as simple as improving the analytics dashboard and pipeline, or more complex, like creating a data mesh to support product and ML teams