SPEAKER_01: Hey, how's it going? This is Craig Cannon and you're listening to Y Combinator's podcast. Today's episode is with Camille Fournier. Camille is a Managing Director at Two Sigma and the former CTO of Rent the Runway. She's also the author of The Manager's Path, a guide for tech leaders navigating growth and change. You can find her on Twitter at scamille. And a quick YC announcement. If you're interested in doing Startup School this year, signups are open at startupschool.org. The course begins on July 22nd and goes for 10 weeks. Select companies who complete the course will also receive $15,000 in equity-free funding. You can sign up at startupschool.org and I'll link it up in the description too. Alright, here we go. One of the things you mentioned in the book that I found particularly interesting was a lot of people as ICs never experience great managers. Why do you think that's the case?
SPEAKER_00: I mean, first of all, I think there's just a lot of bad managers out there. Part of the reason I wrote the book was that I had seen a lot of people who had never had a good manager and I felt like there were a lot of people who wanted to be good managers but didn't even really know where to try or where to start, especially when it comes to engineering management, which I feel like is a little bit different than just generic people management. So first of all, I just think there's not that many good managers out there. And then it's interesting that I'm talking on this Y Combinator podcast because I think the thing that got me really writing a lot about management in the first place when I started blogging about it was actually that there was this really big sentiment in the tech industry and particularly in startups right around 2010, 2011 when I was first sort of doing the startup thing myself, which was that management is bad, management is overhead, flat structures are the best, hire smart people and get out of their way. I think at that time Google still had their 50 people to one manager kind of structure. All of these companies and a lot of successful companies that had started in Silicon Valley that were startups really had this very negative reaction to management and hierarchy. They thought it was bureaucratic and a waste of time. And so I had worked at Goldman Sachs where there was management and I had come to this startup and I was looking around and I was like, you know, the thing that I'm observing
SPEAKER_00: is that actually management is pretty important, that good management is actually a pretty important part of making engineering teams effective, making companies effective. It just simply isn't true that management is overhead or waste, that I had all these friends who had had really bad management experiences and I was like, you know, I think there's something to be said about this. I think there's something for people to learn about this so that they can appreciate it more. And that's kind of what got me into writing about the topic in the first place. And you know, that's part of why I wrote the book was that I wanted there to be more good material for people that would help them appreciate management, help them understand that it's kind of a hard and special discipline, but it's also a technical discipline and not just something that, you know, any random people manager can do. Right.
SPEAKER_01: And it's addressed in the book, but you're like, this is not a bullshit job. This is a real thing and it's important. Yeah. Now why do you think that ideology, because it was definitely pervasive and it still is to a certain extent, why did that become so common within tech and more specifically within startups?
SPEAKER_00: I mean, I think the thing is like when you're a really, really small startup, like yeah, you don't necessarily need to think that much about management, you know, when it's a very small group of people that are all just really very closely working together on very obvious objectives.
SPEAKER_00: And you know, you've all already agreed to have a lot of skin in the game because you're probably not getting paid all that much money. And you know, it's all about sort of these future rewards. I don't think that management, I'm sure a great manager in that situation who also happened to be like a great founder and a strategic thinker might be great or super helpful. I don't know. But you know, like realistically there are other more important things, but at some point you get enough people that you need to really coordinate work amongst people who are not just like joined at the hip, talking to each other all the time, completely on the same wavelength. And that's when structure and hierarchy and some kind of management starts to become more important. So I think it's really just, I think like when you have a lot of people who have seen success at these very small stages and they believe incorrectly that the thing that made them successful is just like, well, we just got these smart people together and let them do what they thought was right and you know, success happened. You can take the kind of wrong lesson from that. And I think that contributes to this sort of, you know, not a disregard for management.
SPEAKER_01: Right. What stuck out to me was the book's focus on that transition from IC to manager. Like so many other things are about like org structure and like motivating the team and all that kind of stuff. This is very much about like this is your technical job and then all of a sudden you're transitioning to another job, which is technical, just in a different way. So I think maybe what would be most helpful for us to talk about are those like early days that like, you know, first year maybe of an IC's transition from an engineer full time to a manager. I mean, you have different like tech lead and all kinds of different roles for that, right? So say I just got promoted, I'm a new manager. What should I try and do in the first quarter that I'm managing a team?
SPEAKER_00: I mean, so I think a lot of it is just getting comfortable with the routines of management that are different than what you were doing before. So a little bit depends on what your job was before. There are plenty of tech leads who are already comfortable with, I don't write code all the time because, you know, my job is doing a lot of project management already and sort of leadership and whatever code reviews and things like that. So that maybe you're already used to not having to type code all day. But you probably still aren't comfortable with things like having one-on-ones, for example. One-on-ones are super awkward the first time you do them, the first many, many times you do them. Have you ever been the person who is like the manager in a one-on-one situation? It just is weird. I remember it being really weird when I first started. So now, okay, I understand that.
SPEAKER_01: So one-on-one in the sense of transitioning from peer to tech lead in the most part? Or from transitioning into a position where, yeah, like you're kind of the manager.
SPEAKER_00: Like people expect you not only to be there to give them technical advice maybe and guidance, but actually to like, I'm having interpersonal issues with someone, help me out with this. Or tell me where my career should go or explain my benefits to me even. You know, all of these different like little things that maybe you've occasionally talked about but it's always been a little bit more of like a friend talk. And now you actually have power to do something about them potentially, to influence them. You have the responsibility to do something about them. And that is very awkward. I think maybe not for everyone, but certainly for me it felt like a really heavy change in like focus and the way I had to interact with people. And that was kind of challenging.
SPEAKER_01: I remember you were describing yourself as kind of an introvert and not necessarily like buddy-buddy with people on the team. And so Max from FAIR, a YC company has been on the podcast, and he's actually talked about that too. But he said that in doing so, people stopped coming to him with little things, but then those little things got to be increasingly bigger things because they were intimidated.
SPEAKER_01: How did you navigate that?
SPEAKER_00: Yeah, I think that's part of why like the one-on-one regularity is so important because you want to make people feel like they have a time that you respect for them to bring things to you. So I think that's why I feel like surely everyone has heard this message already, but there are a lot of people who still kind of haven't. They still haven't really internalized. Like the reason that you have one-on-ones, the reason that you try very hard to honor whatever frequency is the right frequency for your team, even if you don't have anything planned to talk about, is that like you need to make it comfortable for them to feel like they're not interrupting you so that when it's like they have some nagging little thing, they don't just leave it aside and leave it aside and leave it aside until it's like a raging fire. Or leave it aside until they've decided there's no job for me here and I'm quitting and I'm going somewhere else and you're scrambling to like recover this person that if you just heard three months ago they were kind of bored and feeling you know disaffected with their project or they wanted to move on to something else, you could have actually done something about it.
SPEAKER_01: Right. And so do you train yourself for certain vocabularies of like people are saying around like you know this is how I'm feeling about a certain project, you just get better you know developing empathy like. Yeah I mean I think you certainly get better at kind of detecting cues in different kinds
SPEAKER_00: of people. You get better at like part of what you need to get better at is getting people to talk to you and getting people to open up to you right. So that's part of why it is important to treat people like human beings at work and to open up about personal things a little bit right. Again you don't have to tell people all of the details of your personal life and you shouldn't pry in all the details of theirs but appreciating people as human beings is important so that you know they don't feel like they have to just be all business with you and I think that in turn just like builds up you know vulnerability, it makes them feel safer, there's that whole psychological safety is a really important research concept in building you know good teams. Teams that feel psychologically safe are able to ask each other questions that are maybe like they're not afraid to look dumb in front of one another, they're not afraid to like admit that they're mistakes and learn and they don't feel competitive and that's really important in building trust in the team and so again part of what a manager needs to do is they need to get good at opening themselves up a little bit so that people will open up to them, they can build that trust, they can build that safety and they can hear about things earlier, people will start to be unafraid to mention things to them.
SPEAKER_01: Okay, so in addition to setting up regular one-on-ones with everyone on your team which you say like every two weeks at most.
SPEAKER_00: Every two weeks would be like my recommendation would be weekly or every two weeks depending on the kind of work and how often you interact with them in other ways. So like I do weekly one-on-ones with all of my directs but I manage managers of managers so I need to talk to them every week because they've got a huge team that they need to tell me lots and lots of things about but you know if you are managing a team of five who's working on a project that you're also doing a little bit of work on, you may only need to do a one-on-one every other week because a lot of the project work and conversation is going to come out in other ways.
SPEAKER_01: Okay and so what else do you think is part of like an effective recipe for the first 90 days?
SPEAKER_00: So something that I just recently, I don't think I ever wrote about this or I don't know if I've written about it yet but like something that came up to me was I was coaching someone recently who was like yeah so I'm just, she's a new manager and she's like and I've just started this team and like you know I'm seeing these problems between these people on the team and we're talking about it, we're talking about it and I was like you know well like how does your team work together? And she was like well they don't really, like they each have their own little thing that they're working on and I was like do you do team meetings? And she was like no, not really and I was like oh well okay so this is another good thing to do right? So you have a team, presumably you know if you are a manager of a concrete something, set of projects or project or whatever, make your team a team. And that means make them sit down together as a team on some cadence to just talk about the work, talk about the projects, talk about what's going well and what isn't, you know help them think of their identity as a team so that they feel comfortable working with one another right? You know it can be very easy I think for engineers with certain kinds of backgrounds to think of engineering as really like individuals kind of like if anyone listening to this has kids you know that when kids are like a certain stage of development they do this called parallel play where like you know you've got two like three year olds or two year olds, they're not really playing together they're kind of playing next to each other right? And I think that a lot of engineering sometimes feels like parallel play where it's like people they aren't really working together exactly they're kind of each working on their own project separately and maybe they give each other code reviews but making your team actually like feel like a coherent group so that every teammate understands their role in the team but also you know hopefully can cover for one another a little bit you know sharing support burdens, you know code reviewing, doing design together. That's another big thing to do in your first 90 days that I don't think I've written about yet and is actually something important that not everybody realizes.
SPEAKER_01: And now in terms of remote work which is increasing your book came out a couple years ago so even now it's more so than it was a couple years ago. How does this apply in that context?
SPEAKER_00: It definitely applies. I will be the first to admit that I am not an expert at remote work because I've never really managed a fully remote workforce so I have like I have a team in Houston and I have some people in London right now but I you know they are in offices in those locations right they aren't sort of remote around the country but I have a lot of friends who do and I've talked to them a lot about it because I think it's really interesting. And my understanding is that it still applies it might even apply even more in certain ways in remote work because you don't have the natural occurrence of just seeing each other every day in the office when you're remote. So some of the best practices I've heard about in helping your team kind of feel like a team when you have a remote team obviously if you can get people physically together for a few days every quarter or twice a year or whatever that helps a lot. Some teams I know do something that they call like afternoon tea where everybody just turns on Zoom or whatever video chat thing that they use and they all get tea or coke or coffee or whatever they like and sit around and talk about not work for half an hour and whoever you know wants to stop by and just like hang out in an afternoon that's a chance to like see people and have a specific kind of ritual that would be like talking at the water cooler at the coffee pot at work. So those are pretty important ways of just like kind of building that camaraderie and team culture even when you have a remote team.
SPEAKER_01: Okay yeah that time zone syncing is so huge. Like I know a few companies that are basically like you can be remote but you have to be within like these four time zones basically because otherwise we have no overlap and it's really hard because you don't want to force someone to stay up till 2 a.m. No totally. All right so now like if we expand to the first year of becoming a manager what are the big super common mistakes that a rookie manager often makes but can avoid?
SPEAKER_00: So the big mistakes that a rookie manager often makes and can avoid I mean okay so one of the big mistakes that I see that's hard to avoid and has a little nuance but new managers tend to default to writing code to solve their problems. So new managers who used to be ICs they look at a team and they look at a team that's struggling and the thing that they want to do is be like I can just take some of these tickets I can take some of these features I'll bang it out over the weekend I'll bang it out tonight I'll get us back on track no problem and that very rarely works well. Usually if your team is struggling to ship or they've got a tight deadline that they're not meeting the right thing for you to do is not to jump in there and add more code but is to figure out what went wrong in your planning that got you to this point is to figure out how you can unblock them in other ways how can you get designed to get them assets faster or whatever how can you work with the product team to down scope what needs to be delivered instead of just jumping in and writing code because it is very difficult to switch between the really deep focus work of writing code and the kind of broader focus work of making sure that a team is delivering well and executing well and that is definitely one of the very very common mistakes I see new managers make that you can avoid. I always want to be a little careful because I do think that it's okay for new managers of small teams to stay somewhat hands-on in the first few years. You want to stay technical. There's different technical skills needed at different levels of management but if you're managing five or six people especially if they're fairly mature people that you don't really need to hand-hold through a lot of stuff staying in the code a little bit just so that you kind of know what's going on can be helpful. So I always want to be a little careful with that advice because I don't want people to think that I'm saying never ever ever write code but at the same time if you're like in a problem situation and your default is I'm going to code my way out of it that is probably a big mistake. A big mistake that I see rookie managers make is just not dealing with interpersonal issues on their team proactively. If two people are not getting along and you just let that sit and fester it's just going to cause you problems. You can't just be like well I'm just going to have them work on completely different things and you know we'll be fine. You've got to figure out some way of dealing with it whether it's move one of the people to a different team, whether it's talk it out with them and try to figure out the root of it and remove whatever that is, whether it's you know there's a lot of different approaches you know whether it's fire one of them sometimes that's the right thing to do. But it is your job to address those interpersonal issues between people on your team and that is something I think a lot of new rookie managers are very uncomfortable with. They're uncomfortable with having those just unpleasant and kind of like gray area conversations where maybe it's not clear that one of the two people is wrong. Maybe they're both a little bit wrong and you've got to figure out how to tell each of them like you need to you know flex a little bit more on this thing and you need to stop doing that thing that's driving that person crazy. And so practicing I would say rookie managers often avoid having hard conversations and so you know when you see yourself in a situation where you do need to have a hard conversation just practicing the muscle of getting comfortable having those conversations is pretty important.
SPEAKER_01: Yeah that was one of the things I really enjoyed about the book where you basically put a name on all these different personality types you know like the people who are like working in private and then they show up all of a sudden with like all this code and like a million other types all the way to the point of these are the people that are end up being like toxic for your company. So in terms of like firing as far as I understand is like one of the hardest things for an average manager in general but a new manager in particular. What are the signs that a new manager should be looking for? It's like you know what I might actually have to step up and do this.
SPEAKER_00: So the big ones are okay so like first of all let's go through the obvious ones. Like they're coming from the company, lying, harassing their colleagues, screaming at people like that stuff is just it's not okay you can get in trouble for it you can get in trouble the company can get in trouble you know. I know while management might be sort of regaining a little bit of popularity in tech HR still seems to be kind of you know less let's say less popular but like there are important things that HR knows about that are like legally important for you to kind of be aware of. So okay so there's that set of things.
SPEAKER_00: So the harder ones are someone who's just not producing and then someone who is a drain on the team and very negative on the team but isn't like actively harassing people or you know something where it's just super very obviously over the line. Not producing is still hard because I think often we really want to make excuses for people and say like well you know they're on this really hard project they weren't ramped up well that's that kind of situation is where if you have an HR team they'll help you come up with like a performance improvement plan at PIP and you don't have to have an HR team to do this. That's really just you have to sit down and think to yourself what would I need to see from this person over the next 90 days 30 days whatever makes sense to know that they are able to produce at the level that we need them to be able to produce right. Whether it's you know finish this project you know submit this many features that don't without bugs or with minimal bugs you know and getting specific is hard and it often feels a little scary I think for managers right. Getting specific about like these are the things that you absolutely have to do to not get fired is kind of terrifying but it is pretty important to get as specific as you can on that side. On the personal interpersonal interaction side I think is a little harder because I do think that there are sometimes when you shouldn't PIP someone you should just say you know what this is just not working out and we just need to part ways. I think that people who clearly are just unhappy that they clearly don't want to be there they're super negative about everything you've talked to them in the past and said like hey can you be more positive can you be more constructive and they just don't take the feedback that they're draining the team you kind of see them just draining the productivity of the team. Those are the people that a PIP just does not always make sense right when your PIP is like change your personality.
SPEAKER_01: Like the product. You know I just I think that's kind of a hard thing to ask of someone.
SPEAKER_00: You can I've seen so I will say that I have never I've always said this but I'm always surprised when I do it and I watch it happen which is like when you have someone on a team who's just clearly a big negative drain move them you know moving to them to another team another area or moving them out of the company even if you don't have like even if they're very productive or you think of them as like very smart and very productive the impact the positive impact on the team when you get rid of that negative energy is always shocking to me because it's always more than you think it's going to be like the team is always so much happier and healthier and therefore more productive once they get rid of those kind of like super dragged down individuals in a way that to this day like I've and I've done this a bunch of times and I'm still always a little bit surprised like wow gosh just a negative person on a team can really drag a whole team down.
SPEAKER_01: Okay yeah that's a good insight. To step back a little bit you were talking about becoming a manager and still wanting to write code. I know a lot of people who have made that transition really struggle. It's a big part of their lives. They were drawn to it for a reason. They want to be a maker.
SPEAKER_00: Yeah.
SPEAKER_01: To some extent. What do you say to that person?
SPEAKER_00: It's hard. I mean I would say like the first two years that I was a hands-off manager I felt the thing is part of it is that you feel guilty. Like I actually think a lot of it is just that you have this guilt that you're like not productive. Right. Because if you have been a really good productive engineer for a number of years you are just used to that dopamine hit of like I committed some code the tests passed it's in production people are using my thing. I see myself burning down the tickets. I see these fast feedback loops. And management is slow slow feedback loops. And so I think that I do think some of it is like you just kind of kind of push through that feeling of you're not being productive. You're doing something you're not as good at also. So it's going to take you a while to get that mastery that you probably have with code. And be patient and see where you feel. If after six months or a year you've given it your all and tried to get better and you're still hating it don't force yourself to be a manager. I think the industry has done a really good job over the last 10, 20 years of good companies try very hard not to force good engineers to be managers to continue to get promoted. Most companies that I see that I would consider to be quality companies they have separate tracks that do not require you managing a lot of people or any people at all to become a very senior person. You have a career. These days I'm always thrilled when I find someone who is a really good engineer who said they wanted to manage and maybe they did start managing a little bit and then is like you know what never mind I'm happy being an ICM. Always like yes this is great because there are so few really great seasoned experienced engineers who are comfortable not having to manage a whole they're comfortable with like leading through influence instead of having the actual authority of managing people and they kind of know what to do around big projects. That skill set is so rare. You have a career path. Don't force yourself to be a manager.
SPEAKER_01: That's great advice. So do you have an opinion on side projects to scratch that itch? I think side projects are great.
SPEAKER_00: I mean like I think both side projects are great and that you shouldn't feel like you're like you have to have side projects. You know if you're a side projects person you were probably already a side projects person before you became a manager and so you'll probably continue to be one. I actually have not really mostly been a side projects person. I kind of like working on and thinking about things that I feel like are really directly relevant to like kind of immediate goals in front of me. So I think side projects are great. I would say the downside of side projects especially so look I do like platform engineering, infrastructure engineering, big distributed systems. Knowing a little bit of like Go or like having like spun up Kubernetes on my you know on a test cluster at home is not nearly enough to have an informed good opinion about a new language or like a new system like like you have to run those systems in production in anger and get cut and burnt and you know hurt by them to really understand them. And so I would say the one risk of side projects is that sometimes when I see leaders who are really obsessed with their side projects they're always kind of trying to tell their engineers like oh like I know better and this is like totally easy or I've done this. I played around with this and I think this is super cool so let's work on this. And not respecting that like that's not the thing that you've actually spent 40 hours a week for the last few years like really focused on and you don't really know what you're talking about. So you want to be a little careful about letting your side project teach you things that it's not actually teaching you.
SPEAKER_01: Yeah it can also it can change people in the way that they always feel like they have to jump from the new coolest thing to the new coolest thing when in reality they have no experience scaling that thing. Certain things are around for a reason. So I think another common thing that new managers feel is just being overwhelmed. And so as a new manager when you're feeling like this is so much like I don't know what to do what do you tell that person?
SPEAKER_00: So I mean one of the things I tell them is like welcome to management. You know because I actually feel like management is being overwhelmed a little bit. Like management is especially at a startup is sort of having more things going on than
SPEAKER_00: you can possibly know all the details of and you have to get comfortable making decisions without knowing all of the details of things. So some of the things I tell people are like you know first of all like what could you just stop doing? Like what can you just drop? And maybe it will fail but it's just not that important and so whatever right? What is something that you are just stressing out about? It's just like is this really a thing for you to even be worrying about? Can you delegate it? Can you give it to someone else to do who may not do as good a job as you would but it will get done? They'll learn something and you will get some time back. Learning how to delegate is definitely a huge part of that. You know what are you holding to to high a standard that just isn't important enough to hold to that high a standard? Everybody's going to have different answers about that right? But you know I think I'm trying to think of some good examples. Certainly like you know most I think startup engineering managers will say like recruiting is super super important and you don't want to drop that. But there are actually times when it's like you know what maybe you doing every single coffee with every single person isn't the right use of your time. And like if you are a senior person and you're hiring some very junior folks like maybe there's someone on your team that you're like this person is a great culture carrier for this company they can help me do some of these coffees to sell candidates to come in and interview here right? You know I don't have to be on every hiring loop for every junior engineer right? So like there's no there's no one thing that you absolutely can't ever drop right? Occasionally you're going to drop things. I think getting comfortable with that is pretty important. And then you know don't be afraid to ask for help also if you can. You don't always get help but like you don't have to know how to do everything. Especially if you're a new manager if your manager has any experience at all they're going to know that you don't know how to do everything that you need help. And you know speaking for myself as a manager of managers it's much harder to manage someone who never asks you for help and doesn't think that they should you know lean on you occasionally than someone who knows when to come to you and ask for help. Because like I mean it's the same as look if you're a new grad you know individual contributor right? If you never ask any questions and you just let yourself like drown in a project you know your tech leader your manager is going to get kind of frustrated. It's better to say like I've been working on this for half a day or day I cannot figure it out I need to ask some questions. Like that doesn't change when you become a manager.
SPEAKER_01: And now are you a proponent of new managers getting coaches?
SPEAKER_00: I mean I think coaching is great. I think having peer mentoring, coaching, asking your friends for advice. Like I basically think management is super hard and it's you know it's hard. I would not have gotten to where I was if I hadn't had coaches and friends that I asked for advice. Like I use every outlet I can possibly have to like think of good ideas for how to do things so I'm definitely a fan of that.
SPEAKER_01: Okay cool. So now I have some like team management questions. There's a lot of interesting stuff happening where like acquires people running small startups get brought into teams, larger companies, maybe someone joins a big company and then tries to bring all their friends over.
SPEAKER_01: Sometimes the teams don't always mix perfectly. How do you get a team to gel like vibe together and be productive as a team rather than like two silos?
SPEAKER_00: Yeah so I think personally that like generally speaking the clearer you can be about the values of the company or your division of a company and reinforce those values in people the better you'll be able to get people's ultimately to gel. I think when I see teams that really don't gel at all usually it's just like a values mismatch. So and that could mean like one team is very much a like they're over communicators, they like to eat lunch together all the time, they're constantly like talking and collaborating and brainstorming and they're very much sort of that kind of team. If you bring in another team that's very much like no like we're all researchers, we work on our things separately, we occasionally like consult one another and then you know but our job is like working independently on things and then bringing them when they're more close to fruition which is not necessarily the wrong way for a certain kind of you know role to work. If you try to bring those two cultures together you're going to start to see a lot of culture clashes. And so I think that as a manager you want to reinforce a sort of shared cultural values as much as possible on teams. And that can also mean like you know that can also mean really just being taking a hard line on like look this isn't our culture and you know we need you to behave in a different way right? Like yeah you're used to like really going off and being very independent and working on your own thing and then bringing it out and some fruition but this is a team where we just collaborate a lot more, we work a lot more closely together, we talk a lot more. We need you to try to like work with the way we work or perhaps this is not like a good fit for us.
SPEAKER_01: So wait like let's make that concrete right? So say like you know even with like this PIP thing in mind right? We talk a lot more. Yeah.
SPEAKER_01: What does that mean?
SPEAKER_00: So okay so let me give you a better example because like you know people always get very touchy about this because they're like you know people have different person I'm an introvert, I'm an extrovert.
SPEAKER_00: If you have a team where you expect people to come to stand ups, to come to planning meetings that you have an expectation that like you know that you know if you want to do a new project you're gonna sit down, you're gonna create a design document but then sit down with people and get that design document like you know get feedback on it. You're gonna do pair programming let's say and you have someone who comes in and is like I'm not doing stand ups, stand ups are bullshit. All this process is nonsense. I'm not gonna do any of that stuff right? I'm not bringing you a design document. I'm bringing you a fully fully implemented system. That's just not gonna fly right? And I think it's you know these are like these sound like processes but there is a bit of
SPEAKER_00: a cultural element to those processes right? Maybe a more concrete one is like operational excellence is a big cultural thing for the team that I run now. I think it's very important because we run big platform infrastructure. You want really good operational practices. People who like just never ever ever want to think about supporting their own software are not gonna be good fits for my team because it's just simply not okay for you to write software and throw it over the wall to some magical operations team that doesn't exist and pretend like that's gonna be fine. It's like no actually other people use your software. If it breaks you need to be able to fix it. You need to be thinking about how people are gonna use your software and how it's gonna live for a long time. And if you want to write software that is sort of more like experimental or like not really used by large groups of people you shouldn't be working on a platform infrastructure team because that's not gonna you know you're just not gonna gel right?
SPEAKER_01: Yeah well that's I mean in my mind that's just one of those things when you're hiring someone you're like hey listen this is how we roll if that's not cool with you we're fine here.
SPEAKER_00: Yeah and I think you're I think you're right but at the same time like I actually think that people don't rarely take the like time to do that in hiring.
SPEAKER_01: No.
SPEAKER_00: Right like I think there are companies I've heard that like Amazon is like has a process where they go through like the core values of Amazon they're trying to like make sure whoever they're interviewing is matching those core values. But even the core values of Amazon aren't necessarily the core values of like AWS based
SPEAKER_01: in New York. It's true.
SPEAKER_00: Well and the thing is that a lot of engineering companies do have interview processes that don't really lend themselves to that. So like if you have these interviewing processes where it's just like we have a standardized process for every engineer that joins this company and then we put you on whatever team you have no way of knowing like you may a company may need people who both like hack at the edges and think really carefully about reliability and you may have an interviewing process that interviews those two people exactly the same way. Yeah. And does not give you any indication of what kind of person you're getting out of this process you get some people like who are hackers and some people who are reliability wonks and you just randomly place them. And so it's actually very very hard to a lot of hiring processes just are not set up well to screen for that. Right.
SPEAKER_01: And so are you I mean that's the thing like are you a proponent of trial periods?
SPEAKER_00: I think trial periods I mean I think trial periods are a very nice idea. I think in the current competitiveness for staffing you would be very lucky to get away with trying to do that. I also think that like if your company is big enough you should be trying if you hire someone and you think they're great but they don't work out in the job you put them in as long as you think they're a general cultural fit for the company you should try to find a place for them. Okay. And that's something that I've actually had to work on and been working on a lot where it's like I really want to figure out what people's strengths are and play to those strengths and not try to be so arrogant as to say if you don't meet all the strengths that I think the ideal engineer has you're out. Because you know I've just learned too often that like there are those people who have unique personal strengths that maybe make them kind of one-offs in my team but that one-off thing that they do is so useful for my whole organization. Right. But even though we hire them as you know a software engineer on this kind of team the fact of the matter is they're willing to do this other role for my whole org that's so critical it's totally worth it. And that's something that I've learned and been working on over the years and getting better at is like if I think someone's really talented but they're just not in the right spot can I find the right spot for them in the organization.
SPEAKER_01: So following those strengths what are the best ways to you know give kudos to someone like as a new manager how do you like tell someone that they're doing great? I mean. Obviously it's time and time. I mean tell them that's obvious but not a thing everyone does.
SPEAKER_00: Being specific. Figuring out people. Some people like to be praised in public and some people don't. Although I will admit that like I'm not very good at remembering to ask people that. Like if I was a little bit more aware I would be better at asking that. I guess I'm just too vain. I can't imagine not wanting to be praised. You know I think being specific. I actually do my team every time we do an all hands we do at the very end we say like you know who's done something awesome. And I ask people to just stand up and thank their coworkers for doing great things. And that's something that we started at Rent the Runway and I've carried over to my current team. I just think like one of the best ways to praise people is not just your manager saying you did something great although that always feels nice. But it's also to have your peers like say something nice and encouraging people to feel open with praise and kudos. I think it makes for a nice place to work.
SPEAKER_01: Cool. So transitioning to some other non-specific managerial topics. How do you feel about non-engineers running engineering teams?
SPEAKER_00: So I mean generally speaking I don't like it. I think you know engineering management is a technical discipline and so I think that mostly you need engineers running engineering teams. At some point you know at most companies you're going to report to someone senior enough is going to report to someone who's not an engineer. When I was the CTO at Rent the Runway I reported to the CEO she was not an engineer. And so if you are an executive or a very very senior manager you might have to report to a non-engineer and you should feel very comfortable with that. But I think that it's really important to have engineers, former engineers be engineering managers as much as humanly possible for just so many reasons. Part of it is just credibility. It's hard to have credibility with an engineering team if they don't feel like you understand what they do. And you know non-technical managers can find themselves getting into this thing where they end up playing manager telephone where they're talking to product or business or whatever about something and they're asked something about like oh like how hard is it going to be to build this feature or you know what's the load blah blah blah right. And they can never answer that question. They always have to then telephone back to a member of the engineering team, ask them that, take that, translate it back to the business. And so they end up in this like telephone role which is just not efficient. If all you're doing is playing management telephone your manager is adding very little value to the team. And so that's why I think management is not just about people management because people management is just not all of the job. Like not all of the job is just having one-on-ones and talking to people about their careers. It's also like are we working on the right things? Is the team executing efficiently? How do you know that if you don't know what it feels like to be on an effective engineering team? If you don't know what the challenges of writing code are or operating systems or whatever?
SPEAKER_01: So then how do you as someone now is not writing code. I assume you're not writing code. How do you stay legit?
SPEAKER_00: How do I stay legit? I stay legit by having a lot of technical senior IC friends who I talk to all the time about what's going on, what they're thinking about, what they're working on. Just thinking about systems and how they're evolving is part of it. I mean I stay legit because I see I get a lot of design presentations given to me. I was always sort of an architect as well as an engineer. Whether or not you believe architecture is a thing. I've done a lot of software and systems architecture. I'm still pretty good at thinking about systems and the way systems should interact and how they break down. That applies kind of to humans and to software. I still hear a lot of that stuff. I still sit in and read design docs and try to understand the inner workings of the systems a little bit. That helps me ask good questions. I think being able to ask good questions is what makes you legit to engineers. If they feel like you actually understand what they're telling you that they're working on and can ask them an insightful question about that system, you get a lot of crowd immediately.
SPEAKER_01: Okay. Okay. How do you differentiate management from leadership?
SPEAKER_00: This is an interesting question because I think people think about this question a lot. There's a lot of kind of like anodyne answers to it. I actually thought about this question. You sent me some of these questions beforehand. I thought about this and I talked to some friends about it because I was like, I want to give an answer that's a little bit more interesting than leadership is everywhere. Which is true, by the way. People can be in leadership positions without being managers. One thing I was thinking about yesterday, and this is a little bit of a half-assed thought, but you'll have to indulge me on this. So one of the things I was thinking about yesterday is that there's kind of like three elements that you can sort of think about people having. So one of them is their execution skills area. One of them is their strategy, strategic thinking, vision area. And one of them is kind of like the interpersonal, charisma, whatever. So if you think about these three skill areas, I would say that leadership can be seen in
SPEAKER_01:
SPEAKER_00: any of them, but most people who are leaders have at least two of them that they're pretty strong at. So if you think of like a visionary founder who's maybe not a good manager and doesn't even necessarily have like deep tech execution skills or anything like that, but they're like super visionary and also they're just like very charismatic, really good at selling their vision, really good at getting people to follow them. So they've got kind of the interpersonal and the strategy side, right? Clearly a leader. I think that a lot of managers fall into the, they're very good at execution, they have good skills on management and possibly also on engineering and they're good interpersonally, right? They can get people to talk to them. They understand how to like work with a team. A strong individual contributor leader might have really good skills and really good strategic sense, right? But maybe they're not as good at interpersonal and that's okay because their strategy kind of speaks for themselves. So what is leadership? Leadership is whatever that quality is that gets people to want to follow you, right? And sometimes people follow people because they trust that they just like they know what they're doing and that they have their best interests at heart. And sometimes people follow people because they just think that their vision is amazing and like it's so clear that if they do what that person says, even if maybe they don't like them that much interpersonally, that they're like something amazing is gonna happen and they just have the kudos and the cred to do that. So I think leadership can come everywhere. What I will say is that I don't think there are very many successful managers who don't have any leadership skills. I think management is leadership. That doesn't mean all leadership is management. But I do think it is very hard to be a good manager without people wanting to work for you.
SPEAKER_01: And so how do you build that? Another common one is just like you're just super legit. You made something that a ton of people used and you had a crazy insight there. If you sense, and I think this is already a great set, but if you sense like you know what, like maybe I don't always have that leader vibe, what would you say to that person? How do they build it up?
SPEAKER_00: So I mean it would very much depend on the person, right? But like I think what I would say is like are you able to like provide clarity in times of ambiguity about whatever it is that you do, right? So if you're an engineer, let's say you don't manage people, you're an engineer and someone comes to you with like a big hairy problem, do you just add complexity to that problem
SPEAKER_00: for them and tell them all the ways it's going to break or all the ways it's going to fail or why this is hard? Or do you kind of look at that problem and go away and say maybe it is hard, you know, and maybe you say like this is actually, we can't do this because these fundamental reasons. But do you simplify the getting to a solution to that problem? And can you explain to other people what that simplification is? You know, that, I think that providing a clarity is one of the most important parts of leadership wherever it comes from, right? Because I think a lot of people, you know, a lot of the things we deal with in life are just ambiguity, right? And ambiguity is scary and people look to leaders to make them feel less scared, to make them feel, you know, like things are going to be okay, to give them, to help them make decisions. And so you have to be someone that people want to look to to make those decisions. And you know, again, sometimes that's you just need to develop a track record of showing that you make good decisions and then people will start to trust you. But sometimes that's you need to get good at explaining and simplifying the way you think into a way that other people can understand what your decision process is so that they then can follow you, right? And sometimes you just need to, you know, frankly sometimes you just need to work on your interpersonal skills so that you don't, you know, shove people away so much and, you know, make them feel bad every time they talk to you, right? You know, you don't have to have the best interpersonal skills to be a leader, but like if you really like make people afraid a lot and, you know, that's pretty bad in the modern workflows, I think. Yeah, I mean if you've been in tech for any longer than a week, you've met that guy before.
SPEAKER_01: Yeah. There's a lot of condescension. Yeah. Awesome. So this has been really, really great. If someone wants to pick up your newest book, where can they go?
SPEAKER_00: So it's going to be an O'Reilly publication, so it will be on Safari, it will also be on Amazon, Kindle. I don't exactly know what the date is yet, so that'll be sometime fall, early winterish, timeframe is my guess. But yeah, it will be your favorite, the world's favorite bookstore, Amazon.com certainly. And that is also where you can find my current book, so.
SPEAKER_01: All right, awesome. Thanks so much, Camille.
SPEAKER_00: Yeah, thank you.
SPEAKER_01: All right, thanks for listening. So as always, you can find the transcript and the video at blog.yacombinator.com, and if you have a second, it would be awesome to give us a rating and review wherever you find your podcast. See you next time.
