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:
Chapter 1, "Management 101." This is not really about "management" in a tech organization, but rather an explanation of what to expect from your manager, and, basically, how to behave so as to get the most out of your manager. The chapter has very little in it that is engineering-specific: Its audience is people who work on projects. I think for most anyone, especially those starting out on their first professional jobs, this chapter is a significant step up: By knowing something about the psychology of the manager/managed-person relationship, one becomes empowered. There is a lot I can do for my reports, and I often suggest things, but it is far better for the employee to have some understand of how one's manager can be leveraged. I took a peek at the publisher's page for this book, and I must say that this chapter should be a free download: It might be a good one to hand out to undergrads who are poised for their first professional positions.
Chapter 7, "Managing Managers." The reason this chapter is so critical is because it touches something very mysterious, namely, how to be involved with the entire management hierarchy, where you are perched in the higher realms. Fournier advises "Skip-Level Meetings" (pp. 128-131) where you take the time to talk to people who report to people who report to you. She tells us that needs to be done with some care, because there are ways to upset just about everyone if you are perceived to be spying on your own reports. The chapter also touches on being too much of a people-pleaser: this is an occupational hazard that needs to be guarded against and trained out of people.
Chapter 9, "Bootstrapping Culture." Here Fournier talks about the transition from the lack of structure which is endemic to many early-stage startups, to more structured/hierarchical organizations. I wouldn't recommend reading this for the particular bits of advice, but rather to get a map of the problems one will encounter regarding structure. There is a solid discussion of how you create a promotions ladder for engineers and engineering managers: I know this is good because I recently participated in constructing one of these; I wish I had read her book beforehand. To Fournier's credit, she notes that her first attempt at this was a failure, and it was only after distributing some of the work to experienced team members that she could get a ladder that was clear, acceptable to the team, and actionable. My company's culture would never tolerate an individual creating such a ladder, so we tapped the experience of senior engineers: Still, the main points here are quite valid.
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.
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.
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).
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