Designing Organizations for Scalability: Building the Structure to Scale
The Global Entrepreneurship Monitor’s Global report suggests that over three businesses are launched each second, or about 100 million each year. Anyone can start a business, and everyone does. Increasingly, those businesses are software-based, with SaaS, PaaS, and other structures appearing alongside organizations using software as the foundation of their business (Facebook, Amazon, Uber, etc.). That same report suggests more than 70% of those businesses go on to fail.
As the co-founder of several software-based organizations including Nmbrs, WallyLabs, Grapster, and an up-and-coming venture to be announced later this year, I have a lot of experience with scaling organizations. I also recently wrote a book to that extent, “Vision to Value.” My opinion across each of them remains the same. Startups are pushed into making decisions for the short-term sacrificing long-term stability for the rush to meet minimum viable product (MVP) before funding runs out. When growing pangs arise during rapid growth, organizations create quick and temporary solutions.
While there are plenty of books out there advocating for growing as quickly as possible, I like to advocate for sustainable growth. Doing so means using approaches designed for long-term benefits, to create a future-proof operational structure. And, more importantly, scaling means paying attention to points of friction and problems that may disrupt growth before you begin to scale.
Building a Solid Foundation
A solid foundation is necessary to support any kind of growth. But what exactly is a “solid foundation”? For most organizations, foundations represent leadership, team structure, customer service, and structures to manage resources like funds, quality, customer satisfaction, employees, and features. A good foundation makes it possible to deliver, even as you grow, because the basic elements you need are in place to enable doing so. This is one of the largest risks for startups receiving seed funds, because you can simply grow more quickly than organizational structure will support.
Team Organization: Waterfall, Agile, Holacracy, Lean, Teal, options can seem endless. Most software companies choose Agile. Whatever you pick, make sure that team management is in place, with the structure, processes, and tooling to support it. For example, my own organization uses Agile, with team structure based on the Spotify Model, using both scrum and Kanban depending on the team. Team implementation is almost non-existent in early startups but quickly becomes essential to basic functionality such as transparency, role and responsibility delegation, and asset management. Create team structures you can implement later, even if your current structure has one person working in four teams. Team organization should include strategies for growing teams, creating new teams, and onboarding new team members. For example, who decides where new people go? (Operations is usually the best choice for SaaS companies). Who’s responsible for onboarding? Do you have a strategy in place to ensure that new team members spend several weeks working with mentors and working in established teams to ensure that new people never work on new projects?
Work Management: Work must be transparent, traceable, repeatable, delegable, and ownable. When something goes wrong, you have to know who’s responsible, what went wrong, and how to fix it. Most organizations eventually end up implementing a work management tool, typically in the form of process management. Tools like Asana and Jira are immensely popular here, but with dozens of options and multiple needs inside any organization, it’s important to find your own. Here, the most critical needs are:
- Work needs to be visible and assigned to whoever will do it.
- Every process, module, or feature should have an owner.
- All work should be documented, hopefully from day one.
- Processes and documentation should be the same across the organization.
- Monitoring triggers should link to work and processes to ensure people act on them.
- One person should ultimately be responsible for any item to ensure full accountability.
Delegation and responsibility are tricky in early-stage organizations, where one person is often required to wear multiple hats. However, you can compromise by creating roles inside your management platform, assigning responsibility to the role, and then changing the owner of the role as your organization expands.
Playing the Long Game
In Simon Sinek’s “The Infinite Game,” the author introduces the concept of using a strategy to succeed in the long-term. Companies that develop an MVP with all their resources but that don’t have the resources to build structure are playing a short game. Putting a product on the market is the only visible goal. About 90 minutes in, and the game is over. Companies that invest in structure, long-term strategy, and continued growth can “play” for much longer.
What does this mean for SaaS companies? Shifting attention towards a continuous cycle of development and feedback implementation, supporting continuous improvement, and focusing on delivering value for the customer. The most crucial of these is creating a structure allowing developers to improve value for the customer as part of a continuous process. Here, a cross-functional team structure — implementing QA and customer support — allows developers to receive feedback from your closest link to the customer, validate quality and functionality as part of development, and continuously push for something that adds value.
Organizations should take a similar approach to processes, work methods, and tools. Any process or tool should have an owner who is responsible for maintaining and updating it, including creating improvements and replacing it with something better when the time is right.
Building a Tech Stack for Scalability
Creating a scalable tech-stack often requires balancing the need for growth with the need to expand quickly as customers come in. Here, most organizations can work towards creating an MVP using the bare minimum of investment, which works providing you have a strategy in place for permanent solutions.
- Scalable infrastructure can be crucial to supporting sudden or rapid growth. Technologies like cloud native servers and virtual machines make scaling feasible for small organizations that can’t invest in everything they need upfront and who expect to have dramatically increasing needs as customers begin to onboard.
- Adopt a microservices-friendly approach to development. Most small organizations can’t afford to implement microservices (teams are simply too small), but it will be necessary to do so as the application scales. Design the monolith in a way that makes it easy to split into microservices when the time comes.
- Automate. QA, development pipelines, security scanning, and monitoring. It makes sense for every SaaS organization to implement triggers across the organization and the application to automatically scan for and notify developers of incidents affecting customer experience (page load time, downtime percentage, processing time, etc.). Importantly, it’s crucial to validate any process before automating it (a bad automated process isn’t a better process, it just happens more often), establish standards for continuous review and improvement, and give relevant teams and product owners ownership of processes so they remain relevant.
Invest in Your Core
One of the most interesting concepts for modern organizations is to simply invest in your core and outsource the rest. In “Built to Last” by James C. Collins and Jerry L. Porras, the authors explain that companies like Boeing, Walt Disney, and IBM have thrived for decades because of their strong vision, culture, and investment into their core business.
What can you take away from this? Invest in your core business and outsource the rest. Organizations have traditionally invested massive portions of their budget into servers, software development, platforms, and hardware — at the expense of core products. Today, it’s highly likely you could outsource those things to see results that are cheaper, faster, and better than you could do yourself. You wouldn’t create your own banking platform to handle your finances, don’t feel as though you have to develop your own IT services, print management, graphic design, accounting and payrolling (until your organization is big enough that it makes sense), compliance and auditing, etc.
The result? Your organization has more time and resources to invest in what you want to be good at. And overhead services are provided by companies that want to be good at them. Everyone wins. This is especially relevant and easy with modern cloud services. For example, my organization Nmbrs runs on PaaS Microsoft Azure and virtual machines. Most importantly, outsourcing offers the ultimate scalability. Cloud networks and servers mean effortlessly scaling up capabilities as needed, often at a significantly lower cost than making changes inside your organization.
While there are dozens of “pain points” or “focus points” you could work to improve before scaling, I believe that focusing on specific points is a mistake. Whatever impediment or friction you have now will scale with you, the most important part of scaling isn’t establishing perfect structure, but rather removing points of friction. You have to look at your organization holistically, identify your unique points of friction, and work to make those as seamless and frictionless as possible. Focus points should remain in key business areas, such as compliance or security, because those points will do the most damage if something goes wrong.
This is, of course, a continuous process because the more speed you put in your organization, the more friction you create, so the organization must be able to monitor impediments, improve as part of culture, and continuously ask, “Will this work when we’re 10x bigger?”