Camille Fournier on Managing Technical Teams

All right, Camila Fournier, welcome to the podcast.

Thank you for having me! So, you are a managing director at 2 Sigma, former CTO of Rent the Runway, former VP of Technology at Goldman Sachs, also an author. Your first book was The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change, and you also have a book coming out this year that you're editing called 97 Things Every Engineering Manager Should Know. We have a lot of management questions for you!

All right, so one of the things you mentioned in the book that I found particularly interesting was a lot of people as ICs never experienced great managers. Why do you think that's the case?

I mean, first of all, I think there were just a lot of bad managers out there. Okay, uh-huh. You know, 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, you know, 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 like 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. You know, I think at that time, like Google still had their, you know, 50 people to one manager kind of structure; like all of these companies, a lot of successful companies that had started in Silicon Valley and 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, you know, I had worked at Goldman Sachs where there was management, and I had come to this start, and I was looking around, and I was like, you know, the thing that I'm observing is that actually like 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. You know, that I had all these friends who 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 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, and it's addressed in the book, but you're like, this is not a 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?

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, 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 strategic thinker might be great or super helpful, I don't know. But, you know, like realistically there are other more important things.

Yeah, 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.

And 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 there they believe incorrectly that the thing that made them successful was just like, well, we just got these smart people together and let them do what they thought was right, and you know, success happened.

Yeah, you can take the kind of wrong lesson from that, and I think that contributes to this sort of, you know, disregard for management.

Right. And what stuck out to me was the book's focus on that transition from IC to manager. Like, so many other things are about 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.

Yeah. 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, 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?

I mean, I—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, 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, like if you've never like been the person who is like the manager in a one-on-one situation, it just is weird. I mean, I remember it being really weird when I first started.

So now, okay, I understand that. So one-on-one in the sense of transitioning from peer to tech lead.

Yeah, in the most part. Or if I'm transitioning into a position where, yeah, like you're kind of the manager, like people expect you not only to be there to give them technical advice maybe and guidance, but like I'm having interpersonal issues with someone and help me out with this or tell me where my career should go or explain my benefits to me, 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. Yeah.

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 that was kind of challenging.

I remember you were describing yourself as kind of an introvert and not necessarily like buddy-buddy with people on the team, and so how did you navigate that?

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, you know, 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 don't really internalize 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, right?

And so do you train yourself for certain vocabularies, that like people are saying or like, you know, this—I'm feeling about a certain project? You just get better, you know, developing empathy.

Yeah, I mean, I think you certainly get better at kind of detecting cues and different kinds 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 into 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—a 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 their 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.

Okay, so in addition to setting up regular one-on-ones with everyone on your team, which you say ever like every two weeks at most—

All right, every two weeks.

Every two weeks is, would be 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.

Okay, so if like I do weekly one-on-ones with all 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.

Okay, and so what else do you think is part of like an effective recipe for the first 90 days?

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, 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 there's like, do you do team meetings? And she said, no, not really.

And I was like, oh, okay. So this is another good thing to do, right? So you have a team, presumably, you're, you know, if you are a manager of a concrete set of projects or project or whatever, make your team a team.

Mm-hmm.

And that means making them sit down together as a team at 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 for this has kids, you know, that when kids are like a certain stage of development, I do this called parallel play where like, you know, 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, 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, yeah. But making your team actually feel like a coherent group so that every teammate understands their role in the team, but also, you know, if we 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 it's actually something important that not everybody realizes.

Hmm, and now in terms of remote work, which is increasing, your book came out a couple years ago.

Yeah, so even now it's more so than it was.

Yeah, how does this apply in that context?

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 are sort of remote around the country, but I have a lot of friends who do, and I've talked to them a lot about 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 on. 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 or everybody just turns on Zoom or whatever video chat thing that they used.

Yeah, um—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—an opportunity like 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.

Yeah, um, so those are pretty important ways of just like kind of building that camaraderie and team culture even when you have a remote team.

Okay, yeah. That timezone syncing is so huge. Like I know a few companies that are basically like you have to—you can be remote, but you have to be within like these four time zones basically, yeah? Otherwise, we have no overlap, and it's really hard.

Yeah, because you don't want to force someone to stay up till 2:00 a.m. All right, so now that 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?

So the big mistakes that a rookie manager often makes that I can avoid—I mean, okay. So one of the big mistakes that I see—it'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're—you know, they've got a tight deadline that they're not meeting, yeah, 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 whatever? 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 focused work of making sure that a team is delivering well and executing well. And that is definitely one of the very, very common or key mistakes I see new managers make that you can't avoid.

No, I was gonna be a little careful because I do think that it's okay for new managers of small teams to stay somewhat hands-on in that, you know, in the first few years. You know, like you want to stay technical; there's different technical skills needed at different levels of management. But, you know, if you're managing five or six people, especially if they're fairly mature people, that you don't really need to like handhold through a lot of stuff. Staying in the code a little bit just so that you kind of know what's going on, it 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," yeah, that is probably a big mistake, right?

Um, you know, other mistakes that I see working managers make—I mean, a big mistake that I see working managers make is like 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—it’s just kind of caused you problems. You can't just be like, well, I'm just gonna 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 moves 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 you—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, right?

Um, you know, 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 very important.

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 the sudden with like all this code and like a million other types; all the way to the point of these are the people that end up being like toxic.

Yeah. So in terms of like firing, as far as I understand, it's like one of the hardest things for an average manager—manager in general—but now a manager in particular, yeah? What are the signs that the new manager should be looking for us?

Like, you know what? I might actually have to step up and do this. So the big ones are, okay, so like first of all, let's go through the obvious ones. Yeah, stealing 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, 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, 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 do, so—right?

Okay, so there's that set of things. 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 everything.

Yeah, 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, a PIP, and you—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—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 it's a little harder because I do think that there are some times when you shouldn't tip someone; you should just say, you know what, this is just not working out. Yeah, and we just need to part ways.

Yeah, and I think that 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 like, hey, can you be more positive? Can you be more constructive? And they just don't take the feedback; 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, like the product, I just—I think that's kind of a hard thing to ask of someone.

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 in 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 you don't have like— even if they're very productive or you think of them as like very smart, 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 drag-down individuals in a way that to this day, like I've done this a bunch of times, and I'm still always a little bit surprised.

Wow, gosh, just a negative person on the team can really drag a whole team down.

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.

Yeah, it's a big part of their lives; they were drawn to it for a reason.

Yeah, they want to be a maker to some extent. What do you say to that person?

Like, oh, 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, it's 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 pass, it's in production, people are using my thing, like, 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 like—I do think some of it is like you just 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.

Now, if after six months or a year you've, you know, 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. Like, I think the industry has done a really good job over the last 10, 20 years of good companies trying very hard not to force good engineers to be managers to continue to get promoted.

Like, yeah, most companies that I see that I would consider to be quality companies, they have separate tracks that do not require like you managing a lot of people or any people at all to become a very senior person, a very well-put career.

Yeah, I actually—you know, these days I'm always thrilled when I find someone who is like a really good engineer who said they wanted to manage, and maybe they did start managing a little bit, then it's like, you know what, never mind, and I'm always like, yes!

Yeah, this is great because like there are so few really great seasoned experienced engineers who are comfortable not having to manage a whole—that 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 on big projects.

I just—you know, that skill set is so rare, you have a career path, don't force yourself to be a manager.

Yeah, that's great advice. So do you have an opinion on side projects to scratch that itch?

I think side projects are great. I mean, like, I think I think both—I both think side projects are great and that you shouldn't feel like you have to have side projects. Yeah, I—you know, if you're a side projects person, you were probably already a side projects person before you became a manager, and you're 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'm in—I do platform engineering, infrastructure engineering, big distributed systems. Knowing a little bit of like Go or like having spun up Kubernetes on my test cluster at home is not nearly enough to have an informed good opinion about a new language or like a new system.

You might 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've played around with this. I think this is super cool, so let's work on this, right?

And not respecting that like that's not a 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.

Yeah, so you want to be a little careful about letting your side project teach you things that it's not actually teaching you.

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.

Yeah, certain things are around for a reason.

Yeah. 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, I don't know what to do, what do you tell that person?

So, I mean, I—but one of the things I tell them is like, welcome to management, okay? 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 you could 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? You know, what is something that you're 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 this as good a job as you would, but it will be done? They'll learn something, and you will get some time back.

Mhm. Learning how to delegate is definitely a huge part of that.

Um, you know, what are you holding to the highest standard that just isn't important enough to hold to that highest standard? Everybody's gonna have different answers about that, right? But you know, I think I'm trying to give some good examples like 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 cultural 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 gonna drop things. Getting comfortable with that is pretty important.

Okay, um, and then, you know, don't be afraid to ask for help also if you can, but you don't always get help. But like you don't have to know how to do everything. It's just, if you're a new manager, if your manager has any experience at all, they're gonna know that you don't know how to do everything, right? 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—that doesn’t know, 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—you know, 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 lead, your manager is gonna get kind of frustrated. It's better to say like, okay, I've been working on this for half a day or a day; I can’t figure it out; I need to ask some questions. Like, that doesn’t change when you become a manager, right?

And now, are you a proponent of new managers getting coaches?

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

Okay, cool. So now I have some team management questions, and there's a lot of interesting stuff happening where like aqua hires, people running small startups get brought into teams in larger companies. Maybe someone joins a big company and then tries to bring all their friends over.

Yeah, sometimes those teams don't always mix perfectly.

Yeah, how do you get a team to gel, like vibe together and be productive as a team rather than like two silos?

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 ultimately to gel.

Okay. I think when I see teams that really don't gel at all, usually it's just like a values mismatch. So, you know, and that could mean like one team is very much a—like they let their over communicators, they like to eat lunch together all the time; they've just like—they're constantly like talking and collaborating and brainstorming, and you know, 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 gonna start to see a lot of culture clashes. And so I think that as a manager, you want to reinforce sort of shared cultural values as much as possible on teams in, you know, 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 bringing it out into some fruition, but this is a team; well, 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.

So wait, like let’s make that concrete, right? Since I like—you know, even with like this pip thing in mind, right?

Yeah.

We talk a lot more.

Yeah. What does that mean?

So, okay. So let me give you—let me give you a better example because like, you know, people always get very—people always get very touchy about this because they're like, you know, people have different personal—I'm an introvert; I'm an extrovert.

If you are—if you have a team where you expect people to come to stand-ups, to come to planning meetings that you—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 all—this 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 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've 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 walls of 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 able to fix it, to be thinking about how people are gonna use your software and how it's going to live for a long time.

Yeah, 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 gonna gel, right?

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.

Yeah, and I think you're right, but at the same time, like I actually think that people don't rarely take the kind of time to do that in hiring, no, right?

It's like, I think there are companies I've heard that like Amazon is like has a—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, but even the core values of Amazon aren't necessarily the core values of like AWS based in New York.

Yeah, one—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 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. It's so—it's actually very, very hard to—a lot of hiring processes just are not set up well to screen for that, right?

And so are you—I mean, that's the thing—like are you a proponent of trial periods?

I think trial periods—I mean, I think trial periods are less or 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.

Yeah.

Um, 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 on the job you put them in—as long as you think there are a general cultural fit for the company, you should try to find a place for.

Okay.

And that's something that I've actually had to work on. I've 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.

Yeah.

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?

Right.

But even though we hired 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, right? And that's something that I've learned and been working on over the years at 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?

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 telling them, you know—that's obvious, but not another thing everyone does. You know, being specific, figuring out people—some people like to be praised in public and some people don't. Although I will—I will admit that like I'm not very good at remembering to ask people that. Like if I was—I was a little bit more aware, I would be better at asking that.

I’m just too—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 is—you know, like this just makes for a nice place to work.

Cool! So transitioning to some other non-specific managerial topics, how do you feel about non-engineers running engineering teams?

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. Now, at some point, you know, at most companies you're gonna report to someone who's senior enough is gonna report to someone who's not an engineer, right? When I was a CTO, right, the runway I reported to the CEO; she was not an engineer.

Yeah.

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. Like part of it is just credibility; it's hard to have credibility with an engineering team, yeah, 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, you know, they're talking to product or business or whatever about something, and you know, they're asked something about like, oh, like how hard is it gonna be to build this feature or, you know, what's a little 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.

Right? 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 like—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? Are—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?

So then how do you, as someone now who’s not writing code—I assume you're not writing code, right?

Yes.

How do you stay legit?

How do I stay legit? I stay legit by having a lot of technical senior—I see 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, you know? Whether or not you believe architecture is a thing, like I've done a lot of software and systems architecture, and so, like, 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 de humans and to software, and so I still hear a lot of that stuff. I still sit in and read design docs and try to understand like the inner workings of the systems a little bit, and that helps me ask good questions. And I think, you know, being able to ask good questions is what makes you legit to engineers, right? If they feel like you actually understand what they're telling you that they're working on and can ask them like an insightful question about that system, like you get a lot of credibility immediately.

Okay, okay. How do you differentiate management from leadership?

So this is like—this is an interesting question because I think people think about this question a lot, and there's a lot of kind of like, you know, anodyne answers to it.

Okay, so I actually thought about this question. You sent me this question, 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 because which is true, by the way.

Like, maybe people can be in leadership positions without being managers, and so one thing I was thinking about yesterday—and this is so—this is a little bit of a hassle, but you'll have to indulge me; it's a kindness—so one thing I was thinking about yesterday is that there's kind of like three elements that you can sort of think about people having, right?

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 a leader 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.

Okay. 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, right?

So they've got kind of a thick—the interpersonal and the strategy side, right? Clearly a leader.

I think that a lot of managers fall into the—they're very good execution; they have good skills on management and possibly also want engineering, and they're good interpersonally, right? 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, right? But maybe they're not as good at interpersonally, and that's okay because their strategy kind of speaks for it themselves.

So, you know, what is leadership? Like leadership is whatever that quality is that gets people to want to follow you, right? And you know, 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—they just have the kudos and the cred to do that.

You know, but so I think, you know, leadership can come everywhere. What I will say is that I don't think there are very many successful managers who are not—who don't have any leadership skills.

Okay.

Like, I think management is leadership. That doesn't mean all leadership is management, yeah? But I just—I do think it is very hard to be a good manager without people wanting to work for you.

And so how do you build that?

Like another common one is just like you're just super legit, like you made something that a ton of people used, and you had a crazy insight there.

If you're—if you've since—and I think this is already a great set—but a few sense, like, you know, 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?

So I mean, it would very much depend on the person, right? But like I think what I would say is like, are you—are you able to 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.

Mm-hmm.

Do you just add complexity to that problem for them and tell them all the ways it’s gonna break or all the ways it’s gonna 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 of 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 of 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 if you—you don't have the best animal skills to be a leader, but like if you really like make people afraid a lot, that's pretty bad in the modern workplace, I think.

Yeah, I mean if you've been in tech for any longer than a week, you've met that guy before.

It's a lot of condescension.

Yeah.

Awesome, so this has been really, really great. If someone wants to pick up your new book, where can they go?

So it's gonna 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 winter-ish timeframe is my guess.

Okay, yeah, it will be—it will be your favorite, the world's favorite bookstore, amazon.com, and that is also where you can find my current book.

So—

All right, awesome. Thanks so much, Camila!

Yeah, thank you!