Transcript
Stefan Tilkov: Welcome to a new episode of the CaSE Podcast, another conversation about software engineering. This is Stefan Tilkov. My guest today is Camille Fournier.
Stefan Tilkov: Camille is a managing director and head of platform engineering at Two Sigma. She was CTO of Rent The Runway and she's also a former VP of Technology at Goldman Sachs. While she often focuses on technical topics, such as distributed systems and microservices, her most recent book is about management. In fact, about developers embarking on the manager's path, which is the title of the book and the topic of today's episode.
Stefan Tilkov: Welcome, Camille!
Camille Fournier: Thanks, I'm excited to be chatting with you.
Stefan Tilkov: Glad to have you. Camille, how did you end up writing a book like this?
Camille Fournier: It was a little bit of a lark. I was at Rent The Runway for about four years and I did a lot of blogging in that time about a lot of the things that I was learning as a manager and as a leader in my time there, and when I left, I decided to leave my job and take some time and kind of rest up, because you know, being a CTO at a startup is quite stressful... And one of the things that I did in the first few months I was off is this thing that's very popular (at least in the States) called National Novel Writing Month, which is where in the month of November a lot of people spend the month and try to write a 50,000-word book. It's kind of like a gamified system - you write 2,000 words a day, or something like that, and that gets you roughly to about 50,000 words.
Camille Fournier: I figured "You know what? I've got a lot of content... I've been thinking about this a lot, I've been really deeply invested in learning about management and learning about how to lead well, so why don't I try to just throw some words on paper and see how it goes?" I ended up at the end of the month with an extremely rough 50,000-60,000 word manuscript. I wasn't sure that I was going to do anything with it, but I had some friends that encouraged me and said "You know what, I'd really love to hear what you want to write on this topic."
Camille Fournier: I sent the draft to O'Reilly and they said "You know what, this is pretty good. We can make something of it", so I said "Alright, fine. Let's do it, let's write this book!"
Stefan Tilkov: There are a lot of books about management and about how to work or how to act in a professional work environment; how different is the IT industry, the tech industry from others, and how specifically tailored is your book to this particular industry?
Camille Fournier: I think my book is fairly specifically tailored to people who are in technical management positions. It's really got a lot of things that are about managing software projects and software developers. I actually know people who are in sort of tech-adjacent positions, like people who work in design in tech (visual design or UX design) who have also read it and enjoyed it, so maybe there's a little more widespread appeal than just solely to engineers.
Camille Fournier: I definitely wrote this with engineering management in mind, because I felt that there were a lot of good books for general management. There's a lot of good books out there to teach you how to manage people, how to motivate people, how to give people good feedback; there are a lot of books out there about leadership in general, how to be a strong leader. There's a huge industry of books about leadership. But there are very few books that are really written with software engineers in mind, and I thought "That's what I know. I'm not a great manager of other kinds of things." I've never managed a customer service team, I've never managed a marketing team. I've managed a lot of engineers; a lot of different kinds of engineers, yes, but mostly engineers.
Camille Fournier: I wanted something that was very specific to people like me, because I felt that there were a lot of people like me who needed something more specific to the challenges of their job.
Stefan Tilkov: Do you think to be a good manager in the tech industry you have to be a technical person yourself? Do you have to be a developer or do you have to have been a developer to be a good development team manager?
Camille Fournier: I don't think that that's absolutely 100% necessary, but I think it's fairly rare to find people who are good managers of engineers who have not spent some time working the job themselves. I have met a few people who have done it. Now, the people I've met who have done it have been still fairly what I would call technical; they're very technically savvy, they really understand architecture. I know someone who manages engineers at actually quite a technical company, and she spent a long time at ThoughtWorks doing a lot of engagements there. ThoughtWorks, obviously, does a lot of technical business engagements, so she was always working very closely with engineering teams in that job and had to learn a lot about architecture and software design from a high level so she can speak the language. And she's very technically savvy, even though she's never been a software engineer herself.
Camille Fournier: There are people like that out there. I do think it's fairly rare though to find really strong engineering managers who have never been engineers themselves, just because it's hard to know what is hard about the job of engineering if you've never done it. And frankly, it's hard to get the respect of engineers when they feel like you really don't understand their job and you could at least sort of approximately do their job.
Stefan Tilkov: What about the other direction - do you think that developers should have more respect for managers?
Camille Fournier: Well, as a manager, I would love to get more respect... I think management is important, and good management makes a huge difference in your day-to-day life, whether you realize it or not. A lot of people have never had a good manager, so they may not appreciate what someone who is good at that job can bring to the table, but I do think that good management is important in making effective teams and making companies that people want to work at. It's an important part of a healthy software engineering team, someone who is managing that team well and who is keeping track of the people, of the work that's going on, and keeping that high-level picture of what's happening. That's a very important job, so I do think that respecting this as a valuable skillset is important.
Camille Fournier: Obviously, none of us exist without the other one. We need software engineers, a large enough team size definitely need managers, so we kind of all have to work together.
Stefan Tilkov: Before we start talking about the different levels of management, the different kinds of managers or the career path that one might follow, if you're not yet a manager, what's a good way to help your manager do a good job?
Camille Fournier: So if you are not the other managers, and you have a manager and you want to help your manager do a good job, there are actually things that you can do. A lot of people view themselves as helpless to the whims of their manager - if they have a bad manager or there's just simply nothing they can do. I think that's not entirely true. I think that you can help by setting certain expectations. For example, if you don't feel that your manager is having one-on-one meetings with you often enough or at all, you can say "Hey, I'd like to meet with you more regularly. I'd like to meet with you one-on-one more regularly."
Camille Fournier: One-on-one meetings are one of the most important jobs that a manager has to do, that regular one-on-ones with the people who report to you are essential for developing a strong relationship for developing trust and for making sure that you can stay on top of issues as they arise. And if your manager isn't doing that as much as you want and you want more, you should ask. Now, your manager may not agree with you; they may say no. You can't force your manager to have meetings with you. But if you want more of that, you can ask.
Camille Fournier: At a larger scale, you have more power than you might believe in managing your career and in managing your relationship with your manager. When you want different tasks, ask. When you see a project that you might wanna work on, ask. If you're confused as to how to get promoted or if you feel like you're not getting enough feedback, ask for that feedback. Now, none of this guarantees that your manager will actually do any of that for you, but you will make their job so much easier by being explicit about what it is that you want, what it is that you're looking for, what it is that you need, and I think that most managers will try to meet you there.
Camille Fournier: It's a real pleasure to work with someone who knows what they want and can just sort of tell you what you need to do to help them. That, as a manager, is actually a great thing to have.
Stefan Tilkov: Let's dive into this hierarchy thing. What do you see as a typical career progression? I didn't intend to say hierarchy in the sense of the strict hierarchy, I'm just thinking of a progression of consecutive roles that you might fill on your way to becoming the CTO or the CEO of the company.
Camille Fournier: Yes. I mean, I think for many people if you follow a somewhat a typical management career path, obviously you start out as a developer, most of us, and you do that for a while. I have always encouraged people to stay in hands-on engineering for as long as possible, as long as they still feel like they are learning and growing and have opportunities to challenge themselves. I think people underestimate how much time and energy it takes to become a really great engineer. For most people it takes ten years of doing it to get there; maybe you can shortcut some of that by having spent your college degree in getting a technical degree, what have you, but you've still got a lot of time, spending every day writing code before you really have those deep-set instincts. I always encourage people to stay hands-on for quite some time.
Camille Fournier: A lot of people become tech leads throughout some part of this, and also they often become mentors as well. As you become a more senior engineer, whether you decide to become a manager or not, usually you're going to have some kind of leadership responsibilities, whether that's mentoring new people who are coming into the company, mentoring people who are more junior than you on your team or on other teams, being seen as an expert in some kind of technology or some part of your company's systems... Becoming a tech lead - which is a leadership role that I think a lot of people benefit from, whether they are going to become a manager or not, that often involves some degree of project management, technical project management for the things that your team is doing. It involves leadership, it might involve sitting in a few more meetings that you're used to, because you're now the kind of go-to person for the product team or the business team or your manager, under-sitting what's really going on in the day-to-day work of the team itself. And you're showing a lot of technical leadership there, as well.
Camille Fournier: Then, beyond tech lead - usually this is where people decide (at least initially) whether they want to think about becoming a manager of people, or whether they want to stay in a more senior individual contributor path. I try to encourage people to say "Look, it's very rarely that you're stuck in one side or the other forever", but this is usually the point at which people decide which of those two they want to do. You've gotten to be a senior enough engineer, you're a tech lead, and now it's like "Okay, what next?" After that point, often if you decide to become a manager, you start by managing usually a small team of people, maybe three or four people. You're probably still writing some code, but a lot less code than you would be even as a tech lead who's not managing people.
Camille Fournier: If you succeed at that, you may manage a couple of teams' worth of people. Companies have different names for this level... Often, it's just called "engineering manager"; some companies don't even have names for these roles at all, but often if it has a name it's called "engineering manager", maybe "manager one." Maybe there's a senior manager position if you're managing a couple of teams... At some point you might start managing managers. That's usually a director of engineering type of position, and managing managers can go on for a long time.
Camille Fournier: The team that I run now is close to 100 people, and I have a bunch of managers of managers who report to me, and some of those even have managers of managers reporting to them. So you can imagine you can get into a lot of levels. I don't necessarily encourage having this huge number of people in between the leaf nodes and the root, as it were... But it can happen.
Camille Fournier: Then at some point, if you are managing managers, you may manage divisions of a company. You might manage all of a large subset of either the technology associated with a part of the business, or a specific type of technology. Maybe you're the director of operations, you might become a VP, and then eventually, you could become whatever it is your company calls the senior most position. Sometimes that is CTO, sometimes that's CIO, sometimes that's like an SVP of engineering; sometimes there's not one person in that role, there's a bunch of very senior people in peer roles there... But that's what the progression tends to look like for people.
Stefan Tilkov: You mentioned that this very much depends on the size of the organization. A 20-person company is very different from a company with 100,000 employees, but what do you think of organizations that try to avoid managers as much as possible, for as long as possible? If they're maybe at (let's say) 100 or 200 people in size.
Camille Fournier: I think that's fortunately a trend that is mostly dying right now, which is good. A lot of people tried that and it just is not a very effective way to run anything that's a large number of people where you have long-term goals that you're trying to achieve. It's very hard to organize a lot of people towards long-term goals without having people in management roles.
Camille Fournier: If you're just organizing something real quick that is a very tactical, very specific short-term goal... Maybe you're on a couple of weeks of a volunteer crew just trying to get something done really quickly, maybe you don't need managers there. But if you are in a stable system where you've got one-year, two-year goals and you're trying to grow a company, I just think it's very hard to do that without management, partly because it's very hard to coordinate communication.
Camille Fournier: When you want everyone to be kind of going in the same direction and highly aligned, that takes a lot of work to get that alignment, and usually that work is done by people in positions of authority. And if you don't have people in explicit positions of authority, then what happens is you have some kind of shadow hierarchy that happens... Whether it's the CEO's best friends, the early employees - they are the people who have all the power and you know that even though there are "no titles and no managers", you've gotta talk to Joe who was employee number one and who has the CEO's ear to get anything done. I'm not a fan of hiding structure and pretending like it doesn't exist.
Stefan Tilkov: Fair enough. Maybe we can talk about each of those levels a bit. We start with a software developer who suddenly finds themselves in the position of being a tech lead. What changes and what are some ways to find out what to do next?
Camille Fournier: You know, all of these things, I always to be caveating with - different companies have different ideas of what this might mean. But I think in a lot of companies the tech lead is someone who is respected by the team, who is considered to be a strong developer, and who is also considered to have good technical judgment so that they can be trusted with being either the tie-breaker on certain decisions or the person making certain technical decisions.
Camille Fournier: Usually, you want someone in the tech lead role that there is a communication element there. Usually, this person is going to be working maybe more closely with your product manager or your project manager or your business partner to help figure out what really needs to be built and how to build it, to some extent. That's a communication job as much as anything else. I always expect my tech leads to be taking a very active role in the project management. I don't usually have a lot of project managers on teams; I'm not a fan of that for small teams. For certain projects yes, but for small teams I think it's better when someone who is an active participant in the team - who's actually doing the work - is also in charge of making sure the project is moving forward. Often, the tech lead role involves the technical side of that project management, whether it's running sprint planning, or just breaking down the project to make sure you know how the work needs to be completed, in what order.
Camille Fournier: Then there is an element of just leadership. You've got a team, people are going to disagree on the ways that things should get done sometimes; your team is not perfectly aligned all the time, and you as a tech lead will be called upon to help mediate those disagreements, to help chime in sometimes to make those decisions. You will probably be the person who needs to know who the experts on your teams are in different subsystems or particular areas, so that you can dig in and ask the right people the right questions to get the team unblocked, or to answer questions from a business partner or a product manager. Those are some of the things that you expect from a tech lead.
Stefan Tilkov: Is that a job for everyone? Do you expect everybody wants to be a tech lead and only some of them should? What are some criteria that people might self-assess themselves based upon to see whether the tech lead job is one they might like?
Camille Fournier: I think that many people can become tech lead. I certainly don't think that everyone should be a manager. I think tech lead has a wider range of implementations, such that more people could do this if they wanted to. It is a lot of responsibility, and if you are the happiest with headphones on, head down, writing code day in and day out, you probably won't be all that happy with the tech lead job, because it's less of that. It's not none of that - you're definitely still writing code, but it is sitting in a few more meetings probably than you were sitting in in the past. It's writing more documentation or design docs, or reading more design docs, doing more code reviews, running more stand-ups than you would have been doing in the past.
Camille Fournier: If you are happiest to just be super focused on writing code and that's what you want to be doing day in and day out, then probably tech lead is not something that you necessarily want to do now... Although I do often encourage people to try it once. I think the nice thing about tech lead is in most companies tech lead is not a job title, it's kind of a role that you can take on for projects, or maybe you service the tech lead for a team for a few months, but you're not necessarily a tech lead for the rest of your career at that company. It does have a nice aspect of being something that is usually a little bit more flexible in how you get that role and how long you have to hold it for.
Stefan Tilkov: Makes sense. Do you see a relation or a distinction to what an architect does, or is that essentially the same thing for you?
Camille Fournier: Architect is such an interesting job title, because a lot of companies don't have architects at all. Architects are a very specific group. I think there's some overlap between tech lead and the person who you might describe as the architect in a team. More teams need tech leads than need architects, let's put it that way. I think that you probably need a tech lead for every team -- I would say most teams of 4-8 need a tech lead. They may not need an architect. You may need one architect for an entire area of technology.
Camille Fournier: You may say, "Okay, we really want an architect who's really focused on all of our back-end systems, or all of our mobile apps", but that may be a person who is thinking about the architecture across the general systems and not as much in project-by-project or specific smaller-focused products teams. I think that tech lead is a little bit more of an operational role than architect. Architect is a little bit more of a strategic or high-level of a role than tech lead.
Stefan Tilkov: If you're a high level manager, should you try to get people into one of those positions? Should you try to convince somebody to become a tech lead?
Camille Fournier: Well, I think that if you are a higher level manager you should look at your teams and ask yourself "Do we have tech leads?" If you don't, you should ask yourself "Do we need a tech lead? What would a tech lead do for this team? Do I think that this team needs a point person who is going to take over the responsibility of making sure that certain technical processes maybe are follow, that's going to take responsibility for collaborating most closely with the product manager or the business analyst for the team and get the team organized and make sure the projects are running smoothly?" If you think that that would be a helpful thing to have for the team, then yes, I think you should probably ask someone to be a tech lead.
Camille Fournier: I would encourage you to not just ask the person who you think is the best engineer on the team, but make sure this person is also a good communicator, that it's someone that is going to make your team able to operate better and not just think that "Oh, now they're the tech lead so they can tell everyone that they have to implement everything exactly their way and they get to make all of the rules."
Stefan Tilkov: Does anyone get to do that? Does anyone become a tech lead and get to make all the decisions?
Camille Fournier: I'm sure it happens, but it shouldn't be that way. I'm sure it does happen. I'm sure there are companies that are too hierarchical. When we were talking before about -- I think people don't want to put hierarchy again because they don't want to limit people's ability to independently make decisions or feel like they have some autonomy. And it's bad when your tech leads are telling everyone exactly what to do, thinking that they get to make every single decision because they're in this tech lead role. It definitely happens though, so as a manager you have to be careful that when you put someone in that role it's pretty clear to them that this isn't just a role where they get to make every single decision.
Stefan Tilkov: I think most developers among our listeners will be able to imagine that role pretty well, because they're probably working very closely with somebody in that role if they're on a larger team, in a larger organization, but what about the next level? If I understood you correctly, the next level would be some sort of team manager, somebody with actual responsibility for direct reports, right? Is that the distinction?
Camille Fournier: Yes.
Stefan Tilkov: How do things change at that level?
Camille Fournier: Usually, when you are managing a team of a certain size, your job starts to become disproportionately about people, and maybe project management and organizational tasks, and less about deeply technical things. Sometimes tech leads will manage individuals; I did when I was a tech lead, but not all the time. That's certainly not a requirement for tech leads, but sometimes the tech lead role will also have you managing a few individuals. I personally am of the opinion that you can manage people up to a small number - three, maybe four - without really being a "manager." You do need to be responsible for making sure you're doing one-on-ones and you're doing some of those general management and coaching tasks, but there is a difference between having a few people who you are responsible for, who you're doing one-on-ones with and you're writing their reviews and you're making sure they know who to go to to answer various organizational questions, and being a manager, being a real team manager.
Camille Fournier: Usually, once you become a team manager, you start to spend more and more of your time on things like larger organizational meetings, maybe the meetings with the other managers in your division, figuring out what the planning is for the future, focusing not only on the people that you have on the team now, possibly on hiring, a lot of recruiting, interviewing... You often get pulled into the organizational tasks that every company and every team needs people to do, whether it's making sure we are doing a planning off-site for this team, or making sure we're doing teambuilding events, which is not usually something that you expect a tech lead or even a person who just happens to have a few direct reports - you don't usually expect those kinds of organizational things to fall on their shoulders.
Camille Fournier: The rule starts to change. Now, I encourage people to keep writing a little bit of code, even when you're managing a team, as long as your team isn't so big that you really spend all of your time on management. Different people have different rules of thumb; I have a peer right now who's very analytics, and I think he's done the math and he says "Every person to reports to me directly, it takes like 13% of my time." He knows exactly how many direct reports he can have before he is literally spending every bit of his time thinking about those people or their teams.
Camille Fournier: If you're managing a team of four or five, you probably have a little bit of bandwidth, and I think it's a good idea to still write a little code or fix some bugs occasionally, be involved in on-call, make sure that you're really still in the details of the technology, even though you're probably not going to be the person that's writing big features - that's not usually a good use of your time, and you certainly never want to be the bottleneck for the rest of your team, because you have other organizational tasks to do.
Stefan Tilkov: One of the things you mention a lot of times in the book and you mentioned in this episode as well are one-on-ones. Can you define what a one-on-one is?
Camille Fournier: Sure. A one-on-one is a meeting between you and your manager - one on one. I recommend that this be a regularly scheduled meeting. I prefer a weekly. I think weekly is the best thing you can do. Every other week is okay, some people can make that work; I prefer more regular.
Camille Fournier: A one-on-one is not a performance review, it's not a status update, it's not a planning meeting. It is simply a chance for you and your manager to have regular time to talk about whatever. And sometimes you will talk about performance, sometimes you will talk about status, sometimes you will do some planning, sometimes you'll do coaching. But the point of the meeting is really that you have this reserved time, hopefully every week, to touch base with your manager and talk about whatever is important for you to talk about in that meeting.
Stefan Tilkov: Can you talk a bit about why you think one-on-ones are so important and how you actually do go about organizing them?
Camille Fournier: Yes, so I think that one-on-ones are how you build trust with people. Humans need interaction to trust one another. The more you interact with someone, the more familiar you become to them, the more you trust them, the more you're willing to open up to them about things. So doing regular one-on-ones helps you, as a manager, build that trust with the people who report to you. It helps you kind of just get to know them better, it helps them get to know you better, and it reserves this regular opportunity for them to tell you uncomfortable things that they may be scared of saying or reluctant to bring up. "Oh, I really am just having a hard time working with so-and-so." If they perceive you as too busy to ever talk to them, and you very rarely do one-on-ones, like once a month or once a quarter, people are not going to tell you these light things... Maybe they're not serious yet, they're not an urgent issue, but it's something that's kind of bothering them, and those things are the things that tend to build up and build up and turn into big problems. If you can catch them early, you can correct the situation. If you don't ever talk to people and if people don't feel comfortable coming to you and expressing the minor annoyances, then you don't have that opportunity to catch them before they become major annoyances, before they become things that cause people to quit or cause projects to fail.
Camille Fournier: I just think one-on-ones are really a very essential interpersonal trust-building exercise, and I care about them also because I've had managers who canceled my one-on-ones all the time or who didn't do them regularly and I had a very hard time working for those managers... In comparison to the managers who were very good at making sure I got that time every week as much as possible, and that they were they, they were attentive and they were listening to me. I felt much more comfortable going to them with issues and we just had a so much better working relationship.
Camille Fournier: How you run a good one-on-one - I think everybody does it differently and everybody expects different things out of one-on-ones. I think that one-on-ones are not always any one kind of thing - they're not always career coaching, they're not always project-status updates, they're not always just chatting about life, but all of those things probably happen on one-on-ones. It's not actually necessarily a bad thing to occasionally get project status updates in a one-on-one, because sometimes that gives you a good chance to really dig in on something that you may not have heard about as a manager. Certainly, as a manager of managers, a lot of the time you spend on one-on-ones is actually going to be around the projects that their teams are doing, because you as a manager of managers are not going to have the time to know all of the details and to read all of the details from every team that is in your organization necessarily.
Camille Fournier: In those kinds of meetings, you probably will spend a little more time on project status updates and possibly a little bit less time on career coaching or technical mentorship, whereas when you're managing individual contributors, a lot of what you probably spend time on is more -- there's going to be more career coaching, there's probably more helping, going into details about what they're working on and anything that you can help with. Maybe you can give them feedback on a piece of design, or talk them through a code review that they're struggling with. What happens in your one-on-ones definitely depends on the level of people that you're interacting with and your personality.
Camille Fournier: The final thing I will say is some people are very meticulously organized on their one-on-ones. They have running documents, they share Google Docs or Google Spreadsheets of "Okay, here is the topics we're gonna talk about. You're going to put some stuff in, I'm going to put some stuff in and then we're going to run through this list. Every one-on-one we're going to go through the list of things that we've put in the doc." I have tried to do that and it just does not work very well for me, I have to admit. I prefer a little bit more of a -- I prefer my one-on-ones to be a little bit more of... I don't want to say "casual" exactly, but I want to make sure that we have time to dig in on things that are mentally pressing us right now, when you walk in the room, and we don't feel constrained to an agenda that we may have written two weeks ago. On the other hand, you don't want to miss stuff that comes on the agenda that should be important but isn't just urgent in this moment. That's the tradeoff there.
Stefan Tilkov: What is the limit of one-on-ones a manager can do in a week?
Camille Fournier: There's certainly a time boundary. Assuming you work 40 hours a week and you do 30-minute one-on-ones, you could only do 80 of them.
Stefan Tilkov: Only 80...
Camille Fournier: Only 80, right? You would probably kill yourself, and I don't know when you would go to the bathroom.
Stefan Tilkov: Absolutely.
Camille Fournier: There's a limit to how many people you can have as direct reports and really be effectively managing those folks. For me personally, I don't manage very well after about seven direct reports. I can do it, but you're not getting as much of my attention. I prefer to have six direct reports; it's my sweet spot, that's about how many I like. Usually, with six direct reports, some of those will have hour-long one-on-ones, some of those will have half an hour one-on-ones, depending on the level of detail that we maybe need to be going into based on the work that their team is doing, or the kind of coaching that they need.
Camille Fournier: Obviously, every person is a little different, and depending on how you run your one-on-ones and what you're doing in them, you can have more or fewer of them in a week. But I certainly advise people to have one-on-ones with all of their direct reports every week as much as possible, and if you have too many direct reports to do that with, then you should probably start thinking about how you can layer some of those direct reports, or just add another manager of managers, such that you don't have quite as many people directly reporting to you.
Stefan Tilkov: A few minutes ago I asked you what changes when you go from being a software developer to being a tech lead. What changes from being a tech lead to being a manager, in addition to having regular one-on-ones?
Camille Fournier: Let's say you are really a full-time manager. So you have gone from having maybe three or four direct reports to managing a couple of teams' worth of people, and let's say you have eight or maybe even ten direct reports, or you have two distinct teams of project work that are reporting up to you. I think that the big changes there are that you're going to spend a lot of your time thinking about whether the team is operating well or not, and how you can be making the team operate better. That includes everything from paying attention to the interpersonal interactions on the teams and making sure people are jelling well there, they're collaborating well, you don't have toxic personalities that are undermining people on the team, that you've got teams that are collaborating effectively together.
Camille Fournier: That means things like making sure the products team is working effectively with your engineers. Not everyone works with product managers, but for those who are in consumer-facing companies often, usually, in most startups, you have this product management organization, and product managers can be tough for engineering managers to work with and tough for engineers to work with sometimes. They have a roadmap of features that they want to get done, and they're thinking about the customer, or they're thinking about this beautiful UX design that is their dream of this beautiful app, and you as an engineering manager are going to spend a lot more time collaborating with them and making sure that they are not steam-rolling over your team and ignoring all of the technical things that the team needs to be working on, in favor of just feature after feature after feature, and that the engineers feel like they have a voice, and what's actually getting built, and that when they have ideas, that they at least feel like their ideas are being heard.
Camille Fournier: Even though the product manager does own that product roadmap, you do want your engineers to feel like they understand why the product roadmap is how it is and that they feel like they're a part of that team that is making those decisions, to some extent. So you spend a lot of your time much more on "Is the team operating effectively? Are we moving forward well? Are people getting along well? Are we hiring the right people? Are we developing the right talent? Are we building the right things for the future of the business?" As you go to more and more senior levels of management, the technical side of this job turns into "The business is going in this direction" or "The users that we are supporting are going to need these things. The tech industry is going in this way." "We're all moving to the cloud", for example. "Are we set up to support that as we need to do it, as we need to move more applications to the cloud, or as we need to write mobile applications in a new language?" or whatever it is that's applicable to your business. "Are we building the right technology for the longer term and not just focused on today and these little ideas that we had today?"
Camille Fournier: This is some of the ways that your job starts to change as you manage teams and you become a full-time manager of larger and larger organizations.
Stefan Tilkov: This sounds like more of a almost strategic perspective on the whole thing, right? Not focused on a particular project, but rather on the organization building those products or projects that used to be your main focus when you were a tech lead or a developer. Is that a fair way to summarize it?
Camille Fournier: Yes, and it's a scale. You go from very detail-oriented, at a small scope, or you have a lot of control over the work because you're actually doing a lot of the work yourself as a tech lead or a senior developer, and as you add more levels of indirection between yourself and the work that's being done, and you're no longer doing the work, you're more about the meta-work; you're more about the way the work is done, the people who are doing it, and thinking about what work should be done at all.
Camille Fournier: Another major thing that managers are really responsible for is ultimately they are very much responsible for prioritization. As you get towards the end of a big project and you're almost ready to ship, and you've still got this sort of competing -- things that everybody says need to be done, whether it's the product manager saying "Oh, but I just really want this feature. There are these three features that I just think are super essential", or the tech lead saying "Oh, but we really want to do this refactoring", or "We really want to make it work with this other system", you as the engineering manager are going to sit in between those and look at them and try to kind of negotiate and prioritize to the things that actually have to be done for launch, or can be delayed until the next version, so that you can get these things out the door successfully... Because a lot of the responsibility you have at that point is "Is the work actually getting done? Are we getting stuff out the door? Is it of high quality? Is the team operating effectively, and are we retaining the people on the team? Are they developing, so we're not having a bunch of people quit on us? Are we hiring well?"
Camille Fournier: All of these aspects start to be what you're actually going to be held accountable for by your manager, and therefore you tend to get a lot more about the details of how we're prioritizing things and making sure we're really doing the right work.
Stefan Tilkov: What about stuff like salary negotiations and performance reviews and all those other classical management tasks?
Camille Fournier: That's certainly part of it. Performance reviews - most companies, if you are managing someone, if you are listed as someone's manager in some HR system, you will be doing performance reviews for that person, assuming that they get performance reviews. I like to encourage people -- if you're managing individuals, to be giving regular performance feedback. When someone does something great, or when someone does something that maybe is not so great, I encourage you to tell them quickly. Certainly praise - it's good to tell people they're doing good work; it's good to be specific about what they're doing that's so good, not to be like "Good job, folks!", although I fell under that trap sometimes, I will admit... But you want to be giving people performance feedback on what their strengths are.
Camille Fournier: When they do something - let's say they write an unkind comment in a code review, and you can tell that it upset the person who is on the other end of it, you may want to grab them, pull them somewhere private and say "Look, that was not a nice way to address that issue. Let's think about how we could perhaps have done that better, so we can do that better in the future."
Camille Fournier: I am a fan of more in-depth performance reviews yearly, where you actually get feedback from other people, and you ask the peers of a person, or the customers of a person how they feel about interacting with that person, and you spend a little time kind of thinking more deeply about their performance and what they're good at, and where they could be developing themselves.
Camille Fournier: It's worth having some focused time to think about a person and gather data and evaluate. "Do they seem great just because I like them and they are fun to see day-to-day, or are they actually getting amazing work done?" I think a more formal performance review is also useful for that process.
Camille Fournier: Salary negotiation I would say very much depends... Not every level of management does compensation stuff. Different companies handle that different ways. Some companies have salary bands in HR and recruiting do all of that negotiation, and maybe the senior manager of the division signs off on that. If you're at a startup, you may be just working with recruiting or the CTO to figure out what you should be offering someone. That's a little bit more of a case-by-case, and doesn't often come until you're a little bit more a senior manager at most companies.
Stefan Tilkov: How do you find out whether you're a good manager or not?
Camille Fournier: That's tough. I think because it's always a very lagging indicator. If you're a good or at least pretty good engineer, you have very short feedback loops. You write some code, you write a test, the test passes, the code gets into prod, people start using it... Either you get paged or someone gets paged, or it all goes well. And yes, there are definitely things you can do as an engineer that will be mistakes that you will regret six months later or a year later - we all do that - but by and large it's a lot easier seeing yourself progress and have a good feeling for how good are you at writing code, how good are you at debugging these systems, how good are you at designing things to take into account all kinds of edge cases, and actually then seeing them through to completion.
Camille Fournier: As a manager, it's a little bit more nuanced. How healthy your team is, how well your team is depends to some extent on how talented is the team that you have hired, how motivated are they. They may be really talented but totally unmotivated, or they may be talented but they're so motivated that they can accomplish amazing things. The talent actually doesn't matter as much, because they are really invested in a goal, and they're just focused on getting there and doing it really well. People on the team can have a great impact into how effective the team is. You can have people on the team who undermine the team's effectiveness by maybe just being in the wrong job, at the wrong company for them, and that comes out and it drags everyone down.
Camille Fournier: You don't tell people what to do every day. Managing is not like building a computer where you're literally writing instructions and people are following them, it is not like that at all. You sort of give suggestions, you may set certain priorities, but it's very rare that you're really directly telling people what to do and exactly how to do it. So to that end, you don't necessarily know... If the team is doing well, is it because of you? Is it your fault if the team is doing poorly?
Camille Fournier: How do you know if you're doing well? I think in general you have to measure a few things. Retention is a big one. Are people staying, or are people quitting? If people are quitting a lot, you're probably not doing all that well, although retention is heavily determined also by how well the company pays, how hot the tech industry is, and how much people like the general work that the company has for them.
Camille Fournier: Retention tends to be a good indicator, but it's not the only one. You can be a pretty good manager in a startup that just doesn't pay that well, and that's doing work that not a lot of people are super excited about... You might not have a very great track record of retention. However, you should learn from that, and learn who you're going to hire that you are going to be able to retain. In that case, you may say "You know what, I'm not going to be able to hire people who would otherwise go work for Google, because I'm never going to be able to pay them enough for them to overlook the fact that they're not at Google right now, and instead I should hire people who probably would not get a job at Google, but who have different talents and are excited about the work that we're doing here and are not going to always be looking around the corner for the next big opportunity."
Camille Fournier: So retention is one thing that you often measure yourself to see if you're doing well. I think team engagement is another one. Does the team seem happy to come in to work? Do they seem friendly with one another? They don't have to be best friends and hanging out all the time, but do they often eat lunch together? Or if you were to have a happy hour, would many of them stick around and hang out for a little while?
Camille Fournier: Obviously, you've got parents, so not everybody can do that, but [unintelligible 00:54:32.18] other life obligations, do you feel like your team is working well together and actually enjoys one another's company, and they have positive and supportive interactions? That's a good sign that a team is doing well, and you usually have something to do about that.
Camille Fournier: And then are they getting stuff done? Teams like to ship. I do believe that most engineers like to get stuff done, they like to complete projects, they like to see their work being used, and if your team is getting things done, you're probably doing a pretty good job, especially if what they're getting done is high quality, they're not getting drowned in alerts all the time, they're not just dying from on-call. Those are some of the things that you can use to measure whether you're doing a good job as a manager.
Stefan Tilkov: I think some of those things reflect upon the company's culture, because explaining it from a team perspective, many of those things could be applied to the company as a whole as well, right?
Camille Fournier: Yes.
Stefan Tilkov: So how much of a role do managers play in shaping company culture?
Camille Fournier: I think especially at startups, if you are in a management position, you probably play a pretty big role. Certainly the CTO of any company, but especially a startup, has a huge place in the culture. A lot of what culture turns out to be -- it's a few things. Some of it is the core values of the company. Rent the runway had core values that were written before I got there, and it took me a while to appreciate that. What I learned from being there and watching those core values come into action - and the core values were things like "Roll up your sleeves and get involved", "We are all founders", "Happiness and positivity is a choice"... There were a bunch of core values, and what I found after observing those for a while, and observing who did well at the company was that the people who matched the most of those values were actually the happiest people at the company, the most successful people at the company, whatever their background was. Not necessarily people with gold-plated degrees and amazing backgrounds, but they matched all of those values so well that they just really got along with people well at the company; they had the right attitude, they had the right kind of work ethic, they focused on the right things.
Camille Fournier: I do think that values are important, and if you are starting a startup or if you are an early startup that hasn't spent time thinking about your company's values, I actually think that's super important to do. Then as a manager you should be recognizing and reinforcing those values in your employees.
Camille Fournier: Some people say - and I kind of agree - that one of the most important things for a formal performance review is helping people see where they are out of alignment with company values and where they're in alignment with company values, and reinforcing that culture.
Camille Fournier: There's more to it than that. I think other things about culture are just the simple documents that show people "This is our career ladder", for example. "This is what it means to be at various different levels of career ladder", or "These are the skills that we are looking for in engineers. These are the skills that we think are important", and being explicit about that.
Camille Fournier: Some of the cultural things that you need to think about are also the rules of engagement for people. Do you have a way that you do code reviews that people understand - they understand what the point of the code review is, they understand how to go about it. Do you have processes around architecture reviews or operability reviews? These are kind of cultural documents.
Camille Fournier: Then there's also things that are just like "What are the kind of activities and celebrations that you do as a culture?" Do you do things like weekly learning sessions, where somebody will come in and teach the team [unintelligible 00:58:57.22], something that they have learned? Or do you do quarterly off-sites where you all go to a park and hang out and throw a Frisbee and talk about work or talk about nothing? All these different cultural things will shape what kinds of people are going to do well and how people know what it means to do well in your team and in yoru company.
Stefan Tilkov: How much formalization do you think all of this needs?
Camille Fournier: I like to formalize things, I will admit. I think that you want to formalize them, but at the right time. For example, career ladders - I do think that having levels... I actually am a fan of having a career ladder and having levels; not everybody does that, and that's okay. I like it.
Camille Fournier: I think you should do it and try to be as -- I try to actually be pretty explicit with it, because that makes it more valuable and more useful as a rubric. If you're really talking about documents that tell people what it means to be successful at the next level, it's worth spending some time and being relatively precise, knowing that you're never going to be perfect, that there's always a ton of nuance and interpretation to all of this stuff... But I think that the formalizing process is worth engaging in, because you're talking about something that's really important to people - you're talking about their career, and you're talking about their future.
Camille Fournier: I think process is good to have. You want to keep it to what you need and no more. As you put a process into place, don't be afraid of removing steps that turn out to be not that useful. If you were to start (let's say) an architecture review process and you had a step where everyone going through it had to get comments from ten people on the team on their design, and that just took everyone forever and it actually didn't provide all that value, and it would be faster to just say "Actually, you need to write a document and bring it to a room and talk about it for an hour and that's it", that I think is -- you want your processes to be as easy to follow as possible, but not burdensome.
Camille Fournier: The value is in just being specific about the things that you can be specific about, but not too over-prescriptive, because there's always room for nuance and interpretation here.
Camille Fournier: Stefan Tilkov:[01:01:59.09] Let's talk a bit about something you mentioned at the beginning, which was mentoring. You mentioned maybe even at a point where some of your peers are becoming tech leads and you might focus on different ways of being valuable beyond the code level, so to say. What's the point of mentoring and how do you go about becoming a good mentor?
Camille Fournier: I think the point of mentoring is that you're helping people develop. You're making your team better by helping someone who's usually new to the company - or maybe even new to the job entirely - and you're helping them get up to speed with what it means to be successful in this job or at this company, and you're being a set of ears to listen to their questions and answer questions for them. And you yourself actually learn a lot when you're mentoring someone because you get to see a fresh perspective on things, and that helps you see things in a different way and it can help you identify places where "Oh, everybody just knows that, except every new person I mentor doesn't just know that, and they're always very confused about why this system looks this way or why we do this. We've never bothered to really write it down, and there actually is a really good reason for it, so maybe we should write this down. Or maybe we shouldn't do it this way, this doesn't actually make any sense, and there's a reason that every new person is confused by this."
Camille Fournier: I think mentoring is a good exercise for people because it teaches you a bit of humility - you need to be listening, you need to make yourself available to people and be patient with them and listen to them if you're going to be a successful mentor, and it gives you a fresh perspective... And frankly, it's just good for making connections with people. The people you mentor may end up being your best friend on the job, or they may end up being the person who gets you your next job, you never know. So I think it can be a good relationship-building exercise.
Stefan Tilkov: Are there restrictions on who a manager can mentor?
Camille Fournier: That's interesting... As a manager, you're probably not going to mentor someone on detailed technical things necessarily. You might, if you truly are an expert in certain technical areas maybe, but usually when you're a manager you might be mentoring new managers, or you might be mentoring someone who's a tech lead or who wants to become a manager. That often makes more sense than managing someone on the right technical career path if they want to stay highly technical.
Stefan Tilkov: I wanted to get at the question of whether it's possible to mentor one's reports.
Camille Fournier: Well, so you are a coach. I think a part of your job in management is coaching, so you can mentor, but it's good for people to have another mentor who isn't you, who they can frankly go to and ask things that either they may not feel comfortable asking you, maybe things that you would be able to answer well... There are certain things that you're never going to be able to mentor on. I would not be a good mentor to someone who wants to know what it's like to be a superstar Python data analyst, because I've never done that; I can't mentor you on that. I might have people on my team who are doing that job and I have to manage them, but I would probably want someone who is a superstar Python data analyst to be their mentor, instead of trying to pretend like I can do that.
Stefan Tilkov: There is one management level we haven't talked about, I think... Maybe we have and I haven't noticed, but what about the highest level you can get to in a company? This CTO or CIO or VP of Engineering. What changes when you become that person?
Camille Fournier: That is a very different job even than one level below it. It's funny, I am now the head of platform engineering at Two Sigma and I report to the CTO there, and it's great, I have to say! Because the CTO job is really hard. The CTO or the head of engineering, whatever that job is where you are there in the executive team that is running the company as a whole, it's a very stressful job. Your peers, for the most part, are not technical; maybe some of them are, but often you are reporting to a manager who doesn't really know what your job is like. Maybe you're lucky and you are reporting to a very technical CEO; you're at techie startup with a technical CEO.
Camille Fournier: Most CEOs are not really technical people, so they don't really appreciate what the job of running an engineering team is like. They've got a million different things on their plate, they're super stressed out. Your peers are often not necessarily technical. You're working a lot with the CFO, or the head of design, or the head of marketing, so you need to learn how to communicate effectively with those peers without relying on the technical communication skills that maybe you've learned to get to where you are now. And you are the person that everyone in engineering is probably looking up to, and they're watching you extremely closely to see what you are focused on; the things that you care about, they care about, and the things that you don't care about, they don't care about... Which is tough, because maybe you're not all that interested in (let's say) mobile application development, but you have to have a great team of mobile application developers to make your product successful, and everybody's watching you. So you have to spend time on that and take an interest in it, even if it's not maybe your natural interest area.
Camille Fournier: It's a very tough job, and it really does require a different set of communication skills to be successful at, it requires a lot of maturity and poise. Poise is one of the most important things at that level. That was a hard thing for me to learn - you really had to carry yourself and be mature and not overreact to things... And how to lead people really strongly and give them a clear vision for where they're going, how to lead your peers and explain to them why your team is not working on their pet project, but what your team is working on is really important, and you have to lead those engineers and make sure that they have the space to work on things that are important to just engineering, and that they're not just turning into this operational arm that just spits out stuff that the business requests.
Stefan Tilkov: Cool. Maybe as we're getting to the end of this episode, what are some reasons anybody would ever want to become a manager? What's great about managing?
Camille Fournier: I think a lot of people want to become managers for the wrong reasons. A lot of people do think they want to become managers because they think that managers get to make all of the decisions and they get to tell people what to do, and that once they have the ability to tell everyone what to do, things will just be better and the right stuff will get done. I will admit that I may have been one of those people at some point in my career.
Camille Fournier: I think it's actually common for very highly opinionated people who really want things done their way to want to become managers. Now, unfortunately that's not a great reason to become a manager, and as most people who get into the role of management - myself definitely included - what you start to learn is that in fact as a manager a lot of your time is not spent telling people what to do at all, it is spent enabling them to do what they can do, it is spent, coaching them and guiding them and listening to them.
Camille Fournier: Occasionally, yes, you are giving high-level direction of "I think we should be focusing more on this" or "I think we should prioritize this over that", but most of the time you are actually really just trying to balance making sure that as many people are getting to do the things that they want to do and the things that they're good at as much as possible, and not undermining your team by just telling them "This is the way you're going to do it. You're going to do it my way or the high way."
Camille Fournier: Sometimes you're watching people make mistakes that you think "This is a mistake, but if I tell them it's a mistake, they're going to resent me or they're not going to learn anything. So instead, I'm going to sit back and let them make this mistake, so that then once the mistake is made, we can all clean up after it."
Camille Fournier: I think that people who go into management who are willing to sacrifice themselves in certain ways for the development of the overall team, I think that's a good attitude to go into for management. There are plenty of people who go into management because they like people and they like the relationship building and team building. I think that's also a pretty good reason to go into management, but I do think that there is a level of it that it's also good if you do have some degree of opinions and you want to help people grow and succeed and be bigger and you can see a vision, but you're also willing to help the people along the way achieve that vision, if that makes sense. It's a little bit rambly...
Camille Fournier: The people I see who make the biggest mistakes in going into management are people who think that they have to manage people to be successful, and that is the measure of success for their company, or that is the measure of success with the industry - the number of people they manage or the number of teams they manage; that the only way they can be successful is in this management role. And yet, when you look at them and you look at what they do and what they think about and you have a conversation with them, they are super passionate about the detailed aspects of the technology, they care a lot about the engineering... They don't care as much about how the team is working together, they're not that interested in the sort of organizational developments or even necessarily the large-scale project management.
Camille Fournier: They're not really that interested in the interpersonal development stuff. Those folks often will say that they really want to manage, but it's just never going to be their strength. And it's sort of a waste to take someone who could be a great senior staff engineer, who could design great, big systems and mentor younger engineers on how to be better engineers and make them a people manager, where a lot of their time is going to be spent more on organizational process and project stuff.
Stefan Tilkov: That makes a lot of sense. Typically, at the end of an episode we ask "Do you have some pointers for listeners who are interested in learning more about this topic?" That is a question I want to ask you, and obviously we're going to point out that you've just written a book on that and I'm going to link to it in the show notes, but are there any other resources that people should look at? And more importantly, what are some of the long-term things that you can do to support your career as a manager?
Camille Fournier: Yes, so besides my book, obviously, there's actually a growing set of resources for specifically engineering managers out there. There are a couple of different engineering management Slacks out there; I think if you google "engineering management Slack" you'll probably find a couple of different links. I don't hang out in those myself, but I do generally speaking think that having people that you can talk to about engineering management -- and honestly, not even just in the early stages of doing it, but the whole time you're doing it. It's good to have friends to be able to gut-check "Does this thing that is happening make sense? How do I address this issue?" I do this still to this day with a group of CTO peers that I have and it's very, very valuable.
Camille Fournier: So I do think that whether you join one of these Slacks, or you find people in your company or people in the town/city that you live in, developing a network of peers that you can ask questions of and you can get gut-checks from is really important.
Camille Fournier: There are some good conferences. The Lead Developer is a conference - they run it in London, and I think next year they're running it in Austin and New York, and it's a great conference, and the organizers are great. That is sort of a mix of management and tech lead stuff, so for people in the early to mid stages of their management career that can be a very useful conference to attend. And there are other conferences around that can be useful.
Camille Fournier: The talk format is not -- you can learn something from it, you can get ideas to take away, but it's certainly probably not the only thing you should be doing. I should also say that I am the person who runs the Technical Leadership Track in the O'Reilly Velocity conferences, and we have a lot of different topics on technical leadership that come through that track at the Velocity conferences, so you can also look for that; a lot of those videos are available online.
Camille Fournier: I think reading is important. There are a lot of blogs out there that talk about technical leadership engineering, leadership and management... Michael Lopp (Rands) is someone that a lot of people look up to in this area. A lot of his writing is very entertaining, certainly. My friend Lara Hogan, who is the VP of Engineering at Kickstarter, has a lot of great blog posts on this. My friend Kate Houston, who runs all of mobile engineering for Automatic, also has a lot of great blog posts on this stuff.
Camille Fournier: There's a few books out there - Michael Lopp also has a book called "Managing Humans" that a lot of people like. There's a book called "Leading Snowflakes" that a lot of people like. I will admit that -- because I never read those books before I started writing my book, I haven't read them because I didn't want to pollute my mind while I was writing the book with other people's stuff. But I've heard good things about both of those.
Camille Fournier: There are some good general management books I like - "High Output Management" by Andrew Grove (that's kind of a classic). "First, Break All the Rules" is another one of those classics. Those are both cited in my book. There's a lot of great books on leadership out there. If you really want to become a good manager and a good leader, reading is very useful. I get a lot of value out of a Harvard Business Review subscription that I have.
Camille Fournier: The last thing I will say is you may also get value out of coaching. I've worked with a personal coach for years and years on a lot of the challenges of growing as a leader and a manager, and she was incredibly valuable for me, especially in the time that I was at Rent The Runway and growing my career there. I also happened to have a CTO coach with Rent The Runway; that was a little bit through the company, and that was very valuable to me.
Camille Fournier: I think that spending money to invest in your career can be useful. Your company may not pay for it; it's up to you if you have the money to invest in this, if you want to spend your money that way. I certainly think it's a worthwhile investment in continuing education, to have a person to talk to who is good at coaching people through especially these challenging interpersonal situations. That's what a person coach will give you, that's where you'll get the most value there.
Camille Fournier: That's a lot of different resources, because this is not an easy thing. I definitely spent a lot of time reading and learning and talking to people and making a lot of mistakes - and I'm sure I'm still doing - throughout my career. Never assume that you've learned everything that you need to know, because it's almost certainly not true.
Stefan Tilkov: Great. We're going to have very extensive show notes, which is awesome. Camille, it's been a pleasure to talk to you. Fascinating topic, I enjoyed it very much. Thanks for being with us, and thanks to the listeners for listening.
Camille Fournier: Thank you for having me.