Reading The Manager's Path as a map
Camille Fournier's book lays management out role by role. I keep wanting to read it as a house with rooms, not a staircase.
The Manager’s Path by Camille Fournier came out in March, and by now it seems to be the book everyone hands an engineer who has just been asked to “take on a few people.” I’ve read it twice. I’ll probably read it again, though not all of it, and that’s sort of what I want to talk about.
He covers job roles in order of what you’ll likely encounter. Getting managed. Mentoring. Tech leading. Managing people. Managing teams. Managing teams of teams. Managing managers. Floating away in the nothingness of VP and CTO. There’s a wrap-up chapter on culture and process. At the end of each chapter are questions to ponder regarding yourself. It’s like a field guide you’d put in your jacket pocket and pull out when you see a bird. (Mostly meetings are the birds.)
I like that it starts with the best thing about it. Before you’re managing anything, Fournier covers how to get managed well. How one-on-one’s should be. How to request feedback. How to be proactive in your development rather than passively wait for your growth to show up in the mail. So many management books just dive right into ‘and now you’re in charge’. It’s nice to begin with the other end of the deal. It’s difficult to expect others to meet a standard you didn’t ask for.
I keep coming back to the tech leading chapter. It covers it as a real job and having skills for that job. Not just waiting in a lobby for your title of manager to be announced. About how to break down a project. About how to do some hands-on but less hands-on in other ways. At some point, how to decide what type of lean you’ll be. I think a lot of senior engineers would find this chapter really useful and they could just close the book after this part.
There are short sketches of manager traits scattered through. The engineer that has to be the smartest guy in the room. The tech leader that tries to solve every problem with a new process. The avoidant one. The ‘yes-man’. The one that has a ‘us vs them’ story about the rest of the company. These are the things people quote to each other. Sometimes with an important look. I’d argue to use them as a mirror. It’s handy to see yourself in one. Mostly just satisfying to see your co-worker in one.
And then there’s the aspect of diagnosing a team like you’re diagnosing a system, and I love this. If your team is moving slowly, consider the mundane sources of slowness like vague requirements or buggy tools or constant interruptions or some latent disagreement that nobody’s voiced yet. This helps prevent you from prematurely assuming the problem is a person instead of the infrastructure supporting them.
And then the thing I keep coming back to. Because it’s sequential, the outline gives a bit of a stair step, and up there at the top is the CTO with a lanyard. I don’t think it’s intentional from Fournier. And she does mention the technical stuff. But I wish the book had been a bit louder about “you should just stay here.” There’re lots of people who ought to be comfortable and skillful in the first three chapters forever or at least a long time.
The subsequent chapters are short. That’s the right move. These roles are rarer, and they’re huge. They’re more about orientation than instruction. And that’s fine. The new manager shouldn’t really be learning about the CTO role. It’s like learning about aircraft carriers in preparation for a driver’s test.
And it can’t help you with the hard parts. “Give feedback continually” is true, and it’s also the sort of thing a new manager will stare at the ceiling over. It’s more like examples of good, rather than tips for bumbling toward it. I don’t know if any book can do more. You can’t hire someone to sit through your first clumsy one-on-one.
So it’s sort of a floor plan. Here’s my room. Here’s the one next door. Here’s the rest. Neatly tucked away till next year, when the house may change anyway.