Nan Yu
===

Jeff: [00:00:00] Hey, non, how you doing, man? Thanks for coming on today.

Nan: Yeah. Great to be here, Jeff.

Jeff: I'm excited. Linear obviously, super well known, our engineering team was really jealous when they found out you were coming on. 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, they love the product, so I'm sure they want me to pass that on. You've had a cool career I want to get into, but before we jump into the main point of this and talk about tomatoes we always like to find out product management is one of the things that the role is really wide.

So can just briefly describe, 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're talking to like your aunt or something

Nan: Yeah. You're right. There's a lot of different definitions and I think a lot of that comes from, the fact that PMs live in a lot of different industries at different stages of the company, you have very different types of goals, but. So for me when I'm explaining it to my parents or something like that I'm mostly telling them that, look, my, my job is to convince our customers or our potential customers that there's a better, more efficient way [00:01:00] of just getting their work done day to day.

It comes to like process management and 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 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, 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: I think my answers are going to be a little boring. To start with, like the stuff that I live my day to day life out of it's a ton of linear Slack and Google calendar. That's 90 percent of where I actually express my work and my output. But I think in terms of.

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 you like, do a bunch of annotation, draw boxes and arrows and stuff like that on top of your screenshots.

So whenever I'm [00:02:00] like reporting a bug or suggesting a change to a screen or something like that, it's just like default tool I use. , it's like my design tool almost.

Jeff: Yeah, it's interesting. Let's dive into kind of the main crux of the thing here, right?

You've had a really cool career across several, great companies, you've touched a lot of different kind of things from D to C, to linear, which is, b2b kind of productivity product management app. And through that you recently were over at figmas 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 had a couple of really tight takeaways. 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. Not as a fantastic speaker, but basically can I reiterate it back as 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 [00:03:00] need to.

Nan: Yeah I think those are good takeaways from it. And. The thing that really ties it together is you have to believe in Conway's law, right? It's this thing that, 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 right?

And fighting it is really hard because who people talk to you day to day, that really determines who they collaborate with that determines. If they're responsible for different parts of the product, those product, those parts of the product they're going to work together a lot better, a lot more smoothly.

So where you put up walls, you're going to have a big, your customers are going to see it. 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. We're a fast moving startup. We don't have time for that stuff. We got to get going and start writing code or whatever. And it's just yeah you do, but you, the first [00:04:00] step in determining what your product is going to look like is probably going to be, 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 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 I guess the normal, what is seen as normal advice here or what everyone else is doing. And that seems to be one of the big parts is.

You need to customize it around yourself, not around, the average, no regression to the mean here. Now, like I said you were at several, 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 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 [00:05:00] to make a switch In a way that gives you the exit velocity Rather than just going backwards and going through biography of your time Maybe we can hear more about how you got here By talking about some of the companies you were at and examples of this idea of, 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 your thing tasted really good at, maybe like Everlane or mode or anything like that.

Nan: Everland's a great example, right? And I think , it's where I formed a lot of these ideas originally. It's where I learned about, what it really takes to break through the noise, to get, unreasonably good growth really fast.

And, for us there, everything was focused around. Category launches, right? We started off, way back in 2011, we started off with as a, as like a t shirt company and today it's 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. This very [00:06:00] steady March 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 into something that didn't really affect the growth trajectory. And that relentless focus, got us through. The first five, six years of the company's existence, and it, gave us like the real strong growth that we needed to become, almost effectively like a mall brand to some degree, so like to be on the same, mention list, if you're going to mention like gap or J crew or something like that, something where everyone knows those brands, 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. 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 team look like they're on the build side. Where were you guys focused or what enabled you to focus on kind of those category launches?

Nan: you know, it was more a matter of, the team itself, we had engineering, we had design, we [00:07:00] had product, it looked like a very normal tech company on that side, but, the way that we thought about our work was like, okay, what's the next category what is it going to be, what changes do we have to make to the core product to really support it?

So when we entered like denim or something like that, it was like, okay, , we have to make, 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 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 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, we think about it. Is 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 e commerce enabling pieces, and then what are the merchandising pieces that we need to build in order to [00:08:00] enable that e commerce experience, right?

So everything culminated into a single point launch.

Jeff: I like to think we at LogRocket 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 whatever our run rate time timeline is, where we look at, 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 have to explain why you don't have to do those things.

Were there regular things that came up that. Maybe people felt like they were worried about or, 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: Yeah. And when I gave this talk. I had a very specific audience in mind, right? It was startups who had, maybe found their initial traction and they wanted to figure out like what to do next, right? They have money now. They have income.

Maybe they [00:09:00] raised a couple of rounds or something. So how do we deploy those resources in a way that makes sense? And 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 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. But that's not our main thing right now. So the right thing to do is to actively decide to not do that. And. that decision is something you have to make over and over again. So as much as anything, the idea of a main thing, it's here is a decision making framework that says like, how are we going to get to our next objective?

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, the mindset that we should have is like, how do we figure out how to not do that?

What are the things we can do to put that off? We might do things that don't scale. You might do things like manually that could be automated, but like they're not, it's not quite the time yet or whatever. But that's the game. And then the, on the other side of it, for the main [00:10:00] thing, the game is like what can we do to make the main thing even better, to make us more differentiated from, the competition to, to rise out of the sea of noise, that we live in from a marketing perspective. So those two things combined really to help startups get from, we have initial traction to, we have really solid growth. Yeah.

Jeff: to my team is 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, 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 work in progress kills. Everything. If you have too much, what I tell them is anything worth half assing, we're not going to do. And everything we do has to have a whole ass on it. And it always gets a little snicker but the idea is, if we're not going to do it all the way, if we're not going to do it great, we're not going to do it.

And that means you have to figure out what's really important to do really well. So , I loved this talk. It resonated so hard with me and it was fantastic to see what has been bumping around in my head really catalyzed really well from you. But also good to know [00:11:00] that marketing's not the only one who suffers from that kind of shiny object syndrome.

Can we go the converse? 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: I'll talk about, one of the jobs that I had where there was a moment there where, a bunch of new management kind of came in and they wanted to change some stuff and they set up the team , in such a way where you have these sort of very evenly balanced teams, each kind of focused on a different area of concentration that we're all mutually exclusive from each other.

and like looking back on it, 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 really cohesive.

But I think more importantly, we probably over invested in some areas that didn't need it. And that's the real danger of doing this kind of stuff where, if you have two teams that are equal, you're saying like, look, I'm going to have 50%. Effort distributed across these two things.

[00:12:00] And you're making a very strong assumption that they are equally important and that's almost always not the case, right? At Everlane, the only thing that was important was the next category, right? You can sacrifice everything else at the next category launch goes well, numbers go up, we raise more money, we get more customers, whatever it happens to be.

That's the only thing that matters. So like you can literally have everything else be held together with duct tape and it's okay. And I think , that's an uncomfortable sort of mindset for people to adopt really.

Jeff: 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 also mentioned. It's really hard to unwind this.

Once you go down the path of like equal boxes of org pods. The converse though, is you have to probably be a little bit more intentional upfront. That an accurate way of looking at it? Do you have to do more planning? What goes into kind of the upfront [00:13:00] piece here to make sure you're hitting this right two or three years out even.

Nan: Yeah. Yeah. I think that, 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, \ , This is a very specific audience. , you're a startup. You're trying to go from nothing to something amazing.

And in order to do that, you can't just have a passive portfolio management attitude about it. I think what ends up happening is people look at it. They're like you know what I do with my personal wealth or whatever it is, like I put in a bunch of index funds, they're all sitting there and they're all growing at a comfortable rate.

And I can just, you know, kind of hands off. That's not how you want to manage this kind of investment. 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 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, 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 [00:14:00] happening when people, split these teams up.

And they give them like like equal weight is they're saying like 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. They're abdicating their sort of their responsibility to differentiate their product.

And I think that's that's like a truth that you have to accept, right? That you have to take responsibility. As a leader for saying here's where we're gonna be great and really differentiate and, and rise above the market. And I could be wrong, right?

That's the other side. I could be aggressively tragically wrong. And that's fine. You, that's actually probably better, right? You wanna know for sure that you're wrong and that you can switch, directions and do whatever right failing fast is a thing that we want to do.

It's not oh, we're gonna, we're gonna wait and see. We're gonna wait and see on everything. It's no. No. , have some conviction around something, focus on it and let the market, slap you in the face if it's not correct, because then at least, okay we've got to go somewhere else.

Jeff: Yeah, I think. [00:15:00] That is such a great kind of point right there. It's right. You need the opinion. You need to come in with a viewpoint. You're a startup. 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. 

One thing I was wondering as I listened to this is you talk a lot about, know, Have the team that you can redistribute regularly , 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 the scope of your product has greatly increased over the past, 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 continue to, build great product, but also is able to pick up and move to different piece and move to a different piece and maybe sub to that, like, how do you think about, people with very specialized skillsets, maybe people who, I assume you have a couple of infrastructure engineers or you have people specialized in [00:16:00] iOS or Android or different mobile frameworks or something like that.

I

Nan: 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. 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 begin with.

And it's, there's a natural contours, 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 getting continuously bigger and you have a large product surface and then you have to make some decisions about how you're going to manage that.

And it's like a fairy tale that you can tell yourself about. I can split up my product into these sort of, sub components, different use cases or something like that. And then we can have a different team, nice and tidy handle that use case.

And it's not even always wrong, right? that's true in some subset of cases. But creating sort of these artificial distinctions because [00:17:00] it's like convenient for you as a manager, like that's where people end up getting themselves into a lot of trouble.

And, so when you're thinking about like how to set up your teams, like, how did your customer think about your products, our customers have to use our whole product. If they don't get to choose some subset and be like, this is the only part I interact with, they're forced to interact with. Most, if not all of the products, 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, if they don't get to just pick one subsection of it. So I think as product developers, , we have to own that 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 \ , that's also one of these other areas where 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 [00:18:00] yourself because no one person like sees it from that customer perspective, the customer, it's like obvious to them.

I think if you want to hold all those things constant you really have to commit this idea of it's totally acceptable and expected, for the product development team to 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. But I feel like that is a good prodding one. , Engineers start to claim that they're too specialized.

Sales knows the whole product. So you got to know it too, guys. On this, there is conventional wisdom, 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. And they all say it's, six to eight people per manager, or, there's some wisdom that all floats around about that.

Given what we've talked about here, you could very easily end up with a balance of, 20 to one or more than that I guess, how do you think about that in this [00:19:00] situation? , how have you guys 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. There's this thing that we all understand as like engineers, that work will expand to fit the space. 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 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 customer, that sort of thing, because we got this PM sitting 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. It's not out of laziness necessarily. It's more out of this is someone's job description. , it wouldn't feel right for me to do that. And then you start having this learned helplessness.

As soon as a customer has a question about the product or like complaint, but they file a bug even. And then you're like I don't know how to interpret it. I would ask the PM what to do. So I think that dynamic [00:20:00] is probably way more dangerous than a product manager being overworked. 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 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 reverse and it takes a long time 

Jeff: it seems like we keep going back to once you get, there are certain tipping points once you get to, they're hard to come back from. So work hard to prevent those and only hire once you really see the need versus anticipating or land in these kind of pre structured, ratios.

Not even to mention what the CEO of Nvidia Jensen Huang has what, 40 reports. Is it now 60 was the last I heard or something insane.

Nan: something like that. And look, that, that is a special case, right? He's a CEO. All those reports are very like independent and stuff like that. But I think that, take a book like high output management, right? And hopefully the, the audience has read that book on it. They haven't, I really do recommend it [00:21:00] and it's considered a classic.

If there's a lot of good stuff in there, but the good stuff is really about the principles that are driving a lot of the decision making. The principle that Andy Grove talks about in high output management is really focused on 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 directly responsible for, plus all of the adjacent teams that you influence. so accept that as the axiom. Now, here's a bunch of techniques to get the best output from your team. And then, for him, the best techniques were like, do a bunch of one on one meetings, don't have more than eight or nine reports, because you have to do one on one meetings with all of them all the time.

So your schedule is going to be destroyed if you have more than that money but all of this stuff is in service of that original principle. But then like people read the book and 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 lose sight of this idea about 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, [00:22:00] have a much bigger team, right?

You can get a lot more output that way. but there's a natural limit on that based on how much, your communication channels or whatever. But our communication channels are different now. We're able to do a lot of good mass communication, async communication, all that kind of stuff.

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 the ratio is there as an example, not as a burnt in the wood truth. Yeah, I love kind of 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 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?

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 hit that point or how do you make that decision? It's time to carve off some resources where does that come in or does it not are [00:23:00] you guys just still one big?

You know, group that kind of just functions really well.

Nan: 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, we have a bunch of team members in Europe. 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 to all work together and for the Europeans that work together on most projects. So there's some soft boundaries there, but there's not a boundary of like product understanding or a boundary of here's the part of the code base where I absolutely can't touch or something like that.

, and also certainly our product management team, we work with engineers on both sides. So , we're 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, again, I said, like natural kind of carve outs, but other than those extremely specific, specializations, yeah, it's all one big team.

Jeff: And so I guess drawing the difference [00:24:00] between a functional team that owns an area versus for this period of time, you were 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 people have different kinds of like on call rotations and we have a rotation we call goalie and it's basically, 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 piece of functionality, whatever. And then whoever happens to be goalie needs to figure out what to do with it. So that's, it's almost like an exercise to be like, okay pop quiz, something's going to happen.

You better have some way to, dive into that area and figure it out.

Jeff: It ensures that everyone has the breadth across the product that we talked about, right? Cause you, you might have to prove it at some point, so be ready. I kinda love the idea that, It gives you the ability to redeploy quickly as you need to [00:25:00] if new priorities come up because you do have this breadth of knowledge across the team.

Nan: Yeah, I want to say something very specific about that, right? Because, in, 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 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 that doesn't matter, put these other people on it. If they're able to do the work. . And , 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, like there are situations in which that is appropriate, but if you find yourself feeling bad that there's this boundary, you're unable to cross it, then 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 needs to get over.

Jeff: This is going to be a reference that is probably out of left field. But it reminds me, [00:26:00] growing up in the eighties and nineties, is when the Disney movie Aladdin came out and they go through, a whole bunch of hijinks and craziness, but at the end, basically Aladdin has proven himself and 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 Oh, what are we going to do?

Nan: Yeah.

Jeff: You're in charge. It's, 

Nan: 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. I guess one more question I have this and then, let's move on. But you mentioned, 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 this kind of 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 [00:27:00] Solutions you can just buy off the shelf 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 we build, whether we're building a feature or we're building, a specific sort of table stakes feature that is demanded by, like larger enterprise customers. It's a very well defined goal. So 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 that is the ideal outcome, right? When you think about there are things that make your business special, and there are things that are, 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 [00:28:00] business to sell into these, 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, like Samuel team or whatever. Okay, I guess my job is to do the SCIM SAML as much as I can, as much as possible. It's 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, that's not what your business is. Your business is, 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 rule based access control team or anything like that, right?

It's something, 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, worried about expanding [00:29:00] it to the rest of their team and 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. 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 about.

And I have you here now. A I went through a decade and a half ago at this point of running a team where we ended up using JIRA and all those kind of tools to run it. And then we tried out Asana and so on and so forth. And it seems like at some point, there was the opinion a little bit that like project management is a solved issue.

, 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 and I love your take on this, right? Your goal with linear is to, help make sure that everyone's focusing as much as they can.

[00:30:00] On their main thing, right? Like you want everyone's day to day experience to be great. You had a great story here, 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 your framing about, is this not a solve 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 do the same thing. 

I think , that's certainly something that people would ask before they like invest in the company or, when we talk to candidates, they ask that too, right?

They're like how do does it, does success look like you just become Jira? What does the success look like? And I think the best way to illustrate it is the experience that we have talking to Inge managers and product managers when we're doing kind of discovery calls, right?

We'll ask them these questions around Oh, tell me about, your team's planning process, [00:31:00] or tell me about how you manage projects. And they'll, they're ready to talk about it, right? They're like, okay, we've got this setup. We've got this customization. We've got this, 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 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? 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. For a lot of reasons, right?

A big part of it is that, 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 your process at your company and then tell everyone to do it and get it into their brain so that they press the right buttons in the right order and they didn't ruin your customizations, all that stuff.

There's so many things that have to go right [00:32:00] 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, JIRA that much.

So we can come in and compete. And then the PM, puts on their like good PM hat and they go, we're going to listen to customers and see what they want. And then someone's going to be like my ideal situation is this. And they're like, great. 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, 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 know what they're even supposed to do.

Like we talked to companies, this company's like, Oh yeah, well we have, 150 custom fields JIRA that we just, we're like, Okay. Yeah. And then it's like, it's it person's like in order to transition, we got to preserve all of them.

I'm like, do you like what percentage of people even know what [00:33:00] any of those mean, right? And then we'd asked around, just to survey on their behalf, pull in a bunch of engineers and engine managers and Oh yeah, we have no idea what these things are. They're just their legacy. They're there.

Someone added them and just it's like accumulated cruft. But like all of those things, like someone thought that was their ideal. 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 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 [00:34:00] 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, check boxes or pick dropdown menus or, dah, that no one ever used, but it was 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 shelf where no one even realized it was shelf where

Nan: It's it's a sort of false promise right to that. A lot of people take on this because this idea is if I just had this extra thing that I've 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 it's a completely garbage field , that all the data is unreliable in the first place.

Cause no one knows what it's really there for. And., the final step in any of these issues is someone has to write the [00:35:00] code, they make the pull request, they merge it, and then it's in your product now. And then the issue, it just doesn't matter anymore, right?

It's it, you 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: And that's the key, right? If you are a software product and everyone, what I have realized from being at log rocket now I've been in software for a long time, but this is, 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 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.

Yeah, this is, this is such an interesting thing, and it shows up in, linear is famously an opinionated organization, right? You have the product you're building and you've gotten, I'm sure hundreds of requests for custom fields and this, and just add [00:36:00] this one thing.

And it seems like almost always linear says no. And Yet you're still growing really fast. I guess back to your point, 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 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 that?

Nan: Yeah, I think that's mainly the case. We're very sensitive to introducing any features that are basically. That, let like a middle manager express some ideal scenario that they hope to achieve, but in reality adds friction to that day to day life of an individual contributor, right?

If anything has that dynamic, we really question it a lot. And so when, when we see stuff it's, I think everything is viewed through, through that lens. And, the way that you become very similar to incumbents or very similar to, even the sort of next [00:37:00] 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, the real enabler of velocity is you just have to do fewer things in the first place.

Jeff: I heard you really succinctly 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 allows them to focus on their job better.

Nan: Yeah, absolutely. It's, people talk about, Hey, what metrics do you use and stuff? I'm like, it's 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 on both sides, right? You as a higher, 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 and a new org and culturally make sure it makes sense. Which is [00:38:00] also great. Cause 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? So you. Someone comes in like maybe people are between jobs and that's a great, that's a great time But that's probably the exception.

How does that work? Like how do you negotiate this kind of three to five day period where someone's gonna come in and do this? They can't just Tell their job, like I'm going to 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. We've done all sorts of variations on this where we, put a couple of days in the weekend. If it's a bunch of IC work that they have to do anyway 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? 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 I would never spend that much time on a job that I wasn't sure I wanted.

And. Look, if you're not sure that you want it, [00:39:00] cause 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. 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 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 Oh this wasn't the right fit. We have to unfortunately let them go. But another one is they're like, this wasn't the right place for me. I thought it was, but it turns out that after just, interacting with everyone and working real closely with people, like we just don't get along or whatever.

And that's such a big risk to employees because, people stay at places a long time because it's just so much of a hassle to find a new job because you, especially if you want some stability for your family and stuff like that. And I think that the folks that really get it, they look at it as like an opportunity 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 choice is I quit this job that I was fine at before. And like upended my entire [00:40:00] 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.

I think for us, it's like it's largely that's like motivating it.

Jeff: It's funny. I think it's something that people are often skeptical about, but when you frame it that way, it's just God, thank you for making this better. It makes sense. And, it seems like a really, employee but also employer centric way of just making sure that I always 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. How you want motivated people 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. No, it was fantastic having you on. 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. 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, someone's looking to reach out, LinkedIn or [00:41:00] Twitter or something, what's the best way to shoot you a note?

Nan: Twitter is probably the most reliable. My handle is then on you, T H E N A N Y U. And then my linear email is very guessable. It's my first name at linear dot app.

Jeff: Oh, wow. That's brave of you giving that out.

Nan: Plenty of people have guessed.

Jeff: Like you said, as guests, that's the problem with the first name at is not too hard to find. So awesome. 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.