Recently an engineer who is in the process of being promoted asked me what book recommendations I had to help them skill up for the new role. I asked for a bit more context and learned that they'll be leading a small product team and will be reporting directly to the CEO. Below is pretty close to what I sent them in the hope it will be useful to others on the same journey.
The reason I asked about your context as while the first couple of books I recommend for new mangers are always the same, after beyond that there are quite a few forks in the road. The kinds of issues a new engineering manager at the top of product company's team are totally different to the freshly promoted tech lead within an existing management structure.
Luckily the first situation, and yours, is exactly the one I was in at the early days of Envato and I largely self-taught my way though with a lot of reading. I'll list about five I reckon are good to build the fundamentals, in the order I think they should be read.
It's really easy to overload on information and get a bit stuck between all the conflicting ideas. So I'd recommend reading the essentials and then put your effort into deliberate practice with the new ideas you've just put into your toolbox. In Engineering Management: The Pendulum or The Ladder Charity suggests there's about a two year shakedown period to go through as a new manager and that aligns with my experience (both personally and coaching new tech leads).
After these the recommendations get really contextual again, it'll vary on your personal ambitions and desires, whatever the current challenges of your company is, and the different strengths and weaknesses of your team around you.
So onto the list.
This book's relatively new, having only come out in 2017 but it's my new top recommendation for engineers at any level of their career. It does a really good job of explaining the different rungs of the ladder and full of useful tips at each point. Well worth reading cover to cover even if you're on the first couple of rungs as the look forward into the higher roles is really helpful.
This is where I used to recommend Clean Code to people but I've stopped doing that for a couple of reasons. The first is that he's kind of an ass. The second is that the early chapters focus too much on line-by-line conformist pedantry that's been a strong precursor to our current "over-linted and under-thought" code style culture.
This is largely your choice and a matter of taste. Which book it is you read matters less than having a book, knowing it back to front and working through it with your team (maybe via a book club).
Some solid contenders:
I find it a lot easier and a lot more time effective to coach a diverse bunch of engineers when I have a stable (and external to the team) standard to point towards.
Getting everyone on a consistent vocabulary for talking tech will make it easier for you to dip in and out of technical discussions because the rules of the game stabilise. When you bring a new junior on you can quickly identify areas they need to improve on and either assign them book reading, or delegate their coaching with a "Hey so-and-so, can you give the new dev a hand wrapping their head around named concept X and how we apply it here".
If you've got a really idiosyncratic personal or house technical style, you're really going to struggle to get the leverage on your time you need to improve on all the other personal skills you've got to level up.
The gold standard for management books. Nearly 40 years old but covers all the essentials. How to think about your job as a manager. How to do a performance review. How to run 1:1s. Why you should invest heavily in training. All good stuff.
I also feel really comforted knowing that the core ideas of good management are pretty stable and written down a long time ago. Makes me feel like if I'm really struggling someone will have written something useful down somewhere.
Hard conversations are bread and butter for management. For those of us with technical backgrounds it's not amazingly common to have a built in toolkit for handling them. This book is super helpful for improving in that area. If you're already feeling some pain around tough conversations, maybe you've already got an underperformer on your team or a cross-departmental issue, you should definitely pull this one to the front of the queue.
This one sounds lame but you should definitely make time for it (or something similar).
I think about finance reporting literacy the same way I think about Java. I can't write a Java program the same way I can't do financial forecasting, but it's super important to be able to read and talk generally using their concepts.
It'll help you understand your business better and the way in which your boss makes decisions.
I hope that was helpful. If you (the reader) want me to answer any other questions about engineering management feel free to ask on the Hecate twitter account or email your question in to [email protected].