I’m not in a management position, myself, but lately I’ve been taking the lead in more and more initiatives. Nearly all of my existing experience being from the perspective of an individual contributor, so I had never really given much thought to what’s actually involved when moving beyond that stage.

With that in mind, I found the following three books to be quite helpful:

• Managing Humans: Biting and Humorous Tales of a Software Engineering Manager by Michael Lopp
• Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams by Mickey W. Mantle and Ron Lichty
• The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier

Managing Humans touched on a lot of topics I found quite good, especially about the importance of one-on-one’s and giving useful feedback. It grazed the surface of a lot of topics and was a tad repetitive at times, but I overlooked a lot of that once I realized (about a third of the way through) that the author was actually the author of the Rands In Repose blog, which I was a big fan of early in my career.

The Manager’s Path seems better suited for those higher up the ladder, so a lot of the content was a bit dense and way too out of scope for me… Once you reach the stage of being a manager who manage other managers, that’s just way too meta for me….

Managing the Unmanageable felt like it was somewhere between the two, as far as content and style. It didn’t feel as personalized as Lopp’s book but the writing was less distance than the one by Fournier.

Once I was done with all three, they had all sort of blended together for me. I am very glad that all of my bookmarked pages and highlighted text were saved on my Kindle for later browsing!

At this point, I still not sure being a ‘Manager’ is really my thing… but at least now I do have a bit more respect for people who do take on those roles and what they have to deal with.

One topic I did really like seeing come up in my reading was how important it is for a technical lead to continue contributing. Leads should contribute a lot less than before, but it’s still necessary. It helps keep them in touch with the code base, so it’s easier to understand the pain-points in the code. Not to mention while the lead focuses on provide an extra helping hand for squashing gnarly bugs or tackling mundane changes, the core contributors on the team can stay focused on implementing all of those new shiny features that keep them interested and engaged… I dig it.