Ask HN: What books can teach me engineering management skills?
I was recently promoted to an engineering management position of a tiny team. I'll be expected to contribute code while we're still small, then gradually fill my hours with more managerial activities as we grow.
I've never managed people, let alone an engineering org. What books can teach me solid principles for maximizing our team's impact? I've read so many horror stories about "We switched to X software development philosophy and it was a disaster: News at 11" I'm wondering if there are classic instructional books/resources that still ring true today, cutting through the latest fads.
Is the Mythical Man Month still a good start for the software/project side of things, for example?
20 comments
[ 4.0 ms ] story [ 65.8 ms ] threadI'll definitely read The Phoenix Project and see if it can better connect the dots for me, thank you.
"The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change"
It's the book I wish I'd had when I was in your position 4-5 years ago.
The book is old, from IBM's heyday but most of the principles have remained unchanged.
One thing you'll find different is that they recommended offices for everyone so that each person could work in a quiet environment where they could focus as opposed to today's open area. I'd argue the open area has it's merits but everyone wears headphones so the current trend may not be all that great. Promoting a team that communicates is the goal, having an open space is merely one way to try and implement that.
Second, First Break All The Rules. Again, not about engineering, but better than most all other books.
And then also of course Mythical MM and PeopleWare. Those are specific to managing engineering projects/people.
Edit: So is MMM.
As a manager, one of the most important things you can do is schedule regular 1 on 1's with the people who report to you. Both "The Manager's Path"[1] and "Behind Closed Doors"[2] stresses this.
In about 4 months, it'll be helpful to review PG's essay, Maker's Schedule, Manager's Schedule[3] Right now, you'll be coding most of your time, but you'll soon have more and more meetings. MSMS names the feeling of frustration around meetings, and describes how to handle so many meetings.
[1] https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...
[2] https://www.amazon.com/Behind-Closed-Doors-Management-Progra...
[3] http://www.paulgraham.com/makersschedule.html
I've read the MSMS essay a few years ago, but had completely forgotten about it. The scheduling problem is actually something I've been struggling with the past few months in the run-up to this new role. When everything is urgent and you're the only one who can fulfill certain data requests, it's difficult to maintain progress on your own projects.
https://www.amazon.com/Essential-Drucker-Druckers-Management...
If you're just starting this new job (and it is a new job) and you're considering 'maximizing the teams impact' it assumes that you'll in be a good manager and be able to run a team at any efficiency at all. Which is putting the cart before the horse.
You need to start from the basics of people management, just start reading everything and anything you can regarding people management, definitely including non-tech people management.
You WILL make mistakes, you will grow massively and you'll find yourself dealing with problems you might not want to; such as a dev team member missing meetings, or you trusting a team member to deliver something and they tell you 5 mins before the deadline that it won't get done (despite them saying it was all going well), or someone asking why they aren't getting promoted as they've been there for years (but you know they aren't quite cutting it). Or someone wanting vacation during a deadline period. Or in yearly pay reviews you have to choose who gets what and you know that that actually affects their lives....all these things can weigh emotionally on you. Or you needing to recommend that someone gets fired. Or how do your organise a morale event for your team which is inclusive as possible given everyone on your team but also people actually like and increases morale/celebrates your team.
Listen to your team, accept that you're learning, use data to guide your process decisions, be open and honest to your team, learn how to communicate up and down, find a mentor. Decisions you make now affect people as well as code.
It's fun and enjoyable, if not a tad stressful (just think that your job is now debugging people rather than code...and people have wayyyyyyy more race conditions....).
But It Is A New Job Not A Promotion :)
The Phoenix project
The goal
High output management
These were insanely good. I actually bought some of these to my three siblings.
I'd recommend these books because these books opened my eyes on how management can really help if done right
For example, are there metrics you're trying to hit, or are you trying to ship as many projects on time?
We have trouble estimating how long projects will take, which seems to roll up into failing to adequately spec or appropriately chunk the projects we take on.
Improving my project management skills and revisiting our processes for how we prepare for a project are both high on my "to figure out" list.
The informal technique of Management By Wandering Around (MBWA) can help. I've used it in projects that I handled. It is known to have been used at HP (Hewlett-Packard), and has been written about in books on management (I read it in one such book, and applied it some), but since it is a somewhat obvious thing (at least in hindsight), it's likely to have been known much before.
The basic idea of MBWA is: instead of only relying on formal reports such as weekly status reports and such, to track / monitor how things are going, and to be able to take corrective action, walk casually, now and then, around the work area of the team (whether cubicles or individual offices for team members, the same concept applies), and chat with them (not all at the same time, maybe one or two at a time), and/or be there a while at their desk and watch what they are doing, for a bit. You can learn a lot about good and bad or potentially not so good things that are going on, with the team's (individual's) work, some of which might not surface via the regular / formal reporting mechanisms.
Worth a try, IMO, and can also be fun, since you get to interact with your team members in more casual settings. In fact, if you observe a team member doing something not quite right, or something that can be improved, telling them about it informally in such a setting, can be taken by the team member in a better spirit, than if given as a lecture or reprimand in a formal one-one-one or team meeting.
Edit:
>and/or be there a while at their desk and watch what they are doing, for a bit.
Of course, you have to do this in the right way. It should not come across as though you are watching over their shoulder as they do their work - anyone would feel uneasy with that. Can do things like talk with them, ask "how is it going?", "having any issues?", ask pertinent questions about some piece of code or some output or test or design point, etc., and offer suggestions for fixes or improvements as appropriate (both on the specific point and any small process or technique that can help avoid such issue in future - good examples (for junior devs) would be the kind of things that are discussed in books like Code Complete.
Update:
https://en.wikipedia.org/wiki/Management_by_wandering_around
Also relevant:
https://en.wikipedia.org/wiki/Gemba
Typo, should be: one-on-one or team meeting
Another book that was recommended for new managers is https://www.amazon.com/gp/product/1118911954/ -
Your First Leadership Job: How Catalyst Leaders Bring Out the Best in Others by Byham and Wellins
Radical Candor by Kim Scott
Not books, but other resources that might be useful:
https://www.tombartel.de/#blog
http://softwareleadweekly.com/ - also comes as a weekly email with links to different articles
https://medium.com/the-year-of-the-looking-glass