The things engineers are desperate for PMs to understand | Camille Fournier (author of “The Manager’s Path,” ex-CTO at Rent the Runway) | Lenny's Podcast: Product | Career | Growth

I'm curious what it is that PMs do that annoy engineers most.

Hoarding credit. PMs, they tend to be the front -facing person for initiatives.

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.

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

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.

I think it really can be very off -putting.

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

What gets them excited?

A lot of people assume that engineers just write code and don't underestimate the ability for your engineers to want 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.

Today, my guest is Camille Fornier.

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 a 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 Andrew 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 Fornier.

Camille, thank you so much for being here.

Welcome to the podcast.

Thank you so much for having me.

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 work 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?

I would say there are a few things that PMs do that annoy engineers.

And to be clear, I am sure that engineers annoy PM best as much.

So 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 tend to be the front -facing person for 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 they really kind of worked very hard on.

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, what I consider kind of a pretty easy annoyance.

Just like don't forward all the credit, this is not just you.

There's a lot of work best to go into that.

I think that sort of dovetails into 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.

And I think this is just a little bit of a cultural difference, right?

So like if you are, I mean, even managers, just normal managers, right?

People like me who are looking across really broad areas or 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.

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 slash Lenny.

Let me tell you about CommandBar.

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 everyone.

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 slash Lenny, and you can unlock an extra 1 ,000 AI responses per month for any plan.

That's commandbar .com slash Lenny.

By the way, CommandBar just changed their name to CommandAI.

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're being asked questions that you cannot answer because you just don't know, because that's something that involves a level of technical detail that only the engineers have that you just don't have, and 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 ASPR 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.

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 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?

I want to have some creative outlet, so I'm going to use my engineering skills in my creative outlet, and I'm going to spend a lot of time obsessing over the right framework or the right this side or the other that may actually not matter that much for product delivery, but when you take the people

that are part of the project team out of the creative loop entirely, they're going to find that creative outlet somewhere else, and it's actually kind of bad for the product.

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 the system.

Yeah, I mean, that happens without you doing that, right?

But I do think, I think when I see it worst, and I can basically always predict what I'm going to see a lot of that kind of engineers building stuff, finding creative outlets and kind of building stuff, maybe they shouldn't be, I'm going to find that in places where they are so quashed, their creativity for the actual

business or product that they're building and their voice in that is so ignored that they don't have any outlets in that space.

And so they are going to use the space that they have an outlet in, the place where they have some control, and that's usually the technology choices and the details there.

That's fascinating.

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 coming up with what you're actually building, what have you seen?

It's just very tactically, is there anything you've seen a PM do super well?

I think the product managers that have done the best, they're not threatened by other people having ideas.

They're not threatened by the engineering team being full of smart people, because they realize that like, some of the engineers may have good ideas, but they still don't really know how to do the product job.

Like, just my experiences, 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 that they would need to be successful.

And when product managers take the time to 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 what they're really bringing to the table in terms of really,

how do we measure this input?

How do we really understand the customers?

How do we really think through the details of what's going to make this successful from a business or a customer perspective?

I do think that that creates just a much better interaction pattern, and then engineers can feel good about sharing ideas and understanding that many of them won't go anywhere, but there's somebody that's actually going to listen and take the time to care about them.

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

That was not always easy, because again, you have this tension of a lot of the job of any management role is being in meetings and filtering stuff so that people who are in focus, individual contributor mode, can focus and get things done and not spend half of their weekend 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 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.

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, and that's going to cause problems over time.

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 the product, or just obviously just spend their time in meetings and not be building the thing.

Yeah, and sometimes you do it in a group meeting, I feel like Slack and other chat type things actually make it a lot easier to have the right people in a group in a thing, but again, that's distracting.

So there's not an easy solution to that one, just I think it's important to be aware of it.

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?

Is it just like every time they're announcing the product, hey, these engineers were involved?

It's more than just saying thank you to all these people, but it's actually sometimes stepping back and letting other people speak, especially if it's something that's a really, really big technical lift.

I don't think there's a super easy fix to that, because I think it is just really being mindful that can be very much a sore point for engineers when they just feel like, this is my work, I'm not getting any credit for it, and this person is hogging all the glory.

I love that, yeah. I find the best PMs are the ones that talk the least and encourage other people to do the presenting and announcing, and so I think that's a really good reminder.

Let your engineers do that.

Okay, amazing. So we talked a little bit about this idea of rewriting and how engineers sometimes just want to rewrite the system, and I think a lot of PMs do too.

A lot of times you're building your features on a thing that's someone that doesn't even work at the company anymore built five, 10 years ago, and there's always the sense of, okay, maybe we should just rewrite this thing.

Everything will move so much faster.

You have a really 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?

Yeah, so I mean, I have personally overseen a number of, if not quite rewrites, re -architectures and major system evolutions, and so 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 the woes of their experience with the system, it's hard to support, it's hard to change, nobody wants to work on it because 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 really think through, we don't need to touch all of this stuff, but we're going to take the recommendation system really needs to be uplifted,

and that's a well -contained API, and so we can start to fix that without having to change the whole whatever web framework.

So I do think 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 huge, huge problem, particularly when you're talking about systems where you have sort of external people using the system in some

way, whether it's web UIs or APIs, you think, oh, we kind of know what's going on, so it's not going to be that big a deal.

Engineers 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, I'm sure, and frankly, that's a problem.

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 can't really afford to just say, we're going to go away, we're not going to touch the system for a long time, but we're going to build something new over here.

So many things about why that doesn't make any sense.

So this is a little bit of field of like my blog post that you're referring to.

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 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 or you can continue to add and evolve.

You should be investing.

And so there's a, you know, there does need to be an investment.

But 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, and 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, you know, 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 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 making an 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 going to just go away, we're going to rewrite, we're going to build something brand new and it's going to solve all our problems.

It just very rarely works.

I think a lot of PMs will be like, yes, thank you so much for saying this because I think that's also always a big struggle between the Edge 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 going to take a lot longer than you expect.

You underestimate knowing what it actually does and you're going to miss features and you can introduce new bugs.

This actually is very similar to what I've seen with redoing, like redesigning a whole product flow.

There's always the sense of like, let's just rethink this onboarding flow from scratch or let's rebuild this part of the product and always it ends up being a negative experiment result.

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 situation in the product side.

Okay, amazing. I'm going to go to a slightly different topic, which is our engineering leadership.

So I know you've written a lot about engineering leadership.

You spent a lot of time with engineering leaders.

So 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 and 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?

Yeah, 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 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 it would be rusty but I would get there pretty quickly.

Maybe physically I wouldn't be as strong as I was or whatever but I would get there.

You can do that with writing code.

You can do that with technical skills.

If you do it for long enough I think you can develop sort of a baseline mastery where you're not going to be as fast and a lot of the challenges of being technical is actually in all the tooling and all the tooling evolution but you're not going to 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 technical know -how 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 can't have to be hands -off but you just don't have time to write code at all you know

you are going to 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 people care about with technical leaders in my experience because 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 and 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 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 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 am able to stay kind of technically savvy incredible amongst people who work for me

is not that I'm writing code because 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 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 so my last point how are you actually doing that?

Is it like watching going to conferences that friends something else?

Yeah I mean I guess for me 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 you know staying in touch with you know staying in touch with former colleagues it's you know I will admit

I'm kind of a social person and I have a big network so this may be easier said than done but I do think like you know being in the right group chats I'm cool I also think like I'm sure reading various you know tech news and tech tech sort of commentary and discussion boards I mean it's definitely a mixed

bag of that stuff I think I'm 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 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 you don't really pay attention to engineering it's hard for me to say because I'm just like I'm such a nerd I just I've really I really love tech like I'm in I'm in this industry because like I'm just like actually genuinely very interested

and certain certain corners not every corner of technology but certain corners of technology I just like I want to know I want to know what the latest stuff that's happening and databases and infrastructure and you know I just I find it all very interesting 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 yeah but you've been talking about reminds me a little bit of this guy Levels .io on Twitter have you heard of this guy?

He was just on Lex Friedman have you listened to that yet?

I think maybe I saw a clip of him okay okay but I haven't listened to it 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 and a funny thing about him is he works all stuff is in PHP

and jQuery he's just like this works like I've always had this to do learn no JS learn Python and I'm like I'm too busy to build while I'm building to learn these new things 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 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 I think it I don't totally disagree I think the challenge

is though of course like what works as a one person show doesn't always work in a scaled organization for better for worse for a different like you know you've got to you know you've got to match like what makes one person really productive will it make a hundred people a thousand people even ten 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 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 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 just to kind of follow this thread and to kind of nerd snipe you a little bit is there like 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 this is I feel excited but this is not good I will say this one example I actually put in my own notes for this for this 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 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 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 or it seems like an interesting fad that maybe is burning a lot of people.

That's awesome I appreciate you sharing that.

I don't know if this is exactly an example of this but on that podcast levels I forget his actual name Peter I think share that whenever there's a framework that has a VC -funded startup behind it that's not a good sign because their job now is to convince engineers to use it and then pay for it and that's

not necessarily going to be the best product.

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

Or the context of the big company that may have made that framework super useful within that context doesn't translate to startup or small company or even big company that doesn't have the rest of the context set.

So you know I but I don't think he's not wrong I also just think like big companies you know share the blame on that one.

I guess we should all just come back to PHP and jQuery and might be simple.

Maybe. Okay so to close out this thread on engineering leaders finding the right balance just to summarize your advice here one is get to mastery before and is your advice here get to this point before you move into engineering?

Engineering management you know I will say part of this is also like in particular if you happen to be a woman or otherwise underrepresented person in tech because people will tend to underestimate your technical abilities just unfortunately as a get -go like I also think it's particularly important

to kind of develop that internal confidence in your abilities before you make this sort of scary leap which is scary for everyone of like have it you know if you have that mastery before you make the leap I wish more people would do this because honestly I do think like there are a lot of people who never

really gained the mastery they go into management they lose it and some of them are still perfect perfectly good managers and look there have there are good managers who were never technical to begin with I don't want to I don't want to say that that's impossible I just think that if you care about being

technical if you are if you are technical now and you want to maintain that tech savvy don't just become a manager the first time somebody offers it to you like make sure you've really spent your good time you know writing code Is there like a number of years heuristic you think about or some way to

tell you that you maybe you've hidden hit that point you know I think this was has been since disproven but you know there was for that 10 ,000 hours idea of mastery at some point you know for me it was like an undergraduate degree a graduate degree and four or five years of like full -time work so maybe

I might be slow right I didn't start coding a lot in middle school like people might do now but like you know I felt like I took several years of hands -on work and a very intense undergraduate and graduate programs for me so I do think it's probably a like somewhere in the 10 -year range of like really

having spent a lot of your time over those years writing code and you know really understanding how to be a technical expert got it so essentially if you're thinking about moving into management as an engineer uh you may want to wait until you've done it for 10 years in some form which I think is a lot

longer than a lot of people would have thought and I imagine many people are not doing that and then in your experience not doing it could be you know if you if you were programming a lot in high school and you got an undergraduate degree so you you know you've let's say you've got six years I see you

know you may only need four or five years of like work 40 hour a week writing code experience I'm sure it depends on the company but like I do think when you see people that are like 23 they are just out you know very recently out of school it's a different thing if you're a founder and you're you know

that's a whole different life right but you know if you're in a big company and somebody's like you have great communication skills why don't you start to become a manager often they're actually pushing you to become a project manager which is actually also the worst you know worst sort of path to real

leadership in my opinion like spend you know if you don't feel like you've done also if you just don't feel like you're done right if you're still having fun writing code don't rush becoming a manager like writing code is awesome have fun and don't bite it I know exactly what you mean so I used to be

an engineer actually I was an engineer for 10 years I definitely don't have mastery at this point I moved into product from that and I definitely so missed actually just sitting there and writing code and building stuff that was very hard to give I imagine you still miss that you know I it's been I

think I might have forgotten about it at this point but it is I there is nothing as satisfying as because you get the fast feedback loop it's just wonderful yeah this episode is brought to you by coda I use coda every day to coordinate my podcasting and newsletter workflows from collecting questions

for guests to storing all my research to managing my newsletter content calendar coda is my go -to app and has been for years coda combines the best of documents spreadsheets and apps to help me get more done and coda can help your team to stay aligned and ship faster by managing your planning cycle

in just one location set and measure okrs with full visibility across teams and stakeholders map dependencies create progress visualizations and identify risk areas you can also access hundreds of pressure tested templates for everything from roadmap strategy to final decision -making frameworks see

for yourself why companies like door dash figma and qualtrics run on coda take advantage of this special limited time offer just for startups head over to coda .io slash lenny and sign up to get six free months of the team plan that's coda .io slash lenny to sign up and get six months of the team plan coda .io

slash lenny 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 are they most often not understand or are surprised by like oh man i did

not see this as part of my job yeah i mean i think there's a few things i do think i assuming that they're actually trying to do it well do you think there are a lot of people who move into management and then just don't really understand the job at all and are you aren't even self -aware enough to know

that they don't 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 going to revolt they're not going to listen to you you know you you don't 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 it just doesn't create creativity right it's the same thing as like pms trying to have all the ideas right like you know you know 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 and 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 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 i wonder if engineering

is where most where the highest percentage of people are moving to management move back to ic i've seen that a bunch and i wonder if engineers are the most common i don't you know i don't know but um after realizing what you just said is true so do you not think product managers also do this because i

think product managers also actually suffer from exactly this kind of they do sometimes they do yeah 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 oh yeah because pms

are way easier to manage pms are awesome to manage pms wants to like they're just so helpful they're like wants and do this they're good communicators i love managing pms i have to say i have to say i just like my engineers are such a pain they are all prima dada's they're all no i love i love it i

am an engineer but like he my pms are more fun to manage my experience so actually you have a point you know the point but i wonder yeah because i haven't seen 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 yeah yeah 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 contrarian take that maybe you should have less one -on -ones especially as an engineering manager you talk about that yeah so so to be clear i you should have one -on -ones with your direct reports in your manager and you should you should hold

those sacred i try and tend to do mine weekly or maybe every other week so this is not about that set of one -on -ones they're the one -on -ones of 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 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 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 slash 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 this 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 they don't they don't really care about what you're

doing they actually may not like it that you're asking them for a one -on -one let me show up because 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 a sort of stakeholder management so when you're meeting with people that's not your team but like other stakeholders 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

because i've built internal platforms is a big part of what my job has been in the last many years having all these meetings 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 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 i had

these other one -on -ones with all these people and they're saying it's fine and it 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 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 your 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 to get coffee let's go to lunch and let's like hang out and honestly those people are really successful in many ways i am not like i do sort of envy that skill i'm really good if you want to 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 various ways but i'm really bad at 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 with that's your comfort zone if that like getting to know you random you know relationship building one -on -one is your comfort zone 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 eight meetings today therefore i was productive yeah that super resonates it's kind of pulling on the thread of how you operate

and how you work something that i've heard you're really known for is creating a work culture where people work really hard but also have a really good work -life balance and when we were chatting 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 a 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 older work kind of lets you just sidestep doing the hard work of figuring out what's important in the first place you know you 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 you know

who you shouldn't 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 is swaging 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 important what's important to do does change over time but you're never 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 right i also think like people don't delegate enough 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 i guess

you have to teach people whatever it is that you're trying to get them to do not always sometimes those 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 um so i guess i just like i'm just a real

believer that working hard in a focused way for 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 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 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 p .m or something let's say and i am not or i'm not going to 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 out 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 p .m i'm going to you know because your brain is probably going to keep thinking you might still be a little stressed out 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 p .m every night like i just want to get this done and it meant that like i didn't do quite as many copies 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 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 i mean yeah i have a lot of like rituals like you know i have my my my caffeination rituals say more well i mean like i i can't drink coffee anymore because 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 helped me i i have to be in a quiet place um i do find like non music that is like like i really like forte for example as like music to focus or the new andre

3000 flute album is extremely good for focusing where it's like not quite predictable 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 folks that is awesome i have a similar caffeine strategy i'm drinking tea always during these podcasts and this little thing i got here and then my wife doesn't want me to drink diet coke because she thinks of the sugar and it is not good but i still drink it sometimes and it works i switch to

green tea that's my approach start with black tea and then switch to green tea oh that's mine oh man there's so many things you wanted to dig into let me share a couple things that 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 yeah and like like you just you're never going to scale if you don't delegate yeah and it's hard to 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 some if you're not cutting if you're not sometimes regretting something you cut or potentially firing someone you don't regret

ilan actually hit ilan 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 stuff you cut you was a mistake you're probably not cutting enough stuff 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 especially for the overachievers that often end up in these kinds of you know companies and jobs but you know if you again you kind of do things that scare you or you're never going to grow so okay i'm going to 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 or 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 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

that are often slow they're often pushing us to compromise on features to adopt their systems they often get infinite funding even though they say you're building something customer facing any tips for effectively working with a platform team and building a great relationship there 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 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 are not explaining their value to the company and it is infuriating 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 going to make everything worse in the short run 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 i would put are like look find the parts of that team that are good because 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 them 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 you probably 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 head count 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 leave 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 with all of 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

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 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 yeah 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 first of all i really am 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 sre's that are software engineers but they tend to not want to 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 because that doesn't really create a cohesive and coherent platform it doesn't really create it doesn't create products right

and frankly you need to be platforms or products ultimately um 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 operation systems sre specialists as well and of course you need product people

i've had you know product teams on and product managers for my for all 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 just i just believe that like it is you're not going to 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 for the actual details and focus of the product work is just 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 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 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 well you just got to run the infrastructure and you know make sure

it works 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 the internal world but it's still very important if you want to do platforms on the line

of having pms within the platform team 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 like that's where you could have some of the highest leverage because platform teams enable the rest of the company to

move faster yeah 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 yeah yeah 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 got to 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 different so we do over 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 i mean i guess

i like the high level definition that i have 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 you're 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 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 part of a platform offering i actually kind of believe that there are there's also sort of what you might call integration platforms or platforms that are kind of in between that infrastructurey developer tool stuff and products 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 infrastructurey 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 the blended area 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 so yeah so what's like you're shaking your head if people aren't watching on youtube uh what's a sign that's time maybe to start creating a platform team and setting aside resources

for something like that 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 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 have your github and somebody's kind of making sure that like all of that stuff you know is 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 an efficiency where you're seeing like the same people across a bunch of different teams each team has the same kind of people having to solve the same

kinds of problems it just seems like why do i have three people in every team like dealing with this instead of like centralizing and making 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 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 but it's really like generally speaking i would not jump into it early it shouldn't you know 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 my you know from a cost and efficiency basis at at minimum 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 if you want to do platforms if you're if you're an engineer certainly if you're an engineer or an engineering manager 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 up 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 gotta be really both interested in kind of working with really smart like engineers who are going to 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 and 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 you know assimilating them and making them available to more and more people and so i think you

know if you want to 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 going to you know you'll be happier in that in that circumstance awesome is there anything else along these lines before we wrap up uh and yet there are very exciting lightning round uh that you think might be helpful for folks working platform teams working on a platform team

building platform teams i think there are there are two things that we that we haven't touched on maybe three that are like really hard about platform teams and that i think you don't get much press which is like running platform projects is a little bit different than running agile um agile projects

like not there are you can take a lot of the 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 migrations happen even if you don't force them on people you know your cloud provider is going

to say oh you've got to migrate from eks v 119 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 the application teams think you so people who are interested in how to smooth over the customer 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 and 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 is a platform partners drive him crazy like i have no doubt he drives them crazies 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 there's actually a big part of the job particularly as either product managers or engineering leadership is like 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 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 scale of 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 even the product you said there's a few things we haven't touched on is there anything else that's that's

kind of the that's the that's very that's the fastest and anybody who's interested my book will be coming out in the next couple months from o 'riley and amazing covers all of this at depth yeah is there a date specifically people should watch out for um i think it's actually pre -order on amazon now

it's called platform engineering and then there's i think it's like a guide for technical product and people leader or something like that um but i think the i think the release i don't know exactly when the kindle release will be but we're still in poppy edits but it should be done pretty soon okay

amazing so you can pre -order now we'll link to it obviously in the show notes and description it's called platform engineering uh before we get to a very exciting lightning round i want to take us to 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 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 ai work any way you use it in an interesting way 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 in chat gpt 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 just before that and like small i think it's large large lots of text i haven't i haven't had as much luck with i'm

not i'm a little bit of ai novice still i would say on what i will say is that ai is really bad if you try to ask it for quotes or at least chat gpt is 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 chat gpt of the new what is it megopolis yeah yeah um and uh and i was like you know i actually had that 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 chat gbt

knows but 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 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 uh so double ask it for quotes because or if you do make sure it's a real quote and not just uh an interestingly phrased is somewhere i

mean in good good summarization in some ways of like the the text it was sort of quoting from just not an actual quote that's a good reminder of just generally don't assume what it's telling 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 no i am i am not figured out the prompt engineering thing at all i i had

i tried to get it to summarize a paper for me the other day and like it just saw it literally gave me the summary of a different paper and then i asked friends and they were like well here's the summary i was like actually that seems like a good summary and they're like well you know first i told the ai

that it was like an expert in the field and i didn't need it to read carefully and that it was really smart and i'm just like i don't how do i have to manage the machine like i already have to manage all these humans like why are you making me manage machines now too please i thought this was going

to solve all of our problems um yeah that role there's like an acronym for how to approach prompt engineering and one like there's always like give it the role here's the role you're going to play for me like you are an amazing uh writer and here's what i want for me yeah i'm also very bad at by the way

uh clauda here is really good at writing that's like one of its superpowers so if you want to try writing that's worth your idea by anthropic on the second point you made a fake quote so yeah francis for copal is coming out with this movie with as you mentioned this trailer is just full of all these

quotes that people supposedly said about his all his other movies that are father and stuff and they're all like these are terrible like they're all terribly mean quotes about his movies turns out yeah they're all not real quotes and they actually took down the trailer as i just read because he's just

making up quotes by famous critics wow well so you know that was chat gbt you could you can get fooled i don't know if it was chat gbt or or a cheeky intern or something but you can get or very intentional marketing stint probably or that yeah anyway with that camille we have reached our very exciting

lightning round are you ready yes amazing okay first question what are two or three books that you recommended most to other people so the first one is what got you here won't get you there i love it i think anybody who is trying to challenge themselves and grow should read it it's fantastic the second

one is called when things fall apart by pemma children that is when you are for me anyway when i am struggling with whatever circumstances around me i find it a very soothing reminder that like life this life is hard and the best way to to you know you just sort of have to breathe with it and and be

with it and you know let it remind you of how life is hard for everyone and sort of make you a a kinder person in the process is there a favorite recent movie or tv show you've really enjoyed i loved alien romulus it was great if you like a scary alien movie fantastic and i hate scary movies uh so it's

a new alien movie okay i didn't know what it was i loved it awesome is there a favorite product you recently discovered you really love whether it's an app or even physical product so i don't know about recent i'm a big one of my i'm just a weird fan girl for it i don't know i just really i enjoy it

i use it every day maybe it's totally inaccurate but it seems accurate enough and i just find it a very interesting and cool product i know product people listen to this podcast so i think they'll be happy to hear that two more questions do you have a favorite life motto that you often come back to

share with friends or family find useful and worker in life if you don't if you don't challenge yourself if you don't take risks you just you'll never grow that's a big one i think you've got a you know challenging yourself taking risks is how you grow i think the other one for me is stay curious you're

just you know the more you can remember that there's more that you don't know than that you do know and staying open -minded and being willing to be wrong you know i think the and and uh the the the better you'll be as a leader for sure final question on the topic of working out uh you're blocking it

with your head during generally during the podcast when when you moved behind you as a very significant looking uh barbell set or dumbbell set i don't know which ones which talk about your workout regimen or anything along the lines of how you how you workout i have been lifting rates probably for longer

than some of your podcast listeners have been alive um which says more about my age than anything else but so i used to be i i now have two kids so i i lift weights as sort of maintenance but like i used to be a very like i could deadlift more than twice my body weight and i was just a very very strong

person now of course everybody's into weight lifting which makes the gym really annoying so partly why i have a a set in here a small set with a baby sized bar is uh so when i can't make it to the gym i can at least you know lift a little bit at home what's your favorite workout lifting wise i love

like really basic like deadlift squat overhead press um that's that kind of you know very simple the classic lifts amazing camille this is awesome is everything i was hoping it'd be we covered so much stuff two final questions uh where can folks find you online if they want to reach out follow up on stuff

and check out your books and how can listeners be useful to you yes so with the weird state of social media now that's actually a harder question to answer than it normally is um i do i am on linkedin so i you know you can always uh follow me on linkedin and i will probably i haven't traditionally put

that much there but i'm expecting i'll probably start putting more there in the coming months i also have still use medium when i write action like medium so medium .com scamil is my username those are two good ways i have a twitter slash i guess x account that is currently locked and i may or may not unlock

it at some point um but you know uh social media as i said i've got has gotten weird so uh i think probably linkedin is the easiest way for uh and i read somewhere that scamil is uh rooted in your love of ska music back when you were younger is that right it's true yes it was from high school i was a big

ska fan it's funny how our usernames just like stick from we were really young and that's like the way we were represented online now forever yeah that's absurd uh and then you didn't answer my final question which is how can listeners be useful to you i have a new book come out coming out i have i

have another book that i've already written um obviously i love it when people buy my books so when people share my books with other people um my first book is translated into like a bunch of languages which is super exciting so you know uh i and i hope that if you read it and enjoy it and learn something

from it you will let me know tag me on some social media i think that's just awesome and you know stay tuned like if you if you're looking for people potentially to come talk to your company about platform engineering i could be interested in that but you know i always love to meet interesting people

if you're in new york um you know reach out who knows but this you know this has been an amazing uh amazing time getting to chat with you lenny thank you so much for inviting me on the show i feel the same way thank you for agreeing to come on the show camille you're awesome thank you so much for being

here take care bye everyone thank you so much for listening if you found this valuable you can subscribe to the show on apple podcast spotify or your favorite podcast app also please consider giving us a rating or leaving a review as that really helps other listeners find the podcast you can find all

past episodes or learn more about the show at lenny's podcast .com see you in the next episode

[How to Build High-Performance Engineering Teams and Master Product Management: Insights from Camille Fournier]-[The things engineers are desperate for PMs to understand | Camille Fournier (author of “The Manager’s Path,” ex-CTO at Rent the Runway)]

📋 Summary

Navigating the Engineering-Product Relationship: Insights from Camille Fournier

Common PM Behaviors That Annoy Engineers

The "Rewrite Trap"

Transitioning from IC to Management

Rethinking One-on-Ones and Focus

Building Effective Platform Teams

🎯Key Sentences

📝Key Phrases

📖 Transcript