Camille Fournier 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 @skamille.
00:00 - Intro
00:35 - Why do many individual contributors (ICs) never experience a good manager?
3:15 - How did the ideology of management being bad become pervasive in startups?
5:15 - What should a new manager do in their first 90 days?
8:45 - Getting better at 1:1s
11:05 - More tips for the first 90 days
13:05 - Remote work
15:00 - Mistakes rookie managers make
19:15 - Letting people go
23:25 - Being a manager and still wanting to write code
27:45 - Feeling overwhelmed as a manager
31:15 - Getting a team to gel
38:30 - Giving people kudos
39:45 - Non-engineers running engineering teams
41:55 - Staying legit technically as a manager
43:15 - Management vs leadership
Craig Cannon [00:00] -All right, here we go. One of the things you mention 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?
Camille Fournier [00:54] - First of all, 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, where to start. Especially when it comes to engineering management, which I feel like is a little bit different than just generic people management. First of all, I just think there's not that many good managers out there. 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 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. At that time, Google still had their 50 people to one manager kind of structure.
Camille Fournier [02:05] - 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 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, the thing that I'm observing 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, "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." That's what got me into writing about the topic in the first place. 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 a special discipline, but it's also a technical discipline and not just something that any random people manager can do.
Craig Cannon [03:15] - Right, 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." 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?
Camille Fournier [03:34] - The thing is when you're a really, really small startup, you don't necessarily need to think that much about management. When it's a very small group of people that are all just really very closely working together on very obvious objectives and 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 it's all about these future rewards, I don't think that management, I'm sure a great manager in that situation who also happened to be a great founder and strategic thinker might be great or super helpful, I don't know. 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 joined at the hip, talking to each other all the time, completely on the same wavelength. That's when structure and hierarchy and some kind of management starts to become more important. 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 was just like, "Well we got these smart people together and let them do what they thought was right and success happened." You can take the wrong lesson from that. That contributes to this disregard for management.
Craig Cannon [05:00] - What stuck out to me was the book's focus on that transition from IC to manager. Many other things are about org structure and motivating the team and all that kind of stuff, this is very much about, "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." Maybe what would be most helpful for us to talk about are those early days. That first year, maybe, of an IC's transition from an engineer full time to a manager. You have different, tech lead and all kinds of different roles for that. 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?
Camille Fournier [05:43] - A lot of it is just getting comfortable with the routines of management that are different than what you were doing before. It, 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 my job is doing a lot of project management already and leadership and code reviews and things like that." Maybe you're already used to not having to type code all day, but you probably still aren't comfortable with things like that 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. If you've never been the person who is the manager in a one-on-one situation, it just is weird. I remember it being really weird when I first started--
Craig Cannon [06:32] - Now, okay, I understand that. One-on-one in the sense of transitioning from peer to tech lead in the most part?
Camille Fournier [06:40] - From transitioning into a position where you're the manager. People expect you not only to be there to give them technical advice maybe, and guidance, but actually to, "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." All of these different little things that maybe you've occasionally talked about but it's always been a little bit more of like a friend talk. 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. Maybe not for everyone, but certainly for me it felt like a really heavy change and focus in the way I had to interact with people and that was kind of challenging.
Craig Cannon [07:30] - I remember you were describing yourself as kind of an introvert and not necessarily buddy-buddy with people on the team. Max from Faire, a YC company, has been on the podcast and he's actually talked about that too. 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. How did you navigate that?
Camille Fournier [07:55] - That's part of why 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. 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 that 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 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 recover this person that if you had just heard three months ago they were kind of bored and feeling disaffected with their project or they wanted to move on to something else, you could have actually done something about it.
Craig Cannon [08:57] - Do you train yourself for certain vocabularies of what people are saying around you know, "This is how I'm feeling about a certain project"? You just get better at developing empathy?
Camille Fournier [09:08] - You certainly get better at kind of detecting cues in different kinds of people. You get better at, part of what you need to get better at is getting people to talk to you. Hetting people to open up to you. 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. 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 they don't feel like they have to just be all business with you. That, in turn, just builds up vulnerability, it makes them feel safer. There's that whole psychological safety is a really important research concept in building good teams. Teams that feel psychologically safe are able to ask each other questions that are maybe, they're not afraid to look dumb in front of one another. They're not afraid to admit that their mistakes and learn and they don't feel competitive and that's really important in building trust in the team. 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.
Craig Cannon [10:30] - In addition to setting up regular one-on-ones with everyone on your team, which you say like every two weeks at most, right?
Camille Fournier [10:40] - 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. 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. If you are managing a team of five, who's working on a project that you're also dong 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.
Craig Cannon [11:11] - What else do you think is part of an effective recipe for the first 90 days?
Camille Fournier [11:16] - Something that I had just recently, I don't think I ever wrote about this or I don't know if I've written about it yet, but something that came up to me was I was coaching someone recently who was like, she's a new manager and she's like, "And I've just started this team and 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, "Well, how does your team work together?" And she was like, "Well, they don't really. They each have their own little thing that they're working on." And I was like, "Do you do team meetings?" And she goes, "Not really," and I was like, "Oh!" This is another good thing to do. You have a team, presumably if you are a manager of a concrete something, set of projects or project or whatever, make your team a team. 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. Help them think of their identity as a team so that they feel comfortable working with one another. It can be very easy, for engineers with certain kinds of backgrounds to think of engineering as really like, individuals, if anyone listening to this has kids, you know that when kids are at a certain stage of development, they do this called parallel play. Where you've got two three year olds or two year olds, they're not really playing together, they're kind of playing next to each other. A lot of engineering sometimes
Camille Fournier [12:42] - 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. Making your team actually feel like a coherent group so that every teammate understands their role on the team but also, hopefully, they can cover for one another a little bit, sharing support burden, code review, 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.
Craig Cannon [13:15] - 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?
Camille Fournier [13:25] - 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 a team in Houston and I have some people in London right now, but they are in offices in those locations where they aren't remote around the country. 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. 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. 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 afternoon tea where everybody just turns on Zoom or whatever video chat thing that they use and they all get tea or a Coke or a coffee or whatever they like and sit around and talk about not work, for half an hour. Whoever wants to stop by and just hang out, an opportunity, it's a chance to see people and have a specific kind of ritual that would be like talking at the water cooler or at the coffee pot at work. Those are pretty important ways of just building that camaraderie and team culture even when you have a remote team.
Craig Cannon [14:51] - Okay, yeah, that time zone syncing is so huge. I know a few companies that are basically like, "You can be remote but you have to be within 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 til 2:00 am.
Camille Fournier [15:05] - No, totally.
Craig Cannon [15:06] - All right, so now 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?
Camille Fournier [15:22] - The big mistakes that a rookie manager often makes and can avoid... 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. 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." 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 design to get them assets faster or how can you work with the product team to downscope 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 a team is delivering well and executing well. That is definitely one of the very, very common rookie mistakes I see new managers make that you can avoid. Now, 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.
Camille Fournier [17:03] - 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 handhold 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. 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 in a problem situation and your default is, "I'm going to code my way out of it," that is probably a big mistake.
Craig Cannon [17:37] - Right.
Camille Fournier [17:38] - Other mistakes that I see rookie managers make. 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 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, there's a lot of different approaches, whether it's fire one of them, sometimes that's the right thing to do. It is your job to address those interpersonal issues between people on your team and that is something I think a lot of rookie managers are very uncomfortable with. They're uncomfortable with having those unpleasant and kind of 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. You've got to figure out how to tell each of them like, "You need to flex a little bit more on this thing," and "You need to stop doing that thing that's driving that person crazy." I would say rookie managers often avoid having hard conversations and so 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.
Craig Cannon [19:08] - That was one of the things I really enjoyed about the book, where you basically put a name on all these different personality types. The people who are working in private and then they show up all of a sudden with all this code and a million other types all the way to the point of these are the people that end up being toxic for your company. Firing, as far as I understand, is one of the hardest things for an average manager, manager in general but a new manager in particular. What are the signs that a new manager should be looking for as like, "You know what, I might actually have to step up and do this"?
Camille Fournier [19:44] - First of all, let's go through the obvious ones. Stealing from the company, lying, harassing their colleagues, screaming at people, that stuff is not okay, you can get in trouble for it, you can get in trouble, the company can get in trouble. I know while management might be sort of regaining a little bit of popularity in tech, HR still seems to be kind of less popular, but there are important things that HR knows about that are legally important for you to be aware of. There's that set of things. 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 actively harassing people or something where it's just very obviously over the line. Not producing is still hard because often we really want to make excuses for people and say like, "Well, they're on this really hard project, they weren't ramped up well." That kind of situation is where, if you have an HR team, they'll help you come up with a performance improvement plan, a 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. Whether it's finish this project, submit this many features without bugs or with minimal bugs and getting specific is hard and it often feels a little scary for managers. Being specific about these are the things
Camille Fournier [21:39] - 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 some times 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." People who clearly are just unhappy, they clearly don't want to be there, they're super negative about everything, you've talked to them in the past and said, "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 and you can kind of see them just draining the productivity of the team. Those are the people that a PIP just does not always make sense. When your PIP is like, "Change your personality."
Craig Cannon [22:30] - Like the product.
Camille Fournier [22:32] - You know? I think that's kind of a hard thing to ask of someone.
Craig Cannon [22:35] - Of course.
Camille Fournier [22:37] - I will say that 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, moving them to another team, another area, or moving them out of the company, even if they're very productive or you think of them as very smart and very productive, 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. The team is always so much happier and healthier and therefore more productive once they get rid of those super drag down individuals. In a way that to this day, and I've done this a bunch of times and I'm still always a little bit surprised. A negative person on a team can really drag a whole team down.
Craig Cannon [23:27] - 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 to some extent. What do you say to that person?
Camille Fournier [23:51] - It's hard. I would say the first two years that I was a hands off manager, part of it is that you feel guilty. I actually think a lot of it is just that you have this guilt that you're not productive. 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." Management is slow, slow feedback loops. I do think that some of it is you just kind of got to push through that feeling of you're not being productive, you're doing something you're not as good at also. 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. Now, 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. 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
Camille Fournier [25:25] - wanted to manage and maybe they did start managing a little bit and is like, "You know what, nevermind, I'm happy being an IC." I'm always like, "Yes, this is great!" Because there are so few really great seasoned experienced engineers who are comfortable not having to manage, they're comfortable with leading through influence instead of having the actual authority of managing people and they kind of know what to do around big projects. That skillset is so rare, you have a career path, don't force yourself to be a manager.
Craig Cannon [25:55] - That's great advice. Do you have an opinion on side projects to scratch that itch?
Camille Fournier [26:01] - I think side projects are great. Side projects are great and that you shouldn't feel like you have to have side projects. 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 are really directly relevant to immediate goals in front of me. I think side projects are great. I would say the downside of side projects, especially... I do like platform engineering, infrastructure engineering, big distributed systems. Knowing a little bit of Go or having spun up Kubenetes and Eddy's on a test cluster at home is not nearly enough to have an informed good opinion about a new language or a new system. You have to run those systems in production, in anger, get cut and burnt and 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, "I know better, this is 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 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. You want to be a little careful about letting your side project teach you things
Camille Fournier [27:36] - that it's not actually teaching you.
Craig Cannon [27:38] - 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. I think another common thing that new managers feel is just being overwhelmed. As a new manager, when you're feeling like, "This is so much, I don't know what to do," what do you tell that person?
Camille Fournier [28:07] - One of the things to tell them is like, welcome to management. Because I actually feel like management is being overwhelmed a little bit. Management is, especially at a start up, is sort of having more things going on than you can possibly know all the details of and you have to get comfortable making decisions without knowing all of the details of things. Some of the things I tell people are first of all, what could you just stop doing? 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 that'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. What are you holding to too 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, but I think, I'm trying to think of some good examples. Certainly most start up engineering managers will say recruiting is super super important, and you don't want to drop that. But there are actually times when it's like, maybe you doing every single coffee with every single person isn't the right use of your time. If you are a senior person and you're hiring some very junior folks, maybe there's someone on your team that you're like, this person
Camille Fournier [29:44] - 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. I don't have to be on every hiring loop for every junior engineer. There's no one thing that you absolutely can't ever drop. Occasionally you're going to drop things and I think getting comfortable with that is pretty important. Don't be afraid to ask for help also if you can. You won't always get help but 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. 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 lean on you occasionally, than someone who knows when to come to you and ask for help. It's the same as, if you're a new grad, individual contributor, if you never ask any questions and you just let yourself drown in a project, your tech lead or your manager is going to get kind of frustrated. It's better to say I've been working on this for half a day or a day, I cannot figure it out, I need to ask some questions. That doesn't change when you become a manager.
Craig Cannon [30:57] - Are you a proponent of new managers getting coaches?
Camille Fournier [31:02] - Coaching is great, I think having peer mentoring, coaching, asking your friends for advice. I basically think management is super hard and 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. I use every outlet I can possibly have to think of good ideas for how to do things. I'm definitely a fan of that.
Craig Cannon [31:25] - Now I have some team management questions. There's a lot of interesting stuff happening where acquihires, people running small start ups get brought into teams, larger companies, maybe someone joins a big company and then tries to bring all their friends over. Sometimes the teams don't always mix perfectly. How do you get a team to gel, vibe together and be productive as a team, rather than two silos?
Camille Fournier [31:58] - 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 ultimately to gel. When I see teams that really don't gel at all, usually it's just like a values mismatch. That can mean one team is very much, they're over-communicators, they like to eat lunch together all the time, they're constantly talking and collaborating and brainstorming, they're very much that kind of team. If you bring in another team that's very much like, no, we're all researchers, we work on our things separately, we occasionally consult one another, but our job is 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 role to work. If you try to bring those two cultures together, you're going to start to see a lot of culture clashes. As a manager, you want to reinforce a shared cultural values as much as possible on teams. That can also mean just taking a hard line on like, "Look, this isn't our culture and we need you to behave in a different way. You're used to going off and being very independent and working on your own thing and then bringing it out when it's in 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 work with the way we work or perhaps, this is not a good fit for us."
Craig Cannon [33:50] - Let's make that concrete. Even with this PIP thing in mind, you're like, "We talk a lot more." What does that mean?
Camille Fournier [34:00] - Let me give you a better example. Because people always get very touchy about this because they're like, people have different, "I'm an introvert, I'm an extrovert." 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 if you want to do a new project, you're going to sit down, you're going to create a design document, but then sit down with people and get that design document, get feedback on it. You're going to do pair programming, let's say. And you have someone who comes in and is like, "I'm not doing standups. Standups are bullshit. All this process is nonsense, I'm not going to do any of that stuff. I'm not bringing you a design document. I'm bringing you a fully implemented system," that's just not going to fly. And I think it's, these sound like processes but there is a bit of a cultural element to those processes. 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 just never, ever, ever want to think about supporting their own software are not going to 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 going to be fine. It's like, no actually, other people 'use your software, if it breaks you need to be
Camille Fournier [35:34] - able to fix it, you need to be thinking about how people are going to use your software and how it's going to live for a long time. If you want to write software that is sort of more like experimental or not really used by large groups of people, you shouldn't be working on a platform infrastructure team because you're just not going to gel.
Craig Cannon [35:56] - 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."
Camille Fournier [36:03] - I think you're right but at the same time I actually think people rarely take the time to do that in hiring.
Craig Cannon [36:11] - No.
Camille Fournier [36:12] - Right? I think there are companies, I heard that Amazon has a process where they go through the core values of Amazon and they're trying to make sure whoever they're interviewing is matching those core values.
Craig Cannon [36:21] - Even the core values of Amazon aren't necessarily the core values of AWS based in New York.
Camille Fournier [36:27] - It's true and the thing is a lot of engineering companies have interview processes that don't really lend themselves to that. 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. A company may need people who both hack at the edges and think really carefully about reliability and you may have an interviewing process interviews those two people exactly the same way and does not give you any indication of what kind of person you're getting out of this process. You get some people who are hackers and some people who are reliability wonks and you just randomly place them. It's actually very, very hard, a lot of hiring processes are just not set up well to screen for that.
Craig Cannon [37:12] - Are you a proponent of trial periods?
Camille Fournier [37:19] - Trial periods are a very nice idea. In the current competitiveness for staffing, you would be very lucky to get away with trying to do that. I also think that 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. 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 I've just learned too often that there are those people who have unique personal strengths that maybe make them one-offs in my team, but that one-off thing that they do is so useful for my whole organization that even though we hired them as 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. 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?
Craig Cannon [38:37] - Following those strengths, what are the best ways to give kudos to someone? As a new manager, how do you tell someone that they're doing great? Obviously beside telling them.
Camille Fournier [38:51] - Telling them is obvious but not a thing everyone does. Being specific, figuring out people. Some people like to be praised in public, and some people don't, although I will admit that I'm not very good at remembering to ask people that. If I was little bit more aware I would be better at asking that. I guess I'm just too vain and I can't imagine not wanting to be praised in public. Being specific. My team, every time we do an all-hands, we do, at the very end, we say who's done something awesome? I ask people to just stand up and thank their coworkers for doing great things. That's something that we started at Rent the Runway and I've carried over to my current team. 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 say something nice and encouraging people to feel open with praise and kudos, I think it just makes for a nice place to work.
Craig Cannon [39:54] - Cool. Transitioning to some other non-specific managerial topics, how do you feel about non-engineers running engineering teams?
Camille Fournier [40:04] - Generally speaking, I don't like it. Engineering management is a technical discipline and so I think that mostly you need engineers running engineering teams. At some point, 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 of Rent the Runway, I reported to the CEO, she was not an engineer. 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. It's really important to have 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. 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 how hard is it going to be to build this feature, 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. They end up in this telephone role which is just not efficient. If all you're doing is playing management telephone, the manager is adding very little value to the team. That's why I think management is not just about people management because people management is just not all of the job.
Camille Fournier [41:40] - Not all of the job is just having one-on-ones and talking to people about their careers, it's also 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?
Craig Cannon [41:59] - How do you, as someone who's now not writing code, I assume you're not writing code.
Camille Fournier [42:04] - No.
Craig Cannon [42:05] - How do you stay legit?
Camille Fournier [42:08] - 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, what they're thinking about, what they're working on, just thinking about systems and how they're evolving is part of it. I say legit because 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, and so I'm still pretty good at thinking about systems and the way systems should interact and how they break down and so 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 cred immediately.
Craig Cannon [43:20] - How do you differentiate management from leadership?
Camille Fournier [43:26] - This is an interesting question because I think people think about this question a lot and there's a lot of anodyne answers to it. I actually thought about this question, you send me some of these questions beforehand and 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. And so one thing I was thinking about yesterday, so this is a little bit of a half-ass thought but you'll have to indulge me on this. One thing I was thinking about yesterday is that there's kind of three elements that you can sort of think about people having. One of them is their execution skills area. One of them is their strategic thinking, vision area. And one of them is the interpersonal, charisma, whatever. If you think about these three skill areas, I would say that leadership can be seen in any of them, but most people who are leaders have at least two of them that they're pretty strong at.
Camille Fournier [44:35] - If you think of a visionary founder who's maybe not a good manager and doesn't even necessarily have deep tech execution skills or anything like that, but they're super visionary and also they're very charismatic, really good at selling their vision, really good at getting people to follow them. They've got the interpersonal and the strategy side, clearly a leader. 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. They can get people to talk to them, they understand how to work with a team. A strong individual contributor leader might have really good skills and really good strategic sense, but maybe they're not as good interpersonally and that's okay because their strategy kind of speaks for themselves. What is leadership? Leadership is whatever that quality is that gets people to want to follow you. Sometimes people follow people because they trust that they just know what they're doing and that they have their best interest at heart and sometimes people follow people because they just think that their vision is amazing and it's so clear that if they do what that person says, even if maybe they don't like them that much interpersonally, something amazing is going to happen and they just have the kudos and the cred to do that. 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
Camille Fournier [46:08] - all leadership is management, but I do think it is very hard to be a good manager without people wanting to work for you.
Craig Cannon [46:15] - How do you build, another common one is just like, "You're just super legit. You made something that a ton of people use and you had a crazy insight there." If you sense, and I think this is already a great step, but if you sense, "Maybe I don't always have that leader vibe," what would you say to that person, how do they build it up?
Camille Fournier [46:39] - It would very much depend on the person. I think what I would say is, "Are you able to provide clarity in times of ambiguity about whatever it is that you do?" If you're an engineer, let's say you don't manage people, you're an engineer and someone comes to you with a big, hairy problem. Do you just add complexity to that problem 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 maybe it is hard and maybe you say, "We can't do this because these fundamental reasons," but do you simplify the getting to a solution to that problem? Can you explain to other people what that simplification is? Providing a clarity is one of the most important parts of leadership wherever it comes from. I think a lot of people, a lot of the things we deal with in life are just ambiguity. Ambiguity is scary and people look to leaders to make them feel less scared, to make them feel like things are going to be okay, to help them make decisions, and so you have to be someone that people want to look to to make those decisions. 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.
Camille Fournier [48:16] - Frankly, sometimes you just need to work on your interpersonal skills so that you don't shove people away so much and make them feel bad every time they talk to you. You don't have to have the best interpersonal skills to be a leader, but if you really make people afraid a lot, that's pretty bad in the modern workplace, I think.
Craig Cannon [48:43] - If you've been in tech for any longer than a week, you've met that guy before and it's a lot of condescension. Awesome. This has been really, really great. If someone wants to pick up your newest book, where can they go?
Camille Fournier [48:57] - It's going to be an O'Reilly publication. 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. It'll be at the world's favorite bookstore, Amazon.com, certainly, and that is also where you can find my current book.
Craig Cannon [49:23] - All right, awesome, thanks so much Camille.
Camille Fournier [49:24] - Thank you.