Books for software engineers and managers

Managing Humans

Biting and Humorous Tales of a Software Engineering  Manager

by Michael Lopp, Author of Rands in  Repose

Categories:
Engineering Manager

Your engineering career may dead-end if your own manager is a non-factor within the  organization

To understand your own growth and promotion opportunities, look to your own manager’s ability to navigate the organization.

  1. Does your manager really understand what’s happening politically?
  2. Is your manager involved in the larger organization?
  3. Is your manager respected by their peers?

Or is your manager considered a non-factor? The organization’s view of you can be capped by their view of your manager.

Before laying down a mandate, check your idea against each personality type on your  team

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.

For design and architecture meetings, bring people with both technical ability and a desire to teach because those ideas need to permeate through the  team

Engineering ability isn’t enough for design and architecture meetings. You need engineers who can explain their rationale and persuade others.

When you sense someone is on the edge of quitting, evaluate them through Maslow’s Hierarchy of  Needs

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.

If your engineers aren’t debating how to build software, you have become stagnant and it will trickle into your  product

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.

Engineers don’t hate process, they hate process that can’t defend  itself

There’s a myth that engineers hate process. That viewpoint is too simplistic.

In my experience:

  • Engineers hate process that can’t defend itself
  • Engineers hate process they don’t control

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:

  1. Ask for trust
  2. Do the work yourself to demonstrate you are also impacted by the process
  3. Show progress

If progress doesn’t come, change the process more collaboratively

You need iteration but only progress will silence  critics

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.

Miraculous things happen when nerds can stay in the zone, so managers need to protect the  zone

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.

When you’re delivering bad news, create two meetings: one for review, one for  objectives

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.

Good project managers decrease chaos by increasing  clarity

There’s a three stage process for uncertainty applicable to engineering managers, project managers, and tech leads:

  1. Awareness – Do you even realize there’s chaos and uncertainty?
  2. Vocalize – Do you raise the issue of uncertainty in your 1:1s, retros, or other communication channels?
  3. Action – Are you taking steps to increase clarity?

Good project managers deliver clarity which increases confidence and delivery speed.

Managing Humans

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.