Fournier, The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change (Book Review) by jgn on Saturday, September 2, 2017 in Reading, Reviews, and Technology

Camille Fournier's book The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change is a wonderful guide to understanding the different roles and processes in engineering leadership. If you're in an engineering organization and have wondered about the distribution of responsibility, how and why different people do different things, and how to set up or change your organization: Read it. Some people may want to read this book because it delves into questions such as "what is a tech lead?" (Chapter 3) and "what is the difference between a CTO and a VP of Engineering?" (much of Chapter 8) -- these sections are good for asking questions, but the variety of engineering organizations makes the specific recommendations hard to operationalize. So what I like about this book is more the expanse of its map, rather than the specific terrain. I have some reservations which I'll get to in a few moments, but there are some real gems here. In particular:

Throughout the book, Fournier alludes to her own personality and challenges: I wish there had been even more of this, because I found her momentary confessions quite engaging. We learn pretty early on that she engaged a professional coach (p. 125); coaching is not for everyone, but learning more about this in a concentrated way would be useful (I'd like to note additionally that there's a story around how coaching can be abused; maybe she hasn't seen that). Later on we find that she "lost [her] voice repeatedly during my first few months managing multiple teams" (p. 107); Wow--I'd be curious to hear her war stories (no doubt they are not suitable for publication).

But I have some concerns around how the book talks about work delivery, the role of hiring, and the basic premise that you, the reader, have to fix things up by yourself. I don't want to offer these as criticisms as much as thinking through matters of emphasis and possibilities for more counsel.

Organizing work delivery

My first concern is that the book has a bit of a split personality around technical methodology and work planning.

On the one hand, it would seem that Fournier is in the "agile" camp. In her Chapter 6 on "Managing Multiple Teams," she pretty much berates the reader to release code frequently (p. 115), write tests ("I find that engineers who don't write tests often have a hard time breaking down their work"; p. 117), and check in code frequently (ibid.). All of these practices are about reducing batch size and continuous delivery -- things we know about from twenty-five years of agile development and extreme programming. Meanwhile, later on, there is good stuff about depersonalizing code reviews (pp. 213-214). And there is a great section on organizing your delivery teams as cross-functional groups (pp. 208-211): "The cross-functional team worked as a group to design and delivery the feature . . . the contributors all felt that they understood the goals of the project" (p. 209). This is basically Scrum; her discussion comes very close to suggesting that the team is self-organizing. I think this is what Fournier likes, and it would seem that especially recently her teams have been productive working this way (in contrast, she alludes to having worked in Finance with very critical colleagues, while her present is more functional and agreeable).

And yet: there is a rather long section on traditional project management (pp. 34-39), espousing dependency analysis (suggesting "a spreadsheet, or a Gantt chart, or whatever works for you"). I almost wanted to cry when I read this. I can't think of the last time I saw an effective engineering organization deliver the right thing quickly using detailed resource and time planning. Tied to this is an idea that managers own things as individuals: "Jane has given her tech lead Sanjay a big project to manager"; "Sharell has given Beth her first big project to run" (57). I am not sure that the emphasis on hierarchy here fits high-performing engineering organizations any more. A useful distinction might be to stress that while responsibility might be hierarchical, delivery doesn't have to be, at least not all the way down. Another way to get at this might be to better describe management roles that are more strategically-oriented, rather than about delivery. Some highly effective companies practice "holocracy" (Zappos; Valve): so I think the kind of hierarchical engineering management assumed here may need some leavening by other patterns.

Of course a book can only do so much. I think that the catch here is that Fournier felt that to write a book about the "manager's path" requires some accounting of project management. And yet, the book has a strong undertow of the author feeling that agile is the way to go. So I would say: Put the traditional project management discussion into an appendix, and be forthright about what, in the author's experience, actually works. There are apologies in the book, e.g., "I want to make clear that I'm not suggesting that you go into waterfall" (p. 93); "I'm not going to advocate for any particular software development methodology" (p. 117). Please. Go for it.

Another oddity about the book is that sometimes the tone suggests that shit just happens, and you have to accommodate. For instance: "Crunch periods will happen" (p. 81). What's funny here is that elsewhere in the book, Fournier is quite eloquent on creating a culture where this shouldn't happen -- by intention and design:

Go home! And stop emailing people at all hours of the night and all hours of the weekend! Forcing yourself to disengage is essential for your mental health, believe me. Burnout is a real problem in the American workforce these days, and almost everyone I know who has worked sustained excess hours has experienced it to some degree. It's terrible for individuals, terrible for their families, and terrible for teams. But this isn't just about preventing your own burnout--it's about preventing your team's burnout. When you work later than everyone else, when you send those emails at all hours, even if you don't expect your team to respond to those emails or work those hours, they see you doing it and think it's important. And that overwork makes them less effective, especially at the detailed knowledge work that engineers need to perform. (p. 122).

I read this as saying that good management and good managers design crunch periods out of the system. What provoked this rant from Fournier? It's because of questions managers ask: "when managers ask whether something can be done faster, what they explicitly or implicitly want to know is whether the team can work harder or longer hours to delivery it in fewer days" (p. 122). Her immediate answer is to "encourage you to develop and show the value of laziness [i.e., getting your software and process to work for you]" (ibid.), but I don't think this line of argument is going to work with non-technical bosses and peers. There's a nice bit in the book called "Ask the CTO: I have a Nontechnical Boss," followed by some guidance on "Senior Peers in Other Functions" (pp. 176-180); if there's a second edition of the book, I'd like to see this expanded to a chapter and include a discussion of how to advocate for the "right thing" for engineering. In my experience over the last twenty years with many non-technical bosses, I have found that training them is a big deal and quite an adventure.

Hiring

I have already mentioned an occasion where the book concedes that shit happens. Of course it does. One of the best ways to keep shit from happening is to hire the right people, fire the misfits, and get great at onboarding. Hiring is here rather an incidental topic (discussed in Chapters 2, 4, 6, 7, 8). The book would benefit by breaking all of the observations about hiring out into a separate chapter. For example, in the chapter on "Managing a Team," we learn that the "best way to avoid brilliant jerk syndrome is to simply not hire one" (p. 91). Right, but . . . there's so much that goes with this. Another reason to emphasize hiring in its own place is that Fournier is quite good on the perils of hiring friends of friends, which can reduce diversity, and, in the worst cases, be discriminatory (p. 202).

The "aloneness" of the audience

This is going to be a hard thing for me to capture, but I was struck by how this book speaks to an audience of one, namely, the individual who is traversing the hierarchy. Here's an example about coaching: "continuous feedback works best when you, as a manager, pair that feedback with coaching . . . there will be times when you don't have either the qualifications or the capability to provide the coaching that everyone on your team needs" (emphasis added; p. 63). This worries me. This is in Chapter 4, "Managing People," but I am not sure that an individual self-consciously inventing and providing coaching is something that an individual should take on herself. I.e., I suspect that the coaching role/aspect really needs to be programmatically designed into the engineering structure, so that at every level, people know that coaching exists, that it has a pattern, and that in some cases the individual requires coaching from someone other than the manager. One reason that patterns around coaching need to be developed programmatically is that managers should get credit for it. Self-initiated investments of management techniques can backfire when they are reported during a self-review, and one's own manager wonders why this was done. Another example: "your new manager can be shockingly clueless as to even the basics" of running 1:1s and similar things (p. 136). Yes, this is true, but I wonder if this is for "you" to accommodate, or if it means that you need to get a job where there's a more coherent plan for training managers. Thus, every time I read these counsels to the-reader-as-individual I realize that the critical audience is really not the mid-level manager, but engineering leadership. Leaders should be establishing coaching patterns. If you as an individual have to work up your own ideas of coaching, I would worry that they would diverge from what the culture of the organization needs. Coaching's a specific case, but my more general point is this: Every time the book tells the individual how to fix something up, I wonder to what extent such a problem deserves an organizational solution and needs to be addressed formally. It may be that the orientation to the individual sufferer is semi-autobiographical: In the conclusion Fournier tells us that "The most important lesson I've learned is that you have to be able to manage yourself" and that "For me, having a meditation practice has been essential to developing self-management and self-awareness" (p. 217). These are great points. I almost wish the book split the story of "you" from the story of getting engineering organized properly.

comments powered by Disqus