Managing Humans

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.

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:

• 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

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:

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.