Q&A on The Manager‘s Path with Camille Fournier

In the book The Manager’s Path Camille Fournier explores managing engineers and what it takes to be a technical manager. She describes the different roles which form the path from mentors and tech leads to senior engineering management, discusses the challenges of technical leadership and provides advice on how to deal with them.

InfoQ readers can download a sample of the Manager’s Path.

InfoQ interviewed Fournier about what employees expect from their manager, where things often go wrong and how to deal with that, challenges for technical professionals when they are promoted to become tech leads, what tech leads can do to create a culture of continuous feedback, how to balance technical and management tasks, and what it takes for tech leads to become a top level manager.

InfoQ: Why did you write this book?

Camille Fournier: When I wrote the first draft of the book, I had just finished an intense period of learning how to manage and lead an engineering organization, and all of these hard lessons were fresh on my mind. I didn’t think there was a lot out there about the path that many people take as engineering managers, from mentor all the way through to senior management. I also didn’t feel that there was much out there that addressed what it meant to be a technical manager.

InfoQ: For whom is this book intended?

Fournier: This book is intended for anyone who is interested in engineering management. For those who are early in their career and curious about what that path might entail, the book provides an idea of some of the opportunities and challenges that might present themselves if they choose to follow this path. For those in management roles, my hope is that this provides some pragmatic and focused advice about common challenges that engineering managers will experience. And even for those who have been managing for a while, this book can help remind them the challenges more junior managers face, and help them to guide the managers on their own team. My goal was to write something that the reader could reference over time, and something very specifically aimed at technical managers, not just generic management advice.

InfoQ: What are the main things that employees expect from their manager?

Fournier: The biggest things employees should expect from their manager are regularly-scheduled 1-1 meetings, feedback, and resources for career growth. Your manager should be able to guide you through the ins and outs of your workplace, in order to help you get around roadblocks in your work, and they should know what resources are available for you to get training. Some managers will act as coaches for their employees, but this is not always something that your manager can provide. Managers might provide technical feedback, and sometimes set the roadmap for projects for the team, but it’s not universally true that every manager you have will hold these responsibilities.

InfoQ: Where do things often go wrong between managers and employees?

Fournier: It’s pretty common for people to have bad managers. Managers who skip your 1-1s, or never even bother to set them up, are a particular pet peeve of mine. Some managers treat their employees like cogs, and spend all their time discussing project status without ever providing any feedback on how the employee is doing, whether they are performing well, or what they might need to do to get to the next phase of their career. And unfortunately, some managers are cruel to their employees, manipulating, micromanaging, or even bully them.

InfoQ: What can employees do themselves to deal with such problems?

Fournier: The #1 thing you can do is, as much as you can, choose your manager wisely. We don’t always have the power to choose our managers, but identifying people you want to work for in your workplace is a good idea. When you’re interviewing for a job, ask about the manager you would be reporting to and look for managers who seem to have a good reputation with the people who work for them. There’s no guarantee that you’ll get someone great, but it can help. You will notice that there are managers who have employees that follow them from job to job, which tends to be a good sign.

I also advise people to remember that ultimately, we’re all adults and responsible for our own destiny. That means that you should spend some time thinking about what you want for yourself, and what you want for your career. When you know what you want, you can go out and find it more easily, and you can ask your manager for what you want if you aren’t getting it. If they keep canceling your 1-1s, tell them that you would like to get on a more regular schedule. Ask them for feedback explicitly. Tell them what you are hoping to accomplish in your career, so that they can better help you.

If your manager turns out to be cruel or harmful, take care of yourself. It’s not easy to quickly get out of these situations, but I generally think that the best thing to do when you find yourself working for a bully is to find a new team or a new job, if at all possible.

InfoQ: What are the challenges for technical professionals when they are promoted to become tech leads?

Fournier: I think that many people don’t realize that their job has changed when they get this role. Instead of focusing on writing code all the time, they now need to pick up a lot of other pieces of delivery, such as technical project management. And their managers often don’t really make it clear what it means to be a successful tech lead. In fact, many managers don’t really have a clear idea what a successful tech lead looks like, partly because it depends on the team and the projects that the tech lead will be dealing with.

When I’ve seen tech leads struggle, it has been largely with the change from heads-down 100% focused engineer to only doing that, say, 30-50% of the time. You’re pushed out of your comfort zone, and if your manager doesn’t help you understand what the new role needs, it’s very hard to know what to do. So you get people who stop coding entirely and become a full project manager. You get people who think they are the person who makes every technical decision for everyone on the team. You get people who start micromanaging everyone on the team. And of course you get people who take the role on but don’t actually change their day-to-day, and neglect everything but the code.

In general, every step into technical leadership means a change in your day-to-day job. You don’t really get promoted for doing the same thing you’ve been doing most of the time.

InfoQ: How can they deal with the challenges of technical leadership?

Fournier: First, recognize that while you are the tech lead, that doesn’t make you the technical dictator of the team. Figure out which technical decisions should be made by you, which should be handed off to other team members who have more expertise, and which decisions should involve the whole team coming to a consensus.

Second, be careful of getting too obsessed with processes to solve problems that are related to communication or leadership gaps. Some tech leads think that the solution to every problem is a new or better process. While process can be useful, it can also be overdone, and it is rarely the one true solution for a dysfunctional team.

Third, don’t step entirely away from the code. As a tech lead, you should be writing code some of the time. It may only be 30% of your time, but that is enough for you to be staying in the mix of what it is like to write software on your team. For people who become engineering managers, staying technical is an important element to management success. While you will probably stop writing production code at some point in your management career, staying technical by reading code, writing scripts, debugging, and staying in touch with technology news and trends is a pretty critical part of successful technical leadership.

InfoQ: What if someone finds out, after becoming a tech lead, that they don’t like the managerial work that comes with it- is there a way back?

Fournier: Absolutely. I think one of the nice things about the way most tech companies think about career growth is that there are usually two paths: one for management, and one for technical individual contributors. For people who have not yet chosen a path, the tech lead role can give you some idea of which career path might be more interesting to you. If you like the management elements of being a tech lead, great, but if you prefer the technical focus and system design and don’t want to think about the people and organization, you may decide to stay on the individual contributor path.

My personal advice for almost everyone is that you should be a tech lead once, even if you know you don’t want to be a manager. If you choose to remain an individual contributor, following that path requires you to exercise leadership and understand how to get teams rallied behind your ideas and executing well. So you want to learn these skills, but that doesn’t mean you have to become a career manager.

InfoQ: Which advice do you have for employees starting their first day as a manager?

Fournier: Spend time getting to know your new team as individuals. If you are coming in to manage a team of individual contributors, don’t just focus on understanding the projects and the tech. Ask the team members about themselves, how they like to receive feedback, what they’re excited about at work and what they’re struggling with. Get a sense of where they are with their career and what kinds of career goals they might want you to help them with.

The other advice I have for those just starting out as a new manager is to give yourself some time to figure out what the group needs most from you. Whether you’re new to management or new to a team or company, each situation is a little bit different. Some teams need more hands-on help from you, and you’ll find yourself very internally-focused on the day-to-day operations. Other teams may be operating well but need you to help them figure out the future strategy or advocate for the team’s projects with other groups externally. There is no formula to apply, so be flexible and look carefully for where your efforts will be most valuable.

InfoQ: What can tech leads do to create a culture of continuous feedback?

Fournier: Continuous feedback requires some work on the part of the manager. You have to be paying attention to your team in order to see things, and then get into the habit of regularly providing praise and constructive criticism. It helps to know what your people are looking for. What are their goals? What do they want to get better at, or stop doing? Get into the habit of touching on this feedback in your 1-1s, even if it’s a simple “nice work helping James debug that issue”.

You can get your whole team into a habit of continuous feedback by encouraging processes like regular retrospectives. This encourages the team to notice what’s going well and what isn’t going well, and talk about it openly. The easiest thing to start with is handing out kudos when people do things well. Regularly recognizing good work is a simple first step. But retrospectives are not just about what’s going well, and providing room to talk about the things that are less positive is just as important in creating a healthy team.

InfoQ: How can engineering managers balance technical and management tasks?

Fournier: The balance is tough, and it changes as you grow to manage larger teams and organizations. In the beginning, as a tech lead, you are probably still writing code, but if you continue on as a manager you will eventually realize that you don’t have the time to write quality code and push it all the way through to production.

My advice is to make sure that you aren’t holding on to hands-on tasks just because they are the thing you find easy. It’s hard to make the transition to being mostly hands-off, but you do your team a disservice if you neglect your management tasks to focus on writing code. This is the time to practice the essential skill of delegation. You might love the technical details, but you need to train other technical people on the team to manage those details so that you can look at the broader picture. If you really find that you don’t feel ready to give up the technical work yet, then don’t follow the management path yet. It’s better to stay in an individual contributor role until you feel that you have achieved mastery than to jump off too early and wonder what you’re missing.

Finally, you don’t want to completely lose your technical edge. Stay informed by occasionally reading through code and doing code reviews, helping to debug systems that you understand well, asking engineers to give you deep dives on the systems they are writing, or even watching talks and reading blog posts.

InfoQ: You stated in the book that if teams aren’t shipping code or delivering frequently, there's something wrong with the team. How can you find the underlying problems and deal with them?

Fournier: Debugging slow teams can be similar to debugging slow systems. You need to have a sense of the various places you can inspect to figure out what’s going on. Usually, there are pretty obvious causes to the slowness. Too many alerts or incidents that are causing the team to spend a lot of time firefighting. Projects that are unclear or poorly specified, which means that you need to work on making the requirements clearer. Developer tools that don’t work well, slow builds, painful release processes, or other bottlenecks that slow down the act of writing code. All of these are problems that you can tackle by prioritizing work to stabilize the systems, speed up the processes, or improve the specs.

Sometimes though there’s no one obvious cause. In these cases you might need to dig deeper. Are there personality conflicts among team members that are causing tension? Is the team bogged down in a bunch of pointless meetings or bureaucracy? Do they feel like their ideas aren’t being heard and demotivated by a culture that expects them to just churn out code without listening to the team’s feedback on what they could be working on? These challenges take longer to solve. Take the time to talk to team members, sit in their meetings, and get a feel for the group dynamics, and look for ways to change the processes and interactions.

InfoQ: What does it take for tech leads to become a top level manager, e.g. CTO, CIO, or VP of engineering?

Fournier: It can be easy to become a CTO or VP of Engineering- just be the technical co-founder of a successful startup! Of course, getting the title and holding onto it as the team grows are two different things. Whether you get the role by being in the right place at the right time, or by years of climbing the ladder, there are some common skills that successful leaders have to learn.

There’s a lot of factors that are different than being a successful tech lead or engineering manager. For one, you need to communicate with a lot of non-technical people, and that requires the ability to translate technical challenges into a language and format that non-technical leaders can understand. You need to have a sense of the larger business that you are working in, and understand what is important overall to that business, even when it is not purely technical. As a senior leader, your first team is not always the technology organization. Your first team is the other company leaders, and you have to think first about what will make the overall company successful, and only after that do you worry about what the technology organization might need.

However, just because you spend a lot of time thinking about the larger business doesn’t mean you ignore the technical side of things. You may be the person who sets the larger technical standards and culture for the company, and that means understanding what is really important for the technical team to value and making those values and standards clear to the team. You are also going to be the role model for the team. They will look up to you and pay more attention to the things you say and do than you might expect, so you must behave in a way that you want your whole organization to emulate.

About the Book Author

Camille Fournier is the author of the book “The Manager’s Path” published by O’Reilly, as well as the author of O’Reilly’s “Ask the CTO.” She is the former CTO of Rent the Runway, a member of the project management committee for the Apache ZooKeeper project, and a board member for the ACM Queue publication. She serves on the technical oversight committee for the Cloud Native Compute Foundation. She can be found on twitter @skamille, and she blogs occasionally at elidedbranches.com.