Organizational design, for the most part, is a dry topic. The mere mention of the subject conjures up images of neatly organized two-dimensional tree diagrams, dividing into different branches and reporting lines, making it all-too-easy for eyes to glaze over. That’s why it’s no surprise that even as a startup begins to scale, team structure isn’t always approached with the intentionality and first principles thinking as other parts of company building. Nan Yu wants to change that.
Now Head of Product at Linear, Yu has spent his career building startups in various different stages and industries, from heading up the technology org as CTO at Everlane to scaling product-market fit at the business intelligence tool Mode. In between his last two roles before Linear, Yu took something of a startup “gap year,” teaming up with early to mid-stage companies in Silicon Valley and advising founders. “But as much as anything I was there to learn,” Yu says. “I wanted to see how people were solving problems, what elements of company building they were taking for granted.”
By the end of his advising stint, Yu had seen quite a lot of variance in tech stacks, go-to-market approaches, and fundraising strategies. But what remained unchanged at nearly every startup he visited was team structure, especially in the product org.
“There was the same basic setup. Small teams. Usually cross-functional, headed up by one PM. Each team focused on a very narrow slice of the product,” he says. “What founders slowly discovered over time is if you break up your teams into little bits, and ask them each to cover a narrow scope that is mutually exclusive from the other teams, it’s probably not going to work. They ran headfirst into Conway’s Law.”
Coined in the 1960s but popularized anew by investors like Steven Sinofsky, at its core, Conway’s Law describes the link between the communication structure of organizations and the systems they design. For startups, those “systems” are products, and many founders have successfully internalized its defining takeaway: You will ship your org chart.
But, even with widespread awareness of this mantra, what Yu saw was that as soon as startups began to scale, org design work was inevitably passed off to someone in an operating role, and not in the hands of the folks shaping the product every day. In other words, org design has been pushed to the wayside.
Conway’s Law is so commonly referenced in Silicon Valley at this point it’s almost a meme. But I still don’t think we take it seriously enough. Because your product will be a mirror of your teams. You will ship your org chart.
In his presentation at Figma’s Config conference, Yu addressed founders directly, making a compelling argument for more intentional org design. Blending simple tactics with stone-cold management theory, Yu lays out a concise, yet powerfully effective playbook here for structuring a product design org (though his takeaways can be applied beyond this scope, of course).
He starts by dissecting why the current model of small, symmetrical “squads” doesn’t serve fast-moving startups in the long run, weaving in a gardening metaphor to help drive the point home. He wraps with the three sections to consider when building a team structure: shape, size and scope. Each section serves as a mini-playbook, full of tactics that can be applied right away. Let’s dive in.
WHY “SPOTIFY SQUADS” AREN’T WORKING FOR YOUR STARTUP
Yu heard one thing over and over again at every startup he worked with in his gap year: “I remember when we moved fast.” The sense of nostalgia and loss in these companies was palpable, according to Yu. “As startups add more and more people, they start to feel themselves slow down,” he says. “I kept hearing: ‘We added a bunch of people. Now we’re moving more slowly than before. Or ‘I can't get the team to focus on anything. We're just going in so many different directions. And on top of this, we're drowning in technical debt.’ Something about the way they operated changed and made these things hard to achieve,” he says.
To help founders diagnose the problem, he’d ask how they landed on their current team setup. Especially for those who followed the stereotypical pattern of several small teams, the answer, more often than not, was “I read it on the internet.”
More specifically, they cited a seminal 2012 essay on Scaling Agile at Spotify. This whitepaper has been widely circulated and re-purposed. To emphasize just how endemic this theory has become, Yu found that 50% of the time he asked ChatGPT to come up with a team structure for a product design org at a startup, it would reference language pulled directly from this paper.
“The issue isn’t that the methodology Spotify used at the time is wrong or bad,” Yu says. “It’s that the startups copying it have almost nothing in common with Spotify. They don’t look the same, they won’t have the same scale, trajectory, culture, and most importantly, product. But this information is so widely available and prevalent, that these startups found it and followed it, and it caused them to make decisions in such a way that they eventually had to bring in outside help to fix it. They ended up on a Zoom call with an advisor like me.”
If you believe that you're going to ship your org chart, then you should make an org chart that you want to ship. The differentiation that every startup has in their product, should then be reflected in their teams.
On those calls, the problem tended to reveal itself after Yu asked two simple questions:
- What do you think the team ought to focus on?
- What do they think they ought to focus on?
For most founders, Yu found their answers to the first question were clear, but the latter pulled in highly variable responses. “Their missions were really tight. They presented it at all-hands. But when people get off Zoom and sit back at their desks, the setup of these small, individually mandated squads wiped that away, or at least muddled it. They’re left wondering, ‘How does my narrow part of the product contribute to what we just heard at the all-hands meeting?’” he says.
Yu found that it’s often hard for folks to answer that question. “Because the truth is that not every part of the product surface contributes to company goals,” he says.
Breaking your team up into small parts and asking them to do mutually exclusive things and then expecting company-level focus probably isn't going to work.
“People might contort their logic in such a way where they’ve created some backward justification to connect the two,” Yu says. “So the teams tended to just keep doing what they were doing in the first place.”
He uses a silly, yet simple gardening metaphor to drive this point home. “Think of two types of tomatoes,” he says. “There are lumpy, lopsided and colorful heirloom tomatoes, designed to taste good. And then there are your typical globe tomatoes, designed entirely to look like a pretty sphere.”
Startups, he argues, can be engineered in the same way. “Startups excel when they put all their energy into one main thing,” he says. “If you want to hit escape velocity, your startup should be designed to focus on that. In other words, it better taste good. But if your startup is designed to have several teams all equal in size, where’s your focus? Where’s your center of gravity?”
If we think of the org chart as a tomato, weirdly irregular yet delicious heirloom tomatoes are the better product, not perfectly symmetrical — but ultimately bland — spheres.
In this next section, Yu zooms into this “heirloom tomato” org chart on a molecular level, putting each one of its three core elements under the microscope. He also includes tactical advice on how to pack your org chart (and, according to the logic of Conway’s Law, your product) full of flavor.
THE FOUNDER’S GUIDE TO GROWING AN HEIRLOOM ORG CHART
Shape
If Yu had the power to permanently press one piece of advice into founders’ brains, it would be to resist the very human urge to make everything symmetrical.
“When you read management books about org design, they always show you these perfectly balanced charts. Symmetrical tree diagrams and curated grids that fill up to the margins. But creating a pretty looking chart is not a KPI,” Yu says.
A nice, perfectly symmetrical org chart should raise your suspicion. Because it tends to spread your attention everywhere.
Where you should train your focus instead, he argues, is on a chart that easily communicates the core product. When considering what that looks like on paper, take three things into account:
- 1) One easy-to-spot team. Usually focused on the core product or “main thing.”
- 2) A few supporting teams with narrower scopes that are noticeably smaller in headcount.
- 3) Instead of a team dedicated to “what you’d rather not do,” distribute these responsibilities across other teams (more on this later).
“This is ugly and lopsided, but it has a point of view on what is important and what is not,” Yu says. “With an heirloom org chart, you can clearly point out where a startup’s main focus is. The startups that lose sight of the plot are the ones that drift too far away from that first column. You start with a shape that looks nice and even. And then you force fit your product into that shape. Conway's law gradually takes over and the product becomes unfocused because the team is now paying equal attention in five directions,” he says.
This inevitably impacts the product itself. “If five to eight teams are each pursuing a different mandate, you are going to end up with five to eight different products that are vaguely related,” he says.
Size
With the shape squared away, founders can now turn their attention to provisioning their teams. Unsurprisingly, there is a status quo ruling here too. Yu found that while there were some exceptions, staffing five to eight people per team was a real sticking point with founders. This sparked Yu’s curiosity. Where did this number come from? Why were so many founders so reluctant to break this pattern?
“When I ask people this, especially in Silicon Valley, the answer is often our favorite Spotify paper or a little nugget of wisdom from Jeff Bezos about two pizza box teams. Perhaps the most popular answer is a book called “High Output Management” by Andy Grove, the former CEO of Intel,” Yu says. “Now, I’ve read this book, and it has some great insights and is considered a classic for a reason. But it was written in 1983 — when Intel was on its way to becoming the premier computer chip company in the world — and as a result, it assumes the constraints of building a business in 1983.”
If you haven’t read it before, the quick synopsis is that Grove was a strong advocate for managers to have five to nine direct reports, managing them primarily through one-to-one meetings. As Yu has observed, many managers still follow these points religiously. “But CEOs like Grove lived in a very different communication environment than we do today. There was no Slack or Zoom. To get to a meeting, he probably had to be physically present. He certainly didn’t have collaborative tools like Google Docs,” he says.
Instead, Yu says, it begs the question: What would High Output Management look like if it was written today? “Now, the premier computer chip company in the world is Nvidia. And its CEO, Jensen Huang has been pretty public about his management style. He does no 1:1 meetings and has 40 direct reports. This isn't to say that 40 is the right number. But just to illustrate the fact that five to eight is not the ceiling. This number came from a specific context. When reading any sort of strategy advice, you have to think about what the context was when people created these ideas.”
When you're choosing how to size your teams, don't pick a number in a vacuum. And certainly don’t pick one because you read it in a book or a blog post, a million miles removed from its original context.
Instead, Yu directs founders back to that “main focus.” “If you’re a startup, chances are there are a few things that make your product truly different. These are the areas to over-provision. Leave enough slack on those teams. Not just to build the first version. But to deal with inevitable user feedback, maintenance, bug reports, polish,” he says. “The most differentiated aspects of your product also tend to undergo the most change. And when this happens, you incur more technical and product debt,” Yu says. Over-provisioning, he stresses, is the key to paying that debt back.
He recounts what it was like to make the initial decision to over-provision at Linear. “When a startup begins, it typically has just a single dev team, and a lot of these decisions are made as you grow. What do you do with that team? Do you split it up at every opportunity, or do you let it grow as large as you can? At Linear, we chose the latter because we prioritize software quality very highly, and we realized that adding more bandwidth and slack to the team enabled us to keep the quality level high, even though the scope of the product was increasing,” he says.
The tradeoff here, of course, is management convenience. “In practice, we’re constantly forming project teams from within the larger org — usually a designer and 2-3 engineers — giving them a mission and re-absorbing the team once they accomplish it,” Yu says. This is a lot of overhead on our management staff but it lets us course-correct very quickly. “We're not passive portfolio managers. We're making active product investment decisions constantly. We have two large strategic planning moments per year, but we're effectively re-evaluating our near-term roadmap every 3-4 weeks.”
Scope
This brings Yu to his last and final point: “The most underrated aspect of having these larger, lopsided teams is that you don't have to pre-commit to overly narrow team scopes,” Yu says. “Narrow scopes can sometimes be appropriate, or powerful, but you don't want to be forced down that path because all your teams happen to be small and equally sized.”
He shares an example from his days advising startups. “I had a client who did the thing I really lobby against, which is to have a dedicated team that works on purely back-office stuff that the customer never touches. They had a dedicated PM and designer (because they felt like they needed to make their teams symmetrical) and their admin tools were way overbuilt,” he says.
“What they should have done is just use Retool or something similar and invest the fewest possible engineering and design hours, but they ended up with a dedicated design system for just this kind of stuff, formal PRDs for no reason at all. They could literally just sit next to their users for 8 hours a day. Meanwhile, they were starved for resources in parts of their main product,” Yu says.
“Another example is a fintech company that hired a PM for every four-person eng team at the company because they needed to have that checkmark on every little unit of the org chart, so it created a self-reinforcing situation where the engineers never learned any of the domain because they always leaned on the PM to do it,” he says. “Everything was super slow because any decision had to be filtered through the PM org before it ever touched engineering.”
Yu also cautions founders about another unintended outcome; narrow scopes can foster the insidious effect of kingdom-building.
If you take ambitious people like PMs, designers and engineers, and put them in a little box, they are going to overbuild. They are going to figure out all the nooks and crannies and fill out every corner of that box, and when you’re not looking, they’ll make that product bigger.
“We've all seen this before. PMs especially are often guilty of this. They'll find every single marginal use case for their part of the product and over-optimize for them because their scope is so constrained,” Yu says.
“But this is another consequence of Conway’s Law. The org chart says they are going to work on something really specific. If you are told that your only purpose at this company is to build within the confines of a small team, and your performance is tied directly back to that one thing, you are gonna ship the heck out of that thing,” he says. “It’s their only outlet.”
So rather than slice off a handful of small teams with even numbers working on a slightly different part of the product, Yu is in favor of letting teams grow to cover a larger surface and maintain flexibility.
“Just because you can point to a component of your product, doesn’t mean you should have a dedicated team for it. Some things are pure table-stakes, the kind of stuff you want to do as little as possible,” he says. “The default number of people working on it should round to zero, and when it needs to get done, it's a responsibility that can be shared. It doesn't need to be anyone's full-time job.”
One example at Linear is integrations. GitHub, Slack, etc are all first-party integrations for the startup, but it doesn’t have a dedicated engineering team for them. Responsibility for maintaining and improving these integrations is shared. “Customer support interfaces are another example,” Yu says. “We take it very seriously, and when there’s a demonstrated need, we make sure it’s satisfied. But no one believes they are the ‘internal tools’ team.”
Founders don’t need to be afraid of a barrier to entry to get started here. There are three pillars that Yu lays out to guide them in the right direction.
Step 1: Start with the product you want to build and work backward to find the scope for your teams.
“Don't start narrow as a default and fragment your team. Instead, start by asking ‘What is the largest scope that you can give to a team and have them make reasonable trade-offs?’” he says. “It might even cover all or most of the product, and that’s okay. A team with a wide scope can fluidly shift their focus to what’s needed most in the moment, without feeling like you need to kick off a company reorg to do it.”
Step 2: Peel off narrow scopes when it’s been demonstrated that you need it.
When the tradeoffs become too hard to make, then it’s time to split the team. “Some companies have different product lines with their own P&L. That’s a great place to consider a strong team boundary,” Yu says. “A good example of this out in the wild is PostHog’s affinity for small engineering teams. It's not a great pattern if you have a single focus, but they have a portfolio of products that are all adopted separately by their users. They are independently priced and sold as separate SKUs. They are shaped very differently than the typical startup, so this kind of pattern makes sense for them.”
For teams with a single product, like Linear, slicing things off is easiest when you have a natural contour, like a technological or skill set boundary, usually at the platform level. “We're all very comfortable running separate iOS and Android teams, for instance. Infrastructure is another example of a starting point for us,” he says.
Step 3: Beyond that, if you're going to pick a narrow scope for a team, be ready to set clear limits and even conditions for disbanding or re-evaluating its purpose.
“Maybe there's some aspect of your product that you're okay with overbuilding a little because of how important and special it is to your business,” Yu says. “For example, maybe your product is more creative, and you want your team to be relatively unbounded. Overbuilding there is okay, but go into your planning process knowing that. Assume that’s going to happen, and leverage that to your product and business’s benefit.”
On top of this expectation setting ahead of time, documenting kill criteria in a written strategy can steer founders in the right direction when focus starts to get scattered. “But at some point, what these teams are working on might be done. It’s perfectly fine to say ‘Hey team, you fulfilled your purpose you don’t need to exist anymore.’”
If you're going to pick a narrow scope for a team, be ready to set clear limits and even conditions for disbanding or re-evaluating its purpose.
Ultimately, Yu says, the purpose of setting a team scope is to make sure that people on the ground can make the right tradeoffs. “Adequately sizing those teams ensures that those things get done at the quality level you expect, and the overall shape of your team keeps it aligned with your product goals,” he says. “The result is a team that reflects what you want your product to look like.”
Teams and scopes don't need to be divided along a uniform dimension. They don't need to be mutually exclusive or narrowly defined. Those are made up of constraints in service of symmetry.
CROSSING THE BRIDGE FROM THEORY TO PRACTICE
Understanding these principles is one thing, but putting them into practice is where the real challenge—and reward—lies. As with any complex system, the proof is in the implementation. To illustrate how these concepts manifest in the real world, Yu puts Linear's own organizational structure under the microscope.
Each square below represents a person. Red squares are PMs, orange are engineering leaders, blue are designers (the top one being the CEO/Head of Design) and pink are engineering ICs. Despite the rainbow array and weaving report lines, it can still be broken down into the three elements:
- Shape: On first glance, this org chart looks like an intricately woven blob. Teams are organized mainly by region, but most people are focused on the “core” product and other teams like mobile, website or infra, are quite small. Its asymmetry is intentional, you can clearly spot what the “main thing” is.
- Size: The single core product function accounts for more than 50% of staff and covers the entire product surface. Over-provisioning here is also intentional, to account for inevitable technical debt on the core product.
- Scope: There are dedicated narrow teams for native mobile apps, the website and infrastructure. Linear’s two PMs, including Yu, and engineering managers weave in and out of the teams.
Compare this to Linear’s non-EPD teams (marketing, sales, talent, etc.), which each have fewer than 10 people. “Now this particular heirloom tomato shape might not be the right configuration for your team — but almost certainly neither is the perfectly round sphere,” Yu says.
Our products are different, and it takes different organizations to build them.
There is one last piece to this that any gardener worth their salt will tell you — patience is key. Much like resisting the urge to slice off narrow scopes in the beginning, Yu tells founders that revamping an org chart doesn’t need to happen tomorrow. “If you go and do this all at once, then you now are pre-committing to something you may not want to pursue in the future,” Yu says.
“All startups and products look different from each other. So their org charts should look different from each other too. “The companies I met with didn’t know what they were supposed to look like in the future,” Yu says. “In the beginning, all these founders could do was build the most important thing and ship a great product, and that got them to a good place. They started to get customer traction and eventually fundraising. The natural next step is to start building out the team, they, understandably, get nervous.”
Yu wants founders who find themselves teetering on this edge, right at the first moment of real scale, to feel confident about following their intuition. After all, he reminds them, it’s what got them to where they are in the first place. “Follow your product, lean into that, and everything about designing a team structure will fall into place,” he says.