This Framework Will Change How You Think about Your Career | Shishir Mehrotra (CEO Coda)

He says, shashir, I just, I think you're wrong about this. And I said, why? What am I wrong about? And he said, I think you've misunderstood the problem. So the problem actually has nothing to do with the product or the buying experience or anything. The problem is the name. The problem is the name of the product. And I said, what does that mean? And he says, but you call it skippable ads. But like whose value proposition is skippable ads? It's a value proposition to the end user. But who pays for advertising? The advertiser pays for, for advertising. Why would an advertiser want their ad to be skipped? It's like reinforcing all their worst nightmares about what's happening to their ads is that people aren't paying any attention to them and it's just a really bad way to frame in the problem. So he said, I think I'm not going to focus on the engineering, getting the product ship or so on. I'm just going to focus on the name. And my first reaction was, this is what I get for putting a salesperson into product. This is, you know, this was a clearly not going to work out. And it turned out he was totally right. So they renamed the product to TrueView. So the value proposition is you only pay for true views from the sales team perspective. This went from being the product that the sales team didn't ever want to talk about to the number one most requested topic for the sales conference the following year. The product went from zero to a billion dollars in about 18 months. It was one of like fastest growing things we ever did. If you skip the ad, then obviously the viewer benefits. But it turned out the advertiser benefits too because the advertiser gets this much more engaged user who chose to continue to watch this video.

All right, so my guest today is Shasheer, the co founder and CEO of Coda and former chief product officer of YouTube. Shashir is writing a new book called Rituals of Great Teams that I'm really excited to dive into. Welcome Shashir.

Thanks for having me, Peter.

Yeah, so one of my favorite frameworks from you is the PSHE framework, or you call it maybe the PSH framework. I don't know what you call it, but, but it's such an amazing framework for thinking about your career. I share with everyone that I talk to, so maybe you can just quickly, briefly recap the framework again for us.

Yeah, so the acronym is psh Problem Solution, how execution. And I've tried many times over the years to come up with a better acronym that is just a word or something that's easy to pronounce. And I've never been able to come up with one, so. So we just call it the push framework. And for people who are old enough to remember DJ Jazzy Jeff and the Fresh Prince, it's the same sound that they use when they introduce themselves to each other.

Nice. Nice.

The. So. So I can explain the. The concept and the. You know, this came out of a set of discussions when I was still at Google in 2011 or so, Larry took over. Larry Page took over a CEO and he got rid of the functional organization structure. And we had all these business units then and YouTube became a business unit, so on. But one of the things that caused was some conflict around what do we. How do we decide who is a good product manager, engineer, so on, and keep it consistent across teams. So I got particularly involved in the team working on product management. But actually turns out this framework has very little to do with product management. And at the time, the main way we judge product managers was on scope. So it was some function of how broad an area you covered. And so, you know, I cover the feature or a group of features or 10 engineers versus 100 engineers, or, you know, $10 million of revenue versus a billion dollars of revenue or whatever it might be. And that just turned out to be a really poor way to judge product managers. There are a few problems with it. You know, first off, it naturally led to divisions with fragmentation. So like the Google search team hated it because Google search was like one big product. And the ads team, the Google Ads team, loved it because it was lots and lots of little products and ads. It also felt a little bit like an input, not an output. As, you know, you ask people, hey, this person should get promoted. Look how much scope they cover. And you could say, well, but actually they have that scope because their manager gave them that scope. And it really isn't. It isn't. You know, it's a little bit of an indicator, but they should have to do something with that scope for it to be. For it to be rewarded. And the biggest problem with it was that scope was sort of led people away from risky projects because the riskier projects, some of our best people were working on things we didn't know yet is this going to be a feature or going to be some giant thing? We didn't really know. And so, so we had a lot of discussion and we ended up coming up with this framework that, like I said, has kind of a poor acronym. But it's stuck. It's okay. So pshe. So I'll explain how it works and then give you some observations about it. So let's imagine you're a junior product manager. Then the way we like to describe it is we hand you a problem, we hand you a solution, we hand you the how. And your job is just to execute. So it might be, we say, talk to this person, write this document, hold this meeting, do this research, whatever it might be, and you just have to execute on that plan. At some point, you advance in your career. We hand you the problem, we hand you the solution, you figure out the how. And so you figure out the this is how the team should run and how the milestone should be set and how the cadence should work and so on. At some point, we hand you the problem and you have to come up with a solution and figure out how to solve that problem. And at the top of this pyramid, we hand you the space and you have to come up with the problems. And so I might say, hey, I think the problem here is activation. And you come back and say, oh, no, actually I figured out the problem is retention. Or the problem actually has nothing to do with those things. It's engineering quality, or the problem is our marketing or whatever it might be. And the idea is that this sequencing is a more effective way of judging people, sort of independent of scope. And so there was this really interesting exercise that, you know, we came up with this. There were eight product leads at Google at the time. And one of them went off and calibrated their team. Her name was Jesse. She calibrated her team on both these axes, an axis of scope and an axis of this pshe. And what emerged was this really interesting S curve. So it turned out that early in people's careers when they had, they were mostly on that E part, the execution part of pshe, they mostly grew by increasing scope. So we would hand them instructions and they would do it on sort of bigger and bigger features or bigger and bigger areas, so on. Later in career, same. The same. We hit this P part and you're handed spaces and, you know, now we hand you bigger and bigger products or suzettes of products or so on. But in the middle, the curve sort of turned the other way. And she put a big circle around this and said, this is the trough of disillusionment. And so why is it the trough of disillusionment? She said, well, it's where from the employee's perspective, it kind of feels like you change the rules on them. Like, up till now, you kind of instructed them that, you know, just bigger and bigger scope, that was the goal. But. But all of a sudden that didn't matter as much. It was some other axis that was harder to explain. And then from the perspective of the evaluator, from the manager or the calibration committee, all of a sudden your rubric has changed. Because two people with the exact same scope, you know, may not really differ on the scope, but they differ dramatically in how they do the job. And that frame sort of changed how we thought about product. Now it turns out this has actually nothing to do with product. So I came back, started applying the same thing for my engineering team. And, you know, if you want to know who the best engineer on the team is, you'll say, oh, the engineer who can see around the corners the best indicator of the really amazing engineer. Or if you ask the marketers or the designers, kind of very similar. And the one that was the most challenging was sales. Because in sales, the general viewpoint is that sales is already quantitative. You don't need any of this, any of these rubrics. You just look for whoever beat their quota by the most or brought in the most revenue. But then you go ask a team and you say, oh, you know, so and so she must be the best because, you know, she's at 400% of her quota. And her team would snicker and say, nah, not really. She got lucky, got the right customer, got the right moment, so on. I'd say, okay, so great, so who's the best person? And then they. The way they would describe it is, well, you know, so and so she's definitely the best salesperson, you know, And I'd say, why? And they said, well, because she can handle anything. She can take a product that works and a product that doesn't work, a category that's growing, a category that's shrinking. Know a region that's working, a region that's not working. A great team, a not so great team. And she'll just figure out the right problems, identify the right solutions, figure out how to implement those solutions, and then execute and deliver all those results. And so since then, I've come to this framework PSHE as not only a great way to judge product talent, but also as a way to judge people, employees generally. So I kind of use the same rubric everywhere.

It's kind of like going up. The PSHE is kind of like dealing with more ambiguous problems and having the autonomy to drive it yourself without looking for a lot of help is that kind of accurate?

Yeah. I mean, and we always struggled with what name to put on that axis. It's like, psh, what's the. What's the name? And, you know, there were lots of. There were lots of different labels put on. It's probably the one that stuck the most was called Leadership, which I don't really love because I think it, like, lots of implications in leadership. I often called it the training wheels axis. So what is the most ambiguous framing you can give someone without having to give them training wheels on exactly what to do next? And the. And I think that was kind of a good way to think about it. Another way to think about it is certainly true of product people, but it's kind of true of all roles is at the end of the day, our jobs are to create. I mean, eventually our job is to create results, but on that path, it's generally to create what I call clarity out of ambiguity. We're all handed situations where the signal's not perfect, the data's not perfect, the math's not perfect, whatever it might be. And our jobs is to take ambiguity and turn it into clarity. And so in some ways, the PSHE axis is a measure of how effective is someone at turning ambiguity into clarity.

So let's talk about, like, how can we point to practice? Right? So, like, let's put some hypothetical situations. Maybe you have some real examples. Like, let's say you're a product leader. You've been assigned a specific area, and you're doing a good job at it, but you actually don't think this is the most important area you should be working on for the company. So. So how do you talk to your manager or, like your management chain? Like, hey, actually, we should be working on this instead. Like, how do you have an example of this?

Or, yeah, I. So there's one that comes to mind. It's not perfectly matching the way you frame the question, but I think it's a good example. So the example that came to mind is I had a product manager named Lane Shackleton. He's actually now the head of product here at Kodak, but at the time, he worked in sales at YouTube, and he worked in sales. And he came to me one day and he said, hey, I really want to be a product manager. And at the time, we had this kind of crazy rule that you couldn't be a product manager at Google unless you had a computer science degree. Yep. And it was just something that Larry and Sergey felt really strongly about. And so I told him, this is really Hard. I, I don't really know what to do because I can't really get around this rule. And he said, come on, that's silly. I write code in my free time. I'm just as technical as anybody else. Ask any of the PMs. And he said, let me prove it. I said, okay, I'll let you prove it, but I need you to do it on a project that, you know, I pick and I need you to. Oh, the other thing I said is you need to do it in your 20 time, but not like 2080 time, but like in 100, 120 time. Like you can't. I can't have your boss mad at me about the job you're doing. And he said, oh yeah, no problem, that's fine. And he said, so what's the project? And I said, I want you to go work on skippable ads. So maybe as like sort of broader context, when I got the way I got to YouTube was sort of this interesting path of. I had written this paper about what's broken with video advertising. And to be honest, I knew nothing about video advertising at the time, but I had this idea that if you put a skip button on ads, then it would totally change the incentives of that, of that advertising system. And it just seemed really obvious to me that you put a skip button on ads. You say if the user skips, then the advertiser doesn't have to pay. But now the publisher, in this case YouTube, has an incentive to pick better and better ads. It's very similar to the same philosophy that, that makes Google AdWords work and why the ad system there is so effective. I just thought this was really obvious, like we should clearly do this. I'd written this paper about it. Roundabout story how I ended up at YouTube to actually work on this. But it turned out that the sales team thought it was a terrible idea. We not like a little bit bad idea, but a terrible idea. And their logic was really simple. They said, you know this, you're going to put a skip button on ads. People are going to skip 80% of the time and we're just going to lose 80% of the money. And we were already As a business, YouTube was really struggling at the time. You probably don't remember this time period, but there's a time period where YouTube was seen as Google's first mistake in acquisition. Like, we had all these other successes, but this one was seen as a failure. We're losing billions of dollars a year. We were, you know, grainy videos, big lawsuits, on. And so the idea of tanking revenue like that made no sense to anybody. And I was told that, you know, every year there'd be this sales conference for all the salespeople. And I was told, shashir, you're allowed to come speak as long as you promise not to talk about your stupid skippable ads idea. This is. So I told Lane, hey, you're going to take a project. This is the project I want you to take. And because he was sort of new to product and, like, thinking PSAT terms, I handed him the whole manual. So I said, look, here's the problem. It's really obvious kind of what I just framed here. I have the solution, and the how has turned out to be tricky, but I have the answer. I have this friend who works in the ads team, and she's going to help you make sure this gets shipped into the ads product in a way that you can sort of secretly get some momentum behind it. And then, you know, people will start buying it and they'll just start working and just talk to this person and then come back to me next week. And so he goes off. He comes back to me the next week, and I say, so did you. How'd it go? Did you talk to the person? Is it you working on AdWords? And he said, yeah, I talked to the person. I'm working on it, but I'm not so sure that's the right path. And I said, really? And I said, no, no, you should talk to this person, tell them this, and it'll work out okay. And said, okay. He comes back the next week, and I kind of say, how's it going? And. And he says, yeah, I know. Like, I'm doing those things. I'm not so sure it's gonna. It's gonna work. And here's some of the signals I'm seeing. And then finally, the third week, he comes to me and he says, sure, I just. I think you're wrong about this. And I said, why? What am I wrong about? And he said, I think you've misunderstood the problem. So the problem actually has nothing to do with the product or the buying experience or anything. The problem is the name. The problem is the name of the product. And I said, what does that mean? And he says, but you call it skippable ads. But, like, whose value proposition is skippable ads? It's a value proposition to the end user. But who pays for advertising? The advertiser pays for advertising. Why would an advertiser want their ad to be skipped? It's like reinforcing all their worst nightmares about what's happening to their ads is that people aren't paying any attention to them and it's just a really bad way to frame the problem. So he said, I think I'm not going to focus on the engineering, getting this product shipped. So on, I'm just going to focus on the name. And my first reaction was this is what I get for putting a salesperson into product. This is clearly not going to work out. It's okay. The product has already been on the shelf for three years. It's okay. Well we'll. There it goes. And it turned out he was totally right. So they, they renamed the product to TrueView. So the, the value proposition is you only pay for true views and you like very much lined up with. At the time, people were very, you know, the idea of YouTube view counts was like one of the best rubrics for everybody. But certainly for advertisers that was a, it was a well known thing that, you know, your ad was so good it got tens of millions of views and said, hey, this is what, how we're going to align the advertising model. We're going to call it TrueView. From the sales team perspective. This went from being the product that the sales team didn't ever want to talk about to the number one most requested topic for the sales conference the following year. The product went from zero to a billion dollars in about 18 months. It was one of like fastest growing things we ever did. And it turned out that it wasn't actually anything about the concept. And the basic idea of the concept was totally right. You know, the idea of if you skip the ad then obviously the viewer benefits. But it turned out the advertiser benefits too because the advertiser gets this much more engaged user who chose to continue to watch this video. And it turns out that the stats were right about only about one in five people watch the ads. It was about 80% skip rates but the price that people paid per view was about 10x higher. So overall the unit performed 2x better than anything else we were doing. And it was a significantly better user experience for the user. But the whole reframing and in this particular case the person that was wrong turned out to be me. But it was all, you know, Lane, I think did a really nice job of finding a problem and describing to management why we had gotten it wrong. I thought it was, I thought it was a very good example.

Wow. And it came from sales. Right. So it was probably, he had to Convince sales that this is like the right thing to do. Right. So it kind of makes sense.

I mean, and Right. Makes sense. I mean, it turns out Lane is a fantastic product leader and I do think one of his skills is deep user empathy. And so he's a really good eye for when you've got a problem and you've kind of misheard or misunderstood the customer problem because it's often customers will describe their problem in ways that are, you know, not that clear. But like, no, nobody, you know, the customer generally would say things like, it's a big problem that people aren't watching my ads. So I need you to make them bigger. I need you to make them harder to skip. I need you. And so the idea of like, let me find a way to re channel that and say, actually that's not what you care about. What you care about is that the right people watch your ads and that you pay for those cases where they really do. And it kind of worked.

And like, that's awesome. I didn't realize he was in sales because he's so level headed, but I guess that helps. Well, what about these like, you know, big organizations like YouTube and maybe Coda to a lesser extent. But like sometimes you see this obvious problem that you're like, you know, someone needs to solve this, right? And then you want to take initiative and just solve it, but then there's someone else working on it or like, you know, it's like an team on it. I didn't want to like become territorial or something like, how do you navigate that kind of stuff or.

Yeah, I think the short version I'd say is be selfless. And I think people can spot selfishness miles away. Actually, the example I gave how I got to YouTube was I wrote this paper about what I thought was broken with video advertising. The paper was titled why doesn't television feel like the super bowl every day? That was the concept was the super bowl is the one day a year where we all watch the ads. We're really happy to watch the ads. We rewind and watch them again. We tell our friends about them. What causes those incentives to be so good that one of the day of the year? And interestingly, I didn't know anything about advertising. I never bought or sold an ad in my life. I didn't really understand what the dynamics were, which probably made it for a more interesting paper. And to be honest, I thought the thing was kind of obvious. And so I just sort of handed it off to people. And at the time I handed it off to the guy who was running product at Google and he kind of convinced me to come work at Google. And then Chad Hurley was running the YouTube team and he read it and said, oh, that's kind of interesting. And I was talking to Hunter who was running park team there. And because he could spot that I wasn't like lobbying, I wasn't lobbying for the job. I wasn't trying, I wasn't trying to take any credit for it. I mean, I had sent it to Hunter and said, you can do whatever you like with it. I think that people will see it. They'll see, are you like intellectually engaged? Are you engaged with teamwork? Are you seeking credit? Are you giving credit? But I think people see selfishness a long ways away. And if you find yourself in that situation, which will happen a lot for the, for, you know, as you think about the PSHE scale, the people who are on that P mindset will often identify problems that are not in their direct control. Yeah, right. So now what do you do? You have to go help people see why that's the problem they should, they should care about. And if they suspect it's because you have some ulterior motive, then they'll know. But if you can show them this is, you know, the greater picture of what we're trying to get done. That particular, you know, that particular thing that doesn't seem to come up now, it doesn't always work. If I had to give a single lesson out of it is, you know, if you think you're, if you think it'd be perceived as even a little bit selfish, you need to back off and make it feel as selfless as possible. Give it to them secretly. Take the influencer, make sure it's their idea, like dumb little trick, add them to the list of people who wrote it, who wrote the write up, or make it just from them. And if you really care about, about solving the problem, you know, your job is. There's an old saying that everybody's job is to make your manager look good. And I don't think people really understood the logic of that. You know, why is that so important? And it's amazing how many people don't do that. They sort of compete with their own managers, they compete with their own teammates and they. The moment people spot that your ideas don't win and what you want is to focus on the ideas, not on the person.

I love that, I love that because I think the natural reaction when you see something the problem is like, you know, the person you charge is the incompetent. So I'm going to point him out that he's incompetent.

Right.

But like, I think this approach is much better. You build trust so much more with the other party.

Yeah, that's right. I'll give one more tip, actually, since you mentioned the build trust part. One more quick story. So I get asked a lot. The variation of the question you asked, I get asked a lot is actually between PMs and engineers. So, you know, how do you convince, you know, some other team to go do something, as one variation. But the most common team you need to convince is actually if you're a product person is the engineers. And it's really tricky for product people because they think they've been told that you're the boss. You know, they read some article and say, oh, the PM gets to be like the GM or the CEO. It's like complete misinformation of what the job is actually like. And they'll come to me and they'll say, my engineer is almost in me. What do I do? Can you tell them? Can you tell them they have to listen to me. It's like, no, that definitely is not going to work. And, you know, the first thing I'll tell them is tell me about the relationship. And in particular, like, if you just imagine a world where the engineers didn't exist, what would you do? The answer is you'd probably do very little. I say, okay, let's go the other way. Imagine the PM didn't exist. What would the engineers do? It's like they might build the wrong thing, but they would definitely continue building. So who's optional here is really important for you to recognize, like you're optional, the product manager and basically every company. If you sort of boil companies down, especially tech companies, to people who make the stuff, write code and so on, and the people who sell the stuff, everything in the middle is optional. It has to earn its right there. And so they'll say, okay, so what do I do? And I said, well, listen, your relationship with your engineer is framed or has grown slowly. Trust grows slowly. And in particular for product managers, I think it grows in these four stages. So this, I call it note, note taker, broadcaster, collaborator, leader. So first you're the note taker. You say, hey, msrms, as an engineer, that's a really great idea. Good job coming up with it. I'll write it down for you so you can just focus on writing the code. At some point you graduate to broadcaster and say, not only will I Write it down. I'm going to go tell the rest of the team about it. I go tell customers about it. You can just focus on building. At some point you become collaborator. And the engineer says, hey, we really want to wait and hear what the PM has to say. And the PM says, hey, don't worry. But at the end of that, I'm going to like, we're going to do what you want to do and I'm going to go write it down and broadcast it and I'll do it. Exactly what you want to do. And at some point you grow in that relationship and you become leader and people sort of pause and say like, no, you should probably decide what are you going to do? And interestingly, if you think about product managers, you know that that whole progression, sometimes it happens in three minutes, sometimes it happens in three weeks, sometimes it happens in three years, sometimes it never happens. And it happens slowly and it can fall off a cliff, you can lose it in an instant. And when people come to me and say, my engineers won't listen to me often say, go back to being note taker. Start again. And interestingly, what people hear sometimes is they'll hear, I don't want to be a note taker. I mean, it's like the most insulting thing you could say to the pm. Like, oh, the pm. They just come and take notes and that's all they do. And it's like, why would I want to do that? And I said, no, you don't understand note taking. That's not, I'm not saying it as euphemism. I'm saying it because it's the core skill. What does note taking mean? Note taking means that I can write down what you. That explains it better than you said it. I heard you so well that I can explain it to others better than you could now that I can explain what you mean better than you could. Now I have a chance to interject with something else. But I earn my right to be able to participate by restating opinions. And note taking is actually like the skill for pm. And by the way, like, every role has the same, like designers. You'll ask designers all the time. They'll say, oh, my PM will listen to me, or my, this other designer will listen to me. And I'll say, and I'll go to the same speech, which one's optional? All the same things. Except with designers, the bottom of that stack is you're the mock monkey. And they'll say, I don't want to be the mock monkey. That's like, that sounds terrible. And I'll say you completely misunderstood. What is your core contribution? You can visualize anybody's ideas faster than they can. You're going to take all their hand wavy stuff and you're going to make it literal, visceral, understandable. And by the way, if you can do it really fast, you can visualize their ideas and the other person's ideas and your own ideas right next to each other, and you earn this right to be able to get there. So sometimes I think this, like this question you asked of how do you convince people? I think being selfless is important, but I actually think this idea of bidirectional listening repeat back. So I think people talk about it a lot, but in every role, there's a core skill there. If you can restate the other person's viewpoint better than they can, you earn the right to add your own. And it's a really important skill in how you convince people of things.

Yeah. You almost want to make it seem like it's their own idea, right?

Yeah. You said this thing that's really brilliant. Like it's got all these amazing parts. And by the way, there's one thing you said, maybe you could twist that a little bit and all of a sudden all of the rest of it makes sense.

It's just kind of just like summarizing the PSHU framework. Like, you know, if you're not good at executing your own product area, it's hard for people to listen to you. We have a bunch of opinions about other product areas. Right? The same, same thing. You got to build your trust that way.

That's true too. Yes. You get a lot of credibility out of the stages of your own execution too, for sure.

Cool. So let's talk about strategy and planning. You know, when a lot of people think about strategy, they think about, you know, wow, this is taking a long time. This is like taking time away from like telling your customers, building the product. And you have a similar kind of like, wild process that can make strategy and planning more efficient. We can start with that.

Yeah, I mean, it's. I kind of like this. This analogy. So. So in the book I'm writing on rituals, there's a whole chapter on strategy and planning. And one of. In. In that chapter, we talk about a bunch of different concepts about strategy and planning and how planning systems are sort of similar and sort of different across companies. And I gave a talk about a month ago now with Yuki Yamashita. He's the chief Product Officer at Figma and we talked about, we called it wow Planning. And. And the sort of headline of the talk was, planning can not only be wow, it can be wow. And the idea is, if you can imagine wow with a W and nine O's and then another W, the whole talk was kind of built up to that idea. So I'll explain what that means. So, first off, if you think about planning processes, every company does it. Like you say, it's often the thing that is most iconic and most hated in a company. Yeah. Ask people how a company runs, they'll often talk about the planning process, and you ask them if they think it's going well. And there's very few companies that think they do a great job with this. The interesting thing is if you were to take everybody's planning process and sort of compare them with each other, there's a few elements that are very similar. You could almost put it in a MAD Lib. If you remember those Mad Libs when you were a kid, where you get like four blanks in a sentence and you can fill them in. So there's four blanks in every planning algorithm. We run a blank planning algorithm. Every blank time frame that produces a blank output, which we execute with a blank accountability protocol. Right. So if you think about it in terms of this WOW framework, we think of the W as the first part, the planning algorithm. So a lot of people describe a planning algorithm as a W, where you sort of push down some guidance, they push up some plans, you push down some new guidance or reframing, or you do some alignment, and then you push up to get a new cohesive plan. Sometimes people do it as an M, sometimes people do it as a W. We chose W because WOW sounded better than Mom. So we pick W. So that's the first step. We have some planning algorithm, then you have some output. So, like, at the top of that W, there's a thing there. There's a. We're done with planning when this is produced. And that might be. It might be like a list of priorities. Like, sometimes people use big rocks. It might be a list of assignments. Sometimes people. A very common technique is okrs. Sometimes planning isn't done until the budget spreadsheet's done, and there's a big spreadsheet and says, this is who's working on what, and this is how many dollars are going every division and so on. But whatever it is, you do the W to produce this dot, this, this output, then there is some accountability protocol. So, oh, we're done with planning and now we're going to check in. And, you know, you maybe check in every week, you check in every month, whatever it is. And you. You try to make sure you execute and stay on that plan. It's very important because what's the point of planning if it doesn't actually influence execution? There's way too many companies where you come in, you say, hey, we did all this planning. And then they'll say, yeah, we do all this planning, and then we kind of forget about it all. And then before the next planning cycle, we go back and reread what we said we were going to do, and we kind of like grade everything and we say, ooh, we got lucky. We did some of that. But the great companies obviously find a way to keep it front center. This is what we said we're going to do now. Let's keep it front center. So that's the O. So it's, you know, you get. You do a W planning, and then you do these loops of execution. And then the last part is the time frame. So how often do you do this? And one. One observation is you ask teams how often they plan. You say, like, hey, many companies do annual planning. So I'll ask them, when does annual planning start? And, you know, let's imagine you're on a normal January to January cycle. Many companies say, oh, we start in September. Some companies will say August. Some companies will say July. I've heard companies go all the way back to May, April. And you say, ooh, if you think about that in terms of what you're doing is you're planning sometimes for a third of your time, sometimes a half of your time, but that's a long period of time where not only are you distracted by the planning and what's coming next, you kind of like the moment that planning starts. You kind of signaled that the old plan is no longer valid. It's like, we're not willing to reopen this thing. And, you know, so you could end up spending with half your time on that. And so we had this philosophy. One of the things Yuki and I talked about in this talk is the idea that planning should take less than 10% of execution time. So if you are planning for a year is 52 weeks, you should spend no more than five weeks planning. If you're planning for a month, say a month is 22 working days, you should spend no more than two. Two days planning. If you're planning for a quarter is 13 weeks, you can spend a little over a week planning. So that's one way to think about it. And the reason for the wow is that we said you shouldn't be wow, you should be wow. And the reason is that's a W followed by nine O's. And so the idea is that W should only be 10% of your time. It's kind of an interesting frame for how to think about planning.

And what about like planning incentives, right? Like, you know, every leader wants their product to be P0 and going back to like the selfless concept, right? Like, you know, there's incentives to just like, hey, I'm gonna grow this business to a. A billion dollars. So you're gimme like a ton of headcount. And my objective is like number one prior priority. But how do you get people to actually think about the bigger picture here? Like not just like fight over headcount.

Yeah, yeah. I mean I, I think it's interesting the W. One of the old jokes in the talk we gave was that W does not stand for win. And it's amazing how many people view the planning process as a gain. And I'll see, especially in larger companies, I'll hear statements that'll almost sound crazy where somebody will come and say, they say, how did planning go? And said, oh, it went great, I won. Like what the hell does that mean? How can you win planning? And they'll say, oh yeah, I got, I got allocated all the headcount I wanted and you know, which we can go celebrate now. And it's such an interesting way that people have set up incentives is by making planning feel adversarial, you actually create a dynamic that leads to significantly worse plans. And so this idea, like the W is not for winning is really important. So how do you build that in your planning process is a real challenge. And I think something that, this is one of those topics where people who have done this a lot will resonate very quickly with how hard it is to execute in an environment where planning becomes adversarial. And it's hard because there is a constrained budget, there's a, there are some constraints. It's like we can't do everything. And so there's some judgment applied of like, hey, you propose this idea and you know it was a good idea and therefore you get X resources or X dollars or or so on. So my view is that when you think about the W, the planning part of the, the planning process part of the overall planning algorithm, the I think of it as your main goal is to get people to think outside of their own self interest or their own team interest. So my favorite technique for doing it is something called hundred dollar voting. And it's a really simple idea and we do it at code all the time. I actually do it with my board, which is kind of interesting. Tell you more about that in a second. But the idea is very simple. I started doing this at YouTube years ago. I say, everybody, these are the words. Going to gather the list of all the different things we can go do. And now, everybody, you're going to get $100 to allocate among each of these bets. And then we're going to use it as a signal. We're going to go and take the sum of how many dollars we put in each part and we're going to use it as a signal of what, what we're going to work on. But there's one really important rule is that I want you to use the $100 as if you were me, as if you were the CEO or as if you were the boss or so on. I don't want to see anybody, how can you win planning? And they'll say, oh yeah, I got allocated all the headcount I wanted and you know, we can go celebrate now. And it's such an interesting way that people have set up incentives is by making planning feel adversarial, you actually create a dynamic that leads to significantly worse plans. And so this idea, like the W is not for winning is really important. So how do you build that in your planning process? Is $800 all just going to their teams and you can all spot it right, Right away it's like, oh, you put all your money there. That's like. And I'm not saying you can't put any there, but I want you to think like me and defend like me. And the way we do it at Coda is you have to write a reason so you can't just allocate the dollars, like for each one. It's like, I think we should, I would put 50 of the dollars on this because I found this argument to be the most compelling or because I think this problem is the most important problem to solve or so on. And it turns out that process of take off your team hat and put on your company hat or put on your CEO hat, it's just crucially important because it removes all that sense of like, my job here is to fight for my thing. It's my job here is to make this team successful. If that happens to lead to the thing I'm working on is, you know, overstaffed or understaffed. Or so on, then that's fine. But if not, I shouldn't feel bad about it because this was the right thing for the company to do. In fact, it's like it's a real challenge. And I think something that this is one of those topics where people who have done this a lot will resonate very important signal to me because now I can go reorient a bit and say maybe I can help that other thing a little bit more. Because that's clearly more important quickly with how hard it is to execute in an environment where planning becomes adversarial. And it's hard because there is a constrained budget, there's a. There are some constraints. It's like we can't do everything and for what we're trying to get done as a team or a company or so on. So that's my favorite ritual for drive to make. So there's some judgment applied of like, hey, you propose this idea and you know it was a good idea and therefore ensure the W is not about winning.

I love that.

Yeah.

And have you seen like, just like quick follow up on that. Have you seen like smaller teams? Like, there's a belief that the more headcount I get, the more I can get done. Right. But have you seen actually smaller teams move much faster and get more done.

Oh my gosh, all the time? I mean, there's an old. There's a famous old book called the Mythical Man Month, by the way. I think this is very true for 0 to 1, 0 to 1 teams. When you're early building a product. I think actually compactness is a particular advantage. I actually think it continues for a long time that the. Especially in the tech world, the. At the end of the day, we were talking about earlier, pshe, it's about creating, taking ambiguity and creating clarity. That's not only an individual thing, it's a team thing. I think as a team, you know, if we can turn ambiguity into clarity, then we move fast. Right. Then we're always on the same page. We don't. And I think density really matters. So this ability to have people, a smaller group of people that perhaps cover a little bit less capability but are able to stay on the same page more often, the closer you get to. Here's an old concept of hive mind. The more they act as one brain, the better chance you have of them moving fast. And so I, I think you get X resources or X dollars or or so on. So my view is that when you think about. It's very important we started a new project here at Code, we're building, for the first time, we're building a second product. We're called Coda Brain. And it was one of my key goals. That team has to stay really small. And it was a lot of question about it because, you know, generally the viewpoint is like add what the w. The planning part of the, the planning process part of the overall planning algorithm. The. I think of it as your main goal is to get people to think outside of their own self interest or their own team interest. So my favorite technique for doing it is something called $100 voting. And it's more people. That's how you make it go fast. And to be clear, like once it got clear what they were doing, we started adding more people. But in the early days, very important, small team, get on the same page fast, give them space to run and then you'll get much faster execution.

Yeah, so that kind of goes back to you. You manage all these great PMs and leaders in YouTube and at CODA. Now I think there's a certain person who just really loves to build 0 to 1 or like likes to craft products. Right. And they don't want to like align 50 cross functional people to do this. So how do you think about career path at Coda? Like to kind of account for these folks? I guess you kind of give them an opportunity to work on Coda Brain. Yeah.

I think one of the things I love about the PSHE framework is it pulls the scope element out of the question. And it turns out that some people's way of doing the PSHE is by leading large teams. Some people are very good at it. They're good at, you know, selecting people, motivating people, coaching people, working with lots of people, so on. There's others where that's not their, that's not what they want to do. That's not what they're great at. But you, you know, by framing the world in terms of PSHE instead of in terms of scope, you give a path for doing that and you kind of need to do it in every role. You need a way, you know, and Google is pretty famous for really simple idea. And we do it at Code all the time. I actually do it with my board, which is kind of interesting. Tell you more about that in a second. But the idea is very simple. I started doing this at YouTube years ago. I say everybody, these are the, we're going to gather the list of all the different things we can go do. And now everybody, you're going to get a hundred dollars to allocate among each of these bets. And then we're going to use it as a signal. We're going to go and take the sum of how many dollars put in. We're really celebrating the ic, the individual contributor path for engineers building up a ladder for it. You could become a technical fellow, distinguished engineer, so on. All those signals are really important, and I think it's each part and we're going to use it as a signal of what we're going to work on. But there's one really important rule is that I want you to use the hundred dollars as if you were me, as if you were the CEO or as if you were the boss or so on. I don't want to see anybody's a hundred dollars all just going to their team and you can all spot it right, right away it's like, oh, you put all your money there. That's like. And I'm not saying you can't put any there, but I want you to think like me and defend like me. And the way we do it at Coda is you have to write a reason so you can't just allocate the dollars, like for each one. It's like, I think we should. I would put 50 of the dollars on this because I found this argument to be the most compelling or because I think this problem is the most important problem to solve, or so on. And it turns out that process of take off your team hat and put on your company hat or put on your CEO hat is just crucially important because it's important to do it in every function. You do it in product, you do it in marketing, do it in sales. It's sort of this, it's an interesting dynamic that leads to this feeling of only the manager rewarded. And by the way, I think there's a bunch of signals that lead to it. I mean, it's how you structure team meetings. So if, like, if your team meetings are structured around your management hierarchy, people get this little subtle feel of like, oh, I'm only rewarded if I'm managing large teams. And so therefore I'm going to opt to do that. You do it in your compensation philosophy, you do it in titles. Like, there's a whole bunch of little signals people get of is this a place that allows different ways to create impact? And of course, you know, as you're thinking about what you want them to work on. Yeah, sometimes you put them on the small thing. Sometimes, you know, there's people that are. They don't need to be on the small thing, they're quite happy being on the big thing. They just don't want to be in charge of it. And so I think there's lots of different ways that plays out. But it starts with a viewpoint of if you start with a view and as many companies that have implicitly built it into their whole process, that unless you're managing large teams, you're not valued the that will lead to a certain type of person not feeling, you know, motivated, excited, won't want to work there and you'll gradually, you'll lose them.

Do you see a shift with your other CEOs, other producers talk to towards a company type person more?

You know, I think people say it but. And I definitely think that in the last 20 years I've watched companies become much more okay with it. I do think that some of the bad habits that lead to it are hard to shake. I'll give you an easy example. At both Coda and YouTube, managers aren't allowed to see their employee salaries. And this is like, it's pretty counterintuitive because at many companies you're given a team and a budget and say your job is to figure out how much to pay everybody. And if you can do with a little bit less or a little bit more, that's kind of part of the resources you're managing. And what I found is that if managers are responsible for their employee salaries, you'll very. You won't get inversions, so you won't get cases where the individual makes more than their boss. It's just really hard to pay someone to work for you more than you make yourself. It's not impossible. Obviously there's lots of places where it happens, but it's harder and it removes all that sense of like my job here is to fight for my thing. It's my job here is to make this team successful. If that happens to lead to the thing I'm working on is, you know, overstaffed or understaffed or so on, that's fine. But if not, I shouldn't feel bad about it because this was the right thing for the company to do. In fact, it's like important signal to me because now I can go reorient a bit and say maybe I can help that other thing a little bit more because that's clearly more important hard thing for them to deal with. And so the moment you do that, what you've created is an environment where yeah, we can say all sorts of things about why the individual is valued. But at the end of the day you're managing, like, it's sort of a monotonically increasing compensation that the person who works for me definitely makes more than me and the person works for the. And then you kind of work your way up and so you get a signal. And so that's a kind of an example of some. It's a very small thing and it's very hard to implement, by the way. If you pull that control away from managers, you have to build a whole different apparatus for how you think about compensation. I think it's a healthier apparatus anyway. But it's an example of the type of thing that company cultures struggle with that lead to this feeling of, unless I want to be on the management track managing large teams, I can't be. I can't be effective.

Got it.

Got it.

Yeah, there's a lot of, like, you can say it a certain way, like the, you know, the altruistic way, but there's a lot of, like, like I said, a lot of little signals that people send in the daily work.

Yeah, yeah.

So. So what I respect over time. So, last question. You've had such a great career at YouTube and CODA, and I want to bring the theme back to being selfless. Right. Like, there just is. Some people get disillusioned with this whole corporate thing. They're like, oh, you know, you gotta play politics, you gotta hoard headcount, you gotta do all this stuff to. To rise up. But, like, do you have.

For what we're trying to get done as a team or a company or so on? So that's my favorite ritual for. To make.

Have any advice for someone or how someone can be a selfless leader and kind of grow their career in a selfless way.

Ensure the W is not about winning.

I love that.

Yeah.

And have you seen, like, just like, quick follow up on that. Have you seen, like, smaller teams? Like, there's a belief that the more headcount I get, the more shit I can get done. Right. But have you seen actually smaller teams move much faster and get more done?

Oh, my gosh, all the time. I mean, there's an old. There's a famous.

Well, you've talked about a lot already, but any closing words of advice?

I mean, I think the. The. For a lot of people being selfless, there's a soft line between feeling like selfless and being taken advantage of. And so it's really important to frame it differently. And for me, the best frame for it has been pay it forward. So I think if, you know, a lot of times. One of my favorite questions to ask people when they're, they come, they ask for career advice, they ask for, you know, problem advice and so on. I'll ask them about who the role models are. Who do you feel and by way of asking the question is somewhat specific. If you could take anybody's past and make it your future and feel totally happy about it, who would you pick and like. It's an interesting way to think about, you know, what, how you frame your goals, your way of living, so on. And people talk about the role models and interestingly, when you think about role models, the I think this. So first off, if you pick role models who are selfless, then it'll help you understand why it's okay to be selfless. One of my favorite role models I worked with was a guy named Bill Campbell. He passed away unfortunately a few years back. But Bill, they wrote a book about him a few years ago called Trillion Dollar Coach. He ended up becoming, you know, when I started working with him, he was the coach for the Kleiner Perkins, the venture firm. He coached a number of CEOs there. I was, you know, this was back in 2000, I was 21. This old book called the Mythical Man Month by the way. I think this is very true for 0 to 110 to 1 teams when you're early building a product. I think actually compactness is a particular adventures old. So I was kind of, I was very lucky to have him as a coach. Over the years he became more and more managed. I actually think it continues for a long time that the, especially in the tech world, the, you know, the end of the day we were talking about earlier pshe it's about creating, taking ambiguity, ambiguity. Not after he's Steve Jobs's primary coach. He was Larry and Sergey and Eric's primary coach, Jeff Bezos. Lots of interesting people. But anyways, I got to meet him much earlier and you know what. And he became, you know, one of my key role models. So he was my coach at Centrada. That was the name of my first company. And he used to come and help us out. He would sit in my staff meetings, he'd give lots of advice, he'd give me lots of, lots of feedback and so on. And one day I realized we were having our chat and I realized that we never signed an advisor agreement with him. He just come, he showed up and he just started helping and they said, oh Bill, we should sign an advisor agreement with you. And you know, I'm just so thankful for your contributions. I'D like to find some way to compensate you and we can give you stock in the company or so on. And Bill looked at me and said, I don't want any of that. And to be honest, I was offended. I mean, it's the. What's wrong with my stock? Why don't you want my stock? And the. And he said, well, he said, first off, don't feel bad. If you give it to me, I'm just going to give it to charity. So if you wanted to give it anywhere, you should just give it to charity directly. But he said, that's not what I'm in it for. And I said, oh, that's interesting. Like, you know, you're surrounded, especially in the tech world, you're surrounded by a lot of people who are, you know, they make money, they like. It seemed like it's a reasonable thing to do. Like, who is this person that doesn't seem to care about that? And he said, no, I just don't measure myself that way and it's okay. So how do you measure yourself? And he said, well, I look at the list of people I've worked with, I've mentored, I've worked for me, and I just count how many of them are successful. Creating clarity, that's not only an individual thing, it's a team thing. As a team, you know, if we can turn ambiguity into clarity, then we move fast, right? Then we're always on the same page. We don't. And I think density really matters. So this ability to, to have people, a smaller group of people that perhaps cover a little bit less capability, but are able to stay on the same page more often the closer you get to. Here's an old concept of Hive Mindful CEOs now, and this was back in 2001, and he listed, I think, 20 of the CEOs of the top 100 companies or so that I knew had all, like, worked with him. And it was like, it was an incredible list. And this is well before Google and Amazon and so on to the. Just like a really interesting way to think about how he measured himself, that he measured himself through the progress of others, and that was his sense of success. And I honestly, like, once I saw it, I recognize it in lots of people. It's like the people I like to work with are people that feel that way, that they don't view it as zero sum. They view it as when somebody else succeeds, you know, even a little bit through my help, their success is my success. It's not stealing from my Success. It is my success. And so I think that idea of you want to be selfless, think about role models. And for me, my role models have all been ones that had a pay it forward view that they were mentored by somebody great that helped them selflessly. They turn around and do it for others and they feel like the universe balances it out. And it always does. As you think about it, think about role models. Very helpful frame for it.

That's amazing. Yeah, that's probably, I mean you probably don't remember other advisors who took in.

The more they act as one brain, the better chance you have of them moving fast. And so I, I think it's very important. We're, we started a new project here at Coda. We're building, for the first time, we're building a second product we call Coda Brain. And it was one of my key goals. That team has to stay really small. And it was a lot of question about it because, you know, generally the viewpoint is like, add more people. That's how you make it go fast. And, and to be clear, like once it got clear what they were doing, we started adding more people, but in.

The stock from me or cook money from you. But you remember Bill, right?

Because. Yeah, exactly. Yeah.

So, so sure. When is your book coming out and.

Where can people sign up to learn more? You know the problem with a book like this? So I'm on year three of writing the book now. I thought it was going to take nine months. The book, to be fair, it's about 60% done. And if anybody's interested, rituals of great teams dot com. I publish about a chapter at a time and so people can go and read a bit. Although it's been a couple months since I, I published one. The problem with a book like this is it's an ever growing book. Like every time I talk to people, I get a whole bunch of new rituals that I want to put into the book. And so the book scope grows and grows and grows and grows. So I have been really hoping to get it out this year. But we'll see. Like the scope keeps growing, so we'll see.

You should publish a book, but you also have like a Coda wiki that just kind of grows and expands.

The book is obviously written in coda, so the it will be published online. A Coda doc as well.

Awesome. Well, thanks so much, Shishir. I learned so much about being selfless, everything. Thank you so much for your time.

Thanks Peter. Great chatting with you. Very important small team. Get on the Same page, fast, give them space to run and then you'll get much faster execution.

Yeah, so that kind of goes back to you manage all these great PMs and leaders in YouTube and at CODA. Now I think there's a certain person who just really loves to build 0 to 1 or likes to crafts products. Right. And they don't want to like align 50 cross functional people to do this. So how do you think about career path at Coda? Like to kind of account for these folks? I guess you kind of give them opportunity to work on Coda Brain. Yeah.

I think one of the things I love about the PSHE framework is it pulls the scope element out of the question. And it turns out that some people's way of doing the PSHE is by leading large teams. Some people are very good at it. They're good at selecting people, motivating people, coaching people, working with lots of people, so on. There's others where that's not what they want to do, that's not what they're great at. But by framing the world in terms of PSHE instead of in terms of scope, you give a path for doing that and you kind of need to do it in every role. You need a way, you know, and Google was pretty famous for really celebrating the ic, the individual contributor path for engineers building up a ladder for it. You could become a technical fellow, distinguished engineer and so on. All those signals are really important. And I think it's just as important to do it in every function. You do it in product, you do it in marketing, you can do it in sales. I mean, it's sort of this, it's an interesting dynamic that leads to this feeling of only the manager rewarded. And by the way, I think there's a bunch of signals that lead to it. I mean, it's how you structure team meetings. So if like, if your team meetings are structured around your management hierarchy, people get this little subtle feel of like, oh, I'm only rewarded if I'm managing large teams. And so therefore I'm going to opt to do that. You do it in your compensation philosophy, you do it in titles. There's a whole bunch of little signals people get of is this a place that allows different ways to create impact? And of course, you know, as you're thinking about what you want them to work on. Yeah, sometimes you put them on the small thing. Sometimes, you know, there's people that are, they don't need to be on the small thing. They're quite happy being on the big thing. They just don't want to be in charge of it. And so I think there's lots of different ways that plays out. But it starts with a viewpoint of if you start with a view, and there's many companies that have implicitly built it into their whole process, that unless you're managing large teams, you're not valued. The that will lead to a certain type of person not feeling, you know, motivated, excited, won't want to work there, and you'll gradually, you'll lose them.

Do you see a shift with your other CEOs, other product users talk to, towards accompanying this type of person more?

You know, I think people say it, but. And I definitely think that in the last 20 years, I've watched companies become much more okay with it. I do think that some of the bad habits that lead to it are hard to shake. I'll give you an. An easy example. At both Coda and YouTube, managers aren't allowed to see their employee salaries. And this is like, it's pretty counterintuitive because at many companies you're given a team and a budget and say your job is to figure out how much you pay everybody. And if you can do with a little bit less or a little bit more, it's kind of part of the resources you're managing. And what I found is that if managers are responsible for their employee salaries, you'll very. You won't get inversions, so you won't get cases where the individual makes more than their boss. It's just really hard to pay somebody work for you more than you make yourself. It's not impossible. Obviously, there's lots of places where it happens, but it's harder and it's a hard thing for them to deal with. And so the moment you do that, what you've created is an environment where, yeah, we can say all sorts of things about why the individual is valued, but at the end of the day, you're managing like it's sort of a monotonically increasing compensation that the person who works for me definitely makes more than me and the person works for the. And then you kind of work your way up and so you get a signal. And so that's a kind of an example of some. It's a very small thing and it's very hard to implement by the way you pull that control away from managers. You have to build a whole different apparatus for how you think about compensation. I think it's a healthier apparatus anyway. But it's an example of the type of thing that company cultures struggle with that lead to this feeling of unless I want to be on the management track managing large teams, I can't be. I can't be effective.

Got it, Got it. Yeah, there's a lot of, like, you can say it a certain way, like the, you know, the altruistic way, but there's a lot of, like, like I said, a lot of little signals that people send in the daily work.

Yeah, yeah.

So. So what I respect over time. So, last question. You've had such a great career at YouTube and CODA, and I want to bring the theme back to being selfless, right? Like, there just is. Some people get disillusioned with this whole corporate thing. Like, they're like, oh, you know, you gotta play politics, you gotta hoard headcount, you gotta do all this stuff to, to rise up. But like, do you have any advice for someone or how someone can be a selfless leader and kind of grow their career in a selfless way? Well, you've talked about a lot already, but any closing words of advice?

I mean, I think the, the. For a lot of people being selfless, there's a soft line between feeling like selfless and being taken advantage of. And so it's really important to frame it differently. And for me, the best frame for it has been pay it forward. So I think if, you know, a lot of times, one of my favorite questions to ask people when they're, they come, they ask for career advice, they ask for, you know, problem advice and so on. I'll ask them about who the role models are. Who do you feel. And by way of asking the question is somewhat specific. If you could take anybody's past and make it your future and feel totally happy about it, who would you pick? And like, it's an interesting way to. To think about, you know, what, how you frame your goals, your way of living, so on.