
Ask HN: What books can teach me engineering management skills? - Eiriksmal
I was recently promoted to an engineering management position of a tiny team. I&#x27;ll be expected to contribute code while we&#x27;re still small, then gradually fill my hours with more managerial activities as we grow.<p>I&#x27;ve never managed people, let alone an engineering org. What books can teach me solid principles for maximizing our team&#x27;s impact? I&#x27;ve read so many horror stories about &quot;We switched to X software development philosophy and it was a disaster: News at 11&quot; I&#x27;m wondering if there are classic instructional books&#x2F;resources that still ring true today, cutting through the latest fads.<p>Is the Mythical Man Month still a good start for the software&#x2F;project side of things, for example?
======
yoloswagins
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...](https://www.amazon.com/Managers-Path-Leaders-Navigating-
Growth/dp/1491973897)

[2] [https://www.amazon.com/Behind-Closed-Doors-Management-
Progra...](https://www.amazon.com/Behind-Closed-Doors-Management-
Programmers/dp/0976694026)

[3]
[http://www.paulgraham.com/makersschedule.html](http://www.paulgraham.com/makersschedule.html)

~~~
Eiriksmal
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.

------
petervandijck
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.

~~~
vram22
Seconding Peopleware - read it some years ago - it is great.

Edit: So is MMM.

------
throwmeaway32
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 :)

~~~
Eiriksmal
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.

This is critical to keep in mind, thank you.

------
xq3000
Pragmatic Programmers have a few titles on that: Behind Closed Doors, Manage
It!, and Ship It!. They are all pretty good.

------
wincen
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.

------
lwlml
Kim, Behr and Stafford's "The Phoenix Project" isn't half-a-bad start. Follow
it up with everything referenced.

~~~
Eiriksmal
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.

------
garethsprice
Just read this, highly recommend it:
[http://shop.oreilly.com/product/0636920056843.do](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.

------
nkzednan
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/](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](https://www.tombartel.de/#blog)

[http://softwareleadweekly.com/](http://softwareleadweekly.com/) \- also comes
as a weekly email with links to different articles

[https://medium.com/the-year-of-the-looking-glass](https://medium.com/the-
year-of-the-looking-glass)

------
jbms
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-
Essentials/dp/0061345016)

------
vram22
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](https://en.wikipedia.org/wiki/Management_by_wandering_around)

Also relevant:

[https://en.wikipedia.org/wiki/Gemba](https://en.wikipedia.org/wiki/Gemba)

~~~
vram22
>one-one-one or team meeting

Typo, should be: one- _on_ -one or team meeting

------
jennyp
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...](http://randsinrepose.com/archives/the-update-the-vent-and-the-
disaster/)

------
kevindeasis
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

------
steverb
Lots of great suggestions. I'd add Leading Snowflakes:
[http://leadingsnowflakes.com/](http://leadingsnowflakes.com/)

------
blooberr
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?

~~~
Eiriksmal
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.

