How to Structure your Product Org to Optimise for Growth

When a company grows quickly, it undergoes stress. The faster the growth, the more the stress.

Structure can make the situation better, but only if it is designed correctly for growth. Good structure provides a scaffold that allows your organization to grow. Poor structure can make things worse.

Structural decisions are business critical. They can make or break a company. If your company’s success depends on growing effectively, you need to get these things right.

Define your org structure

There are many ways to organize product development. Two approaches worth considering are:

The Triad model.

Each function (Engineering, Product, and Design) has their own reporting structure and organization. They work together as peers.

The General Manager model. Each organization is led by a general manager (GM) who is responsible for all the functions within their organization. This is also known as the “Single Threaded Owner” model.

Both models work equally well for scaling your organization. However, if you fail to define your structure, this can hinder your growth. I often see companies where the various functions are at odds with each other. When you don’t have an agreed upon way to interact with each other, you add friction to your growth.

Because the Triad model is more common, the rest of this post reflects advice for scaling within the Triad model. Tradeoffs for the General Manager model are outlined in my post retrospective on Implementing Amazon’s single threaded owner model.

Organize cross-functionally within engineering, embed product and design

It is common for Engineering to organize along functional lines. For example, Frontend and Backend teams. It can feel natural to do so, because this is the way engineers often think of the work they are doing. And engineers tend to build their identity around their roles as Frontend Engineers or Backend Engineers. So they expect Frontend teams and Backend teams.

While it is possible to make this work, this approach has many many downsides:

• Increased dependencies between teams, resulting in poor execution.
• Increased complexity of your organization (which gets worse as you grow)
• Increased communication needs.

Every team should aspirationally be able to deliver business value without involving other teams. So as a default, you should organize teams cross-functionally, and only organize functionally when that seems to not work. This is supported by the definitive book on organizational design in engineering teams: Team Topologies. If you doubt my recommendation, give this book a read.

In most cases, you should pretend that design and product are part of the team. Embed a designer and product manager on each team. For a deep dive on how to be successful with embedding, see my guide for happy embedding.

There are times when embedding doesn’t make sense. In that case, a list of ways to coordinate groups of people are visible in my list of coordination models.

Sometimes it can help to have design report into product

For reporting structure, I often recommend that Design report into Product. This is a trick I learned from a design leader. They used this approach to help Design be more effective. By reporting to Product, he forced the Product team to do the work to align themselves with Design. I often see Design and Product working in different directions. This puts an end to that misalignment.

Besides that, the triad leadership can either report to the CEO, Chief Product Officer (CPO), or a VP/Head of Product Development.

Continually improve your onboarding, and define roles

In extreme growth situations, poor onboarding can lead to organizational failure. If you’re doubling in size in six months, and it takes six months to onboard, you’re losing ground. You end up with a decreasing percent of the organization that is onboarded over time.

Image from Will Larsen’s post on hypergrowth

This is why smart leaders invest in efficient onboarding, and do structural work to make onboarding easier.

One example of structural work that aids in onboarding is role definition. Define what type of Engineering Manager you have (company expectations vary significantly). Who does technical leadership? Who does project management? Defining these things is important because you need to hire for those skills, and you need everyone to understand how they fit into the rapidly growing organization you’re building. You can use this exercise for defining lines between roles.

This type of structure is absolutely necessary. I worked at a company where leadership wasn’t happy with how projects were managed. They realized they had given the responsibility to engineering managers, but hadn’t used that as a hiring criteria. As a result, they had a whole team of engineering managers that weren’t good at managing projects! This ended up being a problem that took years to remedy, and hampered the growth of the company. It ended up noticeably affecting the trajectory of the company.

As you define roles, I recommend writing them down in a well-curated location, usually a wiki. Choose someone to ensure the wiki is maintained over time. And make the wiki the canonical source of truth – it’s not true until it’s written in the wiki. You want people to be able to refer to the wiki to learn how things work in the company, and that won’t happen unless it is a reliable source of information.

You should communicate the expectation that anything written down is flexible, and can be changed over time. If these written roles become immutable, then it prevents organizational flexibility and change. This is problematic in a fast-growing company.

Create strong local leadership groups

One of the most common sources of failure in rapidly growing organizations is poor local leadership structures. In fact, I would say this is one of the problems I see most frequently.

Symptoms of poor local leadership structures are:

• Engineering, Product, and Design not aligned. You hear different stories from each area, and they each have different conflicting priorities. You see different communication coming from each function.
• Multiple artifacts representing the same thing from a team. For example, the Product Manager has one version of a roadmap, and the Engineering Manager has another.

This is a larger organizational failure. Leaders often expect local leaders to figure out how to work together. Instead, they should set up a standard approach for local leadership groups, and then let the local team customize it to their needs.

The purpose of the local leadership meetings was to get the leadership to problem-solve together. They need to be sharing concerns, and updating each other. I know the meetings are working well if the leadership team is bringing up concerns that cross functions, and having good discussions about those topics. For example:

• Product Manager: “I’m a little worried about the timeline for this next piece of work. I feel like the team might be overinvesting in this stage of the project.”
• Engineering Manager: “I’m hearing from the team that they’re feeling a little confused about why we’re building this feature”.
• Designer: “I’m seeing some signs that the work we’re doing right now might not be very well understood by end users.”

There is a reason the General Manager model is so effective. It essentially requires you to set up leadership meetings like this. So you can derive some of the same benefits by having good conversations within your local leadership team.

After you start transitioning responsibilities to the local team, then shift your role to being about monitoring how well it is going, and being available to support them.

One tip: if the local team isn’t gelling, give it a deadline. If they can’t figure it out quickly enough, you should shift people around, or even let people go. Give them lots of support and direct feedback. But don’t allow ineffective leadership teams to persist.

Create strong centralized coordination

An ideal organization has fractal leadership:

• Decentralized decision-making on local teams.
• And centralized goal setting, context-setting, and coordination.

Someone should be focusing a large percentage of their time on setting context and goals for the company. Depending on the size of your company, this can be done by:

• The CEO.
• A VP or Head of Product.
• A Council of VPs of Product, Engineering, Design.
• A person that focuses on business strategy.

The most important thing is that people have the right context to make good local decisions. And that someone in the business has done the hard strategy work to ensure your company has a plan that will ensure the company’s success.

When a company is growing rapidly, a lack of these things tends to throw everything in disarray. My biggest suggestion is to write down a strategy, and communicate about it until people don’t complain about lack of context. This can be a full time job, or the work of multiple people. Some books I suggest on this topic are Understanding Michael Porter and Good Strategy, Bad Strategy.

Define interactions between local and central groups

When you have decentralized leaders actively working in their areas, and centralized leaders focusing on goals and strategy, you will end up in conflict. Ideally, you have a good amount of communication between these groups, and have them influencing each other.

One way to accomplish this is to have some sort of defined interactions between the local and central groups. Typically I’ve seen these be called Business Review meetings.

When I was at Gremlin, we copied Amazon’s approach, and had these meetings:

• A “weekly business review” meeting, with local leadership. We reviewed the state of our part of the product, looking at what we’d learned about our customers, how recent features have performed. And talked through risks, opportunities, and so on.
• A “monthly business review” meeting. This had much the same structure as the weekly business review meeting, but was rolled up for a month’s worth of information. And it included the next level up of leadership. This was a chance for us to surface concerns and risks. And it was a chance for us to influence the higher level strategy. We pitched new product approaches we thought were valuable, for example.

The format for these meetings should be adapted to your local needs, but someone should be paying attention to how well the local leadership is working with the centralized leadership.

Frontload hiring managers

The faster you grow, the earlier you should hire hiring managers. This distributes the work of hiring more broadly. It scales better. And it makes sense – the more hiring you’re doing, the more time it will require of the hiring managers.

You will want to standardize your hiring practices to make it easier for hiring managers to participate.

Define your reorg strategy ahead of time

A common source of pain in organizations that grow rapidly is reorgs. If you don’t have a well defined strategy for how reorgs will work, each org will independently execute on reorgs. Typically, this means they will happen independently of each other. Engineering will do a reorg. Then a few months later, Product will do a reorg. They might do it with different philosophies behind it. It will be a chaotic mess.

You should have a product org wide view of how teams are defined, how Product is aligned with those teams, and how Design works with those teams. It’s very common for Engineering to want to organize around technology, Product around customer segments, and Design around design function: UX and Research, for example.

This is a pain point for the Triad model. Write down how it should work. I’ll confess, I’ve never seen this done before. But it’s something that could reduce so much organizational pain. And the faster you grow, the more valuable this could be.

Support your leaders

You need a lot of leadership structure to navigate a rapidly growing environment. Ideally, you have leaders who are constantly improving the organization, and fixing all the inevitable things that break as a company swells in size.

This only happens if you invest in your leaders’ growth. They need to be growing as quickly as the company. I recommend these practices:

1. Use 1-1s to train managers. They are an opportunity to identify skills the manager needs, and to deliberately train them in those skills.
2. Use skip-levels to observe. Skip level 1-1s are a good tool to sample from throughout your organization and find out where there might be problems. You can uncover teams that need help, or managers that aren’t being effective. They also help preserve communication – if you meet with people within your org every three to six months, they are more likely to surface problems to you.
3. Set up management support groups. You can organize groups of managers into small support group meetings. Have each person go around and talk about what is hard for them. Ideally these can become learning meetings, where people are vulnerable with each other about their challenges. And they can learn from each other and become more effective leaders.

Jade Rubick is a former VP of Engineering at New Relic, and VP of Product and Engineering at Gremlin. He now advises startups on how to scale their product development organizations. Jade writes about product development on his blog, and has a free (or paid) course of engineering (and product development) leadership.