Lane Shackleton: preference

Transcript context

…Oh, man. So you mentioned your writing, you mentioned that this is something you want to write about. Shifting to the core topic of our chat, it's very clear that you spent a lot of time studying how great product managers operate and how great product teams operate. You've been doing a bunch of writing on the principles of great product management and also the rituals of great teams. And so I want to spend a bunch of time trying to extract as much as I can from your learning so that listeners can learn. Essentially what are principles of great product managers, what are rituals of great teams and generally how do the best teams operate? And my first question is just why is this something that you started doing? What pulled you into spending so much time and effort trying to understand how the best teams and people operate? Yeah. Yeah. I've been asking myself that question a little bit lately. There's a few reasons. One reason is I just found myself giving a similar set of advice in one on ones. And so I think anytime you find as a leader yourself repeating the same lessons, it should be a good flag to say like, oh, I should probably scale this in some way. And as you know, as soon as you write something down, you have to clarify your own thinking and so it becomes very useful for that. And I don't think I quite expected how useful it would be in that sense. Writing something down and then putting it out there, you start to get feedback back of where you might've been right or where you might not be right. And so for me it's been a good learning experience there as well. I think the second reason is I've always been pretty frustrated with career ladders. Most companies have career ladders with 10 or 15 levels and as soon as they hit some scale levels, there's levels between levels and I feel like I looked at the one at Google and you needed a PhD to decipher it and interpret how to operate within it. And so that's one piece of the construct. If you think more broadly though, they aren't consistent across companies, so now you're in a situation where you're in your version of the rat race. And so I found that I basically wanted to have a broader set of principles that transcended level. So things that could be true when you are an ICPM starting your career and things that can also be true when you're the head of product or running a product team or things like that. That's one. I won't rant further on that but I think that's one piece of it. And then I think the last reason I'll mention is I was pretty inspired by a talk that is by this guy named Brett Victor, who's like a prototyper thinker. May have heard of his work. He has this talk called Inventing on Principle. And in the early days of Coda, one of our first designers, this guy Jeremy Britten, showed this talk to the company and my mind was blown. And I think it was one of those examples of someone developing a clear view of what principles they should operate with and then following that principle. And it was just a meta example of how important it is and how impactful it can be when you decide on a principle and then follow it. And so ever since then I've been thinking what are my principles as it pertains to building software and other things. So those are the three reasons that led me to start writing these things down. Amazing. We're going to find that talk and link to it in the show notes. I want to ask about what principles you've come to, but I also want to understand how you actually ended up doing ladders and performance review stuff at Coda. Would it be better to talk about that later after we go through some of these things or is there something you want to share first of just how you think about it at Coda?…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.