[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]