How to think about structuring a start-up team.
One of the marvels of humanity is how when we work together we can progress so much more than when we work alone. We all have different experience, skills and talent to offer, and businesses are just one example of people working together to achieve more than they could alone.
The challenge facing fast growth companies and start-ups is that they are in a constant state of change. Actually, all businesses need to be in a constant state of change if they are to survive at all. The environment around them changes and to provide value in that environment they need to refine and adapt. The fact remains however that some businesses move faster than others, and start-ups tend move really fast.
And here's the thing, the bigger your team gets, the more structure you need to make the most of your resources. By structure I don't just mean hierarchy, I also mean more clearly defined processes. Most people recognise that small companies need less structure and larger companies need more.
Things aren't that simple though. It's not just size that matters. There are I think four major considerations at play when building an appropriate structure for the business (for that moment in time).
These four are "chunking", "scheduling", "size" and "risk".
1. "Chunking"
By chunking I mean; how easy is it to separate different tasks between different people? It could be that (in say - a recruitment consultancy) one team looks after London, the other team look after New York. Or - (in say - a law practice) one legal team looks after client A and another legal team looks after client B. Where it's easy to do this, we often do because division of labour brings speed, expertise and efficiency. As long as there are not too many dependencies between these teams, you can still run a fairly flat organisation with limited processes.
2. "Scheduling"
In some instances, many different tasks are required AND they need to be done in a certain order. This is where it gets more difficult to manage with little hierarchy. Consider a major engineering project such as building a new bridge. Many different teams are involved in a build process that has to happen in a certain order. In such businesses, more hierarchy is required to get the job done, create the processes to pass the project along from a multitude of task owners. It's not just that this is a lot of people, there are lots of complexities with dependencies that require order.
3. "Size"
Size is more obvious and is where we started out - the more people involved, the more hierarchies and process are needed. Just because two businesses have the same number of people though, it doesn't mean they should have the same depth of hierarchy or body of process. A recruitment consultancy with 10,000 staff will not need as much hierarchy and process as an oil exploration company with 10,000 staff. In the first instance the recruitment consultants can work in small teams to independently mange their customers, develop business and attract candidates. Maybe there's a central payroll system, CRM software or a local marketing team, but it can be quite a flat hierarchy. The oil company will have far more specialists all needing to interact and more hierarchy depth is required.
4. "Risk"
Compare NASA to a theatre ticketing company. In one case if a process fails, someone dies. In another case, the guest might not get a ticket. In situations of high risk, it's likely that more controls are in place to manage resources tightly.
What about start-ups?
I find the four considerations above a useful starting point when thinking about structures that are needed for a start-up.
Some learnings;
- Understand that as you grow you'll need process, but only just enough to make it work. Too much will suffocate productivity
- Build a foundational structure based on your thoughts around risk and scheduling considerations. Figure out how much scheduling is required to make things work. Reduce dependencies where you can.
- Chunk work if you need to, but understand the different between "could chunk" and "should chunk"
- Accept that different parts of the organisation may require different levels of hierarchy and process. Many people assume a company requires a standardised set of levels of management, this is a mistake. Tech may need a totally different level of depth and structure to (say) sales
- when hiring people, try to understand what types of environment and culture they thrive in. Hire not only for your current structure but try to anticipate what you'll need as you grow
Building an organisation framework requires understanding your current state, anticipating your future state and being able to find a balance between the two. As both are always changing, you're never done.
