Michael Lopp, The Art of Leadership: Small Things, Done Well (Book Review)
I'm a big fan of Michael Lopp and this book extends the utility I found from his earlier book Managing Humans: Biting and Humorous Tales of a Software Engineering Manager. There's a lot here about being an effective leader that I think I do pretty intuitively, but I can backslide, so I obtain high value from a reading session with Lopp's books.
This one is a little unusual in that the essays are divided into three categories:
- Manager
- Director
- Executive
As the book moves along, the guidance becomes more nuanced and abstract following the increasing responsibilities of these roles.
One thing I would recommend as you read: When you like a chapter, put a check by it in the table of contents. Then when you're done with the book, reflect on which chapters got the check. My bet is that the checks will cluster where you need to do the most work in terms of responsibility. For instance, if you're an executive but all of your checks are in the "Manager" section, it may suggest that you've lost some of your baseline tactics with the people who report to you (the basic stuff like privileging 1:1's should never go away).
A few beauties from the book:
Pp. 134ff: Good guidance on describing emergent situations in writing and then socializing to increasingly wider circles in the company.
Chapter 24 ("How to Build a Rumor") - The perils of groupthink, and how to mitigate the risk.
Pp. 119-121. Everyone must lead. "There are many good reasons for an engineer to want to move into management but if their only reason is the perception that management is the best place to grow as a leader, then the leadership team has created the perception that leadership is not the job of individuals. This is a disaster" (p. 119).
Chapter 20 ("The Guard") - The culture split between the old-timers and new hires. This is especially a thing in startups. Read Lopp on the trust burden between these groups.
P. 101. Innovation bias. Let's say your company needs an agile process or a "ladder" for engineering roles, and you have something from a prior gig. Lopp says: Use it, and don't try to build something from scratch again. You just don't have time. I agree with this fully and think organizations that do their own design of such things might be better off adopting something "off the shelf" and then modifying it as needed.
Chapter 12 ("How to Recruit"). Apparently some engineering organizations don't know the basics. Lopp tells you.
About my only concerns about this book are: (1) That it's so engineering-focused. Lopp's counsel is generally useful but I think he stays in his comfort zone with the nerds maybe too much. And, (2): In Lopp's world, it seems that reports always work for the person tom whom they report. I have noticed in agile organizations that the "work" may be organized by product owners and scrum masters, but reporting will be up through a different hierarchy. The split between the work and the reporting has a lot of benefits and also perils: I'd be curious to learn what Lopp thinks of that.
Originally reviewed on Goodreads on 26 May 2021.
Comments