Startup teams often grow suddenly, in bursts. Can we anticipate these points where our ways of working together typically break?
When we forecast growth it’s easy to draw smooth lines - up and to the right.
But that’s not how it ever actually works out, in practice.
We rarely anticipate the dips, perhaps because those bits ususally get airbrushed out of stories of successful startups we might hope to emulate.
On the other hand, when we think about how we will grow our team, we don’t always prepare for growth that often happens suddenly, in bursts.
I’ve learned there are several points where early-stage and high-growth teams typically break, when our existing ways of working are no longer suitable and so our teams need to either change or fall into dysfunction…
The first common breakpoint is when the team grows to ~30 people.
This is when we need a clear organisational structure for the first time, with reporting lines and job titles and budgets and performance reviews. Which is not to say that we didn’t have or need any of those things previously, but more that they seemed less important when the team was smaller and everybody was mostly on the same page and just doing whatever was needed everyday to keep things moving.
This is when, for the first time, we have people in the team we don’t talk with directly in the course of a typical week. It starts to get difficult to keep up with what everybody is working on without conscious effort - the ratio of signal-to-noise becomes a problem and we need to start to filter. Our calendars start to fill up with status meetings.
Critically, this is also when the decisions that were made, often unconsciously in the early-days, about team culture and ways of working together, start to become embedded, for better or for worse. If the team is not already diverse then that becomes more-or-less impossible to change.
Then, later, things often break again when the team grows to ~120 people.
This is when it’s no longer likely that everybody knows everybody else in the team by name. At this size we need several layers of management, which causes the team to fragment. This could be by function, or by location, or by tenure.1 It’s much more work to get everybody on the team in the same room, let alone on the same page.
This is when the job of running the team becomes a drag for those who are more suited to early-stages. There is less need for generalists and more need for specialists. It becomes harder to vet every new hire, so inevitably we have to start to deal with performance management, which is never fun.
This is also when we start to get real diversity of style - if we want to maintain a shared culture we have to really work at it rather than just assuming that everybody will pick it up by osmosis.
If the team grows very quickly then the gap between these two breakpoints can seem depressingly short.
(There are very likely additional breakpoints beyond this size, but I don’t have personal experience of those. I’m interested to hear your experiences.)
Here is a simple exercise that help us to navigate these break points, whatever size the team is currently:
Imagine the org chart when the team is three times as big as it is now.
Draw it on a whiteboard.
Don’t worry about putting names in each box, or providing detailed job descriptions. Just think about the different functions or roles required in the business when the team has grown to be that big. What are the jobs that will need to be done? In order to answer this we need to think about the shape of the business model that will sustain the team at that point. And possibly also the funding that will be required to get us there.2
Having watched many people struggle with this, I can confidently predict that you’ll find this seemingly trivial exercise to be anything but simple.
If we have five people now it can be hard to imagine what another ten people might do. How will the current jobs fragment as they increase in complexity and scale? Likewise, if we are a team of 20 people now, imagining the structure when there are 60 in total can be difficult. What sub-teams will form? Who will lead and manage, and how many people will report to each of them?
I’ve found that two areas that are often overlooked are HR and Finance. In a very small team these are jobs that everybody does, and so nobody does. But as the team grows these become separate functions, and are actually vital to fuelling the growth itself.3
Another common point of tension is the split between product and marketing/sales, and within the product team the split between engineering and operations. Again, in a smaller team these are functions that are typically shared between multiple people where everybody does a bit of everything, but as the team grows these will become areas with assigned responsibilities and how those interact becomes critical.
Once we’ve drawn the boxes we can start to think about the existing people we have in the team today and how they might fit into that future structure. Where are the gaps? Where do people need to evolve their role or start to specialise? Who will be excited about being part of the team at that size and who will likely want to move on at that point?
If that wasn’t too hard, then do it again, but this time imagine the team when it is five times as big as it is now! This will highlight a whole new layer of complexity.
One of the mistakes we often make when thinking about startups is imagining them to have a steady state. It’s not that they one day change. It’s that they are constantly changing. This can be invigorating but also exhausting. We have to repeatedly break things to fix them. But, if we can always be thinking a few moves ahead then we can keep up with the adaption that is required to ensure that we get to the next level. And then to the one beyond that.