The Manager's Path
I recently had a chance to read The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier. I found it insightful and useful to me, so I’d thought I would take down notes on some of the more interesting parts.
For starters, a bit of context might be helpful. I’ve been a software developer (employee #1) at a small software agency since I got out of university. We’ve grown steadily over the years to the point where I now find myself managing a team of four developers plus myself.
My management responsibilities have grown significantly in the last year. I’ve found myself on unfamiliar ground, trying to figure out what I should be doing and how I should be doing it. Software management and software development have very different responsibilities and required skill sets, yet it remains normal that developers get put into management positions with no training whatsoever. And yet I’ve always thought of myself as a developer, and my strengths were always technical.
Frankly, Jeff Atwood tweeted it best:
Got into computers because I enjoyed talking to machines instead of people. Now computers all about talking to people. This is some bullshit— Jeff Atwood (@codinghorror) May 30, 2014
So in the face of uncertainty and a bit of recurring imposter syndrome, I turned to what has basically become my solution to all significant problems: get advice from someone who actually knows stuff, via a book.
The Manager’s Path
The book guides you through a career progression starting from software developer up to a senior technical manager over thousands of people. There’s a section for each point of progression, which the author considers as follows:
- Tech Lead
- Managing People
- Managing a Team
- Managing Multiple Teams
- Managing Managers
- The Big Leagues (Senior manager at a Fortune 500)
It’s a very sensible layout, really - for most people (including me) there will be at least a few sections that aren’t relevant and can be skipped, making it a fairly quick read.
I’ve been doing this for a lot of years now, and I really enjoy mentoring & teaching early-career developers. There was nothing groundbreaking here for me, but it was still useful, if only to give me some confidence that I am doing a decent job and not missing anything critical.
The author describes a Tech Lead as a leadership position, but not a management position. The Tech Lead does spend a lot of time writing code, but also represents the team to management and other parts of the business. This person could handle some of the coordination, organizational, and project management work needed to make a project run smoothly.
One of the key insights for me in this section was how Tech Leads have to learn to find balance between their development work and management work. Some days are spent on a maker’s schedule and others on a manager’s schedule.
I wish I had read this two years ago, because I had some major struggles with this. I found it nearly impossible to get into a zone enough to write some code without interruptions. Eventually I learned how to dedicate significant blocks of time for development. In these blocks I would ignore email, phones, and basically everything non-critical so I could focus on my work, and then schedule meetings & calls in groups rather than spread out throughout the day.
Managing People (or a Team)
I’m currently managing a team of four developers, and this is where I really started to feel out of my depth.
One of the most important insights for me here was that as a manager, you are now responsible for other people’s productivity. In hindsight I kind of understood this already, but the way the author framed it made it obvious in a way that will help me focus on what my priorities should be.
A corollary: the productivity of the people on my team is more important than my own productivity, since I spend less time writing code.
If I’m focused on my team’s productivity, that means I will be:
- Identifying bottlenecks and roadblocks, both current and future, and clearing them so the team can continue building things
- Allowing my team to code for long stretches, trying to avoid interrupting them unnecessarily
- Writing some code myself, but trying to avoid core components of releases that have upcoming deadlines. I can get pulled away from code at any time, so I don’t want to have my team waiting for me to finish my code before they can move on.
These are valuable insights to me because there are endless amounts of work I could be doing, and prioritizing is often difficult. These ideas will help me identify the highest-impact work to focus on.
A few other key responsibilities you pick up when managing a team:
- Lead the delivery of major initiatives - no more small projects for you
- Potentially doing systems design & architecture, depending on your team
- Identify areas of strategic technical debt and make plans for dealing with it
- Work towards generating team cohesion
- One-on-ones, performance reviews, etc
- Saying “no” to upper management when too much is asked of the team
- Maintaining some level of technical capability to retain the respect of the team
Becoming a manager doesn’t just entail gaining responsibility though - you do also drop some. As a senior developer, you’re often looked to as the person with all the answers. You know the code base the best, you’ve been around the longest, etc. I found out quickly that this changes once you start spending more time managing than coding. Pretty soon someone else wrote the key new features, and your team starts using a new web framework that they know better than you.
I’ve found this to be difficult to get used to. I liked being the go-to technical expert, and it’s taken time to learn how to take pride in helping the team be more self-sufficient, rather than relying on me so much. It’s tempting to fear becoming irrelevant once my development skills start fading, and there’s definitely something there to be wary of, but I think I’ll have to keep working on finding a good balance.
Basically, I got exactly what I was hoping for out of this book, and I recommend it wholeheartedly if you have some of the same questions I did. I feel like I have a much better understanding of what I need to be doing in my current role to be effective, and I have a lot less fear that I’m incapable of learning how to deal with these new responsibilities.