Review: "Become an effective software engineering manager"
While exploring my own practice and professional development, the book "Become an effective software engineering manager" popped up on my reading list.
This post is a review of the book. I found it contained useful insights and practical hints, but also some notable caveats.
The Gems
Before listing the caveats, I picked up a few gems that made the book worth reading. Sometimes they echoed my own experience strongly; other times they offered an interesting twist on common advice.
My favorite insights are: - a collaborative team can outperform an "all-star" team - a lead or manager, when recruiting, should refrain from only looking for people like them - part of the manager's role is to ensure teammates develop themselves (via time for self-development or "proximal development" tasks) - a manager should share with their team/reports their own actions and findings
I've been fortunate enough to witness many of the benefits of these four points, and I've seen peers who are in disbelief of at least some of them. If you take only a small set of ideas from this review or the book, these four are a good place to start.
I also found the advice about one-to-one meetings insightful. A few of the author's points: - these meetings should be about the report, not the manager - you should get them talking more than you talk
In addition, the author lists a few practical tips to make one-to-ones productive: - use leading/open questions - talk about architecture - deep-dive into a process - do some mentoring/teaching - share department direction - collect feedback - share relevant facts and documents
I found it peculiar that providing feedback — one of the most common recommendations in management training — did not appear in this short list. It seems the author treats feedback as part of a different process (or a different time), explored in the performance-review section of the book.
One thing stands out: this is a good list of tips to make every one-to-one meeting count and ensure you do not waste the other person's time.
Lastly, the author reminds managers that their outcomes and success largely come from their team's outcomes and success, which requires them to: - be a role model - collect and share information - ensure decisions are made (and make them when relevant) - nudge in the right direction
He also offers an important reminder that managers should not become addicted to reacting to every input. They should carve out time for focused work. From my experience, the risk of constant reactivity is real, and any means to regain control of your time are worth pursuing.
The weird parts
I was less comfortable with some approaches and phrasings used to introduce a few topics. Here are the main issues.
The book introduces management by building an analogy with programming. That analogy is a trigger for me because I've seen the "programming" mindset in people management go sideways. Many things do not work with people as they do with machines; a common running gag is the software-developer-turned-manager who tries to parallelize work across the team like CPU cores. I wish our industry would move past this analogy and treat software engineers more like knowledge workers; closer to small scientific communities that experiment and peer-review their findings.
Relatedly, the book frequently uses the term "output." The author is not doing anything inherently wrong with the term, but it leans toward machine-like throughput. I prefer focusing on "outcomes," which emphasize the consequences and value of the work.
One last caveat is the reference to Maslow's hierarchy of needs. As far as I know that model has been abandonned by psychology studies decades ago. Although the author draws a reasonable conclusion about self-fulfillment being a basic need — largely contradictory what is typically presented in Maslow's pyarmid — I'm thinking we'd be better off leaving this concept to the past.
Overall, these "weird parts" felt like attempts to shoehorn valid concepts and advice into metaphors that might appeal to a traditional software-engineering audience. That may help some readers, but it could put off others who come from different backgrounds.
To read or not to read
I would label this book "recommended with caveats". It's an interesting and insightful read, but readers should be cautious about some of the conceptual foundations the author uses. If you focus on the practical advice and recommended actions, though, it's worth a try.
