The Manager's Path with Camille Fournier

You're a very good developer. Probably. Regardless, you write bugs and that's unavoidable. What is avoidable is wasting time trying to track down the cause of those bugs. Century.io provides full stack error tracking that lets you monitor and fix problems in real time. See the severity and scope of the error, get immediate access to the stack trace, connect the problem to the commit that caused it and fixing without delay. Century, a name that's so common we have to include our top level domain in our advertising to make sure you remember them. Century.io. That's Century, S-E-N-T-R-Y, dot-i-o. Open Source, full stack. Web apps, native apps, mobile games, smart oven mitts if you can program it. Century can make it far easier to fix. Any errors you encounter with it. Let's fix broken code together. Visit Century.io. [Music] Hi, this is Scott Hanselman. This is another episode of Hanselman. Today I'm talking with Camille Fornier. She is the head of platform engineering at Tues Sigma and the author of a great new book called The Managers Path. A guide for tech leaders, navigating growth and change. It's actually a number one bestseller in engineering project management. How are you? Good, thanks. Are you? I'm pretty good. I'm happy to be talking to you. You just keep crushing it everywhere. I'll follow you on Twitter and I've been enjoying your book. It's doing very well. It's been out for about a year or so. Yeah, a little. I'm sort of coming up on two years in March April timeframe. And how has the response been? I've heard nothing but nice things and I've been enjoying it in the four chapters that I made it through so far. Yeah, the response has been really positive. I'm actually, I sort of wrote it, hoping that a few people would like it. And I've been kind of overwhelmed by the positive response on. I'm very grateful that I was able to write something that so many people find useful. Have you found in the writing of it that things like this are, they sell because of marketing or they sell because of word of mouth? I think it mostly sells because of word of mouth because there's not really any marketing. I mean, it's an O'Reilly publication. O'Reilly does a little bit like they bring your books to conferences and things like that. But you know, the only marketing that really happened was for a while there are people who were taking pictures of my book that they brought on vacation, which was kind of fun. And they would tweet that me. And so I would retweet that. That was like kind of a weird like viral marketing. Well, it's like my book on like gorgeous beaches like someone took a TV and I'm just like really want to read about engineering management and TV. Okay. That's actually kind of awesome. It shows a commitment to the craft. Yeah, yeah. But you know, it's mostly been a word of mouth book in terms of people picking it up. That's very cool. Do you think that people who are managers are grown or born? First of all, everyone has to learn. However, natural you may be in terms of comfortable talking to people and you know leading them and you know natural charisma, whatever. There's so much of there's so much work. There's a lot of details of the work of actually being a good manager that has really nothing to do with your personality, per se that has to be learned. So in some sense, everyone is is grown into a good manager. There are probably some personality types that will have a harder time becoming a great manager than others. I have worked with people who were managers, but we're also like really, really good engineers. And sometimes what I see with those, especially when they're struggling to be managers is a desire to just go really, really deep into the technology. You know, you're they're having problems with their team. Perhaps there's there's, you know, collaboration challenges going on or projects are missing. And instead of taking a step back and looking at the situation broadly, what happens is that they say, oh, you know what, I'm just going to let go super, super deep into the technology and I'm going to shut the world out and look at it from that side of things. And if that is really your desire and instinct and you can't kind of get over that even after perhaps having it pointed out to you that this is not the ideal thing for a manager to be doing in the circumstance. It maybe is a sign that like you would just be happier and more successful, focusing on the individual contributor work instead of trying to really, you know, keep it that kind of higher level and looking across a bunch of people, which is what the manager needs to do. It's interesting to explore the personality types because like you said, you could say that a personality type is a natural leader, but it's really that they have characteristics underneath that like maybe characteristics of empathy or seeing the big picture or whatever that would then. Be part of the formula, they're not necessarily a natural leader, but it's part of the formula that would make them an effective manager, but what is it about technologists that somehow make us want to like people don't compile so we'll just like you said, I'll just hide in the code because well at least I understand that part. I mean, I just think it's I think it's sort of natural right people always go to what they're good at when they're under stress for the most part is just my you know my observations true myself it's true of almost everyone if you if you watch someone who is really stressed out often their first instinct is to go where they feel comfortable. And so for a lot of engineers, especially those who are new to management, they feel comfortable in the code or maybe they feel comfortable debugging things or you know helping out with operations or whatever and that does totally you know it's totally a natural thing to do but unfortunately it doesn't it's not actually the job anymore right so your job has now changed to something new and. And I think that some people can get over that and can force themselves to be uncomfortable in that uncomfortable learning phase of like I don't know what i'm doing as a manager and i'm doing a bunch of stuff that I don't feel that good at i'm just continuing to work on that and eventually getting good at it and some people just continually refuse to do that and just continue to go back to the code or to their to their comfort zone and you know as a result don't really grow out of that. Have you ever found yourself in a situation where perhaps someone that you were that was your direct that you're the manager and you people who work for you and you have identified that one or more of the people who work for you are probably going to be better. At being the manager than you are because I find myself sometimes in that situation where i'm like you know so and so who works for me really should have my job. So I actually have someone working for me now although he is going to go be a VP at a start-up soon and i'm very happy for him who is probably the best manager i've ever worked with and you know i'm i was thrilled to be able to work with him and I was his manager and he definitely you know I think in a lot of ways was better at some things than I was. And you know so that was actually a joy really honestly it's really fun working with someone who's just like really really good at something that you also care a lot about and are really interested in. And I enjoyed that so from that so I have had that experience and i'm very happy for him that he is going to do something new and excited and i'm very excited to be able to keep in touch with him and you know continue to like. Both share stuff that I know and resources that I can give to him and also learn from him and learn from what he's experiencing. You know I think especially at the level that I'm at now you know every manager and leader is a little bit different and has has you know you can you can fit into a particular niche that other people wouldn't necessarily fit into that well even though they're stronger than you at other areas right. So you know so I think he was a stronger manager than I am and I think perhaps someday I would work for him on the other hand you know there were there are things that I have done that he's never had the chance to do yet right like I've been a CTO and I am very comfortable with the management work of. Of leading of leading an organization and thinking about a lot of the HR processes of sitting at a table with a lot of other executives and and really presenting well you know with them kind of you know how do you talk to those people what is that executive presence like. That you know just not things that he necessarily had a lot of opportunities to do yet so so I guess that's that's that's a long wanted answer right you can definitely have people who work for you who you think ultimately are better than you at some of the aspects of the job and they just need to learn it and I think as a manager part of your job is actually to like give them those opportunities look for those opportunities for them and then you know keep in touch with them when they go off to do something great because you never know who you're next possibly. Yeah that's a I appreciate that very very thoughtful answer I know that is kind of a tough question because it is quite nuance you know someone's not necessarily better than you or worse than you I mean it we are the collection of our experiences but I am always you know I've been in tech for a very long time but I'm always so impressed when young people pick up things so quickly and so intuitively that I found that I found to be hard one skills particularly one and like trying to be a lead or tech lead yeah. There's within the chapter three of your book you start talking about the idea of being a tech lead and I've seen an interesting article go around the net recently that made the the interesting observation that being a tech lead or being a principal software. for an engineer isn't senior senior. Like the tech lead doesn't necessarily the smartest person in the room. - Yes, I absolutely believe that. Yeah, no, I've read that article and it's great. In technical companies, we often just wrap a lot of things up together that don't need to be wrapped up together. So I think there's a lot, we do this thing where we want our leaders or we want people in these positions to be the best at everything. Like, they should be the smartest person in the room, the most technical, the best talker, the best, just everything. And those people, most people just don't have all of those skills. And so then we often say, okay, well, if I have to pick one, I'm gonna go for smartest slash most technical because that's who I know the team will respect the core, that they know how to do the core work really, really well, because they're the most technical. But when the job isn't actually about doing the most difficult technical work, putting the most technical person in the job may not be the right thing to do. I think the tech lead job, and I talk about this in my book, I think a lot of the tech lead job is, there's a large amount of project management in it. There's a large amount of how am I helping a group of people get something done effectively. And as an engineer and working on engineering projects, a lot of that work is technical work. So you do need to be technically savvy and you need to understand the technologies that you're building with and be able to think about the system. But that does not mean you're the best programmer. That doesn't actually necessarily mean that you know like every single nitty-gritty detail of every single part of the system. It just means that you are capable of joining all those pieces together and importantly helping that team work together effectively. And I think you know, whether or not you're managing people at levels of leadership, almost everyone needs those skills to continue to become a leader. There are very, very few people in the world who can shut themselves away and change the world just by writing code by themselves. There are a couple of people like them. It's true. Everyone looks around and they see these exceptions. Linus Torvald's perhaps, right? But for most of us, that just, you know, you have to be in the exact right place at the exact right time. You have to be such an ex-- exact place in exact right time is a big part of it. You maybe also need really exceptional skills. And there's just not that many opportunities like that. For most of us working at companies, what makes you really successful is that you're actually able to get a lot of people to do things, to create big things. And what do you do that by managing them, by leading them, by coaching them and teaching them? There's a lot of different ways. It doesn't have to be a management job. But the role of seeing your technical leadership is about other people. It's about leading, right? You can't lead if there's no people to lead. It's not about shutting yourself away and writing a lot of code and writing the most code of anyone in the company. That's just very rarely the skill that's going to be, you know, the most impactful. So I do think that tech leadership, you know, doesn't have to be the most technical person on the team taking the tech lead job. And in fact, a lot of technical people wouldn't necessarily like to have to do that, because there's so much project management and not exactly purely technical responsibilities to making that job successful. On your blog, you make the very important point that ultimately, if the engineering manager is not good at getting the team to be productive, then that is a problem. So, I mean, shut up and ship is kind of what I'm hearing there. You really have to ship, otherwise, you're going to fail in those areas. Yeah. Again, unless, you know, maybe if you are a researcher, you have a little bit, you know, your time frame of shipping is different. Most of us are not researchers. And even researchers, they've got a shift in me. You know, academics, they've got to get those papers published if they want to make tenure. At Microsoft, where I work, they have this term, and I'm not sure yet if it's a Microsoftism or if it's everyone is them. But the term M1 and M2, have you ever heard that? I have maybe heard some companies, these are like management levels. Right. Like, well, some more like, are you a manager of some people or are you a manager of managers? And you actually have a whole chapter in your book about managing managers. When I saw that, I said, oh, those are M2s, managers that manage managers of managers. And when you get an extra level nested deep, it sounds pretty exhausting. And it's a whole new level of complexity. Yes, it is. You know, to explain it to engineers, I often say, you have this level of abstraction, a new level of abstraction that you may or may not be able to pierce that is all about what's going on in this team. So when you're initially managing, especially if you're a technical person, and you were maybe even a developer on the team that you started to manage, you have just this kind of native understanding of a software. You have this native understanding of the way things work. And that can take you, that can make the job of management a lot easier because you just have good technical instincts. And you can kind of know if people are working on the right things or not. And once you go up levels of abstraction and you are no longer really directly talking to the people that are working on the code or working on the systems that often, and maybe even furthermore, you've never worked on those systems at all. And you're just talking to the manager of that team. You're really just getting what that person is reflecting back to you. That is a very challenging thing to figure out. It's very challenging to figure out how do I continue to know if this team is doing well or not in that scenario. How do I pierce that level of abstraction or how much should I even do that? Yeah, in the book, you have this quote, you actually quote yourself, which I think is great, because it was an email that you sent to your leadership coach and you're saying to them, how do you help with problems that you weren't in the room to see? And I love this with unreliable witnesses. Sometimes I feel like I'm constantly piecing together stories about what did they say? What's the technical problem? What's going on? And you said that you were spending all your time two levels deep in people problems and it's exhausting. But you have to trust your people. How do you find that balance? I would say I'm still learning new ways to do that. It's hard. Do you have to trust your people? And so everybody has different approaches to doing this. Some people are really, really organized. You do see those managers who they really love Jira. And they will set very clear project milestones or whatever. And they will really follow along with the progress of the project. And I think I just can't do that. Honestly, both I don't really like being managed that way. And I don't have the patience for that even as a manager of managers. So there are people who do it that way. And that can work. There are projects for whom that can work. And if you have that kind of attention span and you can figure out a way to do that that won't make your team feel like they're just drowning in bureaucracy, great. And I do know people who successfully manage that way. For me, I do a combination of things. My general philosophy at this point is that my goal is to make sure that I have, as clear in my mind, what is really important for my organization to be doing. What are the really important things for us to be accomplishing or stabilizing, getting done. And keeping those top of my mind and then top of my manager's mind and then getting those managers to keep those top of their managers mind so that if nothing else, like I'm just trying to push prioritization implicitly through the org by helping them know what I think is important. Because people do generally want to make their boss happy. They do generally want to be working on important things. And so I think it's a full-time job understanding what's really important right now and what we need to do and pushing that through an org. And that's kind of the way for me that these days lead. Now that doesn't really solve the people problems. There's also an element of you have to learn how to train managers to be a manager of managers. You have to learn how to teach people how to deal with people problems. You have to learn how to teach people how to do all the various basic management tasks and become more and more independent. And so as you're onboarding new managers, especially people who have never managed before, a lot of the job is teaching them how to do their job well. This episode is sponsored by Stack Overflow for Teams, a private secure home for your teams, questions, and answers. It's everything that you love about Stack Overflow now for your company. Get instant reliable answers from your co-workers without disrupting them. Unlike documentation or wikis, long email threads or distracting instant messages, Q&A mimics the way that we naturally share and find information. Introduce Stack Overflow for Teams to your company and start building products faster and better. Visit s.tk/hansomeandits to get your first month free. That's-- s dot t k slash cancel minutes. You you call out an interesting juxtaposition between the cto having an open door policy. You always want you always get that speech when you join a company in the cto's in front of everyone saying you know my door is always open and it's like well which of us is going to be bold enough to go and get beat up by the boss or our boss's boss. But then you also call out the importance of skip level meetings when someone's talking to their boss's boss in a formal setting. Yes well so so I am a big believer in skip level meetings. I still do them I still do my I always do them. So so I my my feeling with the open door policy is mostly that just people don't really take advantage of it that it's a you know a lot of managers senior managers particular think that if they set this up that people will come to them when things are going wrong and therefore they're not responsible for actively monitoring the organization as it were. They can have this passive monitoring because people will just bubble up problems to them and therefore if they're not hearing anything everything's fine. And the truth of the matter is there are a few people who will do that and hold those people dear to your heart because those squeaky wheels can be kind of annoying sometimes or you know kind of frustrating but they are giving you information that's so hard to get otherwise you know you are you actually need to figure out what your active monitoring strategy is for your organization and skip levels are a pretty good way to do that. So you know talking to the people in your team who do not report to you and on some kind of regular cadence and just getting getting thoughts from them about what's going well and what isn't and letting them try and first of all like a really important part of skip levels is really just making them feel comfortable with you so if something goes really really bad hopefully sometimes they will be willing to come to you with it instead of just quitting or you know what have you. So there is that like breaking the ice and kind of creating an actual relationship with the members of your team that you may not otherwise interact with a little bit often but then beyond that you know you are trying to get some information about what's going on that I might what's a different perspective on this team or this organization that I may not be getting from my manager so that helps you you know independently verify the condition of the team based on your own experience with the team instead of just entirely relying on the self-reports that your managers are giving you about what's going on. One of the things that I particularly appreciate about this chapter and I think it's important for people to understand is that people behave differently in different contexts so you call out of course the benefit of skips and skip level meetings and one on ones but then you say well if your organization gets really loud okay to me gets really large all you would be doing is getting one on one so then you should consider maybe having skip level lunches with whole teams and what I appreciated about the book was that you actually call out a little bit people will behave differently in a group dynamic if you are putting them in a group with people that they know or people that they work with or people of their shared level there's lots of different configurations and you have to recognize that everyone is going to behave somewhat differently and code switch for lack of a better word in those instances and you as the manager or the CTO have to be be conscious of that of that context that they may not even be conscious of. Yeah I mean you know my the organization I'm in now so my team is around 100 people and so it's it's big enough that I can it's not so big that I can't have skip levels with everyone but you know not very often and then we try to do actual lunches for all senior leadership across all of engineering and so we will do these like small like with a lunch or breakfast or whatever coffee meetings with let's say 10 people in the organization and two of the senior leaders at my level and you know it's been it's an interesting experience because I think the goal is for people to feel like they're getting a face time with senior leadership and they're getting perspectives on the organization it is a little bit like pulling teeth though to get people in those rooms to actually ask questions and and really engage it actually takes a lot of moderation on the part of the senior leaders in the room to create a good conversation. It's definitely not just something that always naturally happens. You yourself are highly technical and I saw a video of you where you wrote your own distributed system in the early 2000s before things started becoming kind of commoditized and I wonder what you think about devs who prefer to work with technical leaders versus this kind of inherent suspicion that we have when we're given a leader who isn't kind of like quote-unquote one of us who didn't write code back in the day someone who's more of a manager manager or career manager and if that's problematic. You know I mean a big part of the thesis of my book is that I do think effective engineering management is a technical discipline that does not always mean that the best managers are people who spent a long time writing code. I do know exceptions to this back. I have met people who were involved in technology in not direct hands on ways who are still effective engineering managers. I think they're pretty rare and I think it very much depends kind of on the scope of your job and what you're doing. You know there's just so much of leadership and so much of leadership and management and engineering is about kind of knowing really what's important to do and what you can let drop because there's always just too much to do and you have to be able to gut check what your engineers are bringing to you a little bit. Like you know you're never going to the more senior you get right you're not like looking at their code and you know you know picking it apart but if you have really like no instincts about the way that systems are built it can be hard I think to ask the right questions and make sure that your team is is really taking you in the right direction. So I do you know so that's hard that's part of it right I actually just think you know as an engineering leader it's actually just hard to do your job if you really don't speak their language at all. I also think that there is a level of like engineers don't always respect non-technical leaders and so you know people like to feel like their manager can do their job. In fact this is like a studied thing right so there was a I've cited this in a bunch of talks because when I read it I was like wow there's an HBR article and some people did some research and they were like they asked a bunch of people what are the top things that you care about in your job and they actually said having a manager who has some sort of excellence or authority in the work that I do scored higher even then like more money for a lot of people. So it's I do think that people care about feeling like their manager can appreciate what they're doing and understands you know understands the challenges of their job they can top of their manager they can get ideas about how to do their job better from their manager. So now this doesn't mean that like every person up you know M2, M3 whatever I don't know if you if you term it that way in Microsoft or not but this doesn't mean that you know then you're a manager of managers and you're you know multiple levels up and you need to know and understand every single detail of every person's work right it doesn't mean that you should expect to be able to do the IC job at the at the leaf node when you've been managing for 15 years but it does mean that you should have enough technical chops to be able to to give decent technical feedback to your managers as they are then have a little bit more context and a little bit more you know technical depth at the time to give feedback to their teams. So I do think that I do think that for most people having a good strong technical underpinning will generally make their careers more successful as managers because it'll be easier to gain that respect and just easier to do the job. Yeah absolutely I feel that my boss is good at BS detection. Yeah you know like he's not necessarily the most technical but he's like yeah my sense of smell my technical sense of smell so says that this thing you're describing may be a problem. Yeah he's got that experience. In your chapter on managing people you have an interesting quote from Mark headland where he says that when people become a new engineering manager like when when a when a engineer becomes promoted they shouldn't think of it as a promotion like they do we all say oh I've been promoted now I'm a manager. He says that new manager is an entry level job because and you really need to start with it in that attitude that I am now shifting. Maybe I moved diagonally but I didn't necessarily move up. Yeah you know I generally speaking I agree with that. I think I do think people go a little too far when they say that you're there's it's completely completely different job because I think that people. I totally foreign land. Yeah because I think sometimes people hear that and then they think oh well then why do we need technical people to be managers and for all the reasons that I just said I actually still think you are building on skills you've already go those those skills that you already built come in useful but I do agree that it is a very very different job and sometimes having a hard reset is the thing you need to do to get good at it because you know as I said earlier right it's very tempting I think for new managers to go back to individual contributor habits when they're stuck with problems. They tend to use what's in their old toolbox to solve problems. Oh, this project is shipping late. I'm going to contribute code. This person is unhappy. I'm going to like pair program with them, whatever. You do want to force yourself to say, I'm not going to try not to go back to my individual contributor toolbox. I'm going to try to learn new things and do things that are harder from you or uncomfortable, dig into the details of the project from a higher level instead of just assuming that I can do a diving save by adding code myself. I do think that that is useful to reframe it as a fresh start because hopefully it will help you understand both that this is going to be hard. It's going to be a lot harder than it might look from the outside. Also that you should be trying to do new things instead of just doing things that you have done in the past that are easy for you. You had a blog post a while back when you talk about the failure to delegate. It can be a problem if you're trying to like basically when being helpful is actually hurting, like something that feels intuitive and necessarily be intuitive when you really just want your team to be happy and successful. Do you also personally want to feel useful and needed? Yes. I think sometimes managers will hold on to unpleasant work themselves and they'll say, "Oh, I'm not going to make my team deal with this old, crafty system. I will handle on call for that system." They don't want to deal with the release process or they don't want to deal with talking to this product manager who's giving them trouble. I'm just going to take all of those unpleasant things and do them myself. Can happen with that when you take all of the unpleasant things and always do them yourself is that your team doesn't have the opportunity to see where the problems are and create fixes for them. You probably don't have the time to actually create sustainable fixes for problems like that, right? But where automation might actually just make that on-call problem go away or that release problem go away or where you may just need the engineers to see that this old, crafty system is crafty and perhaps you need to think about how we're going to replace it with something new. They're not going to see that because you're hiding it away from them. I also think that people, there can be a great tendency from some engineering managers, particularly new ones, but not just new ones, but just really want to keep engineers happy. They just have this idea that they're terrified of people leaving and that their job is just to make their team happy all the time. That's just as you will not be successful as that is your attitude going on. You will, in the long run, I think you're going to have a really hard time being successful because actually a lot of people, they kind of don't respect that and they don't realize that they don't respect it, but they end up more unhappy when they feel like they're never given any challenges. When they feel like they're never, they never have to work for anything. But they're just sort of allowed to do whatever they want and there's this idea that most people would be happy if they just got to have full autonomy over everything they did all the time. In my experience, it's actually not true for everyone. There are a lot of people who thrive under, help me get directions and help me focus and prioritize. That's your job as a manager to say no, to occasionally ask them to do unpleasant things. Just to generally help your team feel full responsibility for work and not just a drift and allow to do whatever they want. Well, that actually brings us to an appropriate callback. If we pop all the way off the top of the stack to the beginning of the conversation where we talk about how as a manager or as a manager of managers, you're providing a layer of abstraction, but here you're cautioning us to not be too abstract because if you hide too much, then you're really just, you put a gross layer of abstraction on top of something gross and technical debt will eventually catch up with you. Yeah. And frankly, the same thing with organizational. A lot of people say, the manager should be a, put it nicely poop on Brawla. They should be shielding their teams from bad things externally. And I think there's a little bit to this, right? Some organizations have a lot of politics and kind of unhealthy behaviors, especially at the senior levels. And if you let a lot of that leak through into your team, that can be very upsetting to them. They really don't need to know about executive x-stabbing, executive y in the back. That's probably not healthy for them. On the other hand, I think a lot of people do that role and they say, oh, well, I don't need to let them know that there's a lot of uncertainty in this particular product plan and that we're struggling in this part of the business that happens to touch on my team's work. I actually think it's bad to hide that kind of thing from them, right? Because then they don't really have the context for what's going on, right? So there are bad things that happen that you do need to share with your team, so they have the context to understand, oh, we're struggling to make this product successful. They may have great ideas for that. If you pretend like the product is really successful and everything's going great when it clearly isn't, then they can't be part of the solution, right? So you want to be careful with what you hide from people because part of what you want to do is give them to give you more, give you ideas, bring out the best in them and sometimes bringing out the best in people requires them to understand the truth of the situation even when the situation is not great. Well, I really appreciate you taking the time to chat with me today. Yes, I'm very happy to have gotten a chance to do it. What we've been chatting with Camille of 4nier, she is the head of platform engineering at 2Sigma and I would really encourage everyone to check out her book, The Managers Path. If you enjoyed this podcast, it is a big concentrated bunch of advice. It's effectively so much more in a great book and I am very much enjoying reading it. This has been another episode of Hanselmets and we'll see you again next week. [Music]