jeremy.marzhillstudios.com/content/engineering-managment-is-hard.md

+++
title = "Engineering Management is Hard"
date = 2020-04-19
[taxonomies]
tags = [
    "teams",
    "management",
    "culture",
]
+++

# Learning to be a manager

Some time ago I took on a Management role at work. This is a role that, seven
ago, I swore I never wanted, but life experience has a way of changing how you
feel about certain things. Before joining this company I experienced one of the
most incompetent engineering managers I've ever worked with. I've had some
sub-par experiences but never true incompetence. I realized that I needed a
better understanding of what an engineering manager should do. I needed some
survival skills and the best way to do that is to learn by doing. If I got a
chance to experience some of that in future roles I decided I would take the
opportunity. So here I am with a role that is 80% managment and 20% technical
contribution. In theory I think it was intended to be 50/50 but reality differs
quite a bit.

**Engineering Management is _hard_**

I don't think I realized just how hard managing people is until I experienced
it for myself. Some of the problems are fundamentally unsolvable. The most you
can hope for is to mitigate the fallout. You can't just hack your way around
people problems and management has a considerable amount of people problems to
solve. I've been learning a lot in my on-the-job training experiment, and I'd
like to talk about what I've learned.

# Communication

**You are a conduit between the business and the engineering team**

In many ways being an engineering manager is about being a translator. You are
a conduit between the needs of the business and the capabilities of the
engineering team. Walking a fine line between what the business needs to stay
in business and what it takes to create scalable technology is not an easy
task. You have to tell both sides no sometimes. I've learned that honesty,
transparency, and tact are the among the most important attributes of a good
manager.

## Honesty

It's important not to promise what you can't deliver for either side. Don't lie
to your engineers about when and how you'll be able to tackle technical debt.
Don't promise procedural changes that you can't realistically deliver. Be
honest about what you are empowered to accomplish. Be realistic about the
capabilities of the team to the business. Don't oversell and don't undersell.
If you lose the trust of either side you'll be ineffective in your role.

**People appreciate it when you are honest about your failings**

Come clean when you mess up. You aren't any more perfect than the next guy.
Sometimes you'll drop something on the floor. When it happens acknowledge your
mistake and work to address it. People appreciate when you are honest about
your failings and diligent in addressing them. It gives them faith that you
will be honest with them and they can trust you.

Being transparent when you can and being forthright about when you can't be
transparent are important. Everyone like to understand the reason for decisions
they don't like. If they are able to put those decisions in context it goes a
long way toward calming them and helps them to see whether there is a light at
the end of the tunnel. They understand that you can't always share everything
with them but they appreciate when you are honest about that handicap.

## Tact

Being honest doesn't imply you need to be harsh. It's possible to deliver the
truth without triggering an unnecessarily negative emotional response. Your
goal should be to ensure that any emotional response is derived from the
factual content of your communication and not the method of delivery. This can
be harder than it sounds. Trying to eliminate any emotion from your delivery
can be just as bad as including negative emotion.

**I have found that focusing on empathy is helpful**

I have found that focusing on empathy is helpful. Try to understand how your
audience is going to percieve the news you need to deliver. It goes a long way
when it's clear that you understand the impact what you have to say. Empathy
can inform which type of emotion you should inject in your delivery.

Be sure to listen as well. In many ways listening does as much as to give
people an impression of tact as your delivery does. Follow up your delivery
with an opportunity to listen and see how it was recieved.

# Team Culture

By default culture flows from the top down, and for any team you manage, you
are the source of that flow. You have an outsized impact on your teams culture.
If you are negative then your team will tend to be negative. If you are
positive then your team will tend to be positive. I've been thinking a lot
lately about what you can do to create a good team culture.

## Identity

Identity forms an outsized part of your teams culture. What do you need your
teams engineering identity to be? Should you be a quality at all costs team or
are a ship it and fix it if it breaks in prod kind of team? Should you value
unit testing or do you get more value from Manual QA? Is CI/CD in your DNA or
are weekly planned deployments better? What about developer tooling? Is it
everyone for themselves or is tooling a first class part of your teams
identity. In your technology choices do you tend toward build or buy?

**Your goal is to be in a position where you don't need to micro-manage**

To be effective you need to be clear about your teams identity. This will give
guide rails for your developers and team members. They will know what mental
framework they should use when making decisions, it frees you from having to be
involved in the minutia. Your goal is to be in a position where you don't need
to micro-manage.

## Narrative

As a manager you need to provide a narrative to your team that is positive,
believable, consistent, and evolving.

You don't want a narrartive that is framed as us vs them, something I've seen 
before in engineering organizations. You want it to focus on how the team can 
be productive and make the business successful.

**If you aren't honest then the cracks will start to show**

A good narrative is believable, one that everyone can buy into. Telling a story
about where the company is going and how the team will be able to contribute to
that direction does wonders for team cohesion. Make sure that the story is
accurate and not a fabrication. If you aren't honest then the cracks will start
to show and people will share their own narratives. Narratives that, in many
cases, lead to bad places for the team.

**If parts of your narrative are in conflict then the team won't know how to be self directed**

An inconsistent narrative will kill productivity. If parts of your narrative
are in conflict then the team won't know how to be self directed. They'll be
backtracking all the time and it will appear to them that the ground is
shifting under their feet. If you craft a good narrative then the team will
have a shared story. They will know where they fit.

**Acknowledge that the environment is changing and the team needs to adapt to it**

Narratives need to change and evolve. When this happens, be transparent about
it. Acknowledge that the environment is changing and the team needs to adapt to it.
Acknowledge when something isn't working for whatever reason and get consensus
on how to change it. Don't try to shoehorn the changes into the old narrative.

# Potential Impact

If the above challenges appeal to you then you might be interested in some
managerial roles. The impact you can have on a team and a company make it worth
it. You can be the difference between a good work environment for employees and
a bad one. You have the potential to remove barriers to productivity for a team
if you do it well. If you do it poorly though, you could be the reason a team's
productivity stalls. The risk/reward here is considerably different than any
other role I've had.