As soon as Adrian and I agreed that Management would be the topic of this issue, I knew that I would share the benefits of Camille Fournier’s book, The Manager’s Path. It is the most succinct introduction to software engineering management for both managers and the managed out there.
Plenty has been written on the human aspects of software engineering, and some of it has even been read. Let us leave aside the human-computer interaction topics (design, UX, security etc), which are definitely well-covered. We will look at the other humans: those on our side of the IDE.
The typical names will come out when we list the classics of the humanity of computer programming. Fred Brooks is one such: what is the collection of essays in The Mythical Man-Month other than reflections on the failures of a successful engineering manager? Then there is Jerry Weinberg’s The Psychology of Computer Programming, and Peopleware: Productive Projects and Teams by DeMarco and Lister. Books like Code Complete or Software Craftsmanship: the New Imperative encourage us to reflect on our strengths and limitations as engineers, and of course the multitude of works on running Agile retrospectives and Scrum projects teach us how to walk the delicate balance that is managing a team that believes itself to be self-managing.
But Fournier’s book is the only one I am aware of directly answering the Janus-faced question of how to succeed at managing software engineers, and how to succeed at being managed as a software engineer. It is an important topic; many people know the truism that individual contributors (ICs) quit managers, they do not quit jobs. And most of us who become managers do so from the ranks of engineering, with no formal training and precious little support.
The thing with management is that it requires a completely different worldview than programming. Software is well suited to a positivist paradigm: you can understand how the computer works, and hypothesise that it will react to your stimulation in particular ways. When it does not react as you expect, then you have a problem, and you crack open the debugger. Management, on the other hand, is much more amenable to constructivist analysis: the dialogue between the managers and their reports shapes the mutual understanding of their relationship, but there is no objective “truth” to be determined.
That is why us programmers have such a difficult time when we first become managers. We learn simple rules—have a 1:1 every week; give your reports space on the 1:1 agenda; give praise publicly and criticism privately—and it seems like a simple enough algorithm to run. Then a report wants to move to a different country where we do not have an office, and another report is upset because they only got a great review when they expected an excellent review, and a third report who never brings up anything in 1:1s is pissed off because they were never given space to discuss their issues, and the whole thing goes to shit.
Fournier has been there. She has worked at small companies and large, in IC, middle, and senior management roles. She is not here to refine the algorithm given above, but instead to help us get comfortable with the idea that there is no algorithm, just heuristics. She describes the heuristics that have worked for her, as well as the times when they have not worked.
This book is useful even if you do not plan to be a manager. If you are an engineer and happy that way, then you are probably going to have to interact with managers, and knowing what they are thinking about and what they are trying to achieve will smooth that process. And becoming a more senior engineer means gaining influence, and that means the same skills that the managers are using. It is time to treat the Manager’s Path.
Cover photo by the author.
