Designing your org from 0 to 1,000 Employees

As founders start businesses, org structure is likely a thing that has never crossed their mind (besides perhaps an instinctive distaste for bureaucracy). By ~15 employees, the first questions start popping up around what roles are most important to hire for, and where people should report. And by ~100 employees, in a high-growth business, org design and hiring decisions start to become one of the bigger components of a CEO’s mindshare.

This post is a playbook for how to design your org at various stages of maturity, derived from lessons I learned scaling through these phases at LiveRamp (which I saw from 0 to 800 employees) and Datavant (which I saw from 0 to 8,000 employees). It’s most applicable to high-growth, enterprise B2B product companies (though many of the concepts apply to other types of businesses as well).

This guide is organized as five sections:

1. Principles throughout the journey
2. 0–10 People: The Anarchy Phase
3. 10–100 People: The Leader-Centric, Structured Chaos Phase
4. 50–250 People: The Functional Stage
5. 250+ People: Functional vs. Divisional vs. Matrix Choices

Principles Throughout The Journey:

There is no perfect org structure. Org design fundamentally is about flow of information and decision-making. In the perfect organization, all information flows to everyone in the company, and no time is spent on communication overhead. Once an organization is >1 person, this breaks down, and the complexity of communication scales exponentially as the company grows. So you design the organization to make sure the right information gets to the right people, the right decisions move quickly, and the right amount of overhead is spent on internal communication. This means that there are tradeoffs — what information needs to move quickly, what decisions need speed vs. perfection, etc. The key is to be intentional with your tradeoffs and design the organization that makes sense for your strategy.

Build your bench. Throughout the journey, the biggest bottleneck is usually having the right person who can step into a key role — you need the right overlap of talent, cultural fit, ability to lead, ability to communicate with adjacent functions, etc. Building your internal bench (by hiring well, promoting well, and growing people internally) gives you many, many more degrees of freedom as you grow.

Treat org design as a living experiment. As they grow, many companies have a major reorg that they plan for months, and expect stability after that. That rarely works: a high-growth company changes frequently (and decisions around org design are often wrong). So instead, building a company culture that expects frequent micro-optimizations — and views the organization itself as a form of experimentation — is ideal.

Build operating cadences to compliment your org design. Org design is important as the company grows, but it’s ultimately just one lever on how information flows within the company. Be intentional with how you build operating cadences (team meetings, management meetings, internal aliases, etc.) to manage the information flow as well.

Different people thrive at different stages. There are some people who are exceptional at the early stages, but who strongly dislike the structure that comes with later stages. And there are people who will be great at later stages who can’t handle pre-product-market-fit ambiguity. A very small number of people will thrive throughout — but you’ll want to reassess at each stage who the right people are (and who wants to be involved for the next chapter of the journey).

Try to stay lean. The smaller you are, the more you can accomplish per capita — and the less effort needs to go into organizational design. I generally think a high-performing 100-person organization can accomplish 2–3x what a 10 person organization can, and a high-performing 1,000-person organization can accomplish 2–3x what a 100 person organization can. Hiring well, biasing towards automation, having aggressive goals for each person, and strong performance management go a long way in ensuring you don’t scale more than you have to.

0–10 People: The Anarchy Phase

At 0–10 people, org design is not (and should not be) a topic you spend much thought around — but there are a few key foundations you want to get right.

A few thoughts for this stage.

Keep the org flat. In general, at this size, everyone either reports to the CEO, or the CEO + one other leader (for example, an engineering leader). Organizationally, the most important thing at this size is that everyone has a clear charter, is getting feedback, and knows who to communicate with for key decisions. Any more organization design is overkill at this stage.

Set the right foundations for the future:

• Hire really well, and set a really good culture — these are the foundations for all future scaling
• Be intentional with early titles. I prefer not having hierarchical titles (eg. “Sr. Director of Marketing”) within an organization at any size because of the politics it causes, but it’s only possible to have this policy down the line if you set the precedent of not giving out big titles.

10–50 People: The Leader-Centric, Structured-Chaos Phase

During this stage, you’re still not spending a huge portion of your time thinking about the org design — but you’re beginning to have some foundations of org structure.

A few thoughts for this stage:

Build around people rather than theoretical structure. At this size, there are usually 2–4 superstars in the company who are involved in every major decision, and decision-making de facto involves pulling them in (and they generally know how to stay in sync with each other). So if they’re good leaders, organize the company around them. At LiveRamp, we had Product, Recruiting, and Marketing all report to the same person around this size — not because there’s some logical grouping of those functions, but because she was a superstar who could manage lots of things well. Embrace this for now, and build around the strengths of your team.

Be mindful of team sizes and layers. In general, a good leader can handle ~6–8 direct reports — that allows them to give enough attention to each one, know what’s going on on their team, and provide useful feedback. During this phase, that often means you need to introduce a second layer in your engineering team. You’ll want to be thoughtful about who your best leaders are (often not the same as your best coders), and also begin being thoughtful about building out your leadership bench by creating growth paths for folks on the team.

Focus on getting a few senior leaders. By the time you hit 50 people, you’ll probably want to have 2–3 core leadership roles filled out (over time, you’ll need to fill out heads of sales, engineering, product, people, finance as the most senior roles). These are often external hires, and are extremely important to get right culturally (and obviously important to get a great performer). A lot of your time in this phase should be spent on recruiting these key seats.

Begin designating a management team. While you want to avoid “The Management” being separate from everyone else, it’s helpful to have a small group of leaders meeting regularly who can surface topics across functions — so you will need to begin to designate a management team (usually, at this stage, it’s your direct reports, but not necessarily). Begin introducing this, but be mindful of minimizing the politics it can introduce.

Think about how decisions get made that span multiple functions. At LiveRamp and Datavant, I was explicit that Product could break a tie between functions — which made decision-making fast (and reduced decisions that required my input), and set a cultural tone for the company. That’s not necessarily the right answer for all companies — but there should be an explicit way ties get broken and decisions get made at this size.

Pay attention to how you organize around a customer. As you start to have a team of Customer Success, a team of Product Implementation, and a team of Salespeople, all of which touch a customer — be particularly thoughtful about how handoffs happen between these functions and how the account is owned.

50–250 People: The Functional Stage

Some thoughts on this phase….

Build out the leadership team. In this phase, you are going to fill out all your core leadership functions, and also promote+hire many mid-level leaders (at 250 people, you might have ~50 people in the company managing others — so lots of mid-level manager roles to fill). This is your most important job at this stage: bring in people who can help you scale effectively, and you’ll spend much of your time recruiting and training people internally.

Structure around key functions. Unlike at earlier stages, org structure now matters, and in general, you’ll want to organize things around the major functions (ie. sales, product, engineering, etc.). Key decision points include

• Customer Success — should it report to Sales, or be standalone? And does it own upsell or just renewal? I’ve historically had customer success report into sales, and had CSMs own upsell numbers (except on the biggest accounts) — but this varies from org to org.
• Delivery/Product Success — Many orgs put this in sales/customer success. I’ve historically put it in Product, to keep the Product team internalizing customer challenges (I deep dive on my thoughts on this function here).
• What reports to you? At this stage, you can start to make decisions about what reports to you — both based on your strengths and what’s needed for the org. Do you want marketing as a top-level function or reporting to sales? Do you want privacy as a top-level function? Do you want a COO or CFO to manage all the back-office functions?

Consider sub-team structures within sales and engineering. Once you cross 100 people, both sales & engineering likely have multiple levels of management. You’ll want to think through how you organize subteams. For Sales, there are generally territories — which might be geographic, or might be type of customer (for example, Enterprise vs. SMB). For engineering, you’ll want to have some teams that are organized by product, and some that are system-wide in nature (eg. DevOps team, Infra team, etc.). You’ll likely play around quite a bit with these definitions as you cross ~100 people or so.

Consider whether Product is organized by segment of market or by engineering team. As you start getting a team of product managers, there is an advantage to keeping PMs directly mapped with engineering teams, and there is also an advantage to having PMs deeply embedded in a given market. At Datavant, we ultimately split the team into “Platform PMs” (embedded with engineering teams) and “Solution PMs” (embedded with sales teams and deep in specific markets.

Be thoughtful on how you show up to a customer. As you scale, there will be a moment when you have several PMs representing several products, a customer success team, a sales rep, a CSM, and someone accountable for a new product all trying to talk to the same customer. Making sure you have internal clarity on who quarterbacks the customer’s holistic experience is extremely important.

Get a great head of HR. Starting at this stage, you’ll be spending as much time thinking about the org (recruiting, retention, and org structure) as you spend thinking about any other function. Getting a strategic head of HR who can be a thought partner at this stage is invaluable.

Get yourself leverage. At this stage, there are thousands of pulls on your time, and it’s critical to get yourself leverage. The most important way to get leverage is to get strong leaders in each function. At this stage, I also added an EA and a Special Projects team (people who I could work with on things outside the standard org structure).

Control headcount growth by function. Every leader believes they can accomplish more with more resources. At this stage, you generally don’t have intense budgeting and controllership processes, but teams can rapidly scale without you really paying attention. Make sure you have a strong point-of-view on what teams are bloated and control where headcount goes within the company. Similarly, by this stage, you’ll also have leaders who are great at hiring and leaders who are bad at hiring; you’ll want to help with quality control on the functions that don’t hire as well.

Build the right operating cadences. This is a moment of growth where a lot of process needs to be created to scale effectively and communicate well internally. Be intentional with what operating cadences you create to complement your org structure).

250+ People: Functional vs. Divisional vs. Matrix Choices

At this scale, there are three main approaches to organizing the company:

1. A functional org structure organizes around the major functions in the company — i.e. there is a single product organization, a single sales organization, and a single engineering organization. The pros of this model are that it helps ensure a cohesive product experience across parts of the business and decisions that take into account holistic information, but the con is that this model tends to be much slower to adapt to specific sub-markets and give less entrepreneurial autonomy.
2. A divisional org structure organizes around major types of customers. The leaders in this model are general managers, and they generally have their own sales teams, their own delivery teams, their own product teams, and often their own engineering teams. For example, Datavant is organized with a GM of Life Sciences, a GM of Providers, and a GM of Payers, because the markets are quite different; similarly, ride sharing apps organized around GMs of local markets, and at a much larger scale, there’s a GM of the AWS business within Amazon who is accountable for AWS’s success. The advantage of this model is that it’s nimble to serve specific types of customers and allows teams to be entrepreneurial in servicing the market; cons are that decisions can be disconnected across different business units, product experience can become disconnected, and employee experience can become disconnected (an engineer in one part of the org might be less good than engineers in another part of the org and even use a different tech stack).. Note that most divisional org structures will have a set of “shared service” functions that do not split divisionally (finance, HR, and corporate IT are usually shared services; engineering sometimes is a central function as well).
3. Matrix org structures. To mitigate the downsides of each of these structures, the vast majority of companies end up is creating matrices: you have GMs of each line of business, and ALSO functional leaders. There are many nuances to making this successful, but in general, employees report to the functional leader (who makes hiring/firing decisions and sets compensation consistently across the team, and decides on allocation across divisions), and their priorities are managed by GMs. The upside on this is that you can have both intense market focus AND consistency across the organization, the downside is that — unless you have great alignment and decision-making capabilities — progress can grind to a halt as there are many cooks in the kitchen.

The reality is, most companies end up with some hybrid: they might run the core business as a matrix and a new product as a separate division, or they might alternate between more divisional and more functional. The keys at this stage are:

Be intentional on the functional vs. divisional vs. matrix decision. Even if you change the structure later, have a clear point of view. Decide if you are prioritizing nimbleness or consistency, and what decisions require each.

Decide when to change. It’s fine to switch between models as you grow. And even if you’re consistent with one model, your business units will change over time. When HP was a hot high-growth company, they had a mantra of splitting a business unit into two automatically whenever it exceeded a certain size threshold. So defining the optimal territories and business units will constantly evolve as the business grows.

Decide what is an exception to the model. You might decide to acquire a company, and keep them in a separate org structure. Or make your Japan business completely autonomous from the rest of the company. Or have a new product that moves at a different pace. This is fine, and do it intentionally, and explain it internally.

Figure out where your zero-to-one people go. Many of the people who thrived in the early stages will not thrive in the stages where there are more decision-makers and alignment matters more. Decide if there’s still a home for them in the company, and be intentional about creating more entrepreneurial parts of the company that can be home for zero-to-one teams.

Decide where consistency matters. Do you care strongly about consistency of compensation across teams? Talent caliber? UI? Pricing? Be intentional in designing the org structure and processes to match your thoughts on where consistency matters, and where you want to allow local decision-making.

***

This playbook was intended to help you think through your org structure as you scale. But remember: there is no perfect org design, and your org structure should evolve as you grow, and you should constantly experiment with it.