The purpose of this document is to increase transparency for the team as to how we think about organizational design as the company grows.
We hope that by setting clear expectations about the future we will reduce anxiety and ensure that nobody is surprised when we make major changes to the way we operate our company.
The important principle to keep in mind is that we should expect things to change all the time as the size and needs of the company change. Tools that worked for us when we were 10 people might not work when we're 100 people, and that's ok! We need to embrace the uncertainty.
The best analogy I've heard for this is that company building is like the surfer on top of the wave. She needs to make constant adjustments to stay on top of the chaos below her and you should expect that you'll always need to put work into the system to stay operational 🏄♀️
Levels is a complex adaptive system, as are all startups like ours. In other words, company building is hard, unpredictable, and constantly changing. This is an important concept to keep in mind as our company scales, and we'll explore the terms "complex" and "adaptive" in greater detail below.
Any organization that requires coordination between large groups of people is a complex system. One of the primary reasons why this is the case is that headcount scales linearly, communication paths between people scale polynomially (for more thoughts on how to manage this proliferation of information, see Principles of Internal Communications (Comms) - August 2020).
https://lh3.googleusercontent.com/9v8UpIRvjHIq3uMOCNyWF9nw7NGhGEu6EfG78t8Gd_4u8zoW-0dcwI-RuSva6wmkqUJbl67AYeN4BWA03AVZyNrP8P2m8AwdExCcEMNAL_Ncgh3EDDeQHUOA9gW_utATleEc1wKd
This isn't something to avoid, as it's intrinsic to any organization that reaches some degree of scale. Complexity isn't so much a "problem to be solved" so much as it's something to manage and work around. That is to say, it's not a reasonable goal to try to eliminate complexity from an organization — instead, one should find ways to work with the complexity to maintain velocity at scale.
The important thing to recognize about complex systems is that, at different phases of complexity, different control systems are necessary to make things work.
Example: When building a software company, when you only have one engineer working at the company, you don't need a project management tool any more sophisticated than a Kanban board — if that. But as the number of people in engineering increases, eventually you need a better way to manage priorities and to ensure that your team isn't duplicating work or heading in the wrong direction.
One of the challenges of understanding complexity is that the boundaries of the complexity of a given system are fuzzy. It's obvious to anyone who has worked at companies of different sizes that a startup is fundamentally different than a Fortune 500 company. But at what size, precisely, did that phase change occur? Is it at 100 employees? 1,000? 100,000?
Example: Extending the example of the software company above, how many engineers do you need to have at the company before you add process and structure to ensure the team can work effectively? Is it at 3 engineers? 4? 21? 72? For people who have scaled engineering teams, you'd probably say it's somewhere between 5 and 25, but that depends a lot on company culture, the seniority of the people you've hired, and the types of problems you're solving.
We can use humans in boats as a way to explore the interplay between complexity and control systems.
If you're a single person in a kayak, you are your own control system. You can paddle in any direction you want and you can get where you need to go.
If you're one of three people in a canoe, you need to coordinate with the other people to make sure you're going the direction you want to go, but it's mostly the same control system as you had in a kayak. You don't need to worry about people making independent decisions because coordination is easy.
.jpeg)