When startups are just getting started, no organization is necessary for the most part. The team is so small and everyone is so connected. But, as they grow the question of how to organize quickly becomes important. Once that happens, there is a right way for almost all startups to organize: a functional organization with cross-functional teams focused on particular areas. This doesn’t mean that absolutely every startup needs to be organized this way but it should be the starting point and organizations should have good reasons for going with a different approach.

As Ben Horowitz says,“the first rule of organizational design is that all organizational designs are bad.” So by no means is this a perfect structure that solves all problems. No matter what approach you choose as you structure your company you are inherently optimizing on some dimension. The other dimensions will suffer and you must you consciously take steps to mitigate that effect. The structure suggested here makes a choice appropriate for a single-product company and provides good mitigations for the limitations of that choice.

What’s the Problem?

The right way to design an organization is to try to figure out what you are trying to accomplish and then build an organization around those goals. Although there are many different goals for many different kinds of startups, there are a few that are central to think about for organizational design in startups, particularly once they have acheived some level of product/market fit.

Ship or improve a single product. Startups generally have a single product (or a very tightly aligned set of products with a single go-to-market approach) stemming from a clear vision that they are delivering to customers. There needs to be a level of coherence in the product in terms of design, architecture, and go-to-market.

Ship and iterate quickly. Startups thrive on speed. Any org structure needs to support extremely rapid iteration, which means clarity, great decision making, and autonomy for people working on a problem to let them deliver quickly. There are many different and difficult problems that need to be solved within a startup and getting groups of people working on them effectively is essential. Further, because startups don’t have the degree of specialization that a larger company does, people need to step up and fill roles to make sure that the right things happen.

Develop and build the team. As startups scale they need to retain and grow their people (both into managers and as individual contributors). A lot of this growth happens through people tackling interesting problems, but effective coaching and management play an essential part. In particular gaining mastery within their specific discipline is essential.

The Answer: Functional Organization

Two of the above goals (single product, developing team) argue more strongly for a functional organization while one (shipping quickly) argues a bit more for an organization built around the problems being solved. But, the additional issue that tips the balance towards having a functional organization is the fact that the problems that the team faces change quickly within a startup. If you try to organize formally around the problems chances are you’ll be re-organizing all the time, which is incredibly disruptive.

So, when you draw the org chart for your startup it should have leaders for each individual for each discipline and individual contributors working for those leaders. This means that designers work for designers, engineers work for engineers, marketers work for marketers, and data scientists work for data scientists. This is incredibly useful for evaluating performance, providing feedback, and reducing technical debt (and similar company cruft) over time.

Along with satisfying the core goals above, there are a few other key advantages that this model provides:

Executive team makeup. By structuring the organization in this way, the executive team is straightforward. It should have the manager from each discipline on it, which leads to a very balanced executive team with all of the elements that are critical to the company represented.

Hiring. Finding, attracting, interviewing, and closing candidates is essential and is greatly simplified by having people who know how to recruit in their field.

Depending on the nature and size of the company, there may be different ways of breaking down disciplines. For example, marketing teams include PR specialists and highly quantitative online ad specialists. There can also be “one-off” groups that need to find a home. As with everything in a startup there is a significant degree of flexibility that is needed to make this work, but no more so than any other model.

Mitigating the Shortcomings: Strong Cross-functional Teams

Having set up your organization functionally, you can now generally ignore that structure and should run most of your product efforts using cross-functional teams slicing across your org chart. People will naturally bias towards their function and manager, so the company rhythm should orient as much as possible around the cross-functional teams (often referred to as squads, pods, or cells) that are solving key problems of the company. So, for example, this means that squads should be the ones demoing progress at every company all-hands and celebrating success as features ship.

Squads focused on product improvements usually consist of 3-10 people for some finite period of time. The squads get everyone needed to make the right changes to solve a problem together on a full-time (or close to full-time) basis. They also need to have a clear definition of what they are trying to accomplish. But, once the have that definition they should be fundamentally autonomous and the individuals on the team should be empowered as much as possible to make decisions and progress. Squads that have the core cross-discipline team members together can move quickly and accurately with minimal dependencies and context switching

This doesn’t mean that there is no oversight — designers will still show work related to the problem at the design team’s crits and engineers will still work with the rest of the engineering team to ensure that the architecture is right and the code is properly reviewed. The natural pull of the org chart and reporting responsibilities will ensure that the teams work within the context of the larger product and vision. But in the end the team is given a lot of latitude to get things done.

This squad model maps most cleanly to the part of the organization delivering product—clearly it makes less sense for groups like customer support and sales. Those organizations are served well by the main functional organization in their day to day work, and they also can and should be pulled in to squads as necessary and useful. Individuals in those functions will rarely be completely dedicated to a particular squad but often have a lot to contribute to a project.

Considerations and Caveats

Even though this is very likely the best structure for your company, it is worthwhile to understand the set of tradeoffs you are making as you think about structure. Two of the best posts on this topic are from Steven Sinofsky and Ben Horowitz. Each is well worth reading.

One major caveat, as noted above, is that this model works best for product-centric operations. Operations-heavy startups may need to operate differently in some ways (e.g. if they are very location-specific the idea of general managers for regions might be important) but the basic principles apply.