Camille Fournier: Why PMs lose engineers to credit hoarding

1. 0:00 – 2:17

   Camille’s background

   1. LRLenny Rachitsky0:00

      (instrumental music) I'm curious what it is that PMs do that annoy engineers most.

   2. CFCamille Fournier0:04

      Hoarding credit. PMs, they tend to be the front-facing person for an initiative. Engineers sometimes think that they don't get the credit for their work because the PM takes all the glory and all the credit for the project that they really worked very hard on.

   3. LRLenny Rachitsky0:18

      I find the best PMs are the ones that talk the least and encourage other people to do the presenting.

   4. CFCamille Fournier0:22

      The next thing that engineers really get annoyed about with PMs, when they just don't understand the details and act like they don't matter. It just shows a real lack of empathy for the work that engineers are doing, and I think it really can be very off-putting.

   5. LRLenny Rachitsky0:34

      Is there any insight you can give about what people maybe miss about the motivation of engineers, what gets them excited?

   6. CFCamille Fournier0:40

      A lot of people assume that engineers just write code. Don't underestimate the ability for your engineers to... Who wants to understand the business problem, want to understand the customer problem. I think the product managers that have done the best, they're not threatened by other people having ideas.

   7. LRLenny Rachitsky0:59

      (instrumental music) Today my guest is Camille Fournier. Camille is one of the most respected technology executives in tech, and the author of The Manager's Path, which many consider the definitive guide for navigating your career and moving into management. Over the course of her career, she was CTO of Rent the Runway, VP of Technology at Goldman Sachs, Global Head of Engineering and Architecture at JPMorgan Chase, and Head of Platform Engineering at Two Sigma. She's also releasing a new book later this year called Platform Engineering: A Guide for Technical, Product, and People Leaders, which you can actually pre-order today, and we get into this topic in the latter half of the conversation. We also dig into what PMs do that most annoys engineers, and how to stop doing these things, why major rewrites are often a trap, why you may want to be doing fewer one-on-ones, what most surprises people when they become a manager, and some really useful heuristics for how long you should stay in IC before you make the leap into management, and tons more. This episode covers a lot of ground, and will help you think about management, platform teams, team culture, and the PM and eng relationship in a whole new way. If you enjoy this podcast, don't forget to subscribe and follow it in your favorite podcasting app or YouTube. It's the best way to avoid missing future episodes, and helps the podcast tremendously. With that, I bring you Camille Fournier.

2. 2:17 – 7:09

   Common annoyances between PMs and engineers

   1. LRLenny Rachitsky2:19

      Camille, thank you so much for being here, and welcome to the podcast.

   2. CFCamille Fournier2:23

      Thank you so much for having me.

   3. LRLenny Rachitsky2:25

      It's my pleasure. I want to start by asking you a question that is on the minds of a lot of product managers, is how to be less annoying as a product manager. I know you've worked with a lot of engineers over time. I'm curious what it is that PMs do that annoy engineers most, and how can PMs stop doing that?

   4. CFCamille Fournier2:42

      I would say there are a few things that PMs do that annoy engineers, and to be clear, I am sure that engineers annoy PMs just as much, so... And I realize this is a two-way street. So, I think there's some things that are really easy to fix, and some things that are maybe a little bit harder. So the easy things to fix are hoarding credit. Sometimes I think PMs, because they're, they tend to be the front-facing person for an initiatives, they're talking to customers, they're talking to the executive team, whatever. Engineers sometimes think that they don't get the credit for their work because the PM sort of takes all the glory and all the credit for the project that, that they really kind of worked very hard on, right? And so making every effort to be kind of credit sharing and inclusive of the engineering team, and giving them the opportunity to speak about their contributions when it makes sense, I think those are all things that PMs can do to avoid that kind of, that, that, what I consider kind of a pretty easy annoyance, right? Just like, don't hoard all the credit. This is not just you, right? There's a lot of work that has to go into that. I think that sort of dovetails into the next thing that engineers really un- get annoyed about with PMs, when they just don't understand the details and act like they don't matter. And I think this is just a little bit of a cultural difference, right? So like, if you are, I mean, you know, even managers, some, I mean just normal managers, right? People like me who are looking across really broad areas or you're, you know, you're, you have to be kind of big-picture focused, and you forget that engineering, done successfully, really is all about the details. And you don't necessarily have to understand all of those details, but when you act like they don't matter and you don't care about them, and it's just like, "I don't care, just like, tell me when you can get this done," or, "Why is it going to take so long? Oh my God," like, this just seems like such a little thing. You know, it just shows a real lack of kind of empathy for the work that engineers are doing, and I think it really can be very off-putting. Even though I will totally agree that sometimes you're going to get details that don't really matter, and you just have to be a little bit patient in those circumstances.

   5. LRLenny Rachitsky4:49

      (instrumental music) Today's episode is brought to you by DX. If you're an engineering leader or on a platform team, at some point your CEO will inevitably ask you for productivity metrics. But measuring engineering organizations is hard, and we can all agree that simple metrics like the number of PRs or commits doesn't tell the full story. That's where DX comes in. DX is an engineering intelligence solution designed by leading researchers, including those behind the DORA and SPACE frameworks. It combines quantitative data from developer tools with qualitative feedback from developers to give you a complete view of engineering productivity and the factors affecting it. Learn why some of the world's most iconic companies like Etsy, Dropbox, Twilio, Vercel, and Webflow rely on DX. Visit DX's website at getdx.com/lenny. Let me tell you about command bar. If you're like me, and most users I've built product for, you probably find those little in-product pop-ups really annoying. "Want to take a tour?" "Check out this new feature." And these pop-ups are becoming less and less effective since most users don't read what they say. They just want to close them as soon as possible. But every product builder knows that users need help to learn the ins and outs of your product. We use so many products every day, and we can't possibly know the ins and outs of every one.CommandBar is an AI-powered toolkit for product, growth, marketing, and customer teams to help users get the most out of your product without annoying them. They use AI to get closer to user intent, so they have search and chat products that let users describe what they're trying to do in their own words and then see personalized results, like customer walkthroughs or actions. And they do pop-ups too, but their nudges are based on in-product behaviors, like confusion or intent classification, which makes them much less annoying and much more impactful. This works for web apps, mobile apps, and websites. And they work with industry-leading companies like Gusto, Freshworks, HashiCorp, and LaunchDarkly. Over 15 million end users have interacted with CommandBar. To try out CommandBar, you can sign up at commandbar.com/lenny, and you can unlock an extra 1,000 AI responses per month for any plan. That's commandbar.com/lenny. By the way, CommandBar just changed their name to CommandAI.

3. 7:09 – 8:05

   Avoiding the telephone game

   1. CFCamille Fournier7:10

      The third is playing telephone. Anybody in a manager role can fall victim to this, but I think PMs especially can be very annoying. So if you are being asked questions that you cannot answer because you just don't know, right, because that's something that e- involves a level of technical detail that only the engineers have that you just don't have, and you're, you put yourself in this in-between position where people ask you questions, you turn around, you ask the engineers questions, you take whatever they say, especially when you don't really understand it, which happens sometimes, right, go back to the original asker and sort of get in this kind of middle person scenario, I think that is very annoying, and frankly, it's kind of a waste of time for everyone. This is something that managers of all stripes do, but PMs definitely do it, and that drives engineers, particularly sort of senior engineers on projects, crazy.

4. 8:05 – 9:55

   Hoarding ideas and over-engineering

   1. CFCamille Fournier8:05

      And then the last one that I wanted to put on this list is just when sometimes it feels like product managers want to hoard all the ideas for themselves, right? They want to be the ones that come up with every single sort of product idea and every single detail. And what, what I see happen in those cases is that I see engineers start to over-engineer things, because engineers are like, "Well, I need to take control of something," right? Like, "I, I want to have some creative outlet. So I'm gonna use my engineering skills as my creative outlet, and I'm gonna spend a lot of time obsessing over the right framework or the right this, that, or the other," that may actually not man- matter that much for products delivery. But when you take, you know, the people that are, that are part of the product project team out of the creative loop entirely, you just, you know, they're gonna find that creative outlet somewhere else, and it's actually kind of bad for the product.

   2. LRLenny Rachitsky8:56

      That's really interesting, the last one. So you're saying if you keep engineers from having a voice in what you're building and prioritizing, that's what encourages engineers to rethink, "Let's just rebuild this thing. Let's use a new framework. Let's rewrite this system."

   3. CFCamille Fournier9:09

      Yeah. I mean, that's, that's my, you know, it ... That happens, you know, without you doing that, right, sometimes.

   4. LRLenny Rachitsky9:16

      (laughs) Yeah.

   5. CFCamille Fournier9:16

      But I do think, I think when I, I see it worst and I can basically always predict when I'm gonna see a lot of that kind of engineers building stuff, you know, having, finding creative outlets and kind of building stuff maybe they shouldn't be, I'm gonna find that in places where they are so, you know, quashed, their creativity for the actual business or product that they're building and their, their voice in that is so ignored that they don't have any outlets in that space. And so they are gonna use the space that they have an outlet in, the place where they have some control, and that's usually, you know, the technology choices and the, and the details there.

   6. LRLenny Rachitsky9:54

      That's fascinating.

5. 9:55 – 11:37

   The importance of involving engineers in ideation

   1. LRLenny Rachitsky9:55

      Uh, I want to actually dig further into that, around rewrites, you have a really interesting take on that. But before we get there, let me spend a little time on some of these. These are awesome. So on this theme of not involving engineers in ideation and, uh, I- coming up with what you're actually building, what have you seen just very tactically? Is there anything you've seen a PM do super well?

   2. CFCamille Fournier10:16

      Um, you know, I think the product managers that have, have done the best, they're not threatened by other people having ideas. They're not threatened by, you know, the, the engineering team being full of smart people, uh, because they realize that like, yeah, like engineer, some of the engineers may have good ideas, but they still don't really know how to do the product job. Like I just, my experience is there are plenty of engineers who actually think they can be product managers and they don't really understand all of the elements of the product job, um, that they would need to be successful. And when, you know, when product managers take the time to, you know, kind of build those relationships well, make sure that people do feel like they can both share their ideas, but also that they start to appreciate what the job of this product person actually is and, and, you know, what they're really bringing to the table in terms of really, you know, how do we measure this input? How do we, uh, really understand the customers, right? How do we really think through, you know, kind of the, the, the details of what's gonna make this successful from a, from a, you know, business or a customer perspective? I do think that, you know, that, that creates just a much better, you know, interaction pattern. And then, you know, engineers can feel good about, like, sharing ideas and understanding that many of them won't, you know, won't go anywhere, but like, there's somebody that's actually gonna listen and take the time to, to care about

6. 11:37 – 14:21

   The middle-person dilemma

   1. CFCamille Fournier11:37

      them.

   2. LRLenny Rachitsky11:37

      Coming back to some of the things that you said annoy engineers about PMs, this, uh, idea of playing the middle person sounds like the solution clearly is there, just connect the engineer to the other engineer or your engineer to the PM that's trying to figure this out, right?

   3. CFCamille Fournier11:49

      That one's not always easy, right? Because again, you have this tension of a lot of the job of any management role is being in meetings, right, and, and, you know, filtering stuff so that people who are in, you know, focused individual contributor mode can focus and get things done and not spend half of their week in meetings. You've just got to be very careful about knowing when you're crossing that line and when you're crossing it too often.And, you know, if you're, if you're having to often say, "Let me get back to you, let me get back to you. I don't know, let me get back to you," maybe the person you're talking to is asking the wrong level of questions of you. Um, maybe you need to connect them to the engineers directly. But just being aware that that shouldn't be a default behavior. That will happen occasionally, but it shouldn't be a thing that happens a lot, because if it's happening a lot, then you're likely missing something, you're likely losing something in that telephone game translation, um, and that's gonna cause problems over time.

   4. LRLenny Rachitsky12:47

      Awesome. So basically, if you're just finding your middle person too much, then it may be time to connect people directly. And I know the reason PMs often are afraid of this is the engineer may agree to something that they think is a bad idea for their team, or may not understand all the ramifications of, um, the product, or, or just obviously just spend their time in meetings and not be building the thing.

   5. CFCamille Fournier13:07

      Yeah. Yeah. And l- you know, and like sometimes, I mean, you do it in a group, you know, you do it in a group meeting, you know? I feel like Slack and other chat-type things actually make it a lot easier to kind of see, have the right people in a group in a thing, but again, that's distracting, you know? So, so it, there's not an easy solution to that one, just I think it's important-

   6. LRLenny Rachitsky13:26

      Mm-hmm.

   7. CFCamille Fournier13:26

      ... to be aware of it.

   8. LRLenny Rachitsky13:27

      Yeah. That's a really good point. And then in terms of hoarding credit, is there anything, any tactical thing you've seen PMs do really well here or is it just like every time they're announcing the product, "Hey, these engineers were involved," or...

   9. CFCamille Fournier13:37

      It's more than just, like, saying, you know, "Thank you to all these people," but, you know, it's actually sometimes, like, stepping back and lets- letting other people speak, especially if it's something that's a really, really big technical lift. There's not, I don't think there's like a super easy, easy fix to that, 'cause I, I think it is just a, like, you know, just really being mindful that that's a, that can be very much a sore point for engineers when they just feel like, "This is my work and I'm not getting any credit for it and, you know, this person is hogging all the glory."

   10. LRLenny Rachitsky14:07

       I love that. Yeah. I, I find the best PMs are the ones that t- talk the least and encourage other people to do the presenting and, and announcing. And so I think that's a really good reminder is let your engineers do that. Okay. Amazing.

7. 14:21 – 20:40

   Rewriting systems: a big trap?

   1. LRLenny Rachitsky14:21

      So we talked a little bit about this idea of rewriting and how engineers sometimes just wanna rewrite the system, and I think a lot of PMs do it too. A lot of times, you're building your features on a thing that someone that doesn't even work at the company anymore built five, 10 years ago, and there's always this sense of, "Okay. Maybe we should just rewrite this thing. Everything will move so much faster." You have a really, uh, interesting take that I think a lot of PMs will love to hear, which is that rewrites are often a big trap and often don't end up being what you think they might be. Can you just talk about your experience and perspective on this?

   2. CFCamille Fournier14:50

      Yeah. So, uh, I mean, I have personally overseen a number of, if not quite rewrites, re-architectures, and, like, major system evolutions, and so I've, I absolutely do think they are sometimes a thing that needs to happen. But I also have seen so many instances of cases where the engineers have convinced themselves that the only solution to their, the woes they are experiencing with the system, it's hard to support, it's hard to change, uh, you know, nobody wants to work on it 'cause it's this old, crappy technology, is that they just have to go over to the side, build the new thing that will replace this old system, and that is going to sort of free them from their misery. And I think projects where you acknowledge that you do need to do an uplift, but you make a very thoughtful staged plan as to how you're going to do that and you, you really think through, "Okay. We don't need to touch all of this stuff, but we're gonna, you know, we're gonna take... The recommendation system really needs to be uplifted, and that's a well contained, you know, API. And so we can, you know, start to fix that without having to, like, change the whole whatever, web framework." Right? You know, so, so I do think, like, there, there are ways to do these evolutions, but people really underestimate. They underestimate the time to migrate stuff from the old system to the new system is a huge, huge problem, particularly when you're talking about systems where you have sort of external people, you know, using the system in some way, whether it's, you know, web UIs or, you know, APIs. You think, "Oh, we, we, we kinda know what's going on, so it's not gonna be that big a deal." Engineers notoriously, notoriously, notoriously massively underestimate the migration time for old system to new system, and that causes a lot of problems. By the way, you still have to support the old system while you're working on the new system, right? So I doubt many of the PMs in the audience are ever happy when they hear, "We need to go away for six months, a year, two years to build this new thing, and we just can't really add any features to the system in the interim." Like, that's infuriating, (laughs) I'm sure. And frankly, that's a problem, and I don't know that that should be an acceptable answer in many cases. There may occasionally, again, be a case where that is what has to happen, but I think most of the time, you, you can't really afford to just say, "We're gonna go away and we're not gonna touch the system for a long time and we're gonna build something new over here." So many things about why that doesn't make any sense. So this is a little bit afield of, like, my, the blog post that you're referring to, um, but, you know, so if you've got a system that doesn't really need feature enhancement or development because it's just sort of fine and the users are using it and it's like, it's sort of like, it's just annoying to the engineers, why in the world would you invest so much money in writing a new version of it? There's, there's a little bit of, like, a cognitive dissonance that sometimes happens. Like, if you need to do new stuff and the old system literally is not... It's not possible to do the new stuff that you need to do, you need to figure out a path to get to a sustainable system where you can continue to add and evolve. Right? You should be investing. And so there's a, you know, there, there does need to be an investment. But, uh, you have to ask yourself, like, "If I could go away and not touch this and not do anything to it for a long period of time without it really harming my business..."Is it worthwhile to change it at all? Like, does it matter? You know, there's- there's- there's just a little... There's some questions there. I also think that when people try to do rewrites, particularly, again, if it's something that you're really trying to just, like, move to a new language, for example, or you know, sort of modernize in a certain way, a lot of times people really underestimate what the old system does and how well they know what the old system does. You know, there's so much logic buried in legacy systems. It tends to be undocumented. It tends to be weird. You haven't thought through all the business rules. You haven't thought through the, uh, you know, the- the data, you know, the data formatting and I think, you know, again, it's much, much harder to kind of replicate all the important things from the old system to the new system than people, uh, expect. So there's, you know, there's more than that but like there are... The- I do think sometimes you need to evolve systems, and my advice would be when you're- when you're struggling, make an e- evolution plan. Take pieces, potentially, of the old system, uplift them, you know, make them more scalable, make them easier to work with, you know, clean up the tech debt. But trying to say, "We're gonna just go away, we're gonna rewrite, we're gonna build something brand new and it's gonna solve all our problems," it just very rarely works.

   3. LRLenny Rachitsky19:42

      I think a lot of PMs will be like, "Yes, thank you so much for saying this," 'cause I think that's also always a big struggle between the eng team and the PM team. So, just to summarize what I think a lot of people miss, or what you're saying a lot of people miss when they're thinking about "let's rewrite this thing" is the migration to the new system, migrating customers, users, data to the new thing is gonna take a lot longer than you expect. You underestimate knowing what it actually does and you're gonna miss features and- and there's gonna- you can introduce new bugs. This actually is very similar to what I've seen with redoing, like redesigning a whole up- up product flow. There's always this sense of like, "Let's just rethink this onboarding flow from scratch," or, "Let's rebuild this, um, part of the product," and, uh, always it ends up being a negative experiment result. Like, it always ends up being less good, and then you have to spend all this time clawing back to get to where you were, and also you forget the stuff that would... like the features that you had and you're like, "Oh, shit, forgot about that feature, forgot about that feature." So, it's interesting there's a very similar, uh-

   4. CFCamille Fournier20:38

      Yep.

   5. LRLenny Rachitsky20:38

      ... situation in- in the product side.

8. 20:40 – 36:02

   Engineering leadership lessons

   1. LRLenny Rachitsky20:41

      Okay, amazing. I'm gonna go to a slightly different topic, which is around engineering leadership. So, I know you s- you've written a lot about engineering leadership, you spent a lot of times with engineering leaders, so I have a few questions here. One is that I know that one of the things that haunts engineering leaders most is finding the balance between staying technical in their technical expertise and their leadership expertise, and basically finding the right altitude of how high, where to be in the org and also how in the details to be, and also staying technical enough to be relevant. What have you learned, kind of in your own experience of finding that balance, and how do you advise engineering leaders as they struggle with this?

   2. CFCamille Fournier21:18

      Yeah. Um, so one piece of advice I give everybody is don't stop being a hands-on technical until you feel like it's in your bones, you feel like you've got mastery, that you could... You- if- if you know a second language fluently or if you, like, played an instrument like really, really seriously for a long time or maybe a sport really, really seriously for a long time, you'll be familiar with the, "I haven't done that in a long time, but if I was to pick it up, I would be rusty, but I would get there pretty quickly," right? Maybe, you know, physically, I wouldn't be as strong as I was as, you know, or whatever, but like, I would get there. There- you can do that with writing code. You can do that with, you know, technical skills. If you do it for a long enough, I think you can develop sort of a baseline mastery where, like, you're not gonna be as fast and, you know, a lot of the challenges of being technical is actually in all the tooling and all the tooling evolution, but you know, you're not gonna be necessarily as fast as people who have been doing it, but you won't be completely clueless. And I think that all the things you learn getting to that really comfortable mastery of some part of tech, hands-on tech, will stay with you and will help you just sort of maintain a level of confidence in your own, you know, technical know-how, uh, and maintain a level of kind of empathy for what it means to be a good engineer, and I think just make you a lot less anxious about being hands-off, even though I think everybody who makes that transition for a year or two, especially if you're really like han- have to be hands-off because you just don't have time to write code at all, you know, you are gonna be anxious for- for a while, no matter what. The things to then think about from that point is like, you know, being technical is also just about, like, knowing what's going on and paying attention and, you know, being able to ask... What- what people care about with technical leaders, in my experience, is they want people who actually seem like they sort of understand what you're doing and can ask good questions and help guide you to better decisions without actually being the one who's like, "Oh, no, you need to use this library instead of that library," right? Like, it's actually sort of annoying when somebody that's very senior and like hands-off tries to tell you, "Don't use this library, use that library," because I don't know about you, but like, I don't really believe people who have been hands-off for that long when they try to tell me what to do in the thing that I'm kind of the expert in right now. But I do appreciate it when I'm given more, like, guidance around, you know, "Well, have you considered this?" Like, "Tell me about how you're planning to- to handle that situation. What are the major technical challenges with implementing this?" And that can actually spend the time to listen and ask thoughtful questions on the back of that. The last thing I would say is, like, surround yourself with smart, technical people also as much as you can, and you know, be- be willing to, like, listen to them talk about tech and ask them questions about things. I just- I feel like that's part of the reason that I'm able to stay kind of technically savvy and credible amongst people who work for me is not that I'm writing code, 'cause I'm not, but I am listening to a lot of very smart people talk about technology a lot-... down to the level of, like, "I'm trying to debug this database issue, like what the heck's going on?" And just constantly being interested in those stories and learning from them. And learning what really smart engineers are thinking about and worrying about. You know, the more you can build that network of, of people, you know, that are still hands-on and kind of, you know, stay in touch with that, I do think that, that helps a lot.

   3. LRLenny Rachitsky24:56

      So my last point, how, how are you actually doing that? Is it like watching, going to conferences with friends?

   4. CFCamille Fournier25:01

      Yeah. Yeah. I mean, I guess for me it, it started with, like, going to conferences, meeting people. You know, now I'm in a lot of different, like, chat groups where people are just sort of, you know, regularly communicating. Um, you know, staying in touch with, you know, staying in touch with former colleagues. It's, it... You know, I, I will admit, I'm kind of a social person and I have a big network, so this may be easier said than done. Um, but I do think like, you know, being in the right group chats... And I also think, like, I'm sure reading various, you know, tech news and tech, tech sort of commentary, uh, and discussion boards, I mean, it's definitely a mixed bag of that stuff I think-

   5. LRLenny Rachitsky25:41

      (laughs)

   6. CFCamille Fournier25:41

      ... but like... But there are smart people. There are, you know... You find the smart people in there, you sort of follow what they're saying. I think that's another good way to kind of keep that, keep that perspective.

   7. LRLenny Rachitsky25:51

      Is it a sign, I wonder, if you're not interested in that anymore, that maybe you should move into something else? I don't know if you're like-

   8. CFCamille Fournier25:56

      Well-

   9. LRLenny Rachitsky25:57

      ... you don't really pay attention to engineering or technicalness.

   10. CFCamille Fournier25:58

       You know, it, I... It's hard for me to say, 'cause I'm just like, I'm such a nerd.

   11. LRLenny Rachitsky26:03

       (laughs)

   12. CFCamille Fournier26:03

       I just, I really, I really love tech. Like I, I'm in, I'm in this industry 'cause, like, I'm just, like, actually genuinely very interested in certain, certain corners. Not every corner of technology, but certain corners of technology. I just like, I wanna know, I wanna know what the latest stuff that's happening in databases and infrastructure and, you know, I just... I find it all very interesting.

   13. LRLenny Rachitsky26:25

       Mm-hmm.

   14. CFCamille Fournier26:25

       I find the problems interesting. So I think that makes me very successful because I just have that natural curiosity and passionate interest in it. But, you know, I don't know that that's a total prerequisite.

   15. LRLenny Rachitsky26:36

       Yeah. Uh, what you've been talking about reminds me a little bit of this guy, LevelsIO on Twitter. Have you heard of this guy? He was just on Lex Friedman. Have you listened to that yet?

   16. CFCamille Fournier26:44

       I think maybe I saw a clip of, a clip of it-

   17. LRLenny Rachitsky26:46

       Okay, okay.

   18. CFCamille Fournier26:47

       ... but I haven't listened to it.

   19. LRLenny Rachitsky26:48

       So I think he's, he's one of the most successful indie engineers where he just works on his own thing all by himself, never raises money, just launches products that make money.

   20. CFCamille Fournier26:55

       Yep.

   21. LRLenny Rachitsky26:55

       And, uh, a funny thing about him is he works... All, all stuff is in PHP and jQuery. He's just like, "This works. Like, I've always had this to-do, learn Node.js, learn Python." And I'm like, "I'm too busy to build while I'm building to learn these new things." And, and he's been incredibly successful. So it touches on, like, sometimes maybe you don't need to just keep rewriting to the newest frameworks.

   22. CFCamille Fournier27:16

       Yeah. No, I mean, look, I actually... I feel like I know a lot of smart engineers who are in that category. They're like, "We build amazing things in PHP and, you know, relatively simple SQL," and so much of tech is over engineering things and... You know, and, and I think it... I, I don't, I don't totally disagree. I think the challenges though, of course, like, what works as a one person show doesn't always work in a scaled organization. For better, for worse, for indifferent, like. You know, you've got to, you know, you've got to match, like, what makes one person really productive. Will it make 100 people, 1,000 people, even 10 people really productive? You know, it's, it's always a little... That's always a little hard to, to tell, and that's why I do think you should be, like, not... I think it's always a good idea to be take... Keeping up with what's happening and what's changing, in whatever kind of side of tech you're in, but not obsessively chasing every fad. I think that, you know... I think being aware of, but not necessarily chasing them, but particularly if you're working in, you know, groups, teams, larger companies, even mid-sized companies, you know, there is some amount of, like, you're balancing the, the tech that makes one person go fast with the tech that makes 10 or 100 people go fast. And those are not always exactly the same thing.

   23. LRLenny Rachitsky28:35

       Just to kind of follow this thread a little bit, uh, and to kind of, uh, nerd snipe you a little bit, is there like a, a platform or language or framework these days that you're either very excited about, that you think is helping people move faster and do better work, or the opposite, just like, "Mm-mm. This is, uh... Everyone's excited, but this is not good"?

   24. CFCamille Fournier28:52

       I will say this. One, one example I actually put in my own notes for this, for this, uh, conversation was GraphQL. I would not tell a team to use or not use GraphQL at this point, because it's a bit out of my expertise zone and my level of management. It's not really my job anyway. But it is one of the things that is both popular and thought relatively poorly of by most of the senior people that I know. Uh, and so I guess I would say, like, that's one where I would say if you're seriously thinking about it and you're not, like, Facebook (laughs) -

   25. LRLenny Rachitsky29:31

       (laughs)

   26. CFCamille Fournier29:31

       ... you may really want to be... You may really want to make sure you know what problem you're trying to solve. Because the impression that I have from sort of listening to people talk about it, is that GraphQL is kind of trying to promise front-end engineers that they don't really have to, like, collaborate with back-end engineers and they can just sort of build whatever and it'll all be fine. And it just doesn't ever seem to work out that well for anybody who actually does it in practice. Again, obviously it can work out that well because, you know, Facebook has made a great go of it. I'm sure there are other companies that are. But that's one where, like, it's not that new, but it's... You know, it remains one of these things where it seems like a s- an interesting fad that, that, uh, maybe is burning a lot of people.

   27. LRLenny Rachitsky30:13

       That's awesome. I appreciate you sharing that. Uh, I don't know if this is exactly an example of this, but, uh, on that podcast, LevelsIO... Forget his actual name, Peter, I think, shared that whenever there's a framework that has a VC-funded startup behind it, uh, that's not a good sign 'cause their job now is to convince engineers to use it and then pay for it. And that's not necessarily gonna be the best product.

   28. CFCamille Fournier30:34

       That, that's true. Although, I will say that like some of the, some of the most, uh, time-wasting frameworks have also just come out of big companies, right?

   29. LRLenny Rachitsky30:41

       Mm-hmm. (laughs)

   30. CFCamille Fournier30:42

       (laughs) Or the context of the big company that may have made that framework super useful within that context-
9. 36:02 – 40:32

   Moving from IC to management

   1. LRLenny Rachitsky36:03

      On the topic of moving into management, you wrote maybe the definitive book on engineering manager career path. And so, when someone moves from IC to management, what do you find is the most surprising thing to them? What do they most often not understand or ins- are surprised by like, "Oh, man, I did not see this as part of my job or life"?

   2. CFCamille Fournier36:24

      Yeah, I mean, I think there's a few things. I do think, I, assuming that they're actually trying to do it well, I do think there are a lot of people who move into management and then just don't really understand the job at all, and aren't e- aren't even self-aware enough to know that they don't, uh, don't understand it. But for those who are trying to do it, trying to do it well-I think a few things that tend to surprise them are the fact that, like, you really don't own your time as a manager. Your, your team and your management and the company owns your time more and more the more senior you become as a manager. You know, I think individual contributors often think that like if they become a manager, they will, will still have some of the freedom that they have as a senior individual contributor, but then they'll also be able to tell people what to do and, you know, they'll have all this authority. And the reality is, you know, management is, is much more... I'm not a huge fan of servant leadership exactly, but management really is a service job. You are serving the team. You are serving the company. Your job is to, you know, is to help make things better, and that usually doesn't mean that you're making all the decisions. It usually doesn't mean that people... that you snap your fingers and people jump. You know, you know, and if... because if you try that, especially in tech, right, people are just gonna revolt. They're not gonna listen to you. You know, you, you don't... it, it's just too hard to have, um... that's not the culture that we live in, and I don't think that's a good culture, right? I don't think that command and control, I tell you what to do and you do it, that just doesn't create creativity, right? It's the same thing as like PMs trying to have all the ideas, right? Like, you know, no, you've got all these brilliant people working for you on a team. Your job as a manager is not to tell them what to do in every single case. Occasionally, yes. A lot more you're trying to convince them of, you know, what you think should happen in some ways. You're trying... you're sort of nudging, you're encouraging, you're directing, you're setting guardrails for, for, for, you know, processes or behaviors or whatever. But it's just... it's not... it's not this, like, glorious, uh, you know, fearless leader, "I make all these decisions and everyone looks up to me" and, you know, you know, it's awesome kind of job. It's a much more... it's much more grueling, much more, you know, you are really just sort of reacting to things in the moment, and it, it can be very... it's a hard job. I do think, like, management, particularly management when done well, when you're really trying to, to do it in a thoughtful, kind, you know, but also productive way is a very hard job.

   3. LRLenny Rachitsky39:06

      I wonder if engineering is where most... where the highest percentage of people that move into management move back to IC. I've seen that a bunch, and I wonder if engineers are the most common.

   4. CFCamille Fournier39:14

      I, you know, I don't know, but, um-

   5. LRLenny Rachitsky39:18

      After realizing what you just said is true-

   6. CFCamille Fournier39:20

      Yeah.

   7. LRLenny Rachitsky39:20

      ... like, oh, what have I done?

   8. CFCamille Fournier39:20

      And do you not think... so do you not think product managers also do this? Because I think product managers also actually suffer from exactly this kind of thing-

   9. LRLenny Rachitsky39:28

      They do.

   10. CFCamille Fournier39:28

       ... sometimes.

   11. LRLenny Rachitsky39:29

       They do.

   12. CFCamille Fournier39:30

       Well, the... yeah.

   13. LRLenny Rachitsky39:30

       But interestingly, I was an engineering manager earlier in my career. I really did not like it. I was very unhappy in that role. As a PM manager though, I was very happy. It was a lot easier and-

   14. CFCamille Fournier39:43

       Oh yeah, 'cause PMs are way easier to manage. PMs are awesome to manage. PMs want to, like... they're just so helpful.

   15. LRLenny Rachitsky39:51

       (laughs)

   16. CFCamille Fournier39:52

       (laughs) They like want to do this. They're good communicators. I love managing PMs.

   17. LRLenny Rachitsky39:57

       Mm-hmm.

   18. CFCamille Fournier39:57

       I have to say, I have to say. I just like my experience. Engineers are such a pain. They are all prima donnas. They're all... no.

   19. LRLenny Rachitsky40:04

       That's, that's-

   20. CFCamille Fournier40:05

       I love, I love eng-... I am an engineer, but like PM ma-... PMs are more fun to manage in my experience. So actually you have a point. You have a point.

   21. LRLenny Rachitsky40:12

       But I wonder, yeah, 'cause I've been seeing a lot of PM managers move back to IC product management. I find that once you can build product through teams and not sit there all day in Excel and check in on deadlines and things, like you... it's hard to give that part up. You kind of enjoy being like higher up in that chain.

   22. CFCamille Fournier40:30

       Yeah.

   23. LRLenny Rachitsky40:31

       Yeah.

10. 40:32 – 45:10

    One-on-one meetings

    1. LRLenny Rachitsky40:32

       Kind of along these lines, something that you have a really interesting perspective on is one-on-ones. Most people are like have one-on-ones with everyone, have them regularly. They're really important. You actually have this contrary take that maybe you should have less one-on-ones, especially as an en- engineering manager. Can you talk about that?

    2. CFCamille Fournier40:47

       Yeah. So, so to be clear, I... you should have one-on-ones with your direct reports and your manager, and you should, you should hold those sacred. I try... tend to do mine weekly or maybe every other week. So this is not about that set of one-on-ones. The one-on-ones are the people that you are directly managing and with your own manager, but I think there is this... I think... I don't know if it's the remote work, you know, sort of explosion that's happened or it's big companies or what, but what I've seen and I've heard a lot of friends at many companies, you know, kind of complain about is this idea that like everybody is doing one-on-ones with everyone else. So the manager is doing one-on-ones with their team. They're also doing one-on-ones with all of their peers. They're doing one-on-ones with all of their stakeholders. They're doing one-on-ones with product and design and, you know, and I think that this is just... it's just not a scalable approach, right? Like you linearly scale with the number of relationships you have. And so as your company grows, as the number of things your, your team support grow-... supports grow, as y- you know, the team grows, you just can't scale that way. You cannot expect to maintain a one-on-one approach to kind of organizational relationship building and awareness past a fairly small team/company. Um, I also think that like people think that one-on-ones will solve all of their problems. Um, and I think the reality is like, you know, we have... you have these one-on-ones with people that don't really want to have a one-on-one with you. If they're not in the mind to invest in your relationship, you know, if they don't... if they don't really care about what you're doing, they're actually may not like it that you're asking them for a one-on-one. That may show up 'cause it's like, okay, well, I should do this to be a good, you know, corporate citizen or whatever, but they're just like, "Why are we doing this? Like, what, what is the point of this?"I also think that, like, one-on-ones, particularly when you use them for sort of stakeholder management, so when you're meeting with people that's not your team but, like, other stakeholders y- you know, that you may need to deal with, if you have a lot of stakeholders... So I've been in a lot of positions where I have a lot of internal stakeholders 'cause I build internal platforms. It's a big part of what my job has been in the last many years. Having all these meetings and... as one-on-ones with those stakeholders can actually be kind of a weakness because when your stakeholders just tell you in a one-on-one that they're, they're happy or unhappy with things, your unhappy stakeholders kind of aren't hearing that. So you may have, like, one really unhappy stakeholder and five really happy ones, and all you're saying to your unhappy one is, "Well, everybody else is happy." And they're not seeing it for themselves; they're just having to say trust me because I've, I've just had these other one-on-ones with all these people, and they're saying it's fine. And it just kind of sounds whiny. And so, you know, when you're, when you're dealing with a lot of stakeholders, I think trying to just rely on one-on-one management of that is actually not very productive in a, in a lot of ways. So, in general, I guess I just think, like, people should respect their own time more. As much as I just said management, you know, you're kind of at everyone's mercy, and that is true, but also, like, respect your time. You know, don't just load yourself up with meetings because you're a manager and that's your job. You know, are you, do you really have something to talk to a person about? Do you really need to, you know... These are... You're, when you have a one-on-one meeting with someone, you are asking for their time. You are... You shouldn't just be doing that kind of haphazardly for fun. This is a little bit of my personality. I'm not a great, like, I'm not a great, like, company networker. Like, you know, some people are really good at just, like, "Let's go get coffee, let's go to lunch, and let's, like, hang out and l- build a relationship." And honestly, those people are really successful in many ways that I am not. Like, I, I do sort of envy that skill. I'm really good if you wanna, if I work with you. Like, if I work with you on something, generally speaking, people really come to respect me because I'm very, like, engaged and, you know, I'm a really good collaborator in, in various ways. But I'm really bad at, uh, just, like, getting-to-know-you random one-on-one where we don't have a purpose to the meeting. And that's not to say those are always bad. Uh, you know, but I do think that a lot of people, was that's your comfort zone, if that, like, getting-to-know-you random, you know, relationship-building one-on-one is your comfort zone,

11. 45:10 – 45:27

    Pushing beyond comfort zones

    1. CFCamille Fournier45:10

       like, I should probably do more of them, you should probably do fewer of them, because you should always be pushing yourself to get out of your comfort zone. And, you know, are you really getting something out of that, or are you just being able to tick a checkbox that says, "I had-" Mm-hmm. "... eight meetings today, therefore I was productive." Yeah.

12. 45:27 – 48:01

    Building a balanced work culture

    1. CFCamille Fournier45:27

       That super resonates. So kind of pulling on this thread of how you operate and how you work, something that I've heard you're really known for is creating a, a work culture where people work really hard but also have a really good work/life balance. And when we were chatting, you, you actually told me you don't, you're not a great believer in working too hard. Can you just talk about this philosophy on building great culture where people don't work too hard but also, you know, get stuff done and don't burn out? I think we all understand that if we could just figure out and focus on really the most important things, we would just, everything would be better. And it's hard to figure out what the most important things are, but overwork kind of lets you just sidestep doing the hard work of figuring out what's important in the first place. You know, you... I li- I listened to one of your podcasts where you talked to someone who said, like, if you've never fired someone and regretted it, you don't know where, like, the line is- Hmm. ... uh, you know, who you should and shouldn't fire. And I will admit I have mixed feelings about that, although I, yeah, I get what he's saying. If you don't regularly, like, reset your expectations of, like, what you should and shouldn't let slide, do you have any idea where the line of what is actually important to work on is? Like, I just think... And the thing about that is, like, it's not like firing people where you do it once or twice and you regret it and you, and you learn pretty quickly, unfortunately. I think you actually have to kind of regularly test the circumstances and, you know, challenge yourself to, challenge yourself with, like, am I really, you know, am I really getting the most out of myself? Am I really producing the best value? You know? Or am I just making, assuaging my internal guilt about, like, you know, I need to work 60-hour weeks, I need to sleep in the office, I need to whatever to show that I'm, like, a hard worker and I, and I care? And so I, I guess I just, I do really think that people should challenge themselves to be focused and get the important stuff done and always be asking themselves what is important to do. And what import- what's important to do does change over time, but if you never... If you're n- if you're not regularly doing an audit of your time and trying to knock things off that list that don't matter, you're probably wasting a lot of time on things that don't matter. And okay, you don't want to work less, you love working a lot, that's fine, but you could probably just be getting a lot more valuable stuff done if you would do these audits regularly,

13. 48:01 – 54:15

    Effective time management strategies

    1. CFCamille Fournier48:01

       right? I also think, like, people don't delegate enough. Mm-hmm. And, you know, so if you don't delegate, then you get overwhelmed because your team doesn't know how to do anything because you haven't bothered to spend the time delegating, which actually takes more time initially, usually, because you have to teach people whatever it is that you're trying to get them to do. Not always. Sometimes they'll surprise you and they're better at it than you are, but, you know, maybe not, and so you have to teach them. But then you finally, you freed yourself up to scale. Uh, so I guess I just, like, I'm just a real believer that e- working hard in a focused way for le- bo- over fewer hours, I think, is a more productive way to approach work, and I think it, you know, and I think I've-You know, I have lived my career that way. I've been, you know, successful in it and I have encouraged it and people who have worked for me, and I think I've seen a lot of success through it. But it's just... It's, it's not a thoughtless exercise. It's an active process of constant reflection to get to, you know, that, that, that focus.

    2. LRLenny Rachitsky49:11

       For someone that is listening to this and is like, "I want to start doing this," is there anything, any specific practice you've found useful or any specific tactic to actually do this well?

    3. CFCamille Fournier49:23

       You know, I think there's different, there's different approaches you could take, right? Like, one approach you could take is just, like, every Friday I'm going to stop working at 4:00 PM or something, let's say.

    4. LRLenny Rachitsky49:33

       Mm-hmm.

    5. CFCamille Fournier49:33

       And I am not... Or I'm not gonna let myself work this weekend. Forcing yourself to log off, forcing yourself to, like, have, have, uh, you know, sort of boundaries and saying, "What did..." You know, and then doing of, like, what did I get done? I, I think can, can help. You know, that's scary and people don't like doing that, but I do think that that's one of the best ways to do it, is really just saying, like, "I'm going to log off. I'm going to log off every day this week at 6:00 PM." I'm going to... You know, because your brain is probably gonna keep thinking. You might still be a little stressed out and you're still thinking about work, you're still worrying about it, but there is a difference between thinking about it and doing it. And particularly for those of you who are earlier in your careers, like, this was actually, I think, one of the reasons that I did get to mastery, was because I was extremely good at being focused when I was at work when I was a, when I was a hands-on programmer and really writing code for many of the hours of the day. And that meant I was, like, not... You know, this was pre- pre-heavy social media. I was much less distracted, which I don't know if I would be able to do it in the modern era as easily, but, you know, having that, like, real heavy focus time because I was like, "I don't want to work on the weekend. I don't want to stay here until 9:00 PM every night. Like, I just want to get this done." And it meant that, like, I didn't do quite as many coffees. I didn't, like, go to lunch and chat with people all, you know, all, every day. But I was very, very productive and I learned to get a lot done in a short period of time and I do think, you know, learning those skills earlier in your career and then continuing to apply them throughout your career is another, is another piece of advice.

    6. LRLenny Rachitsky51:16

       In terms of staying and getting focused, is there anything that helps you focus? Is it, like, headphones, a drink? Like, what gets you in the zone?

    7. CFCamille Fournier51:24

       I mean, yeah. I have a lot of, like, rituals.

    8. LRLenny Rachitsky51:27

       Oh.

    9. CFCamille Fournier51:27

       Like, you know, I have my, my, my s- my caffeination rituals. (laughs)

    10. LRLenny Rachitsky51:31

        Say more.

    11. CFCamille Fournier51:32

        Well, I mean, like, I, I can't drink coffee anymore 'cause my stomach got messed up at some point, but I drink, I drink tea in the morning. I have, I drink caffeinated water also. Um, you know, I have, like, a Diet Coke at lunch. So I have, like, these, like, sort of rituals of, like, you know, my, my caffeine hits that, that help me. I, I have to be in a quiet place. Um, I do find, like, non-music that is, like... Like, I really like Four Tet, for example, as, like, music to focus, or the new André 3000 flute album is extremely good for focusing-

    12. LRLenny Rachitsky52:07

        (laughs)

    13. CFCamille Fournier52:07

        ... where it's, like, not quite predictable.

    14. LRLenny Rachitsky52:10

        Check that out.

    15. CFCamille Fournier52:10

        No lyrics and not quite predictable. For me, that helps me focus a lot. Like, I can't be listening to any words and focus. My brain will just... You know, cannot, like, ignore words. Um, so those are some of the things I use to help focus.

    16. LRLenny Rachitsky52:24

        That is awesome. Uh, I have a similar caffeine strategy. I'm drinking tea always during these podcasts in this little thing I got here, and then... My wife doesn't want me to drink Diet Coke 'cause she thinks the sugar in it is not good, but I still drink it sometimes and it works for me. I switch to green tea. That's my approach.

    17. CFCamille Fournier52:38

        Okay.

    18. LRLenny Rachitsky52:38

        Start with black tea and then switch to green tea.

    19. CFCamille Fournier52:40

        Oh, that's smart.

    20. LRLenny Rachitsky52:41

        Oh, man. There's so many things you shared that I wanted to dig into. Let me share a couple of things. Your point about delegating I thought was really important, and I... There's another benefit to learning to delegate, which is team members feel empowered. You give them a chance to take on responsibility and they feel like, "I have an opportunity to show I can do this other thing."

    21. CFCamille Fournier53:02

        Yeah. And, like, like, you just... You're never gonna scale if you don't delegate.

    22. LRLenny Rachitsky53:06

        Yeah. And it's hard to l- start learning to do that. But once you get good at it, it becomes so great. I love... Just delegate everything every time and everyone... And people enjoy it. They're like, "Amazing. You're giving me opportunity." The thing you said about how, uh, s- some... If you're not cutting... If you're not sometimes regretting something you cut or potentially firing someone you don't regret... Elon actually... Elon Musk has a great approach to this. I don't know if you've heard his philosophy on optimizing. He has this whole five-step process of, like, figuring out how to optimize something and one of them is cut, try to cut things. Like, do we need this thing or not? And if you don't recognize that 10% of the stuff you cut you... Was a mistake, you're probably not cutting enough stuff.

    23. CFCamille Fournier53:45

        You'll have to figure out your own, your own metrics, but I definitely think testing, testing the limits... It's scary though, I'm gonna, I'm gonna be honest. Like, doing that is always scary. It brings up, like, you know, "I forgot to finish the assignment" nightmares of school, you know? Um, especially for s- the overachievers that often end up in these kinds of, you know, companies and jobs. But, you know, if you d- Again, you gotta do things that scare you or you're never gonna grow, so...

    24. LRLenny Rachitsky54:14

        Mm-hmm. Okay,

14. 54:15 – 1:02:42

    Advice for platform team success

    1. LRLenny Rachitsky54:15

       I'm gonna go in a whole different direction. You've got a book coming out about platform engineering and platform teams. This is something that I get a lot of questions about. A lot of people are thinking about moving to a platform team, are struggling working on a platform team, or struggling working with a platform team, so I have a bunch of questions along these lines. The first is, I asked a bunch of people that worked with you what to ask you and someone that worked with you shared this quote about, uh, his frustration working with platform teams that he's often complaining to you about. And, and he works on customer-facing products and so he said, "Platform teams are often slow. They're often pushing us to compromise on features to adopt their systems. They often get infinite funding even though they have no... Don't have to show any ROI."And so, maybe from the perspective of working with a platform team, say you're building something customer-facing, any tips for effectively working with a platform team and building this great relationship there?

    2. CFCamille Fournier55:08

       I'm very sympathetic to anybody who feels that way because part of the reason that I, I wrote this book, I co-wrote it with a, a friend, Ian Nolan, is that so many platform teams are guilty of all the things that he's complaining about, that, that, that, that my, my friend was complaining about. That, like, they don't listen, they're not delivering effectively, they're not explaining their value to the company, and it is infuriating (laughs) when you're, when you're, when you're dealing with that. And I, honestly, I'm very sympathetic. You know, the thing that I would say though is, the more you can, first of all, like, spend the time understanding that... The platform team's problems a little bit and trying to collaborate and work with them and, and be clear about what it is you actually need and how you're willing to work with them, I think the better, right? I think if you just, if you get mad and you just try to avoid them or, like, you know, undermine them or whatever, that, you know, may work in the long run, but it's just gonna make everything worse in the short run. Um, and so I do think that, you know, if you've got a platform team that you're frustrated with, some tips I would, I would add, I would put are like, look, find the parts of that team that are good, 'cause I'm sure there are some, right? Maybe the databases team is awesome. And really make sure you are maintaining a good relationship with that part of the team, and you can point to how you are collaborating extremely well with that part of the team. Help give them product feedback. The... It is, this is annoying, but sometimes needs to happen because a lot of companies, I actually think product, you need to have a product mindset, and frankly, you need to have product managers to build good platforms, internal platforms. A lot of companies just don't do this. They don't believe that they should waste headcount on product managers for internal teams. So you end up with this, like, platform team that has a lot of smart engineers, but they don't really know what to build, and so they're just sort of building whatever they think is right. And so sometimes your job is to product manage them, is to tell them, like, "These are the problems that we have, and this is what we need." And, you know, the clearer you can be about that, particularly when they don't have a product team, oftentimes you can kind of lead them from the side in that way. And so I think that's another approach that I would take when you're, when you're in that situation. Find the parts of the team that are working and, you know, working, working well with your team and make sure you develop those relationships, and, you know, try to just get over the, like, anger and frustration, and just be clear about what it is that you need, and help them understand what they should really be doing and building.

    3. LRLenny Rachitsky57:48

       That is really interesting advice. So especially you're saying if they don't have a PM helping make sure they're guiding things well is h- you can help them... Basically help them think through stuff that will benefit them and also help the stuff that you're trying to get done.

    4. CFCamille Fournier58:03

       Yeah.

    5. LRLenny Rachitsky58:03

       That's awesome advice. Okay. So what about from, uh, the leadership perspective trying to build an effective platform team? Do you have any advice on how to structure these teams and incentivize these teams to help them be successful?

    6. CFCamille Fournier58:17

       First of all, I really, I'm a very strong believer that, like, platform engineering has to involve software engineering. If you don't have any software engineers on your platform team and you only have, like, you know, more, like, operation systems engineers, DevOps, SRE, which I realize there are some SREs that are software engineers, but they tend to not wanna write, like, big software. I think you're kind of missing the picture. So, you know, platform engineering is not just, like, you know, maintaining cloud infrastructure and doing, like, small scripts or blueprints or enablement projects for other teams, 'cause that doesn't really create a cohesive and coherent platform. It doesn't really create... It doesn't create products, right? And, and frankly, you need to be... Platforms are products ultimately. Um, you're, you should be thinking about, "How do I create sort of coherent offerings that make this company more productive?" So you need software engineers. Yes, you need sort of operations systems SRE specialists as well. And of course, you need product people. I'm, I have had, you know, product teams on, uh, product managers for my, for all of my platform teams. I've really developed out that, that practice, uh, in the companies that I've worked for doing this, because I'm a just... I just believe that, like, it is n- you're not gonna get great results if you just leave that to engineers and engineering management. They will do their best, and you do occasionally find engineers that have really great product instincts in this space, but the actual details and focus of the product work is just n-... You can't write a bunch of code or, and/or manage, like, a big soft- software engineering team and be a product manager at the same time. That's actually just asking, I think, too much of people to do that really well, at least for very long. So I think, you know, when it comes to structuring a team, recognize, like, this is not just, like, SRE V2. This is, this is more than that. You want software engineers. You want systems engineers. You want product people, and then you... One of the reasons you want product folks is because you want to be thinking about, like, impact-based, outcome-based, uh, approaches, not just, like, "Well, we built this thing that seemed cool. We adopted this technology from this company because, you know, that's what everybody on the internet is talking about, whether it's, you know, VC-funded or, or a big company." You know, like, like, we actually, like, thought about, "What are the problems the engineers at my company are facing? How can we improve their productivity or deliver leverage to this business through whatever it is we're building," right? Are we reducing the cycle time for engineering tasks? Are we solving problems that are preventing products from launching and scaling?All right. Are we, you know, making really meaningful cost reductions or efficiencies and, you know, in our products or in our, you know, in our platforms? These are some examples of, you know, measurable contributions, but, like, I think one of the challenges is that people create these platform teams and think that they can be sort of divorced from having an impact focus, because it's like, "Oh, you've just got to run the infrastructure and, you know, make sure it works." And it's like, no, you, you actually do still have to do, you have to do that OKR stuff or goal setting or, you know, whatever. You've got to take a lot of the best practices of product. It's a little different in an internal world, but it's still very important if you want to do platforms.

    7. LRLenny Rachitsky1:01:45

       On the line of having PMs within the platform teams, some of the best PMs I've ever worked with were PMs on platform teams, and that just tells me it's not like where you put PMs that are just meh.

    8. CFCamille Fournier1:01:55

       No.

    9. LRLenny Rachitsky1:01:55

       Like, that's where you could have some of the highest leverage, because platform teams enable the rest of the company to move faster.

    10. CFCamille Fournier1:02:01

        Yeah.

    11. LRLenny Rachitsky1:02:02

        And one difference there, uh, I'm curious if you agree, is your ratio of PM to engineer can be a lot higher. You can have a lot more engineers per PM on platform teams.

    12. CFCamille Fournier1:02:10

        Yeah. Yeah. I, I think that's right, because I think, you know, a lot... So much of the, of the work in a platform team is not a, is not exactly product work. Like, a lot of it's, like, you know, scaling or really, like, deep kind of technical. Like, I gotta figure out how to actually do this technical thing, or I've got to, you know, do this performance efficiency, and you don't always need, like, a product spec for that, right? Like, that... It's often just a very engineering-heavy task, um, and so yes, I think the ratios do tend to be a bit, a bit

15. 1:02:42 – 1:04:43

    Platform team responsibilities

    1. CFCamille Fournier1:02:42

       different.

    2. LRLenny Rachitsky1:02:42

       So we dove, like, right into this topic. Uh, maybe it might be helpful to help people understand, what is a platform team? Just, like, what are examples of teams that would be considered platform teams?

    3. CFCamille Fournier1:02:51

       I mean, I guess I... Like, the high level definition that I have of platform engineering is, like, if you are developing and operating platforms that, that... Where, where they're trying to manage overall system complexity and deliver kind of leverage to your business. So, a lot of the teams that people think about nowadays, and when they're talking about platform teams, they're really, they're talking a lot about teams that may have formerly been called, like, dev tools, for example. So your, you know, CICD tooling for the company. Um, a lot of the cloud infrastructure provisioning and tooling. Um, if you're at a company with certain technical problems, you know, you may very well be, like, you know, building semi-bespoke storage systems, for example, maybe part of your platform teams. I actually think that there are, you know... And then, and then I actually, like web frameworks, you know, web mobile framework and sort of like support for really, for that, that set of engineering can also be s- part of a platform offering. I actually kind of believe that there are... There's also sort of what you might call integration platforms, w- or platforms that are kind of in between that infrastructure-y developer tool-y stuff and product, so like billing platforms, for example, right? If you have a single billing platform for all of the different products in your company, that's all... That shares a lot of overlaps and, and the challenges of like those more dev tools, infrastructure-y platform teams, because you're probably supporting lots of different product lines that are using, you know, using this system that needs to be able to sort of scale, you know, it with certain efficiencies. You need to still do the product discovery. You probably have a little bit more of a business product focus than, like, the pure internal tools teams, but you know, that, that gets to sort of the, the,

16. 1:04:43 – 1:07:02

    When to form a platform team

    1. CFCamille Fournier1:04:43

       the blended area.

    2. LRLenny Rachitsky1:04:44

       For founders that are kind of earlier stage or companies that are smaller hearing this and they're like, "Oh shit, do I need a platform team?" Uh, so yeah, so what's... Like, you're shaking your head if people aren't watching on YouTube. Uh, what's a sign that it's time maybe to start creating a platform team and setting aside resources for something like that?

    3. CFCamille Fournier1:05:00

       So first of all, I think it tends to be like you have 50 plus engineers. I don't think this is the kind of thing that you start when you are, you know, 10 engineers, right? But when you are, have like sort of the... So there's a lot of ad hoc coordination that's probably happening amongst your, your engineering groups right now, where, like, maybe you just have like one... You know, you, you have your GitHub and somebody's kind of making sure that like all of that stuff's... You know, it's sort of working. You, you have a few, you know, a few cloud databases and you got like, you know, a couple people on each team and they kind of like share notes to figure out, like, what, what's going on or whatever. Okay, it's all good, but at some point you, you hit either a lot of inefficiency where you're seeing like the same people a- across a bunch of different teams. Each team has the same kind of people having to solve the same kinds of problems, and it just seems like why do I have three people in every team, like, dealing with this instead of like centralizing it and making it a little more efficient? It also could be that you hit some core scaling issue that starts to really need a dedicated team to solve. Um, again, that could be like developer productivity, like every development team is trying to do it their own way and everybody's just super slow because like, you know, you, you just can't get code released and it all has to be coordinated across every different team and it's just like, "What is going on? We need to fix that." Or you know, you actually have a technical challenging area that needs sort of a focused team to fix the scaling. Those are some of the signs that you may want to start thinking about a platform team, and it's really like, generally speaking, I would not jump into it early. It should... You know, it's... This is, this is something for companies that have matured where there is... It's worth investing and making people, you know, internally kind of more productive and centralizing certain functions just from a, you know, from a cost and efficiency basis at, at minimum.

17. 1:07:02 – 1:12:48

    Thriving on a platform team

    1. CFCamille Fournier1:07:02

    2. LRLenny Rachitsky1:07:02

       Say you're on a platform team. Say you're an engineer or even a PM.Any advice for how to be successful and thrive within that environment and be a great platform team?

    3. CFCamille Fournier1:07:11

       If you wanna do platforms, if you're, if you're an engineer, certainly if you're an engineer, or an engineering manager, you've, you've got to remember that, like, half of the, half of the work is actually, like, the operational quality, operational excellence of these things. Platform engineering is not, like, just writing code and then throwing it over the wall to someone. The, you know, being, being interested and passionate about kind of the operational challenges and scaling bits of, of systems I do think is, like, fairly important if you want to be a great platform engineer from a, from a software engineer perspective. If you're more like a, you know, product manager, look, you've got to really care about... I think you gotta really, you gotta be really both interested in kind of working with really smart, like, engineers who are gonna know way more than you do about things, um, and, and almost being a really good, like, not necessarily zero to one, but, like, past one person, because actually a lot of the best platform-type offerings in companies start in individual, like, application teams. Like, an application team has a problem and they solve it for themselves, and it turns out that that's actually a really good idea for how to solve that problem, and so a good platform team is often, like, looking around for those and then sort of taking them and then, you know, assimilating them and making them available to more and more people. And so I think, you know, if you wanna be in that kind of zero to one, like, building the brand new stuff all the time, you may not be as happy in a platform team, but if you're really interested a little bit more of, like, taking things over, stabilizing, scaling them, you know, making them efficient, making them evolve as the company evolves, I think that's gonna, you know, you'll, you'll be happier in that, in that circumstance.

    4. LRLenny Rachitsky1:09:01

       Awesome. Is there anything else along these lines before we s- wrap up, uh, and get to our very exciting lightning round, uh, that you think might be helpful for folks working in platform teams or working on a platform team, building platform teams?

    5. CFCamille Fournier1:09:14

       I think there are, there are two things that we, that we haven't touched on, or maybe three-

    6. LRLenny Rachitsky1:09:18

       Mm-hmm.

    7. CFCamille Fournier1:09:18

       ... that are, like, really hard about platform teams-

    8. LRLenny Rachitsky1:09:20

       Yeah.

    9. CFCamille Fournier1:09:20

       ... and that I think they don't get much press, which is, like, running platform projects is a little bit different than running agile, um, agile projects.

    10. LRLenny Rachitsky1:09:29

        Mm.

    11. CFCamille Fournier1:09:29

        Like, not, there aren't... You can take a lot of this best practices you may have learned from, you know, agile-type product delivery, but, like, you're running longer running, larger-scale, more complex builds because a lot of the stuff that you build at the platform level just takes longer. It's a little bit more complicated. So you've got to be willing to get into that kind of stuff, especially if you're in a management job in that space. You are going to deal with a lot of migrations as well, right? So it is very annoying if migrations happen, even if you don't force them on people, you know, your cloud provider is gonna say, "Oh, you've got to migrate from EKS V1- 19 to 121," or whatever, right? And that may require, like, changes in code and then that's a real pain in the butt for all of the application teams. Think, you, so people who are interested in, like, how to smooth over the customer and, and, you know, company impact of this underlying change I think will be very happy in platform teams. If you're not interested in that, you may not enjoy the work as much. There's just a lot of detail-oriented work in platforms. And then of course the final part is, like, the stakeholders are a nightmare. My, my friend who wrote the question about like, how his product part- or his platform partners drive him crazy, like-

    12. LRLenny Rachitsky1:10:51

        Mm-hmm.

    13. CFCamille Fournier1:10:51

        ... I have no doubt he drives them crazy too (laughs) .

    14. LRLenny Rachitsky1:10:55

        (laughs)

    15. CFCamille Fournier1:10:55

        Right? Because you've got all of these stakeholders, you know, your peers in tech, you know, maybe product managers, maybe executives that are like, "What is this team? Are they really worth the money?" Like, "Why are we spending so much on it? I don't understand what they're doing. I could do it better in some cases," right? Like, there's just, you know, and so el- there's actually a big part of the job, particularly as either product managers or engineering leadership is, like, m- stakeholder management and really learning how to do that well. And that is not always, that's, you know, that's probably I think universally agreed to be the least fun part of the job. I don't think anybody loves it, um, but it is certainly a s- a skill set I'm, I'm glad that I have. And so I think if you, you know, if you're, if you're thinking about, like, building one of these teams and you're like, "I can, I can just do the fun tech stuff or, like, the cool product stuff. I'm really passionate about engineering productivity or I'm really passionate about sta- scaled storage systems and I don't want to think about any other stuff," you may not actually be happy in the long run in leadership positions. It may be fine, you know, as an individual contributor, but, like, for leaders in particular, there's a lot more to it than the fun tech problems, the fun operations problems, e- even the product.

    16. LRLenny Rachitsky1:12:07

        You said there was a few things yet we haven't touched on. Is there anything else?

    17. CFCamille Fournier1:12:10

        That's, that's kind of the, that's the-

    18. LRLenny Rachitsky1:12:12

        Okay.

    19. CFCamille Fournier1:12:12

        ... that's very, that's the f- the fast list. Anybody who's interested, the, my book will be coming out in the next couple of months from O'Reilly and-

    20. LRLenny Rachitsky1:12:19

        Amazing.

    21. CFCamille Fournier1:12:19

        ... uh, covers all of this at d- depth.

    22. LRLenny Rachitsky1:12:22

        Yeah. Is there a date specifically people should watch out for?

    23. CFCamille Fournier1:12:25

        Um, I think it's actually pre-order on Amazon now.

    24. LRLenny Rachitsky1:12:27

        Okay.

    25. CFCamille Fournier1:12:27

        It's called Platform Engineering and then there's a, I think it's, like, a guide for technical product and people leaders, something like that. Um, but, uh, I think the, I think the release, I don't know exactly when the Kindle release will be, but we're still in copy edits, but it should be done pretty soon.

    26. LRLenny Rachitsky1:12:42

        Okay, amazing. So you can pre-order it now. We'll link to it obviously in the show notes and description. It's called Platform Engineering.

18. 1:12:48 – 1:17:03

    AI corner

    1. LRLenny Rachitsky1:12:48

       Uh, before we get to our very exciting lightning round, I want to take us to, uh, a recurring segment on this podcast that I call AI Corner. AI is very top of mind for a lot of people and I'm always curious how people are finding i- it valuable in their work or in their life. So, so the question is just, is there anything you've found, uh, AI to be helpful with in your AR work? Any way you use it in an interesting way?

    2. CFCamille Fournier1:13:11

       I find it helpful, for example, if I've written a sentence and I'm like, "I like this sentence, but I feel like it, I don't like the, the phrasing. I don't like the phrasing or the format that I've used." Like I, it needs to be edited, but I can't quite figure out how. I will often, you know, put it into ChatGPT and be like, "Can you reframe this? Can you rephrase this for me?" Doesn't always work well, but like sometimes it does. It's like, oh yeah, if I just like switched this around or changed this word choice, it's a much easier to read sentence. I do think it's, I think it's

    3. LRLenny Rachitsky1:13:40

       Yeah.

    4. CFCamille Fournier1:13:41

       ... useful for that and like small. I think it's large, large blocks of text, I haven't, I haven't had as much luck with. I'm not, I'm a little bit of a AI novice still, I would say. Um, what I will say is that AI is really bad if you try to ask it for quotes, or at least ChatGPT's. I don't, I haven't used a lot of the other ones that much. I actually saw, there was like some Twitter or some- somewhere, some social media thing that's like, did, um, Francis Ford Coppola get like fake reviews from like ChatGPT of the new, what is it, Megapolis-

    5. LRLenny Rachitsky1:14:12

       Yeah, Mega-

    6. CFCamille Fournier1:14:13

       ... Megapolis movie?

    7. LRLenny Rachitsky1:14:14

       Megapolos, yeah, yeah.

    8. CFCamille Fournier1:14:14

       Um, and, uh, and, um, I was like, you know, I actually had that s- scenario where I was like, "I need a quote." I was looking for quotes, you know, for, for the book. And I was like, maybe, you know, the ChatGPT knows about it. I was like, "Can you give me any good quotes on like..." I forget what it was. Let's just say it was on complexity, managing complexity or something like that. And it, you know, gave me these really interesting quotes. I was like, "That's great, but I better double check that." And they were not real. They were never real. Not a single quote. And I'd be like, "That's not actually a real quote." Oh, yes, you're right. That's not, so here's a different one. It's like, that's still not a real quote. (laughs) Uh, so don't ask it for quotes because, uh, or if you do, make sure it's a real quote and not just a- an interestingly phrased summar- I mean, in- in good, good summarization in some ways of like the, the text it was sort of quoting from, just not an actual quote.

    9. LRLenny Rachitsky1:15:06

       That's a good reminder of just generally don't assume what it's telling you is true. Like generally, it's not giving you real things. It's making things up and usually they're right, but often they might not be right. Uh, that's a really good reminder. On that first, uh, tactic, is there a prompt that you find helpful for how to actually feed it in there? Is it just, here's a line, help me come up with a better version of it?

Episode duration: 1:23:14