Nan Yu === Nan: [00:00:00] I could be aggressively, tragically wrong, and that's fine. Have some conviction around something, focus on it and let the market, kind of slap you in the face if it's not correct. Emilu: Welcome to Launchpod, a product management podcast brought to you by Logrocket. Today, our guest is NAN YU, Head of product at Linear, A purpose built tool for planning and building products. On today's episode, Non talks to LogRocket's VP of Marketing, Jeff Wharton, about being intentional with organizational design, that make products special while minimizing unnecessary complexity, and what is so important about heirloom tomatoes. So, here it is, our conversation with non you. Jeff: Hey, non, how you doing, man? Thanks for coming on today. Nan: Yeah. Great to be here, Jeff. Jeff: I'm excited. I mean linear obviously, you know, super well known well thought of our engineering team was really jealous when they found out you were coming on. So, you know, I hope I do them proud here. Nan: That's good to hear. We have a good reputation with your engineers. Jeff: Yeah, we're customers and, you know, they [00:01:00] love the product, so I'm sure they want me to pass that on. But before we jump in, you know, you've had a cool career I want to get into, but before we kind of jump into the main point of this and talk about tomatoes You know, we always like to kind of find out product management is one of the things that the role is really wide. So can you know, just briefly and succinctly describe, you know, what you think product management is or what the role PM is as if you were talking to a family member who isn't technical, you know, you're talking to like your aunt or something Nan: Yeah. You're right. I mean, there's a lot of different definitions and I think a lot of that comes from, you know, the fact that PMs kind of live in a lot of different industries at different stages of like the company, you have very different types of goals, but. So for me, right, when I'm kind of explaining it to my parents or something like that you know, I'm mostly telling them that, look, my, my job is to convince our customers or potential customers that there's a better, more efficient way of just getting their work done day to day it becomes like process management and you know, dealing with their tasks. And it's my job to convince them that there's a better way than what they're doing right now. And then to also [00:02:00] back that up by providing the tooling, right, for them to be able to do it in that new way. So that's my current sort of, you know, day to day job description. I'm sure that will change, right, as Linear kind of grows up a little bit and we get into like larger scales. Jeff: we periodically get some kind of wild answers here. So I always love asking this one, but what are three tools you can't live without? Nan: Yeah. I think my answers are going to be a little boring you know, to start with, you know, like the stuff that I live my day to day life out of, right. It's a ton of linear Slack and Google calendar. That's like 90 percent of where I actually express my work and my output. You know, but I think in terms of, you know, Sort of sharper tools that are more specific. I love clean shot. It's like a screenshotting tool on Mac OS It has a lot of just nice side features that you would want for screen capture screen recording Let's do like do a bunch of annotation and draw boxes and arrows and stuff like that on top of your screenshots So whenever I'm like reporting a bug or suggesting a change to a screen or something like that It's just like default to all use. It's like the it's like my design [00:03:00] tool almost. Jeff: Nice. Yeah, it's it's interesting. I feel like when you are a little early in your career, maybe there's a lot of kind of point tools and stuff. You use a lot more, but I've found that similarly, I'm in Slack pretty much all day. Zoom unfortunately, cause you know, teams are always kind of distributed all over. But yeah, the calendar, right? Like without that, I have no idea where I'm going, what I'm doing, which might actually be good. Might actually cause me to do less meetings and get more work done, but who knows? So, All right let's dive into kind of the main crux of the thing here, right? You've had a really cool career across several, you know, great companies. You've touched a lot of different kind of things from D to C e commerce to linear, which is, you know, B2B kind of, productivity, product management app. And through that, you recently were over at Figma's conference, and you talked about your ideas for org design and basically talked about how most startups are doing it wrong. And what they should do is think about it like an heirloom tomato. When I saw it, I kind of had a couple of [00:04:00] really tight takeaways. I want to make sure I got this right. Cause if people want to see it, go check out on YouTube. It's on Figma's channel, I believe. Fantastic talk. It's great. It goes quick. can I reiterate it back as like, be intentional with your org as you are with your product. Don't worry about being normal, be right for your product, over invest in what makes you special and don't be afraid to change as you need to. Nan: Yeah I think those are good takeaways from it. And the thing that really ties it together is you kind of have to believe in a Conway's law, right? It's this thing that, you know, I'm sure a lot of people have heard about it. And it basically says that the way that you set up your communication structures within your organization, so basically your org chart, it's going to really have a direct impact on what your product is going to end up looking like, right, and fighting it is really hard because who people talk to to day. You know, that really determines who they collaborate with. That determines, you know, if they're responsible for different parts of the product, those products, those parts of the product are going to, they're going to work together a lot better, a lot more smoothly. So [00:05:00] where you put up walls, you're going to have a big, your customers are going to see it, right? They're going to see the separation of your teams just reflected in how your product works. So what you should do is you should treat. Your org design as a product design problem, right? It's not an HR problem, right? People look at, Oh, it's a pure HR problem. You know, we're a fast moving startup. We don't have time for that stuff. You know, we gotta get going and start writing code or whatever. And it's just like, yeah you do, right. But you, the first step in determining what your product is going to look like is probably going to be, you know, how are the people who are building that product, how are they communicating with each other? So that setup is upstream of all of that. And I think that's something where people kind of. Miss that a lot, right? They want to do something like normal or standard for their for the product. And it ends up being something that they have to fight against when they're trying to make the product that they actually want. Jeff: Yeah. And that's the problem, right? This is you start to get people who are experienced in building products, maybe not in teams. And so they look to kind of, I guess the normal, what is seen as normal advice here or kind of what everyone else is doing. And that seems [00:06:00] to be one of the big parts is you need to customize around yourself, not around, you know, kind of the average, no regression to the mean here. Now, like I said you were at several, you know, really interesting companies with a good degree of variance across those. And it seems like you talk about why this is important. Is if you're going to be a startup, you know, you have to be really special at something, right? You have to be highly differentiated. You have to bring something super high value to get people to kind of make a switch in a way that gives you the exit velocity. Rather than just kind of going backwards and going through biography of your time, maybe we can kind of hear more about how you got here. By talking about some of the companies you were at and kind of examples of this idea of, I guess, to use the tomato analogy that you use, the special thing has to taste really good. So can you walk us through a little bit from some of the past companies, how how your thing tasted really good at, you know, maybe like Everlane or mode or anything like that. Nan: Yeah, totally. I mean, [00:07:00] Evelyn's a great example, right? And I think it's, you know, it's where I formed a lot of these ideas originally. It's where I kind of learned about, you know, what it really takes to break through the noise, right. To get, you know, kind of unreasonably good growth really fast. Yeah. And, you know, for us there, everything was focused around category launches, right? We started off, you know, way back in 2011, we started off with as a, as like a t shirt company. And today it's a full, you know, it's sort of like a full line, men's and women's like e commerce brand, right? Like a fashion brand. And the journey to get there was You know, kind of this very steady March of of category launches, right? And then some categories were smaller than others and some were bigger than others, but like whatever we were working on, the next category launch was always the most important thing. And it had to hit. And every single time we hit, we saw the numbers go way up. And if we missed, then things would be flat. And we had invested a bunch of, you know, a bunch into something that didn't really affect the the growth trajectory. And that [00:08:00] relentless focus, you know, got us through. The first five, six years of the company's existence, right. And it, you know, gave us like the real strong growth that we needed to like become, you know, almost effectively like a mall brand to some degree, right. So like to be on the same, you know, sort of mentioned list, if you're going to mention like gap or J crew or something like that, something where everyone knows those brands, right. We had to go from nothing to that in five years, instead of like gap, which started in like the sixties or something like that, right. Like it was, we had to really just accelerate and get to that point much faster than a brand had done in the past. Jeff: And what did the product team look like there? I guess, what did the, you know, not product team, but the entire team look like they're kind of on the build side. Where were you guys focused or what enabled you to focus on kind of those category launches? So. You know, so just spot on. Nan: The team itself, you know, we had engineering, we had design, we had product. It looked like a very normal tech company. On that side, but you know, the way that we thought about our work was like, okay, what's the next category? Like, you know, what is it going to be? What changes do we have to make to the core product to really support it? Right. So when we went into [00:09:00] you know, when we entered like denim or something like that, it was like, okay, we had to, we have to make, you know, kind of size comparison things like on the website. Cause we have a bunch of different cuts and stuff like that. And we hadn't had that before for something like t shirts. So all of the different product changes were sort of downstream from whatever the major launch category was. and when you go into major categories like shirting or denim or shoes or whatnot, right? Like you have to make sure that you're really supporting that particular product, both on the sort of e commerce side, but also on the marketing side, like, what does it mean to market for this kind of stuff? What kind of sort of digital experiences do we need to build to support it? , so the way that, you know, we think about it Right. It's almost like, here's a timeline. What's next major launch that we're doing? What are the sort of direct things that we need to support? Like the launch the day of, and then what are the sort of. You know, kind of e commerce enabling pieces. And then what are the merchandising pieces that we need to build in order to enable that e commerce experience? Right. So everything kind of culminated into like a single point launch. Jeff: Yeah. And do you remember, were there [00:10:00] things you know, cause I think we've seen this, we, I like to think we at log rocket kind of run very similarly where we do very strict planning when we're trying to line up what we're going to do on a monthly or kind of whatever our run rate time timeline is where. We look at, you know, we want to do all these things. Let's prioritize the few that are going to have the biggest impact or most important and spend just a disproportionate or almost all of our time there. And what that inevitably leads to is people feeling like, Oh, we need to do this too. We need to do this too. We need to do this too. And you kind of have to explain why you don't have to do those things. Were there kind of regular things that came up that. you know, maybe people felt like they were worried about or, you know, it seemed like they were going undone that just didn't fit in that. Like the magic of Everlane wasn't the core thing. So you felt pretty confident in just pushing it off. Nan: You know, like when I gave this talk, I had a very specific audience in mind, right? It was startups who had, you know, maybe found their initial traction and they wanted to like figure out like what to do next. Right. They [00:11:00] have money now they have, you know, they have income. They have maybe they raised a couple of rounds or something. So like, how do we, you know, how do we deploy those resources in a way that makes sense? And and like, you're still not a big company, you can't do everything under the sun. So something is going to feel uncomfortable because you're like, well, it would be nice to be able to do this feature. It would be nice to be able to try this marketing idea or whatever. That's not our main thing right now. So the right thing to do is to actively decide to not do that. And. And that's, you know, that, that decision is something you have to make over and over again. So as much as anything, you know, the idea of a main thing, it's like, here is a decision making framework that says like, how are we going to get to our next objective? Right? Our next objective is to get to this much revenue, or this many customers, or this many daily active users, or whatever it happens to be. And here's the plan to get there. So if it doesn't contribute to that plan, what, you know, the mindset that we should have is like, how do we figure out how to not do that? Right. What are the things we can do to put that off? We might do things that don't scale. You might [00:12:00] do things like manually that could be automated, but like they're not, it's not quite the time yet or whatever. But like, that's the game. And then the, on the other side of it, right. For the main thing, the game is like what can we do to make the main thing even better, to make us more differentiated from, you know, the competition to, to rise out of the seat the sea of noise, right. That we live in from a marketing perspective. So those two things combined really to kind of help startups get from, we have initial traction to, we have really solid growth. Jeff: Yeah. The way I try and communicate it to my team is you only have, right. You only have X amount of time. We've raised a bunch of money. And so maybe we're not money bounded immediately, but your time bounded always, you know, we only have X amount of time and you can't get more. And everything you say yes to is something else you said no to by definition. And you can add more things, but kind of work in progress kills. Everything if you have too much, what I tell them is you know, anything worth half assing, we're not going to do and everything we do has to have a whole ass on it. It always gets a little snicker because, you know, but but the idea is, you know, if we're not gonna do [00:13:00] it all the way, if we're not gonna do it great, we're not gonna do it. And that means you have to figure out what's really important to do really well. So I loved your, I loved this talk. It resonated so hard with me and it was fantastic to see. You know, kind of what has been bumping around in my head really catalyzed really well from you. But also good to know that like, you know, marketing's not the only one who suffers from that kind of shiny object syndrome. So, can we go the converse? Have you ever seen, I guess, or where have you seen this kind of org set up? Maybe not deployed well where it was uniform. And what did that turn into? Nan: One of the jobs that I had where there was a moment I worked with this company called abstract and it you know, it's like a, sort of like a version control system for sketch files. So it was kind of trying to be like GitHub for design, right? That was like the kind of major goal. And. There, there was a moment there where, you know, a bunch of new management kind of came in and they wanted to like change some stuff and no they set up the team in sort of such, in such a way where you have these sort of very evenly balanced teams, each kind of focused on a different area of concentration [00:14:00] that we're all mutually exclusive from each other. And, you know, and like looking back on it, right. Like, to be really honest, it was probably not the right thing to do. Because at that point we ended up doing a whole bunch of things at once that were almost like siloed from each other. They like didn't interact in a way that was that was really cohesive. But I think more importantly, we probably over invested in some areas that didn't need it. And like, that's the real danger of doing this kind of stuff where, you know, if you have two teams that are equal, you're saying like, look, I'm going to have 50 percent of the sort of effort distributed across these two things. And you're making a very strong assumption that they are equally important. And like, that's almost always not the case, right? At Everlane, the only thing that was important was the next category, launch launch right? You can sacrifice everything else. If the next category launch goes well, numbers go up, we raise more money, we get more customers, whatever it happens to be, right? Like That's the only thing that [00:15:00] matters. So that you can literally have everything else be held together with duct tape and it's okay. And I think that's the, that's an uncomfortable sort of sort of mindset for for people to adopt really. Jeff: Yeah. That's a difficult part is them feeling like stuff is only done halfway and you're like, yeah, it is. That's fine. It's done as good as it needs to be. And no more. You talk a lot about being intentional with the org design. And that, you know, you also mentioned It's really hard to unwind this once you go down the path of kind of like equal boxes of kind of org pods. The converse though, is you have to probably be a little bit more intentional upfront. I guess, is that an accurate way of looking at it? Like, do you have to do more planning? What goes into kind of the upfront piece here to make sure you're kind of hitting this right two or three years out even. Nan: Yeah. You know, you're saying like, Hey, where does the rubber actually be the road on this? And I think that's a astute observation, right? Because again, you're, This is a very specific audience. You are, you're a startup. You're trying to go from nothing to [00:16:00] something amazing. And in order to do that, you can't just like have a passive portfolio management attitude about it. I think what ends up happening is people kind of look at it. They're like, well, you know what I do with my personal wealth or whatever it is. It's like, I put in a bunch of index funds. They're all kind of sitting there and they're all growing at a comfortable rate. And I can just, you know, kind of hands off. Like, that's not how you want to manage this kind of investment. Right. In terms of like where you put your effort to grow your product. You have to be an active manager. You have to be in the details and understanding all of the reasoning behind the directions that people are making. And like, even if you're saying like, look, I want my teams to be able to have a bunch of autonomy, that's fine. But at the end of the day, you know, as a leader, you own the decisions that they're making. So it has to fit together and be cohesive. And I think what ends up happening when people, you know, split these teams up and they give them like sort of like equal weight is they're saying like, well, I don't know which one's more important, right? They're deciding to not take an opinion. They're deciding not to take a stand. [00:17:00] They're kind of abdicating their sort of their responsibility to, differentiate their their product. And I think that's that's sort of like a truth that you have to accept, right? That you have to take responsibility. As a leader for saying like, here's where we're going to be great and really differentiate and, you know, and kind of rise above the market. And I could be wrong, right? Like, but that's not, I could be aggressively, tragically wrong, and that's fine. You, that's actually probably better, right? You want to know for sure that you're wrong and that you can switch, you can, you know, switch directions and do whatever, right? You that's a failing fast is a thing that we want to do. It's not like, oh, well, we're gonna, we're gonna wait and see. We're gonna wait and see on everything. It's like, no. No, pick, have some conviction around something, focus on it and let the market, you know, kind of slap you in the face if it's not correct, because then at least, you know, like, okay, well, we got to go somewhere else. I, Jeff: Yeah, I think that is such a great kind of point right there is right you need the opinion need you need to come in with a viewpoint you're a [00:18:00] startup, you need to if you need to hit escape velocity, you're not going to do it by being boring, you're not going to be everything to everyone be opinionated go take the risk. Because you're definitely going to fail the other way. If you kind of like peanut butter it, you know, you're going to fall down, take the risk where it's big pay big payoff, you know, big risk. But like you said, you can pivot, you can change, you can make a new bet, but you never learned that if you don't start. So, one thing I was kind of wondering as I listened to this is you talk a lot about, you know, Have the team that you can redistribute regularly redistribute the team as you, you know, you guys at Everlane were doing is all about category launches until it wasn't, I assume. But you have this team here that now you maybe need to reorganize or change around, or maybe you were changing them around during that time. I'm sure linear you know, The scope of your product has greatly increased over the past, you know, years, how do you maintain a team that kind of has enough context and enough depth in areas to be able to drive continuity and [00:19:00] continue to, you know, build great product, but also is able to kind of pick up and move to different piece and move to different piece and maybe, you know, Sub to that like how do you think about you know, people very specialized skill sets maybe people who you know I assume you have a couple infrastructure engineers or you have people specialized in ios or android or different mobile frameworks Something like that. I Nan: you know, what I wanted to do this talk and the message I wanted to convey was like, look, there's some places where having specialized teams is an obvious answer, right? When you talk about infrastructure, iOS, things like that, like there's a very specific technical skillset that you want. You have a narrow goal to sort of begin with. And it's, there's a natural contours, right? That makes sense for those folks. That's not where the difficulty is, right? The difficulty is when you have a pool of maybe like generalist engineers, which is like what every startup starts with. And that pool is kind of getting continuously bigger and you have a large product surface and then you have to make some decisions about how you're going to [00:20:00] manage that. And, it's like a fairytale that you can tell yourself about. Like, well, I can split up my. My my product into these sort of, you know, sub components, you know, kind of different use cases or something like that. And then we can have like a different team, you know, nice and tidy kind of handle that use case. And it's not even always wrong, right? There's, that's true in some subset of cases. You know, like, this, there's this really great company called post hoc. They, you know, they wrote this they wrote this blog post recently about how a postdoc is like nine different products. All kind of living side by side and they're all sold individually and price individually and stuff like that. So yeah, if you have that, then like you have nine lines of business. You can have nine different teams that each focus on it. That's like completely fine, right? That's a natural contour. But creating sort of these artificial distinctions because it's like convenient for you as a manager, like that's where people end up getting themselves into a lot of trouble. And, you know, so when you're thinking about like how to set up your your teams, like how did your customer think about your products? Yeah. You know, our customers have to use our whole product. If they don't [00:21:00] get to like choose some subset and be like, this is the only part I, you know, I interact with, right. They're forced to interact with most, if not all of the products, because if they're, because it's how they do their job, so we should be able to keep it in our heads too. Right. Our sales team has to sell, they have to pitch the entire product. They don't get to just sell this little tiny portion of it. Right. Our support team has to answer questions about any part of the product that comes in. They don't get to just pick one subsection of it. So I think as product developers, we, you know, we kind of have to own that, like, if it's too complex for us to think about all at once, it's probably too complex for our customers to think about all at once. So like, that's, you know, that's also one of these other areas where there's a lot of like customers can see this. Right. If they see your product and they see one area that's like obviously built by one team and it works in one way and there's another area which is obviously built by another team or it's a completely different way, you don't even understand that you have that complexity baked into your product yourself because no one person like sees it from that customer perspective, the customer, it's like obvious to them. [00:22:00] So, you know, we, I think if you want to hold all those things constant you really have to kind of commit this idea of like, it's totally acceptable and expected. Right. For the product development team to like understand the entire surface of the product simultaneously. Jeff: think you just said potentially the Most motivating line you could have which is come on guys if sales can do it. You guys can do it Although I love our sales team. So, I, you know, I digress on that, but I feel like that is a good prodding one. You can, you know, engineers start to claim that they're too special as you've sales knows the whole product. So you got to know it too, guys. Let's go. Come on, folks. I have so many questions kind of off of this piece right here. So I'm going to try to not, you know, sit here with, sit here for the next three hours with you and take it the rest of your day, but kind of on this, right. There is kind of conventional wisdom, you know, I think high output management made this famous and a couple of other books about kind of size of team from a ratio of contributor to manager, right. And they all [00:23:00] say it's, you know, six to eight people per manager, or, you know, there's some wisdom that all floats around about that given what we've talked about here, you know, you could very easily end up with a balance is, you know, 20 to one or more than that. I guess how do you think about that in this situation? Like, how do you ensure that you have the kind of leadership set up where you can support that? Because I don't think that's necessarily a bad thing, but how do you, how have you guys at at Linear kind of made sure that you can support these uneven teams where someone might be supporting a lot more Contributors and others. Nan: Yeah. I, you know, there's this thing that we all understand as like engineers, that work will expand to fit the space., you see teams where there's like a product manager per five or six engineers or something like that, right? It's like a very low ratio. And what will end up happening is a couple of things, right? One, they're going to maybe create a bunch of work for themselves because they have to like justify their existence. But there's another aspect of it, which is engineers will tend to check out a little bit from understanding how the product actually works, understanding the [00:24:00] customer, that sort of thing, because, well, we got this PM senior right here and I don't want them to feel like I'm like doing their job, right? I don't want to like step on their toes. You know, it's not out of laziness necessarily, right? It's more out of like, well, this is someone's job description. So, you know, it's, it wouldn't feel right for me to do that. And then you start having this like learned helplessness. As soon as like a customer has a question about the product or like complaint, but they file a bug even, and then, you know, like, well, I don't know how to interpret it. I would ask the PM what to do. So I think that dynamic is like. Probably way more dangerous than a product manager being overworked. You know, a product manager being overworked, there's a very clear solution and it's solvable. Hire another product manager, right? Like you have a problem, there's your solution. If you end up in a state where your engineering team is like disengaged and they have like learned helplessness, like good luck trying to unwind that. That is a cultural change that you're not going to observe until it's too late and it's very difficult to to reverse and it takes a long time. Jeff: So, I mean, it seems like we keep going back to once you kind of get, there are certain tipping points once you get to, they're hard to [00:25:00] come back from. So work hard to prevent those and kind of only hire once you really see the need versus kind of anticipating or trying to land in these kind of pre structured, you know, ratios. I mean, not even to mention what the CEO of Nvidia Jensen Huang has what, like 40 reports. Is it now 60 was the last I heard or something insane. Nan: Something like that. And like, look, that, that is a special case, right? He's a CEO, all his reports are very like independent and stuff like that. But I think that, you know, take a book like high output management, right? And hopefully the, you know, the audience has read that book on it. They haven't, I really do recommend it. And it's, you know, it's a, it's considered a classic. If there's a lot of good stuff in there, but the good stuff is really about like the principles that are driving. A lot of the decision making. Right? The principle that Andy Grove talks about in high output management is really focused on, like, look, as a manager, you're not doing IC work. So your output, like, why is it called high output management? Your output is based on the output of your team that you're [00:26:00] directly responsible for, plus all of the adjacent teams that you influence. Okay, so like, accept that as the axiom. Now, here's a bunch of techniques to get the best output from your team. And then we, and then, you know, for him, the best output with the best techniques were like, do a bunch of one on one meetings, you know, don't have more than like eight or nine reports, you know, because you have to do one on one meetings with all of them all the time. So like, you know, your schedule is going to be destroyed if you have more than that money and all of this stuff, but all of this stuff is in service of that original principle. So, but then like people read the book and like, look, they don't pay that much attention to it or whatever. They like pull out, Oh, great. Eight reports done check. I can do that. That's a tangible thing that I can do. But they kind of freak, they kind of lose sight of this idea about like. You know, the whole point of doing this is the output of my team is my output. So like one of the ways you can get a lot more output is you can hire a bunch of people, have a much bigger team, right? You can get a lot more output that way. But like, there's a limit, there's a natural limit on that based on how much, you know, your communication channels or whatever. But our communication channels are different now. We have, we're much, you know, we're able to do a, like a lot of good mass communication, you know, async communication, all that kind of stuff. So. You know, [00:27:00] as long as you're able to achieve that core principle, it doesn't really actually matter how many direct reports you have or how big your team is right? Like the answer should be like as big as I can possibly support. Jeff: Yeah, let me like the ratio is there as an example, not as a burnt in the wood truth. So yeah, I love kind of the general sense talking to you that it always goes back to think about what you're trying to accomplish, set yourself up to do that in the best way possible. Understand the concept, but don't die on the kind of like. Detail that maybe was written down or specified or something else that some that worked for someone else. What works for you to accomplish your big goal that makes your startup special in this case? So how do you, I assume there's not just like one linear team at this point. There's probably breakouts and at least one or two subgroups. How do you kind of hit that point? Or how do you make that decision? It's time to carve off some resources. Where does that come in? Are you guys just still one big. You know, group that kind of just functions really well. Nan: [00:28:00] We're basically one big group that functions really well. But in all honesty we are right. And there, there are some soft boundaries and the soft boundaries are more related to practical ideas. Like we, you know, we have a bunch of team members in Europe. You know, we're very, you know, our founders are all finished. So there's a big sort of European footprint that we have. And just from a time zone perspective, it's a lot more convenient for the Americans that kind of all work together and for the Europeans that work together on most projects. Yeah. So there's some soft boundaries there, but there's not like, you know, a boundary of like product understanding or a boundary of like, here's the part of the code base where I absolutely can't touch or something like that. So, you know, in a lot of, and also certainly our product management team, like we, you know, we both, we kind of like work with engineers on both sides. So we were, you know, we're kind of independent of that. Yeah, so there it's effectively one main team, right? We have separate teams for infrastructure and for iOS. For Android, right? Those are, you know, kind of, again, I said like natural kind of you know, carve outs, but other than those extremely specific, you [00:29:00] know, specializations, yeah, it's all one big team. Jeff: And so I guess drawing the difference between a functional team that owns an area versus for this period of time, you're in a smaller group that's working on this area just to drive a specific outcome, maybe a launch of a specific. functionality, but you are still part of this team that owns the whole product. You don't own this area. This is just where your work is focused for a little bit. Nan: Yeah, exactly. And we have this rotation, for example you know, you know, people have different kinds of like on call rotations and we have a rotation we call goalie and it's basically, you know, the sort of defensive mechanism that we have to feel like bug reports and small feature requests and things like that. And those will come from any odd direction, right? Any part of the product, any, you know, any piece of functionality, whatever. And then whoever happens to be goalie needs to figure out what to do with it. So that's, you know, it's almost like an exercise to be like, okay, like, you know, pop quiz, something's going to happen. You better have some way to, you know, dive into that area and figure it out. Jeff: It ensures that everyone has the breadth across the product that we talked [00:30:00] about, right? Cause you, you might have to prove it at some point, so be ready. Okay. That that makes a lot of sense. I kinda, kinda love the idea that, you know, It gives you the ability to redeploy quickly as you need to if new priorities come up because you do have this breadth of knowledge across the team. Nan: Yeah. I want something. Yeah, I want to say something very specific about that, right? Because, you know, in some places I've been in the past and during my consulting time, some of the companies I saw, one of the big problems, one of the big sort of distinct problems that they run into is they go like, well, there's a, there's this main thing, but it's covered by this team and it's only 40 percent of our resources. And so we can't put any more people on it. And it's like, why just make the decision to say like, that doesn't matter, put these other people on it. If they can, you know, if they're able to do the work. And. You know, and it's just, it's this very almost like social boundary that we put into place when we split teams up and having like own certain product areas, you know, like there are situations in which that is appropriate, but if you find yourself feeling [00:31:00] bad that there's this boundary, you're unable to cross it, then like, you should just decide to not have the boundary, right? Like you've set, that's a signal that you have set the boundary incorrectly. And I think that's the hump that everyone kind of needs to get over. Jeff: This is going to be a reference that is probably out of left field. But it reminds me, you know, growing up in in the eighties and nineties, right. Is when the Disney movie Aladdin came out and like, they go through a whole bunch of hijinks and craziness, but at the end. Basically, Aladdin has proven himself and, you know, he's won over the princess and the sultan loves him and everything and he saved the kingdom. And yet they go, Oh, but you guys can't get married. Sorry. You're not a prince. And the sultan's like, Oh, what are we going to do? You're in charge. Nan: in charge, you made the rule. Jeff: yeah, the Aladdin principle right here. Right. Just, you can change that team, put someone else on it if you want to, it's that important. One more question. I have this and then, you know, let's move on. But [00:32:00] what about you? You kind of mentioned, you know, focus on things that make you special, right? Do the things you want to do to continue to drive forward that thing that differentiates you. and Just focus relentlessly and do as much of that as possible. But there are always these kind of like, Checkbox things, especially as you grow as an organ you need to maybe sell more into the enterprise you know some companies have bigger, you know You want to sell to health care companies now and you need to be able to sign a baa or you need to do role based access control and this list goes on and on and some of these have solutions. You can just buy off the shelf, right? Like off zero great exists but how do you think about this? As a kind of problem about they're not the things you want to do. They don't make you special. They just check a box and make you purchasable in a new segment. And some of them you can buy, like I said, but some of them you might not be able to like, where's this fit in? Nan: . It's like any other project that, that we build, right. Whether we're building a feature or we're building you know, a specific sort of table stakes, a feature that is demanded by, you know, like larger enterprise customers. It's. It's a very well defined goal. So [00:33:00] ask a small team of people to go work on it. And then when it's done, they don't have to think about it anymore. And like, , that is the ideal outcome, right? When you think about there are things that make your business special, and there are things that are, you know, things that you should feel very reluctant that you have to do them, right? It should feel bad that you have to do this stuff. So the stuff that you feel bad about your, the game that you want to play is to do it as little as you possibly can, right? You have to do whatever it is that it takes to enable the business to sell into these, you know, kind of target customers or whatever, right? But the amount you want to do is as little as possible. If you tie people's self identity to be like, this is your team's charter. You're the skim, you know, like Samuel team or whatever. Okay, I guess, I guess my job is to do the SCIM SAML as much as I can, as much as possible. It's like, no, that's not, that is WorkOS's job, right? That's not your job. Your job is to do it as little as possible because that's not what you're, [00:34:00] that's not what your business is. Your business is, you know, like selling clothes. Your business is making productivity software or whatever it happens to be. Jeff: Maybe this is the best exit, right? This is taking your point and moving to the extreme of just these things that are clearly not core to business. You would never have, at least I hope not. That I don't know, I don't know a single company has a role based access control team or anything like that. Right. It's something, you know, you have to do. And like you said, you do it, you check it and you move on, you get out as fast as possible. So it seems like people already understand this principle. They just are too, they are worried about expanding it to the rest of their team and kind of expanding how they think about other parts that maybe aren't so binarily obvious.. So as much as I love tomatoes and I do think the analogy you drew there, heirloom tomato org chart is great. It's spot on and tells exactly what it is. I won't move on and talk maybe a little bit about linear itself, if that's cool. Because Nan: Yeah, of course. Jeff: you guys have a lot of really neat kind of cultural and operational things you that have just set you apart that I have just been so damn curious [00:35:00] about. And I have you here now. So, A, like,, I went through , a decade and a half ago at this point of running a team where we ended up using Asana and so on and so forth. And it seems like at some point, you know, there was the opinion a little bit that like project management is a solved issue. You know, there, there was a while where there wasn't a lot of new solutions coming online, or at least none that were really blowing up. Then you guys came along and just exploded like and I love your take on this, right? Your goal with linear is to, you know, help make sure that everyone's focusing as much as they can. On their main thing, right? Like you want everyone's day to day experience to be great. You had a great story here about, you know, you guys loved writing software when you were younger. And then in some, somewhere along the line, it got not fun, but like a, how did you come in to this industry with the idea that like, we can bring something in to this problem that we can change? And then what are the vital pieces of the kind of culture and process and everything that you guys do to deliver on this? Nan: I like [00:36:00] your framing about, you know, is this not a solved problem? It seems like there's these legacy solutions that have been around forever. There's a whole, there's a bunch of like newer generation ones that all kind of do the same thing. And, you know, I think that's, you know, that's certainly something that people would ask before they like invest in the company or, you know, when we talk to candidates and they ask that too, right? They're like, well, how do you know, does it, you know, does success look like you just become Jira? Like, what does the success look like? And I think the best way to sort of illustrate it is the experience that we have talking to inch managers and product managers when we're doing kind of discovery calls, right? We'll ask them these questions around like, Oh, tell me about, you know, your team's planning process, or tell me about how you manage projects. And they'll, they're ready to talk about it, right? They're like, okay, we got this set up. We've got this customization. We've got this, you know, automation, whatever, right? They'll talk about all this stuff and then show us all the spreadsheets and things. And then we'll ask them, okay, so think about the last project that you just launched or the last quarter that you planned or whatever it is. Did you do that? The thing that you just told me that this is your [00:37:00] process? And a hundred times out of a hundred answers, Oh no, we weren't even close. Like we got, we did maybe half of that, right? Like, you know, this is, it was all a pipe dream, right? To start with. And it's because, yeah, like I, I know, cause like you have some idea about what your ideal is and reality never seems to match it because you know, for a lot of reasons, right. A big part of it is that, you know, it's often very hard for you to orchestrate everyone to do the right thing because no one knows what the right thing is. You had to invent the right thing. Your process at your company and then tell everyone to do it and like get it into their brain so that they press the right buttons in the right order and they didn't like ruin your customizations, all that stuff. There's so many things that have to go right in order to actually achieve the thing that you had in your head. And. We want to take a sort of different approach, right? Because if you look at a lot of these companies that try, they're like, Oh yeah, people don't really love, you know, JIRA that much. So we can come in and compete. And then the PM, you know, puts on their like good PM hat and they go, well, we're going to listen to customers and see what they want. And then someone's going to be like, Oh, my ideal situation is this. And they're like, great, [00:38:00] we'll give you a way to achieve your ideal situation. And pretty soon, like inch by inch, you end up becoming the thing that you were there to displace in the first place. Because every single time you give people those customizations and those, you know, like little minute like configuration options, you make it a little bit harder for all of the ICs who have to engage with this thing to like know what they're even supposed to do, right? Like we talked to companies, this comes like, Oh yeah, well, we have 150 custom fields in, you know, in JIRA that we just, we're like, Okay. Yeah. And then it's like, it's it person's like, yeah. Like we have these, we, you know, we have to, in order to transition, we got to preserve all of them. I'm like, do you like what percentage of people even know what any of those mean, right? And then we'd like asked around just to survey on their behalf, right. Pull in a bunch of engineers and engine managers and like, Oh yeah, we have no idea what these things are. They're just their legacy. They're there. Someone added them and just like, it's like accumulated cruft. So, but [00:39:00] like all of those things, like someone thought that was their ideal. Right. At some point, at some moment in time, someone thought that was our ideal. And it turns out that it was just hurting them right in the long run. So what we're trying to do, right? Our thesis is that like, we are here to help you in the short term, be really fast, because there's no figuring out what you're supposed to do. Everything's very natural and intuitive. And in the long run, you're not accumulating a whole bunch of cruft because someone at some moment thought this was their ideal outcome. And now you have to deal with the ramifications of it, right? So hopefully by adopting linear, you're both winning in the short term and the long term. Jeff: Yeah, that would have been wonderful. I just remember I have nightmares of one tool we were using I won't name it but at a past company where no one would update anything because it would take 45 minutes to update a ticket or to put in a new ticket because you had to not just write the description and put it where it is in the process, but you had to write all these kind of sub things that, or fill out, you know, check boxes or pick dropdown menus or you know, dah, that no one ever used, but it was [00:40:00] required to do it. And you couldn't turn it off because there was a central admin. Who's like, Oh no, this team needs this one. And this team needs this one. And, but we have no way to rationally do it by team. So we just, everyone has to do all of them, even if it doesn't matter. So nothing, it just didn't get used. It was shelf where But it was like functional shelfware where no one even realized it was shelfware. Nan: And it's a sort of false promise, right? That a lot of people take on this. Because, you know, this idea is like, well, you know, if I just had this extra thing that I required everyone to fill in, then I could report on that extra thing. I can get you this nice chart that's sliced by that thing. And that's the ideal. But the reality is no one knows what the thing is. So anytime someone chooses an item from the dropdown, it's because they just want to get past the required field so they can hit submit on the issue, right? So it's like, it's a completely garbage field that you have, that all the data is unreliable in the first place. Cause no one knows what it's really there for. And. The sort of final, the final sort of step in any of these issues is someone has to write the code, they make the pull request, they merge it, and then it's in your product now, and then the issue, it just like doesn't matter anymore, right? It's like, you know, you [00:41:00] might need it for reference or whatever, but all of that stuff doesn't matter. So what we're trying to do is get you to like a merged pull request way faster than you otherwise would get to. Jeff: That's the and that's the key, right? Like, if you are a software product, and everyone, what I have realized from being at log rocket now you know, I've been in software for a long time, but this is, you know, One of the most widely utilized products I've been at is that every company is a software company now. And so everyone needs to think about how do you know, if you can get a pull request out a little bit faster, if you can ship that feature a little bit faster and multiply that over teams and engineers and all the resources you threw up building these great products, your velocity skyrockets with small optimizations potentially. So, yeah, this is, I mean, this is such an interesting thing, right. And I guess that kind of goes back to or. I guess it shows up in, you know, linear is famously an opinionated organization, right? You have the product you're building and you've gotten, I'm sure hundreds of [00:42:00] requests for custom fields and this, and just add this one thing. And it seems like almost always linear says no. And. Yet you're still growing really fast. So, I guess back to your point, you know, you find ways around around those things to do the core thing. And you're clearly picking the right things to focus on, but I guess is that where that kind of comes from is you know, people ask for maybe that point thing or that one thing to make it perfect. And the rationale is no, because of this, or is there a different thought behind Nan: Yeah, I think that's mainly the case. We're very sensitive to introducing any features that are basically. Like that let like a middle manager express some ideal scenario that they hope to achieve, but in reality adds friction to the day to day life of an individual contributor, right? If anything has that dynamic, it is we really like question it a lot. And so when, you know, when we see stuff it's, you know, I think everything is kind of viewed through, through that lens. And, you know, [00:43:00] the way that you become very similar to incumbents or very similar to, you know, even the sort of next generation after them that kind of have ended up in a sort of similar space is you keep saying yes to that kind of a request and then you just become no different and people have the same problems, right? It might go, it might be a little more performant, but you know, the real enabler of velocity is you just have to do fewer things in the first place. Jeff: I heard you really successfully put this you were talking about it on another podcast. I think you were on Basically, you don't want people spending their day in linear at least their whole day, right? You want people to not even realize necessarily that they're spending time there Focus on your job and create something that allows them to focus on their job better. Nan: Yeah, absolutely. It's, you know, people talk about, Hey, what metrics do you use and stuff? I'm like, it's like, it's hard to do metrics. Like time and app is not necessarily a good metric for everyone. Jeff: Okay, we're running short time and I have one thing i've desperately wanted to find out about about linear and it's work trials. How does this work? Like I get the benefit I get the benefit on both sides, right? [00:44:00] You as a hire, I get to try someone out and make sure that they're, you know, capable, which is really hard to do in an interview. For them, they get to test out a new org and culturally make sure it makes sense. Which is also great because I think we've all probably had that time that we went into a new company and just almost instantly have buyers regret. Functionally, how does that work? Right? Like, so you, Someone comes in like maybe people are between jobs and that's a great, you know, that's a great time But that's probably the exception. How does that work? Like how do you negotiate this kind of like three to five day period where someone's gonna come in and do this? They can't just tell their job. Like I'm gonna go do a work trial. I Nan: Yeah, totally. Look we try to be as flexible as we possibly can with people's needs and their schedules and things. So, you know, we've done all sorts of variations on this where we, you know, put a couple of days in the weekend, if it's a bunch of IC work that they have to do anyway you know, normally what people do is they just take some PTO and we, look, our work trials are fully compensated, right? At a competitive rate. We are basically just buying people's PTO from them. We're like, look, can we buy some PTO from you? [00:45:00] And and I think what's really underrated, like people look at it and the people who kind of scoff at it are say things like, well, I would never spend that much time on a job that I wasn't sure I wanted. And. if you're not sure that you want it, because there's an interview process before this, and if at that point you're not like, this is the place for me, then that's fine. Right. Like that, you should have just made a decision not to proceed in the process anyway. But for the people who like really do or like are interested, like we want. In the long run, we're trying to reduce our employee churn, right? Employee churn comes from two situations. One, it's like, Oh, this wasn't the right fit. We have to unfortunately let them go. But another one is like, they're like, you know, this wasn't the right place for me. I thought it was, but it turns out that after just, you know, you know, interacting with everyone and working real closely with people, like we just don't get along or whatever. And like, that's such a big risk to employees because, you know, You know, people stay at places a long time because it's just like so much of a hassle to find a new job because like, you know, you, especially if you want some stability for your family and stuff like that. [00:46:00] And I think that the folks that really get it, they look at it as like an opportunity. Like, yeah, I'm willing to sell you three days of my PTO to have certainty that this is actually a move I want to make. Because the downside of making the wrong choices, I quit this job that I was fine at before. Thank you Right. And like upended my entire work and maybe family life in order to do a thing. And now I have buyers remorse and I have to go start the process all over again. And we do not want people to be in that situation. So, you know, I think for us, it's like it's largely that it's like motivating it, Jeff: It's funny. I think it's something people are often skeptical about. But when you kind of frame it that way, it's just like, God, thank you for making this better like that. It makes sense. And you know, it seems like a really, you know, employee but also employer centric way of just making sure that like, yeah, I always kind of talk early interviews, but let's find if there's a match both ways here. And it seems like it's just that kind of really tested to the max. And how do you ensure that you're really doing that which I think is a great thing. You know, how you want motivated people [00:47:00] there who want to be there. And you want people happy, which means if they find out it's wrong, like better find out early, right fail fast back to that idea. Well, no, it was fantastic having you on. I mean, I know we're running out of time here. I you're busy. I don't want to take up too much of your day. Yeah. So I mean, while I have a million more questions, maybe we can have you on again sometime later, but I appreciate you coming on. Thanks for joining. Is there anywhere, you know, if someone's looking to reach out, you know, LinkedIn or Twitter or something, what's the best way to shoot you a note? Nan: Twitter's probably the most reliable. My handle is the non you, T H E N A N Y U. And then my linear email is very guessable. It's my first name at linear. app. Jeff: Oh, wow. That's brave of you giving that out. Nan: well, you know, I mean, plenty of people have guessed. Jeff: Like you said, as guests, I mean, that's the problem with the first name at is not too hard to find. So awesome. Well, thanks, man. I appreciate you coming on. This is a blast. And yeah, I hope to talk to you again soon. Nan: Yeah, that's terrific. Thanks, Jeff.