How to Rethink Organizational Design as Your Company Grows

As leaders—especially engineering leaders—organizational design is probably the most leveraged thing we can do. Since we're talking about the process of dividing a group of people into teams and then connecting those teams together, it’s worthwhile getting into why we design teams in the first place.

My strong belief is that the objective of org design should always be execution, efficiency, and quality. All other optimizations, like career growth of strong people, or culture-building, are secondary (albeit important) objectives and should be applied after an ideal org design is made without them in mind.

There are three fundamental factors in how we design orgs:

• Size: After a certain size a flat group of people starts to become inefficient. This is a self-explanatory but nevertheless important constraint.
• Community/Skills: People benefit from working closely with others with similar skill sets and varying experiences. It gives people a chance to mentor, be mentored and grow. The quality of solutions is better when an org optimizes for skills growth.
• Identity/“Charter”: The product benefits when a smart group of talented people live and breathe a particular problem end-to-end. The quality of problems solved is better when an org optimizes for ownership of charters.

Take for example the classic Horizontal vs Vertical Engineering org debate. It’s basically a community vs identity tradeoff.

Optimizing for community creates horizontal orgs: This optimizes for liquidity and development of talent. People operate and grow faster if they work in a community of others like them. For example, ML engineers would function better in a team full of other ML engineers vs being fragmented with a group of Mobile developers. This advocates for horizontal, skill-set-based teams (e.g. Mobile, Web, ML, Data engineering…).

• This kind of design helps you hire and onboard engineers faster. In larger orgs it lets you hire more senior engineers who are domain experts in those domains and can influence a large team’s work. It also creates a better tech stack and better solutions.
• But you run the risk of the team’s identity being too tied up with a solution vs the problem. The “how” starts to rule and the “why” gets lost, creating a loss of empathy towards the product. Engineers start to feel that end-to-end experiences are someone’s else’s (usually the PM’s) problem. Since there will always be more engineers than most other functions, you have the majority of the org not thinking about the end product but only their part of the solution.

Optimizing for identity creates vertical orgs: This optimizes for clear charters and end-to-end ownership. The quality of product is better if a team is accountable for a problem end-to-end. This advocates for vertical, “problem” based, teams (e.g. Onboarding, Engagement, Growth, Content Creation, Trading…).

• This creates strong empathy in the engineers for the end product vs a piece of a solution. The “Why” and the “what” become the first class citizens. It also creates a strong customer focus in engineering and as a result a big part of the org. This typically creates better products.
• On the other hand, this can create duplication of technical solutions for similar problems by groups that operate in silos. If not done carefully the consistency of the codebase starts to deteriorate and eventually that inconsistency creeps into the product. You start shipping your org chart.

So what’s the right optimization? Neither and both. Based on the org’s life stage and size you usually go from one to the other and then both—back and forth.

Let’s take an example

You start a company (or a new org). It’s all just one small team that has all kinds of people you need (or the people you have to do all the work you need). This is the most vertical team you will ever build. Everyone has the same identity, work gets done fast and there is very little coordination needed.

Scale Stage 1

As the team grows you start to add more people with some skill sets so that you can produce more work faster. You are still working on mostly the same problem/project but with more people. It makes sense to start to organize horizontally based on skills at first. Like Mobile team, backend team, ML team etc. Why?

• At this stage a strong community will create the most amount of efficiency in terms of people swarming on important work. It also helps you onboard new people the fastest.
• It allows you to make foundational decisions about the technical architecture.
• The identity already is pretty clear at this stage as you are focussed on a small number of problems and the company leadership is able to inculcate it at this size.

Scale Stage 2

As you grow, the problem space starts to grow. You start to have multiple top-level problems that you are chasing. Your teams will start to get split into multiple “pods”.

For example, your mobile team is now divided into 3 product projects pods plus a platform team. They work with a backend team which has a somewhat similar split. You start to see non-engineering functions like PM/Design start to be mapped to these “pods” at first for a project but slowly becoming permanent. In essence these functions act as an adapter for a world that has become verticalized over an org that is still horizontal.

This is a fine short term solution but as the team keeps growing and pods become semi-permanent, you should consider a structural change. Why?

• Identity starts to become really important at this point because individual problems become big enough to need end-to-end thinking. And that e2e thinking can’t just be done by PMs or leadership—you want the whole team owning a problem.
• Decision making becomes easier and more scalable and metrics and success is easier to measure
• The team sizes may be big enough by now that even the vertical teams will be able to provide “community” in terms of skill growth. For example, if you were to divide by user objectives (say Engagement, Trading, Community Growth…) each of these parts might have enough Mobile/Backend/ML engineers to provide community and mentorship.

Scale stage 2.5 and so on

You can’t verticalize everything. Some parts would need to stay horizontal. And some parts may need to be cut out of a vertical team and made horizontal. Typically, these are parts which can have their own product identity even as a horizontal.

In my experience it’s one of the two things:

• Code/functionality that is (or should be) shared and has 2 or more users—aka a platform.
• A competency that is so core to the company that it has to stay “skill-based” and be optimized independently. For example, image understanding, or user modeling or OS kernel.

Conversely, you may have something laid out as a horizontal that should merge with another team to form a vertical team. Maybe there is a platform team that only serves one client team (or mostly one client team). It was made horizontal to give it a community but it might be time to bring it closer to its most demanding users.

The question always is when do you go from one stage to the other. Let’s chat about all that next time. I am surprised you made it this far!

Parth Vasa is an engineering director at Meta Virtual Reality working on helping people seamlessly experience virtual reality by themselves and with others. Before VR, Parth worked on Instagram building out the Discovery and Shopping products. Prior to joining Meta he worked at Bloomberg helping build their Search and AI teams. This post originally appeared on his Medium page.