How strongly do I recommend Managing Humans?
8 / 10
Imagine you are a pissed off employee with a dumb manager. Now write a book about engineering management and title it Managing Humans.
This book is snarky but also pragmatic, standing out among more positive and lofty management books.
Truth be told, the negativity in Managing Humans makes it difficult to read and there’s plenty to disagree with. But I still recommend this book because the author provides so many nuggets of cold hard truth about managing software engineering teams.
Top Ideas in This Book
To understand your own growth and promotion opportunities, look to your own manager’s ability to navigate the organization.
Or is your manager considered a non-factor? The organization’s view of you can be capped by their view of your manager.
Good stakeholder management requires communication both upward and downward.
When you’re considering a mandate or change in policy, vet your idea against each different personality type on your team. If your team is small, go one step further and vet the idea with each person individually.
In an ideal situation, your announcement feels like old news and each person on your team feels like they’re an insider.
Engineering ability isn’t enough for design and architecture meetings. You need engineers who can explain their rationale and persuade others.
Use your 1:1s to identify when someone is struggling. Engineers usually won’t tell you directly when things are going south, so you need to look for clues.
That’s where Maslow comes in. Defensive and combative behavior rooted in fear is probably the easiest to identify and understand through Maslow’s hierarchy.
Here’s a point engineering managers forget under the pressure of deadlines and delivery schedules: Getting better at the work is as important as the work itself.
Part of improvement includes debating the best way to actually perform the work.
Be careful though, there’s a big difference between productive debating within a healthy team and unproductive debating among a frustrated team.
There’s a myth that engineers hate process. That viewpoint is too simplistic.
In my experience:
When you’re trying to transform a low performing team into a high performing team, you will be tempted to create process yourself. Instead you should consider turning over ownership to the people doing the work, those that are most impacted by the process.
They are in the best position to decide what processes make sense and which don’t.
However, there is a caveat. Sometimes you do actually know better because you’ve done the work yourself and you have a vision. If that’s the case, your jobs are:
If progress doesn’t come, change the process more collaboratively
Avoid the trap of talking about iteration with your critics. They don’t care about deployment frequency. They only care about progress.
At first progress will feel like decreased lead time. Going from 3 months to build that feature down to 3 weeks. After lead times drop, the definition of progress will shift.
Now progress means sales, user counts, or some other business-level metric. Fortunately for you, those are higher level problems and hopefully you’re getting a raise.
The hard part about managing software and IT teams is that nobody cares about success, they only care about failure. Your service had 99.999% uptime? Who cares, that’s the expectation! But when product stops shipping or systems go down, that’s when heads roll and the consultants get brought in.
Here’s a good recurring question for your 1:1s with engineers:
Recently, rate your ability to stay in the zone
When your engineers have trouble staying in the zone, focus on fixing the environment. Kill meetings, fix process, improve systems.
Bad news throws people into a defensive, argumentative, or disengaged mental state.
Although you’re ready to look for solutions, the recipient isn’t ready. That’s why you need two meetings.
In the first meeting, tell them your goal today is just to review and talk through the issues, not arrive at any conclusions or solutions.
Many recipients of bad news will take that gap between meetings to figure out a solution path themselves, even if you don’t explicitly require it.
There’s a three stage process for uncertainty applicable to engineering managers, project managers, and tech leads:
Good project managers deliver clarity which increases confidence and delivery speed.