How do I scale my startup’s organization as it grows?

Ay you got some money?

You got a million cash?

Be makin’ money money money money money money

Watch it, I’ll flip it

Get big.

Get big.

Get big.

Get big.

(After Dorrough, “Get Big”)

How Do You Grow a Company

We love romantic stories about startups with a tight founding team of 2 or 3 or 4. But in order to become the rare success, a founder has to deal with something much harder: how do you grow a company to 100, 1,000, 10,000 people? In other words, a founder who’s truly creating value must have some skill in recruiting and managing people, a dark art.

When a founder asks the board how to scale their startup and reach their ambition for the team, they usually hear two recommendations:

1. Find an advisor who has done it before.

2. Hire experienced executives who have done it.

That advice is at best limited: you can’t judge skill in an area you don’t understand. It’s like hiring a great engineer having never written a line of code. Notice how both investor-directors (i.e. venture capitalists) and CEOs from big companies who never created companies tend to overweight experience and title, since those are the few signals available to people who have never scaled a startup themselves. Meanwhile, mature companies are full of long-tenured, well-compensated managers who were lucky to land in successful companies and then baffled the people who promoted them with a complete inability to repeat the trick.

Those suggestions are still good. It’s good to find mentors. It’s good to hire executives. But you have to really understand the fundamentals yourself so you can identify the best advisors to talk to and the best executives to hire — and what advice to ignore.

This post doesn’t contain a step-by-step guide to becoming a management genius in 5 minutes. This is a base-layer management writeup. It covers fundamentals and some timeless trends, meant as a context for all the management techniques you’ll find (or write) elsewhere. In later posts I’ll go into more detail on issues like:

• managing senior people
• managing politics
• managing the yearly review/incentives process
• aligning incentives
• hiring people to lead businesses you don’t understand
• reorganizing
• rolling out software for employees

The Core Idea: Retreat Slowly

The core idea: retreat slowly

As a company grows, simple things get harder. Patterns that worked for a 10-person startup have to be revised to keep working for a team of 100 or 1000. Three things suffer:

• Communication slows.
• Information silos form.
• Decision-making slows.

One helpful way to think of these issues is to imagine a startup with just one employee. You write the code, design the user interface, sell it to your customers, support it, plan the business strategy, manage marketing, handle accounting, and fill up the fridge with beverages. Communication is a cinch. And every decision is lightning-fast. Every employee you add only makes information sharing, decision-making, and alignment worse.

But a company that doesn’t grow is barely even a company: it might as well be a tiny startup. So the goal is simply to degrade your ability to communicate, share knowledge, and make decisions as slowly as you possibly can, relative to the speed of your growth.

Think of an American football team, where it’s the job of the offensive linemen to protect the quarterback. When the QB takes the snap, everyone wants the offensive line to stand their ground and keep the defense from reaching the QB. This is rarely successful. Instead, an individual lineman may have to sacrifice some of the yards he’s protecting to hold off an attacker for long enough.

Scaling relies on three tools: specialization, organizational structure and process. Each of those has to be added as a company grows, and none of them is free, or fast to learn. In fact, each one feels at first like giving something up - it feels like there’s a net loss of shared knowledge and the ability to execute. And a football team can’t win a single game without letting the other team get some yards. You just don’t want to lose so much that you lose the game, or allow your growth to overwhelm you and your company.

Practical Steps for Scaling

Practical steps for scaling

When the cost of bringing new people up to speed exceeds the work they take off your plate, it’s time to act. It means the defensive lineman is getting past you. The first line of defense is specialization.

Splitting work into specialized roles

Early engineers write the code, and build, test, deploy and operate it. There are very few handoffs. It works great because there’s a low barrier to having a team who all understand the product. Once companies grow a bit, new people require more and more assistance to get up to speed. Soon the cost of training people, both in technical sophistication and tribal knowledge, starts to cost more than just doing it yourself. It’s time to start handing the work over and taking on some inefficiencies to scale.

Splitting out specialized teams addresses some of those issues. A build team can do the builds. There’s less knowledge-sharing than before and more handoffs, even sometimes competing agendas. That’s where structure and process come in.

Structuring the organization

Each org structure is flawed, built to make some communication easy at the expense of others. A product-management team that lives under engineering will have weaker connections to marketing. Since no design can capture all types of communication, there will be complaints that some kinds of information aren’t flowing freely enough. Critics of a new structure are usually right: it’s only a question of whether the new org design solves more problems than it creates.

At small size, each unit is a single group (e.g. there’s just one engineering group). Then one manager for a functional area (e.g. a QA manager). Then the divisions within a function (e.g. server vs client, or functional area vs use case). Then functional areas vs business units. Of course, it’s possible to split up a team by any number of axes. While engineering may divide their workforce up by platform or technology (clients, servers, operating systems, databases), other teams may organize more around clients or project types.

All org design is communication design, and some connections are more critical than others. With a single manager you get the most communication. Teams with far-apart managers communicate less. If sales is split by product, you disappoint the clients who buy all your products.

To choose an organization design, start with this basic list:

1. Define the different types of knowledge, data or skills that have to be shared, e.g. the core architecture for engineering, QA, product management, marketing, sales, support, and any other areas.

2. Map the most important decisions. What decisions get made the most frequently? Everything from hiring decisions, new features or engineering tasks, and of course ongoing support issues. As the same decision repeats, it makes sense to put all of them under the scope of the same person.

3. Rank the paths. It’s a matter of which of these needs matters most. Is the PM talking to customer about new features, or keeping engineering in sync on customer complaints? Is it more important to know the customer or the architecture? It changes over time; you sometimes find yourself pulling back on one axis to restructure by another.

4. Only now pick out the leaders for each group. A very common mistake made when reorganizing a company is to work from the org chart, instead of working from a design for the activities of the workers. Bad things happen when managers get to build orgs first. Executives line their careers up before considering how to solve the business problems. It’s important to delay choices about who gets which roles until the structure makes sense. Managers always get upset and confused. They get over it.

5. Name the communication paths you didn’t optimize for. They’re almost just as important. They will matter later, and you need to understand the trade-offs you’re making now. Ignored issues tend to take revenge.

6. Plan the mitigation processes. The known gaps create the list of processes. The gaps between groups are predictable issues; if the structures are thought-out, then the needed processes are almost obvious. These processes plug the holes between functions and teams, and will save time or cost money otherwise lost during communication gaps.

These six steps will get any team far. Later posts will cover advanced issues such as how to make them go faster, how much to communicate as you plan, timing a reorg, and how often to reorg.

Formal processes

The principle underlying process is a simple one. Process exists for one goal: to create a practical path for information to flow between people across the company. With a startup that has all of five people, people talk face to face. Process is, basically, unnecessary, just because everyone is still small enough that they can reach everyone else. At 4,000 people, most paths no longer connect all the way across. Process is a way to create connection that is simply no longer physically possible.

At its core, process means any formal or regular way to share information. A six-sigma project and a regular weekly structured meeting are both process. Size the process to fit the function.

Some communication paths are so important that their success has to be guaranteed. Hiring is probably the first process to institute formally. Hiring may have the broadest impact: candidates interview with the hiring team, HR, support teams, managers at every level, and the executives. Different teams care deeply about different aspects of the hiring process.

Who should design a process? In any area, the people who are already doing it informally. They see what flows from one person to another, and what information leads to specific decisions. People hate being told how to do something they already do instinctively.

When to add process? It depends on the situation. One standard is to add a process when it’s difficult for a newcomer to guess what information to track down and with whom. It’s also easier to bring new employees into a process that already exists than it is to impose one on old hands. So it pays to formalize early, and ease onboarding.

Process design is hard to get right and covered at length elsewhere. For now, here are some points for founders just starting out:

1. Start from the output you want (a great hire) and work backward. Build what you expect to see at each checkpoint. Then create steps that yield that.

2. Make metrics for each step, so you can identify areas that are doing well or badly. And so you know where to iterate. In hiring, how many résumés come in? How many get reviewed by humans? How many get interview invites? And of those, how many show up? What percentage gets a job? Out of those, how many stay?

3. Assign ownership for every step, and ensure it’s visible when the steps are done. If it’s important, make it a part of their job.

A closing thought

Scaling an organization is like scaling a software product: its architecture dictates the features it can build. Move too early, and you’re handicapped with a complicated org chart that’s too stiff to solve any business challenge. Move too late, and you clog the central engineering team with work they can’t handle, and your systems melt down. The right balance is to react to real growth and stay slightly ahead of it, anticipating issues that will happen next.