mirror of
https://github.com/zaphar/jeremy.marzhillstudios.com.git
synced 2025-07-22 19:39:56 -04:00
171 lines
8.4 KiB
Markdown
171 lines
8.4 KiB
Markdown
+++
|
|
title = "Engineering Management is Hard"
|
|
date = 2020-04-19
|
|
[taxonomies]
|
|
tags = [
|
|
"teams",
|
|
"management",
|
|
"culture",
|
|
]
|
|
+++
|
|
|
|
# Learning to be a manager
|
|
|
|
I'm about 80% manager these days. Some time ago I took on the role of Manager
|
|
at my current place of employment. This is a role I would have sworn I never
|
|
wanted to have 7 years ago. But life experience has a way of changing how you
|
|
feel about certain things. Before joining this company I experienced one of the
|
|
least competent engineering managers I had ever worked with. Up to then I had
|
|
had some sub-par experiences but never true incompetence. I realized that I
|
|
needed to better understand what an engineering manager needed to do. I needed
|
|
some survival skills and the best way to do that is to learn on the job. 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. In theory I think it was intended to be 50/50 but reality differs
|
|
quite a bit.
|
|
|
|
> Engineering Management is hard
|
|
|
|
Engineering Management is **hard**. I don't think I realized just how hard
|
|
until I experienced it for myself. Some of the problems are fundamentally
|
|
unsolvable. The most you can hope for is to manage and 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. I'd like to talk a little about what I've been
|
|
learning.
|
|
|
|
# Communication
|
|
|
|
> You are a conduit between the needs of the business and the capabilities
|
|
> of 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. They usually don't want to hear
|
|
it when you say no. 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 will be ineffective in your role.
|
|
|
|
> People appreciate it when you are honest about your failings
|
|
> and diligent in addressing them
|
|
|
|
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 that
|
|
it was your mistake and work to address it. People appreciate it 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 it when you can't be
|
|
transparent are important. Everyone like to understand the reason for decisions
|
|
that 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 or not. They understand that you can't always
|
|
share everything with them but they appreciate it when you are honest about
|
|
that handicap and when you share what you can.
|
|
|
|
## Tact
|
|
|
|
Being honest doesn't imply you need to be harsh. It is possible to deliver
|
|
the truth without triggering an unnecessary 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 you 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. 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 the news will have. 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 you delivery with an opportunity
|
|
to listen and see how it was recieved.
|
|
|
|
# Team Culture
|
|
|
|
By default culture flows from the top down most of the time. And for any team
|
|
you are manage, you are the source of that flow. You have an outsize impact on
|
|
your teams culture. If you are negative then your team will tend to take on a
|
|
negative attitude. If you are positive then your team will tend to take on a
|
|
positive attitude. I've been thinking a lot lately about what you can do to
|
|
create a good team culture.
|
|
|
|
## Identity
|
|
|
|
Identity forms an outsize 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 your team
|
|
|
|
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 your team.
|
|
|
|
## Narrative
|
|
|
|
As a manager you need to provide narrative to your team that is positive,
|
|
believable, consistent, and evolving.
|
|
|
|
The narrative should be positive. 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 in your narrative then the cracks will start to show
|
|
|
|
A good narrative is believable. A narrative that everyone can buy into. Telling
|
|
a story about where the company is going and how the team will be able to
|
|
contribute to it does wonders for team cohesion. Make sure that the story is
|
|
accurate and not a fabrication. If you aren't honest in your narrative then the
|
|
cracks will start to show and people will start to share their own narrative. A
|
|
narrative that in many cases leads to bad places for the team.
|
|
|
|
> If parts of your narrative are in conflict with itself 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 with itself 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. A team with a consistent
|
|
shared story doesn't surprise you and is self-directed.
|
|
|
|
> Acknowledge that there is change and we need to adapt to it
|
|
|
|
Narratives need to change and evolve. When this happens be transparent about
|
|
it. Acknowledge that the environment is changing and we need 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.
|
|
Be transparent that the narrative has changed.
|
|
|
|
# Potential Impact
|
|
|
|
> You can be the difference between a good work environment
|
|
> for employees and a bad one
|
|
|
|
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 in many ways
|
|
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. I can do great damage or I
|
|
can be a force multiplier like no other. |