Config 2024: The heirloom tomato org chart (Nan Yu, Head of Product, Linear)

Summary

The speaker shares insights on startup org chart structures, critiquing the uniformity inspired by the 2012 Spotify model. They discuss the importance of aligning team structure with product goals, emphasizing the pitfalls of symmetrical team setups and advocating for a more purposeful, asymmetrical approach that reflects the unique needs of each product. The talk highlights the impact of Conway's Law, the challenges of scaling, and the necessity of making informed, context-aware decisions when structuring teams for optimal productivity.

Takeaways

• 📈 The importance of org charts in startups is often underestimated, but they play a crucial role in shaping the product and the company's direction.
• 🌐 The speaker observed a lack of variance in team structures across early and mid-stage startups, often defaulting to a model inspired by Spotify's 2012 paper without fully understanding its context or applicability.
• 🔍 The speaker's experience with startups revealed that team structures often led to a loss of focus and increased technical and product debt, contrary to the intended efficiency.
• 🤔 The key question posed is whether the current team structure truly supports the company's goals and whether team members understand how their work aligns with the company's broader objectives.
• 💡 Conway's Law is highlighted as a significant principle, suggesting that the structure of a company's team will reflect in the product it develops, emphasizing the need for a well-thought-out team organization.
• 📉 The danger of symmetrical team structures is pointed out, as they can dilute focus and lead to a product that lacks a clear main feature or direction.
• 🛠 The speaker advocates for org charts that reflect the actual shape and needs of the product, rather than following a one-size-fits-all approach.
• 🚀 Resisting the urge to create symmetrical org charts is crucial for startups aiming to focus on their main product offering and avoid spreading resources too thin.
• 📚 Historical references, such as the 'two-pizza rule' and 'high output management', are not absolute and should be critically evaluated in the context of modern communication and work practices.
• 💬 The speaker emphasizes the need for clear communication and understanding within teams, ensuring that everyone is aligned with the company's goals and their role in achieving them.
• 🌟 The conclusion encourages founders and companies to trust their intuition, start with a clear understanding of their product, and shape their org chart around that vision.

Q & A

What is the main topic of the talk in the transcript?

The main topic of the talk is the structure of organizational charts (org charts) in startups and how they can impact product development.

Why is the speaker passionate about org charts?

The speaker is passionate about org charts because they are one of their pet interests and they have spent a lot of time thinking about them and observing their impact on various startups.

What was the speaker's observation about team structures in early and mid-stage startups?

The speaker observed very little variance in team structures across early and mid-stage startups, with most teams being small, cross-functional, and covering a narrow scope of their product.

What common structure did the speaker find in many startups?

The speaker found that many startups followed a structure similar to what was described in a paper by Spotify in 2012, which included terms like squads, tribes, and chapters.

What problem did the speaker identify with the widespread adoption of the Spotify model?

The problem identified was that many startups adopted the Spotify model without considering whether it was suitable for their specific circumstances, leading to issues such as slower progress, lack of focus, and accumulation of technical and product debt.

What is Conway's Law and how does it relate to team structure?

Conway's Law states that the structure of a company's product will reflect the structure of its team. If teams are set up in a certain way, the product will likely mirror that structure.

Why did the speaker suggest that startups should resist the urge to make everything symmetrical in their team structure?

The speaker suggested that startups should resist making everything symmetrical because it can lead to the dilution of focus and resources, which is counterproductive to the main goal of the product.

What is the significance of the 'two-pizza rule' mentioned in the transcript?

The 'two-pizza rule' is a principle from Amazon that suggests a team should be small enough to be fed with two pizzas, implying that a team should not exceed a certain size to maintain efficiency and communication.

What is the speaker's view on the number of direct reports a manager should have?

The speaker believes that the number of direct reports a manager should have is not a fixed number like the commonly cited 5 to 8, but should be determined based on the context and needs of the startup.

Why did the speaker suggest that startups should start with a clear understanding of their product shape and then structure their teams accordingly?

The speaker suggested this approach because it allows startups to make purposeful decisions about team structure that align with their product goals, rather than following generic advice that may not suit their specific situation.

What is the speaker's advice on how to handle teams that are focused on less important or 'table stakes' aspects of the product?

The speaker advises that the default number of people working on less important aspects should be zero, and only assign team members to these tasks when absolutely necessary, to avoid overbuilding and maintain focus on differentiating features.

Outlines

00:00

📈 The Impact of Org Charts on Startups

The speaker begins by expressing surprise at the audience's interest in org charts, a topic they're passionate about. They recount their experience working with startups across various industries and stages, noting a lack of diversity in team structures. Early and mid-stage startups often default to small, cross-functional teams, a trend they attribute to the influence of a 2012 Spotify paper widely cited in management literature. The speaker criticizes this uniformity, suggesting it leads to slower progress and technical/product debt, and proposes that companies should critically evaluate and tailor their team structures to better align with their unique needs and goals.

05:00

🔍 The Dilemma of Team Structure and Focus

This paragraph delves into the disconnect between company leadership's clear objectives and the teams' ability to align with these goals. The speaker discusses how the narrow focus of small teams can lead to confusion and a lack of contribution to broader company goals, referencing Conway's Law to illustrate how team structure influences product development. They argue against the addition of complex systems like OKRs to address this issue, advocating instead for a reevaluation of team structure to ensure it reflects the desired product outcome, and caution against the instinct to create symmetrical, balanced teams that may not serve the product's needs.

10:03

🛠 The Challenge of Team Size and Provisioning

The speaker addresses the common misconception about team size, particularly the adherence to the '5 to 8' team member rule, which they trace back to outdated management wisdom and the constraints of the 1980s. They contrast this with modern examples, such as Nvidia's management style, to highlight the need for context-appropriate team structuring. The speaker suggests that startups should consider over-provisioning their main teams to handle user feedback, maintenance, and to manage technical debt, while being cautious about pre-committing to narrow scopes that may not be necessary.

15:04

🎯 The Importance of Team Scoping and Product Focus

The speaker emphasizes the importance of team scoping, suggesting that teams should be given the largest possible scope to make reasonable trade-offs. They warn against the tendency to create narrow scopes that can lead to 'kingdom building' and over-optimization of minor features. The speaker advises startups to start with a broad team scope and only introduce narrow scopes when there's a clear need, avoiding the pre-commitment to structures that may not be beneficial. They also touch on the challenges of morale and development when teams are assigned to less desirable tasks, advocating for a dynamic approach to team composition.

20:04

🚀 Conclusion: The Origin and Evolution of Team Structures

In the concluding paragraph, the speaker reflects on the initial stages of startups, where the focus is on shipping the main product aggressively due to limited resources. As companies grow and resources increase, they often seek external advice, which can lead to the adoption of standardized team structures that may not be optimal. The speaker encourages startups to trust their initial intuition, understand what makes their product unique, and let that guide their org chart and team structure decisions, rather than relying solely on conventional wisdom or widely circulated management theories.

Keywords

💡Org charts

Org charts, short for organizational charts, are visual representations of the hierarchy and structure within an organization. In the video, the speaker discusses the importance of org charts in startups and how they can influence the development and direction of a product. The speaker's career has been deeply rooted in building startups, and org charts are a central theme of the talk.

💡Conway's Law

Conway's Law is a principle that states that the structure of a system reflects the structure of the organization that built it. The speaker uses this law to explain how team structures can inadvertently shape the final product, emphasizing the importance of aligning team organization with product goals.

💡Cross-functional teams

Cross-functional teams are groups composed of individuals from different areas of expertise, working together to achieve a common goal. The speaker mentions these teams in the context of startups, where they often cover a narrow scope of the product, which can lead to inefficiencies or misalignment with overall company objectives.

💡Spotify model

The Spotify model refers to a particular approach to organizing teams within a company, which was popularized by the music streaming service Spotify. The speaker discusses how many startups adopt this model without considering its fit with their own unique circumstances, leading to potential issues.

💡Squads, Tribes, and Chapters

These terms are part of the Spotify model for organizing teams. 'Squads' are small, cross-functional teams; 'Tribes' are groups of squads; and 'Chapters' are communities of professionals with similar skills. The speaker notes that these terms are often adopted without a clear understanding of their purpose or effectiveness.

💡Technical and product debt

Technical and product debt refer to the accumulation of work that needs to be revisited or redone, often due to shortcuts taken during development. The speaker mentions that startups following certain team structures can find themselves overwhelmed by this debt, which can slow progress and focus.

💡OKRs (Objectives and Key Results)

OKRs are a goal-setting framework used by organizations to align and track progress towards objectives. The speaker discusses how some companies attempt to layer OKRs onto their existing team structures to improve focus and alignment, but this can add complexity without addressing underlying structural issues.

💡Over-provisioning

Over-provisioning, in the context of team organization, means allocating more resources (e.g., team members) to a task or area than might be considered 'necessary'. The speaker argues that over-provisioning can be beneficial for startups to ensure they can effectively develop and iterate on their main product, paying down technical debt and maintaining momentum.

💡Two-pizza rule

The two-pizza rule is a principle that suggests a team should be small enough that two pizzas could feed the entire group, implying a limit on team size for optimal communication and efficiency. The speaker critiques the adherence to this rule, suggesting that it may not always be the best fit for a startup's needs.

💡High Output Management

High Output Management is a book by Andrew S. Grove that offers management strategies, including the recommendation for managers to have no more than 5 to 8 direct reports. The speaker reflects on the relevance of this advice in the modern context of startups, where communication tools and work styles have evolved.

💡Nvidia

Nvidia is a technology company known for its graphics processing units (GPUs) and artificial intelligence technologies. The speaker mentions Nvidia as an example of a company that may have a different approach to team organization and management, with the CEO reportedly having a large number of direct reports, challenging traditional management advice.

Highlights

Speaker's passion for org charts and their impact on startups.

Observation of little variance in team structures across early and mid-stage startups.

Common team structure influenced by a 2012 paper from Spotify.

Startups implementing team structures without fully understanding their context or suitability.

Problems arising from the adoption of the 'squads and tribes' model, leading to slower progress and technical/product debt.

Importance of aligning team structure with company goals and the product's main focus.

Conway's Law and its implications for product development based on team structure.

Critique of the tendency to create symmetrical org charts without considering the product's needs.

The fallacy of the 'two-pizza rule' and the need to critically assess the context of management advice.

Over-provisioning teams to handle user feedback, maintenance, and iterative development.

The risk of 'kingdom building' when teams are given too narrow a scope.

Strategic team scoping to allow for better trade-offs and less overbuilding.

The challenge of disbanding teams that have fulfilled their purpose.

The benefits of starting with a clear understanding of the product's main differentiator before structuring teams.

The example of Linear's org chart, organized by region with a core product function.

Encouragement for founders to trust their intuition and product understanding when structuring teams.

Final thoughts on the importance of shaping the org chart around the product, not the other way around.

Transcripts

[Music]

I'm very impressed that everyone showed

up to hear a talk about org charts of

all things so uh you know it's one of

the um it's one of my pet uh it's one of

my pet things that I really think about

a lot and hopefully uh you know this is

a subject that you might have uh a more

you know well-developed or stronger

opinion on uh after this talk so I want

to start with a story that's really

rooted my career uh I've spent most of

it building startups at different stages

uh across different Industries I worked

on everything from uh direct consumer

Brands to uh design tools and business

intelligence and now uh developer

productivity and in between my last two

roles

I took some extended time off to uh you

know work with some Founders and and

startups um you know across the bay and

also around the world uh to uh help them

you know solve their problems and for me

this was an opportunity to apply my

experience a little more widely but also

to learn from people um I wanted to see

how uh you know how different people

solved different kinds of problems and

uh came to different solutions and and

really what they took for granted

and when uh when I did this I saw a lot

of variance in things like uh their Tex

Stacks um like you would expect uh in

things like go to market and even in

fundraising strategy uh but something uh

kind of surprised me which was uh there

was very little variance in team

structure uh this is mostly early and

mid-stage startups and when I asked why

uh they chose this um particular uh this

particular structure this is the same

basic setup that I I saw

you know everywhere right you would have

these uh these very small teams that

they would be cross functional and you

know maybe you have a PM on each team um

and they would they would cover a very

narrow scope of their product and when I

asked folks why they chose this setup

the answers were not entirely satisfying

um either this was just the way they

like did it before or they did some

Googling and they or they read some

management books even um and often the

response that I heard was hey we we saw

this paper uh that was written by some

Spotify guys in 2012 and I'm you are

laughing because you've seen this paper

right this paper is everywhere um it's

constantly getting referenced in blog

posts and like content marketing pieces

and those pieces themselves are getting

re-referenced by other things uh so it

just becomes like self-perpetuating in

fact if you ask chat jpt how should I

structure my startups epd team the

answer it will come back with like 50%

of the time it's going to have you know

somewhat unique sounding terms like

squads and tribes and chapters and

guilds these are terminology that is

directly from this paper and the

companies I would work with they would

you know this is what they get back and

they would implement the stuff that

sounded reasonable you know the the more

exotic stuff they would just kind of

ignore and then what they would end up

with right was this uh the structure

that we kept seeing and part of the

reason I'm here with you today is almost

like an SEO thing because I want

companies and and Founders in this

position to have maybe something else

for the for them to reference right not

the same thing over and over again um

hopefully something that's like a little

more applicable to their

circumstance because these companies

they don't look anything like Spotify

right they're not even close in terms of

even Spotify 2012 they're not even close

in terms of scale or trajectory or

culture but especially product but the

information that they found is so widely

available and it's just everywhere so

they found it they followed it and it

kind of got them into a little bit of

trouble and that's where they ended up

calling me um and you don't go out of

your way to do this unless you're having

a lot of difficulty and that's really

hard for you to crack and the difficulty

I kept hearing from these companies was

hey we added a bunch of people then

somehow we got slower right we're moving

more slowly than before um or I can't

get the team to focus on anything we're

just going in so many different

directions at once and on top of this

we're kind of drowning in Technical and

product debt

and uh you know when when people told me

this it was almost with like this sense

of nostalgia or like lost because there

was still institutional memory at these

places of what it felt like to be very

fast and focused and not be drowning in

debt uh but they changed the way they

operated and this is where they ended up

so to help diagnose the the problem you

know we just start by asking simple

questions like well what do you think

right as a leader of the company what do

you think the team ought to focus on and

conversely

if you ask the same question what do

they think they ought to focus on and to

leadership of these companies the answer

in their heads at least was very clear

they gave you know very tight all hands

presentations on like what the next goal

was um and what the next major objective

was and here's the metrics you want to

look at but then as as people would get

back to their desks or off of Zoom you

know depending on your culture um you

know this setup would kind of take what

they just heard and and confuse it or

muddle it or or weaken it

uh because it was often hard to answer

the question how does my little narrow

part of the product surface actually

contribute to the thing we just we just

heard at the All Hands meeting um and

what often would happen is they would

say like well you know I'm going to try

to find some backwards way to contort my

logic to get it to make sense and they

would just end up doing what they were

doing in the first

place what these Founders really

discovered was that if you break up your

team into little bits right and ask them

each to just cover a very narrow scope

uh that's you know pretty much mutually

exclusive from the other teams and then

you you want to like tell them the focus

it's probably it's probably not going to

work because they ran head first into

this thing uh that I'm sure you've heard

of called Conway's

law which you know there's a lot of

words to describe it right but at its

very core what it really says is if you

uh if you have a structure for your team

that's set up in a certain way that the

your product is going to look very

similar to it right this is so

referenced in Silicon Valley that it's

almost like a meme but I still don't I

still don't think we take it seriously

enough because at its core it's really a

Saye you will ship your or chart right

however your team is structured will be

reflected directly into your product so

if you have like five to eight squads

each pursuing a different mandate you're

going to you're not going to ship one

product you're going to ship five to

eight vaguely related products

and this uh you know this is something

that some Founders actually really

recognize they're like oh I see what's

going on thanks for helping me diagnose

um so we're going to we're going to do

this thing we're going to layer on like

okrs or something right we're going to

we're going to add some goal setting uh

layer on top of uh on top of the teams

and hopefully we'll patch things

together that way but the problem now is

that if you're going to add okrs to the

situation now you have to learn how to

calibrate them right then well you got

to have metrics so let's start you know

instrumenting all the things and we got

to hire data analyst to like analyze

what we just collected and what did we

what were we even what were we even

doing in the first place and the the

problem here is that they were trying to

solve a situation that was already too

complex by layering on even more

complexity and uh that was never going

to work so what we ended up doing

instead was kind of taking it back right

where look let's start with Conway's law

and let's really take it seriously and

if you believe like if you truly believe

that you're going to ship your or chart

then make an or chart that you actually

want to ship you can make very very

purposeful decisions not mindless ones

not ones you read on the Internet or you

know you just accept because that's just

what you've seen before you can make

very purposeful decisions on uh how you

want to address the the shape the size

and the scope of all of your development

teams so that you actually do end up

reflecting what you want to

build and uh this is what we're going to

talk about today so we're going to start

with shape and uh if there's one

takeaway of from this that I want you to

have uh it's going to sound a little

stupid is that you have to really resist

this very human urge to like make

everything symmetrical right you know

there's a lot of designers in the room

if you see something that's a little bit

out of place it's not really balanced

I'm just going to fiddle with it until

it is like that is not that is not how

you want to like design your teams and

uh the problem is when you read

management books or papers or block

posts or whatever uh they always show

you charts that look like this right

they're perfectly balanced they're like

binary trees or little pyramids or like

perfect grids or whatever um but this is

not the goal right having pretty looking

charts is not your kpi if the the Ora

chart is a tool that's designed for a

purpose if you take these two tomatoes

one of them is designed to taste good

and the other one is designed to be a

sphere and depending on which one you

choose right you're going to have a

different outcome if you're a startup

and you're trying to hit escape velocity

your product probably has one main thing

and that main thing it better taste good

you might have a couple of supporting

things or some other stuff you really

wish you didn't have to do but if your

or chart looks perfectly symmetrical

like this then that should really make

you suspicious because where's the main

thing right this this is going to spread

your attention everywhere and it's what

happens when we fall in love with

symmetry you start with a shape that

looks really nice and even and then you

force fit your product into that shape

right like if you if you have an even

shape you're saying like look I'm going

to divide my product into even parts

does your product want to be divided

into even parts or does it have one main

thing if you do this Conway's lot takes

over and now the team gets some focus in

they paying equal attention in like five

directions now if you take something

ugly and sort of lopsided looking like

this then hey at least it has a point of

view you can read out what is the main

thing what is the supporting thing and

what do you wish you didn't have to do

and when when you have this situation it

ends up being shaped like ideally like

how your product is actually shaped the

biggest thing to notice here is there's

just a ton of variation in size of these

teams and some teams are going to be

over provisioned right to provide you a

lot of bandwidth and some teams are

under-provisioned you can't have the

teams all be 5 to8 people and in

practice this was quite a sticking point

with uh with teams I worked with because

um they got really stuck on this number

58 they kept hearing it everywhere and

then you know it was just something that

uh they they thought was like a default

and uh again when you ask when you just

ask the follow-up question like well why

like where did you hear this number from

the answers are going to be like either

our favorite Spotify paper or uh there's

some there's a there's a little bit of

wisdom right that we've all heard before

about two pizza box teams right from

from like Amazon and uh and then some

some you know sources had a little bit

more gravitas uh there's this book

called high output management which is

very widely recommended uh in our

industry um I've read that book I'm sure

a lot of you have as well it has a lot

of great insights um and it's considered

a classic for a reason but it was also

written in 1983 when intel was really

ascending and it was like the hottest

chip company in the world um and as a

result it will also assume the

constraints of 1983 Andy Andy Grove the

author he uh advocated for you know uh

very strongly for managers to manage

primarily through one-on-one meetings uh

and if you're going to do that you can't

really have a ton of direct reports so

you know he really recommended 5 to n

direct reports as the as the range and

uh and sometimes we will read books like

this and we're going to follow those

those specific points you know almost

religiously but Andy lived in a very

different communication environment when

he wrote this book right he didn't have

slack or Zoom he had to go to a meeting

it had to be in person or maybe on a

landline or something um there certainly

wasn't like shared documents like Google

Docs or figma or

linear

and what would high output management

look like if was written today right in

2024 and know the hottest ship company

was Nvidia and uh you know the Nvidia

CEO Jensen hang has been talking a lot

about his management style right he's

he's said stuff like uh I have no direct

reports sorry I have no one-on-one

meetings I have 40 direct reports right

different sources will say different

things like 40 or 60 or whatever um this

isn't to say that 40 is the right number

or that eight is the wrong one but

Eight's probably not the ceiling right

all of these numbers they come from uh

like a context and you have to think

about what the context was when people

you know created these ideas what was

the reasoning behind them and then

really try to critically apply them to

your own right you can't just take a

little nugget of wisdom that's a million

miles removed from its original source

and just assume that it's going to work

for you if you're a startup your context

is probably this right there's a very

specific thing that differentiates your

product there are only a few things that

really need to be great and you should

really consider over provisioning these

things you have to have enough people

not just to build the first version but

to also deal with all of the inevitable

user feedback and maintenance and Bug

reports and polish and all this

iterative stuff that we do we're not

shipping CDs anymore so when you do that

you're also going to accumulate a lot of

Technical and product debt and that's

how it happens so over-provisioning your

main thing can also help you pay that

debt back and as a side note like

something that uh people ask us all the

time at linear is like how do we

maintain such a high quality bar um you

know often we get asked by

candidates or or users or something and

a big part of it is this we will

sometimes crank our main teams almost

all the way to full debt payback mode

and we can do this and we can be very

comfortable in the uh in the tradeoff

here because we have enough people where

we can still leave uh you know a few

folks to to carry the change lock

forward right we don't have to like

totally kill our momentum and being

comfortable in this trade-off is

probably one of the biggest uh benefits

of over-provisioning teams is that you

don't have to pre-commit to Really

really narrow Scopes and uh and that's

also one of the effects that you see

when you have this very symmetrical

small team kind of system is that every

team has to really pre-commit to a bunch

of narrow Scopes and these can be

appropriate sometimes or very powerful

when when used correctly but uh if

you're do if you do it like this you're

going to force the teams to just pick

that without really uh knowing if it's

needed or not and what ends up happening

is Naros Scopes create a lot of uh a lot

of Kingdom building right like it has

this like potential because if you take

ambitious people like PMs and designers

and engineers and you put put them in a

little box we're just going to overbuild

it right we're going to we're going to

figure out all the nooks and crannies

and fill every single corner of that box

and then like when you're not looking

secretly make the Box bigger and that

we've all experienced this right like

I'm a PM like we are we are the most

guilty of this uh we'll you know hey

here's our product surface let's find

some little use case that we heard from

One customer let's over optimize the

heck out of it and uh and we do that

only because our scope is so constraint

right we have no other Outlet to to sort

of Feed the

ambition this is a consequence of law

because if the or chart says that hey

your identity and your purpose at this

company is going to be really tied into

this one thing U and your your

performance review is going to know

about it you're probably going to ship

the heck out of the

thing and you can avoid all these

problems in the first place by starting

from the shape of the product that you

want to have and then trying to scope

your teams that way this is very hard to

unwind after it's already happened so

it's really best if you can try to avoid

the problem in the first

place and there's a few ways to do that

the the simplest way

uh is something I'm sure we all do which

is hey let's find some technical or uh

skill set boundary that makes sense and

we can just slice off a team for that

we're all very comfortable with like

separate iOS or Android teams and stuff

um another thing that you can do right

if you have a Naros scope is to set very

very clear limits and conditions for

maybe even disbanding the team sometimes

they they might just be done right it is

perfectly fine to say like hey team

you've fulfilled your purpose you can

just you know you don't need to exist

anymore that's fine um and if you're

going to you know let a team be

relatively unbounded and you know decide

that hey overbuilding is okay this is

probably most applicable in more sort of

like creative areas uh go into it

knowing that right just assume that it's

going to happen and if you can leverage

that and make that into a benefit for

your uh for your product and for your

business like that's fine too um but the

question I would really start with

before any of

this is what is the largest scope that

you can give to a team and have them

make reasonable tradeoffs right it might

start by covering all or most of the

products Al together and uh once you

start there you can start slicing off

narrow Scopes as you really demonstrate

a need for them right you don't have to

you can do it one at a time over a long

period of time you don't have to just

say like hey today we're one giant team

and tomorrow we're going to split it all

up right because doing that will

pre-commit you to a whole bunch of stuff

that you don't even know if you need yet

and causes really weird effects and one

of the weird effects I'm sure you've all

seen is you have like a team that's uh

dedicated to stuff you'd rather not do

right whatever you want to call them you

give a euphemistic name like the the

platform team or something like that

like whatever it is that you call it and

um and what ends up happening is uh one

it's not really great for morale like

everyone knows that this is the stuff we

don't want to do it's like table Stakes

it's not differentiating it's not really

important to our product um but also

we're just really tempted to just shove

all the junior developers onto that team

and just say like oh yeah go go go play

here you're not going to do it do much

damage and uh and that's it's not great

for their development they don't get to

work on anything important

um instead right really consider that

the default number of people that works

on that'sit not important should be zero

and then when other teams need to make a

tradeoff to say like hey we absolutely

need to do this we have to kind of put

down our main thing and do this okay

great like that's that's a good forcing

function to really understand what you

the minimum that you need to do uh this

is an area where you definitely do not

want to be

overbuilding so uh the purpose

ultimately right of scoping teams is to

really let the let the team members make

good tradeoffs on the ground giving them

an adequate size lets you deliver on the

quality promise that your customers want

and uh the overall shape of your team

hopefully results in something that is

actually shaped like how you want your

product to

look everything else right everything

else all these other considerations of

making good-looking or charts or having

equally sized teams or picking a single

Dimension that every team has to be

split on all of this stuff is in service

of symmetry and it's basically a false

constraint you don't need to do it and

uh I'm going to show you an example

right so for us at linear this is what

our this is what our or chart looks like

and the main organizing function is

actually by region it's not even by

product surface um but there is a core

product function that slices across both

regions and it accounts for over 50% of

our staff we have narrow teams sliced

out for uh for the mobile apps for uh

the website and for infra um and if you

add our managers and the reporting lines

into here it starts to look like a

really densely woven blob um this is

never going to look good on the

two-dimensional chart it's not a

two-dimensional problem it's not a two

dimensional solution it's not a two

dimensional outcome uh this is just what

our product looks like right and it's

it's great for our customers what they

experience is a network of very

intricately uh related features and a

very rapidly developing mobile app on

the side this may or may not be the

right configuration for your team at

your company but almost certainly

neither is this all of our products they

look very different from each other

we're going to require very different

looking organizations to support them

and I'll conclude with this and I want

to bring it really back to the original

motivation for this right because the

companies that I met with during my time

Consulting they started off not knowing

what they were supposed to do or

supposed to look like all they could do

is decide what the main thing was focus

on shipping it and just do it

aggressively because that's the only

choice they had and that got them to a

pretty good place right they found

traction they raised money they hired

people and then they got really nervous

cuz all of a sudden they have a whole

bunch of resources they didn't have

before so they like asked Google what

should we

do and what I hope that we you know the

stuff that we talked about today I hope

that it gives them a little point of

light and really the the confidence to

follow the same intuition that got them

there in the first place which is to

start from your product really

understand what makes you different lean

into that and then everything else

including your orc chart can follow from

there thank you very much

[Music]