My 5 strongest takeaways from The Manager's Path

Let's be real: No one is a great engineer without training. The same applies for managers!

Over the last two years I went from Engineer to Engineering Manager and around the time that I started this journey someone handed me the book „The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change“ by Camille Fournier. I read it cover to cover and found it super valuable with clear summaries and practical stories of an engineering manager’s day to day challenges. It helped me define my new role within the company.

Here are my 5 strongest takeaways:

1. "All Great Tech Leads Know This One Weird Trick" (p. 31)

The first takeaway is about scheduling conflicts of an engineer growing into the role of a tech lead. As engineer your days might have been 100% coding time and so were mine. My new role immediately required me to act as a mix of engineer and manager. I was not prepared for this conflict of tasks. I felt off for a while, and only realized what was going on while reading this part of the book.

My own transition from engineer to manager was a gradual one. I started with a team of one, me. Where before I was 100% on a maker’s schedule, aka writing code, now I had to handle interviews, cautiously plan the sprint (estimating on my own is a nightmare) and have conversations with my self about code quality - all by myself.

After hiring another engineer the necessary shift was to training and teaching, him and myself. But writing code was still the biggest part of my day. Adding an intern and a second engineer restarted rounds of training on all levels. As a result "code work" vanished more and more from my time table, but compared to my new managing tasks this had been work one could see and measure! Am I still being productive? How can I do justice to both aspects of my work without feeling like concentrating on one aspect takes time away from the other?

I have not found a solid answer for me yet. I'm still switching between a maker’s schedule ("code work") and a manager’s schedule (meetings, project planning) all the time.

One thing that worked for me to get structure into this chaos was setting up this daily planning routine:

1. Is anyone experiencing road blocks in their work? What can I do to solve this?
2. Does any project need immediate attention? What work needs to be prioritized?
3. Is time left for coding? Great! I can choose a task that can fit the time that's left.

The "weird trick" is to find a balance and don't look back at days without code as time that wasn't spend productively. There are days with zero code, no ticket has been moved by me and no release went out. And that’s ok, because the team was productive.

2. "Doesn't agile software development get rid of the need for project management?" (p. 35)

Let's talk about project management. Camille lays out that project management is necessary and relevant to get things done in a way that fits the bigger picture. Estimations for those projects help your Product Owner and the other people in the company to fit them onto roadmaps.

The short answer to the above question is: "no". Project management is an integral part of successful software. I picked up smaller project management tasks during my career without even knowing what I was doing. Supporting a Product Owner in sketching out multiple phases of a feature was my starting point. But then suddenly a replacement of a major library has to happen because of reasons. That's a tech heavy project! The only person who could have planned that at the time was me.

Setting up a project has multiple goals. Such as: define timeline and phases, uncover unknowns and conflicts, estimate individual pieces.

The timeline of a project can be roughly described in 5 phases:

1. Break down the work
2. Push through the details and the unknowns
3. Run the project and adjust the plan as you go
4. Use the insights gained in the planning process to manage requirements changes
5. Revisit the details as you get close to completion

Presenting and iterating on the individual steps will help the team and me to understand what’s going on and what the problem we are solving is about. To make sure we run smoothly through this process I need to provide the guidance from a project manager’s standpoint.

Camille provides a handy "Managing a Project" (p. 36) blueprint. I use it all the time!

3. "Decision Point: Stay on the Technical Track or Become a Manager" (p. 40)

This is a career shaping question advancing engineers will ask themselves at one point: "Should I be a manager or keep writing code?" This decision usually results in a branch-off towards a "Tech Lead" or "Engineering Manager" role. The book includes a section on "Imagined Life" vs "Real Life" examples for both roles that help to think through the consequences of that decision.

At first, I didn’t think about this decision at all because my transition was gradual. Given the situation at the company at that time, I was acting as Tech Lead and Project Manager in parallel anyways. But I knew I was comfortable with people and this pointed me to the potential future of my career! Now, as an Engineering Manager, my focus is on the people in my team. If I can ensure they can do their job I’m already multiplying the outcome of my work.

But I, like most of you, still had responsibilities from my past life as an engineer. Your schedule however is full of managing tasks and meetings where you represent your team. Therefore, you will have to ask yourself much more critically if it is a good idea for you to start writing code for that project that you still have on your desk from before you became a manager? Or if it might not be smarter and more sustainable to invest the time to enable someone else from the team to take over the project from you. I found the second option to cause much less delays and frustration but it is - as with everything else - a learning curve.

Of course, I can completely understand someone wanting to be an individual contributor instead of doing „the people stuff“. Such a position might enable you to crack the hard problems in your company, re-architect that one odd service that is barely maintainable or focus on open source work. All those are perfectly valid ideas for a career.

The book helped me to find a clearer understanding of both roles and while my decision was not based on those it helped me define my role and what I feel comfortable with. Today, insights from the book help me discuss these same questions with colleagues and come up with more structured processes in the company to help people evolve.

4. "Good Manager, Bad Manager: The Process Czar" (p. 45)

Let's talk about process. How do you ensure the right piece of work is done at the right time to get software out the door? Camille describes a particular personality that you will encounter during your career. The Process Czar. This persona believes in the one and only right process to get things done.

Engineers love processes - the more complex the better. I’ve got my first introduction into the theory of processes during my studies. Back then it was all about „the waterfall". Turns out it's not really a software development process that leads to good software, as I was soon to find out.

My actual hands-on introduction into software development processes happened on the job. Back then, Scrum was the hot thing and we did it by the book. We did the full setup and stuck to it like a religion. People who where not following the process had to be trained and convinced or they did not have a real change to participate. I was there, I believed in it, I was the Process Czar.

Camille describes the problems strict processes can have and points to the Agile Manifesto. I could not agree more. In recent years I tend to go back to it https://agilemanifesto.org/ and like to challenge any process, including Scrum, that seems overly complicated.

To find the right balance between Scrum or Kanban or any process your team follows and the ideas from the manifesto is not an easy task. Especially if the setup of people and projects is constantly changing. It’s not your task or my task alone. Finding that right process is a team effort.

My biggest take-away from this part of the book is that the process doesn’t matter at all. As long as everyone knows what's going on and how to contribute the name of the process is irrelevant. What counts is that the bug is fixed, or that the new feature is live and you can sleep tonight.

In the end it’s people over processes, working software over documentation, customer collaboration over contracts and responding to change over following a plan.

5. Communicate (p. 47)

"Your productivity is now less important than the productivity of the whole team." Communication overhead is the price paid to enable a bunch of individuals, without the need to drag them into every meeting, or involve them in every email thread so they can be productive.

This short paragraph helped me realize that knowing how to communicate is a skill a successful leader needs to have. As with project management I picked it up on the side. I always enjoyed writing release notes after a particular release went out. Why not? What could be more important than that the changes you made are now finally in production and that feels good and the positive effect is that everyone is updated about relevant changes.

Communication is crucial. But not only in written form. Being able to present your projects and ideas in front of people is important to get your ideas across. Again: "Your productivity is now less important than the productivity of the whole team". And this goes both ways. Representing the team in meetings is as crucial as informing the team or the company about things that are happening. I, as a manager, might spend more time communicating than my colleagues who are not bothered with that and write their code.

Fin!

Those are my strongest takeaways from the book "The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change" written by Camille Fournier.

Is there a conclusion?

Reading the book was a learning experience for me. It contains plain facts and guides for growing managers. But even more than that it was a process that brought me reassurance in regard to my own thoughts and approaches. I feel good about my work and progress at the moment. I got this! Thanks Camille!

What about you?

There are way more good things in there. If you have not read it yet go ahead get your copy and dive in there! You've read the book? What's your strongest takeaway? Let me know what you've learned!