Ask HN: What books can teach me engineering management skills?
20 comments
Managing engineers is a new career, that is separate from being an Engineer. Many engineering skills don't transfer to management, even when you think they do.
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
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
Thanks for these. I've got Behind Closed Doors on order from a previous recommendation in this thread, but The Manager's Path appears to be especially apt!
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.
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.
High Output Management, by Andy Grove. It's not specific to engineering management, but still rocks.
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.
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.
Seconding Peopleware - read it some years ago - it is great.
Edit: So is MMM.
Edit: So is MMM.
You shouldn't really be getting 'promoted' from engineer to engineer management. I know it always happens but it shouldn't, being a good engineer does not mean they'll be a good people manager.
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 :)
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 :)
Thanks for this. You're absolutely right, of course, this is A New Job, not a slight re-spin of the old position.
Decisions you make now affect people as well as code.Pragmatic Programmers have a few titles on that: Behind Closed Doors, Manage It!, and Ship It!. They are all pretty good.
Peopleware by Tom DeMarco and Timothy Lister
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.
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.
Kim, Behr and Stafford's "The Phoenix Project" isn't half-a-bad start. Follow it up with everything referenced.
Interesting! I've read The Goal before and found it fascinating, but difficult to tie some of the prescriptions to our roles, in particular. It encouraged me to view more of, well, the goal of the company and how we're a machine that processes raw materials (sales leads) and turns it into profit, as well as the different drop offs in the funnel (conversion rate, failure to collect, etc.)
I'll definitely read The Phoenix Project and see if it can better connect the dots for me, thank you.
I'll definitely read The Phoenix Project and see if it can better connect the dots for me, thank you.
Just read this, highly recommend it: http://shop.oreilly.com/product/0636920056843.do
"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 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.
Check out Managing Humans by Michael Lopp. Or, as @jennyp mentioned, check out his blog - rands in repose. His book is basically a collection of blog posts.
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
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
The Essential Drucker: The Best of Sixty Years of Peter Drucker's Essential Writings on Management
https://www.amazon.com/Essential-Drucker-Druckers-Management...
https://www.amazon.com/Essential-Drucker-Druckers-Management...
My 2c (as a developer who has done some engineering / project management earlier, in companies):
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
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
>one-one-one or team meeting
Typo, should be: one-on-one or team meeting
Typo, should be: one-on-one or team meeting
rands has some good stuff on management, I liked this one in particular on 1:1s http://randsinrepose.com/archives/the-update-the-vent-and-th...
I'm reading some of the books here in the comments. Last two weeks I finished the books:
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
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
Lots of great suggestions. I'd add Leading Snowflakes: http://leadingsnowflakes.com/
Anything specific you want to accomplish for maximum team impact?
For example, are there metrics you're trying to hit, or are you trying to ship as many projects on time?
For example, are there metrics you're trying to hit, or are you trying to ship as many projects on time?
Great question. Mostly the latter. We are using GitPrime to track some basic metrics, but don't have anything structured that we're tracking outside of their measurements.
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.
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.
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?