
On Being an Engineering Manager - boyter
https://nickmchardy.com/2019/02/on-being-an-engineering-manager.html
======
fizx
I don't know if you're looking for advice, but:

It seems like you aren't a manager, but rather a junior director who doesn't
know it yet.

13 people across 4 initiatives is too much to directly manage effectively.
Find someone to lead each one, and make them team leads.

Meet twice weekly with your leads, once to plan, once to problem-solve.

Move your HR/career-oriented 1:1s to every-other-week. If any of your team
leads are good with people, delegate your 1:1s.

You only need a half hour for recurring meetings.

Delegate more.

~~~
onlyrealcuzzo
As an engineering manager, this sounds like almost every startup I interview
at.

It's almost always the CTO directly managing ~15 engineers. The CTO is always
a man. He's always hiring a manager only because he doesn't have time for the
1:1s anymore. He never believes in hierarchies. The engineering team is flat,
he tells me. They don't need teams, no siree. He's only interviewing me, he
assures, because 1:1s aren't a good use of his time anymore.

Don't worry, he assures me, he'll still take care of all the architectural
decisions. And he might even manage half of the team still, he hasn't decided.

That's usually about the time I nope right out of the interview.

~~~
hitekker
Superb insight about 1:1s. They are an essential team process, which the
manager alone is responsible for. They can't be delegated; a manager cannot
establish and maintain a direct, personal relationship through a proxy. That's
just not how human beings work.

In my experience, the desire to "delegate" 1:1s typically signals that team is
raising truthful (and deeply troubling) problems, which the executive does not
want to think about. Rather than think, they rationalize: claiming that
consistently and privately listening to their subordinates is "not a good use
of my time", "drama-filled", "not relevant to the tech", "isn't that what HR
is for?" or some easy excuse. Whatever helps them coast until they jump ship
next year.

Good on you for avoiding that mess, and for not playing along with their
softheaded pretense.

~~~
cosmie
It's also commonly a signal of an executive-by-default vs. an executive-by-
experience.

The traditional path to leadership roles generally involve a stepped process
from a role that's fully an individual contributor to one that has virtually
no IC component. It's progressive enough that by the time you've stepped up to
another level of management you've already grown accustomed to what you needed
to let go of and what you needed to shift focus to, while having someone above
you to essentially provide integration and regression testing as you acclimate
to your new role.

A CTO-by-default skips that and goes from IC to "executive level authority and
autonomy". They're not only managing people all of a sudden, but architecting
teams and org structures. With little or no prior experience to lean on.

So they nope out of it - avoid org structure planning (and ensuing
uncomfortable decisions) by keeping it all flat, bring in a people manager as
a short term solution to the problem they created with keeping up with
everyone, while also avoiding some of the messier side of people management.
And seek comfort in the familiar work of system architecture and (maybe) keep
directly managing the parts of the team that are the most capable of self-
management and aren't as uncomfortable to manage.

Still a mess to be avoided, just as you said. But a mess that's rooted more in
inexperience and discomfort than in arrogance and hubris.

------
jarjoura
I actually think for most of us, after some point, switching to engineering
manager track is often far easier to continue leveling up in. Most good
companies have an equivalent tech track, but unless the stars are aligned and
you're blessed with a supportive manager AND the right project that align with
your talents, its going to take a much longer time progressing.

Of course in both tracks, it's no longer only about your own contributions and
impact to the team, but that your contributions and impact now translate to
everyone else you work with so that they're able to improve their own
contributions and impact. Or in another way, is what you're doing helping
everyone else do better?! So even though that sounds straight forward, showing
that at performance review time can actually be really challenging if you're
in a tech role vs. a people management role.

I've heard the complaint that some of us shouldn't be EMs, but I'm a firm
believer that if it's something you enjoy, you can absolutely learn how to be
a great EM. I would only consider sticking with the tech track if you enjoy
the tech work more.

~~~
maxxxxx
"I actually think for most of us, after some point, switching to engineering
manager track is often far easier to continue leveling up in. Most good
companies have an equivalent tech track, but unless the stars are aligned and
you're blessed with a supportive manager AND the right project that align with
your talents, its going to take a much longer time progressing. "

That's a really important point. In theory my company has a technical track
but it's freakishly difficult to move up on it. On the other hand I see a lot
of mediocre managers moving up higher on the pay scale all the time.

~~~
silveroriole
My company has a tech track but NO developers are on it. It’s basically
designed so that nobody can ever qualify for it. As far as I can see it’s
purely there to entice developers and then push the blame back on them when
they inevitably have to turn into managers - “look, you COULD have been on the
tech track if you tried harder, you made the choice to progress on the
management track.”

~~~
maxxxxx
I think one thing is that in a lot of companies there still is the belief that
your pay is determined by the number of people you have under you and that a
manager always has to make more than than the people they manage.

~~~
nojvek
That’s usually the right economics. If you want to make money as an older
person, management is the way up.

Very few companies hire engineers above 40. It’s the unfortunate reality of
our industry.

~~~
silveroriole
Surely it’s insane economics for the company though. My management skills must
be almost useless (and I’m considered an ok manager) compared to my dev
skills. I can’t understand what’s in it for the company to make EVERYONE into
crap managers AND pay them more AND make them unhappy AND ensure that only
inexperienced juniors have time to actually do work. Just don’t get it. But
every company wants to do it.

------
ascotan
There are some trade offs when you go into management (from experience):

Upsides:

\+ Your reports will treat you with respect

\+ You will get more opportunities to travel

\+ You will likely get much more visibility in the organization

\+ You will get the opportunity to engage in team building activities and have
fun

\+ You can set the standards and direction of the group

Downsides:

\- You will have to learn the art of politics to deal with your peers

\- You need to be much more cautious about your communication and actions

\- You have a target on your back and so you need to learn how to block

\- You will likely have to spend more money on corporate travel & activities
than your used to

\- You have to have the maturity to deal with 'wasteful' activities that are
part of management

One of the biggest problems with people being asked to be a manager is whether
or not the organization is asking for a real "manager" or a "leader". This is
a particular problem with technical staff being promoted to management.

Managers by definition are there to set everyone straight. Define the rules.
Make the process repeatable. Make sure no one is out of line.

However, many companies are not really seeking this from technical staff. What
they really want are "leaders". If people are asking you as a manager to set
the technical direction or lead and train the engineers or give presentations
at conferences, they're not asking for a traditional "manager". Ultimately, if
you seek to be a traditional manager (in this type of environment) you're
doomed to fail.

Great people managers are really a type of coach. They give pep talks, they
throw events, they motivate, recruit the best talent, etc. Think of your high
school football coach.

In this style of management you're going to be graded on retention,
motivation, drive, energy, etc. etc. If this isn't you, you better think twice
about moving from engineering.

If this organization is really looking for an Architect or Principal Engineer
that will dive the direction and strategy for their technology, they let them
know that.

~~~
muratsu
Are there any good books or resources that comes to your mind for better
understanding what you've described?

~~~
ascotan
There are a number of good books on both leadership and management. Harvard
Business Review has a lot of smaller books on leadership and management like
this one:

[https://www.amazon.com/Managers-Become-Leaders-Michael-
Watki...](https://www.amazon.com/Managers-Become-Leaders-Michael-
Watkins/dp/1633693023/ref=pd_sim_14_4/138-1293681-0303815?_encoding=UTF8&pd_rd_i=1633693023&pd_rd_r=e469ed4b-3378-11e9-9126-7b5e4f5c8ab6&pd_rd_w=X9T67&pd_rd_wg=Tgwv3&pf_rd_p=90485860-83e9-4fd9-b838-b28a9b7fda30&pf_rd_r=X680EBCR0AAGSCYY3DW9&psc=1&refRID=X680EBCR0AAGSCYY3DW9)

One of the challenges though in management is understanding what the business
wants from you. Once you understand that you can be effective (and pick the
right books to read)

------
RickJWagner
When I was a junior programmer (about 25 years ago), I thought it would be
great to be a programming manager.

One day, a senior programmer told me he'd been a manager for a while. I was
surprised-- I figured it was a step down to go back to coding. I asked him why
he went back to programming.

His reply: "When you are a programmer, you have a boss above you that gives
you tasks. When you are a manager, there is a boss above you and several
people below you that bring you tasks. They nip at you from the top, and they
nip at you from the bottom."

It made sense to me.

------
ppod
I manage a team that do what could broadly be described as data science, here
is one thing I feel unsure about and I'd like others' opinion on:

How much should I tell my team about what's going on above me? If my manager
tells me about a customer meeting where they request a demo with certain broad
requirements by a certain deadline. Should I go into the details of the
overall business goal of the client and the exact deadline for the final demo?
Or should I just delegate specific subtasks and keep the information structure
within my team somewhat modular/encapsualted?

~~~
iaresee
I have, over the years, gravitated towards telling everyone in my teams as
much as I possibly can at all times. I use top-down information sharing like
your scenarios as a chance to connect my teams (which tend to be
infrastructure and futher from the core business) to the business and their
needs.

Any system of information sharing that requires me to remember what and with
whom I shared specific bits of compartmentalized information is ultimately
doomed to fail. You'll forget who knows what and eventually screw up and then
you look like a manipulative middle-manager for withholding information.

Unless there's a clear reason not to share (layoffs, acquisitions, etc.), I
share.

~~~
ro_sharp
Amen. Work without context is demoralising and can lead to micro decisions
that don't align with the macro context of the business you're in.

~~~
mk89
But if you don't share context you can always blame it on the fact that there
was a misunderstanding or that you had so much to do, that you couldn't
blablabla.

And who is gonna challenge a manager and say that it's his job to prevent
misunderstandings by sharing information?

The blame game is a great asset when you need to hide incompetence and you are
afraid of judgement.

~~~
Aeolun
Nobody will be able to officialy blame you, but everyone will hate you
privately.

If you thrive in such an environment, more power to you.

------
paxys
Great read. More people need to realize that moving into a people manager role
is NOT a requirement for career advancement. If you feel that is the case at
your company, and you are more passionate about coding or architecture, you
should really consider switching jobs. There are a ton of companies out there
that will value a great IC over an average manager.

If you are at a smaller company, push for them to formalize a career ladder
which has parallel tracks for manager and IC roles going all the way up till
C-level execs.

~~~
bradleyjg
> More people need to realize that moving into a people manager role is NOT a
> requirement for career advancement.

It kinda is though. At any reasonably level of comp you care to name there's
someone playing sports making that amount of money. Nonetheless it is entirely
reasonable to say that playing sports isn't a great path for career
advancement. Same thing with tech IC. Sure, there's someone, somewhere making
$1MM/year as an IC, but there's a heck of lot more people with reports at
making that. Same thing is true at $750k and $500k.

Maybe at $300k it isn't? And yes, to be sure, that's a ton of money. But given
how hard it is to advance from there, can you really expect to sit there for
20+ years? How many organizations are there around that don't have some kind
(possibly unofficial) up or out rule?

~~~
humanrebar
> How many organizations are there around that don't have some kind (possibly
> unofficial) up or out rule?

They don't push out the person that wrote all that business critical COBOL
spaghetti. It's not all that hard to code yourself into job security. Digging
into someone else's technical debt and stewarding it along for years 13-28 of
its life is easy too.

~~~
bitwize
"I'm gonna code me a minivan."

------
austincheney
Managing developers is weird. I have a unique perspective on this matter as I
am a senior developer at one company and a managing principle at another.

As a senior developer I am deeply introverted and I am skilled at my craft
because I can go into these fugue states of deep focus blocking out everything
else. I don't need to be concerned with the world outside my team, and often
not so concerned with my teammates. As an individual contributor your success
is largely determined by the quality and frequency of your contributions.

As a manager you need to be more concerned with what is going on outside the
team than within. You are the interface and diplomat between the team and
everything else. You are interfacing externally outside the team so that your
team doesn't have to and so that you are the single funnel of priority and
direction.

As a manager you are largely done writing code. Use your experience writing
code to set the proper tone and direction when your developers hit a wall.
Guide them into the proper direction for resolution and provide them with
resources they likely aren't even aware of. That is you, the manager,
providing a vague solution to a code problem without having to write any code.

Your coding experience allows you to set business standards (not code
standards) that determines acceptable contributions and enforce those
standards. Code standards tend to be highly subjective and are often
completely vane or superfluous. By ensuring the standards exist outside of
code, such as execution speed or statement count, the standards are likely to
be objective and uniformly applied. You should automate this enforcement as
much as possible and grant exceptions only with careful deliberate
consideration.

Setting high standards is a defensive action against future stupidity. Even as
a manager there is still much in the world you do not control. Strong leaders
are proactive in shielding their team from stupidity as much as possible.
Perhaps the strongest and most enduring form of stupidity defense is CYA
(cover your ass). High standards of deliverables is proactive CYA.

If standards are set high members of your team will complain. It will happen.
Accept it and own it. Managers without a strong development background or weak
soft skills may find it easier to keep the team happy. That is bad. Remember
who your team works for. They work for you, not the other way around. If you
are quick to cave on product quality its like sharks smelling the blood in the
water. Smart managers will spin this as the company's product is merely a tool
to advance the team members personal development and competence of their
craft. If after sufficient time, patience, and training are exhausted and a
teammate still cannot accept the high standards transfer them off the team.
Incompetence is a drag on everybody.

The most common reason why product quality slips is because either the
business is setting unreasonable delivery timelines or because your team lacks
confidence. The second is far more common than the former since, as the
manager, you can often negotiate more realistic external delivery terms. An
inexperienced team is not a reason to release shit back to the business. That
is the opposite of CYA.

Fortunately your team will make this foolishness clear to you by advocating
for _easy_. If you ever hear your team advocating solutions or alternatives
because of _easy_ or _hard_ take a long hard pause and reevaluate what they
are really saying. When they advocate for easy it might sound something like:
"We should use framework X because it makes things easy and then we can
deliver twice as fast!" What that really says is something like: "We are slow
to make decisions and our jobs are challenging!" In that case the problem is
insecurity/anxiety and the framework is a bandage over a much larger wound.
Always remember the name of the game is high quality output so that you put
your CYA immediately up front. The _easy_ option your team advocates is likely
to shred every ounce of CYA both now and in the future.

One way think of your place in the world, as a manager, is that the group is
worth more than an individual but the product your team supports is worth more
than you or your team. Your entire team can be laid off and that product will
continue to live.

------
misingnoglic
Thanks for sharing :)

------
infinii
If you're having 1:1s each fortnight, you probably won't even need 30mins. In
practice, schedule for 30mins but in reality it rarely takes that much time so
don't fret about losing so much time.

------
azmany
nice write up. Thanks!

------
painful
Hopefully you won't subject your workers to scrum; it is evil. Refer to
[https://michaelochurch.wordpress.com/2015/06/06/why-agile-
an...](https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-
especially-scrum-are-terrible/)

~~~
shemnon42
I would take everything that mchurch says with a grain of salt.

~~~
painful
Granted it's an opinion, but if you've been through as much scrum as I have,
especially if you're a senior developer, you'd know it's a true article.

