
Engineering management lessons (2014) - mzehrer
http://www.defmacro.org/2014/10/03/engman.html
======
biztos
Having just spent a couple weeks on a pretty hard engineering problem, after
having done more "architecture" stuff for quite a while, I would definitely
add one thing to the Do's:

* Protect your engineers' attention.

As a manager you are the primary firewall between the world of distraction and
the world of getting shit done. Most places these days have institutionalized
some amount of distraction -- the various recurring "ceremonies" \-- but
anything beyond that, it's essential that the manager can protect the
engineers from being distracted when they're working on hard problems.

(I've been pretty lucky in this regard throughout my career, but now that part
of my job is to live among the distractions it's really been driven home.)

Also:

> You’re the one who makes hiring and firing decisions. Everything that
> happens on your team is your responsibility.

This is, to put it gently, not quite true in larger organizations.

~~~
jt2190
> Protect your engineers' attention.

Can you elaborate on "attention", and what does "protecting" it look like?
(I've seen this reasoning used to keep developers out of requirements
gathering, for example.)

~~~
biztos
I've never been an engineering manager so this is my perspective as a software
engineer:

My attention is my ability to concentrate on what I need to do right now --
not what the company needs in a broad strategic sense, not what the stock is
doing, not what might be on the horizon in a few weeks. All of those things
are important to me but my attention can only be on one at a time. And I think
the reality of serious software engineering is that sometimes you need to
concentrate on the code and not on the other things.

Protecting my attention means knowing when I need to be in the "zone" (asking
if you aren't sure); giving me plenty of warning if I'm going to be involved
in things like requirements meetings; totally insulating me from any corporate
politics except where I've asked to be informed or it directly affects me; and
escalating appropriately (HELO phone?) if I'm too busy to answer
e-mails/chats.

I absolutely think you want engineers in requirements meetings, but I also
think that if you have an engineer who should be in the requirements meeting
and she's super busy implementing that autonomous social-graph API then hey,
move the meeting.

~~~
pionar
I am an engineering manager, formerly a dev, so I know what you mean.

I have a rule that I'm the gatekeeper to my group's time. My people know that
if someone tries to contact them directly (unless as part of an ongoing
project/conversation), they're to direct that person to me, where I can set
expectations appropriately. It doesn't happen much anymore.

I see part of my role as a liaison between my group and the rest of the
company.

My people don't fight fires, there's a team for that. I'm sorry that you don't
feel like your issue gets the attention it deserves over there. Those guys are
swamped. Pinging my team directly is not the appropriate resolution.

Usually, what happens is someone from some other group (sales, support,
services) will come to me to ask a question. If I don't directly know the
answer, I'll throw the question in a Slack channel. My ask of my team is that
they check that before they head out to lunch, head home, etc., because it's
usually a 5-minute investigation.

------
theprop
The single most important thing in engineering management is hiring only the
best. The best have two key characteristics: strong technical skills primarily
in aptitude but also in technical knowledge, and a great ego-less attitude.
It's at least as important to test for ego than for technical skills.

Most of our "engineering disasters" were related to lowering our bar for
hiring. Some "engineering disasters", though, i should note were related to
inexperienced product development - so if you're a first-time product leader,
get an experienced mentor.

~~~
reledi
The replies are all playing word police and missing the point. Hyperboles are
great for getting a point across, except when they're taken too literally.

OP means you should be raising the bar for hiring at your org.

~~~
theprop
Thanks! Yes, exactly what I meant. "The best" is according to your
organization's criteria in terms of skills, attitude, etc. for your team. In
my experience, when we've started lowering the bar (after interviewing umpteen
candidates and eager to just hire someone), we always had problems down the
road and usually big ones (i.e. none of those candidates are any longer with
us).

I'm not talking about the mythical 10x engineers or anything like that. It's
your bar for what skills fit into your company. If you have no bar...you've
got much bigger problems than management...

That said, if you lower the bar a bit in hiring, do not lower the bar in
expectations. See if that person who you weren't that confident in can catch
up fast. Some candidates work very hard and make it. Those who aren't are
apparently fairly quickly...you have to let them go.

Incidentally, there is no real "best" when it comes to engineers -- I've found
there are two ways to think about the engineers you need: specific skillsets
and brilliance. Someones you need someone who really knows a particular
technology or area and can do that very well even if that person isn't
generally super-capable. Such a person is often much more efficient than any
new-comer will be even after several months of training. Then there's certain
work that requires learning or general brilliance (which is probably learning
fast if I had to define it...).

------
siliconc0w
Managers should get good at RTS games. A lot of the same principles apply -

* production vs process - you can spend resources on improving process(usually tooling) to improve production but this isn't always an easy knob to tune and can have diminishing returns. "Automate all the things" is how I know you don't know what you're talking about.

* DOTs - damage over time can be brutal, question every meeting and email that hits your team. Similarly- Engineers need large blocks of time to find flow and be effective(aka void rays). That 15 minute 2pm weekly check-in may seem trivial but you're pretty much nuking an afternoon's worth of productivity.

* macro vs micro - you generally need to spend time on both. Even Sr. engineers can benefit from occasional guidance because you should know more than them(see below). (knowledge != intelligence)

* bottlenecks/'stage III' production - you can have too many resources on something.

* Some resources are much better at certain tasks than others.

* situational awareness - know the executive roadmap, your roadmap, your internal customer's roadmaps, know 'the theory of how engineers are working in your org' and the reality. Know every project in your code repository. Know about most other possibly relevant open source technologies. Mostly this is just a lot of listening and reading. Be Omniscient

* 'strats/build-orders' \- similar to the above, know how the industry/competitors solve the same problems your org has (but don't necessarily seek to copy them)

That said, treating people like RTS units is also a good way be disliked and
ultimately be ineffective so you have to do the whole empathetic human thing.

------
exelius
It's pretty simple: engineers are professionals. Professionals make mistakes,
but are most effective when allowed to own up to them without consequences and
learn from them.

In a good software team, a single developer's "big mistake" gets fixed by the
whole team. I guarantee nobody on that entire team will make that same
mistake; nor will they hold anything against the offending developer unless
there's a pattern.

But in short, empowerment is the most effective leadership style in this
environment. It's not appropriate for all employees (specifically newer folks
who need a bit more hand-holding at first) but for professional workers like
engineers, it's really the only way to go -- especially if you have senior
technical employees who have decades more experience than their manager.

------
alexchamberlain
Strongly disagree that an engineering manager shouldn't code; that is the
shortest way to lose the respect of the team. Don't get me wrong; you need not
be the "best" or the expert in all areas, but you do need to stay on top of
technical developments both within and outside your organisation.

~~~
endymi0n
There's an easy way to accomplish this: Commit yourself to 95% reading of code
and 5% writing. Through great code reviews, spread your knowledge through the
company and make others as good as you. Has the added benefit of making the
stack more homogenous. (I still code review 50% of all commits relating to the
data model - SQL & API interfaces myself)

Then about the 5% - this is high prio, high visibility fixes where you bring
in your extraordinary expertise in some domain. Believe me, that's enough to
stay respected. Your time is much better spent at sparring systems
architecture & high level design, hiring and building well-oiled teams and
discussing the business needs with the rest of the company.

Isn't as fun, Doesn't feel as good, but it helps most the long run. The
alternative is a high performance coding monkey that gets a tiny area of the
company right - and the rest of IT goes wild and rewrites core APIs in the
latest three hype language because "we needed to get rid of technical debt".

The 44 lessons of the OP are distilled gold from years of experience, I
rehearse them every year and can recommend them to any aspiring tech lead.

~~~
watwut
Code reviews by a dude who codes only a little and has formal power are pure
hell. It is tricky when he is wrong, he can force you to do things that cause
trouble and so on and so forth - all that because writing and reviewing code
are much different and he is gradually out of touch.

~~~
sanderjd
It sounds like you've run into some bad apples, likely due to "promoted too
early" syndrome, which is unfortunately pretty common. In my experience, code
review by senior engineers is extremely valuable whether or not they're
currently writing much code.

~~~
Spooky23
That's why coding managers is dumb.

The army figured it out. The Officers are in charge, but the sergeants get
shit done. In engineering, your leads/supervisors are the sergeants.

Officer quality varies between complete shitbird and Julius Ceasar. Either
way, the army marches.

~~~
dismantlethesun
Sound like tech leads are sergeants and project managers are officers.

~~~
Spooky23
That's where the analogy breaks a bit. Where I work, PMs don't "own" people,
just deliverables.

Their main weapon is pestering you.

------
jkovacs
Question: It says at point 8:

> Don't supervise the quality and volume of people’s work.

And I agree with the argument following that sentence. On the other hand, 2
points above that it says:

> Do enforce behavioral and performance standards. Fire bullies and
> underperformers.

So how else _do_ I recognize underperformers without taking note of quantity
and quality of people's output? Surely I can't just take someone else's word
for it (and by the point a peer complains about this it's probably too late
already anyway?).

~~~
dom0
If you require metrics to determine whether an employee is productive in a
team, then that is a red flag (to me) that you need to communicate more.
Talking to people is a far better way to find issues than looking at metrics.

I'm highly sceptical of managers that are focused on measuring metrics.

~~~
ooqr
This would be a pretty nerve-wracking position for an employee. Sometimes it
takes a long time to hunt down a single-line change to the code to fix a bug.

~~~
sleazebreeze
I believe it's the responsibility of the person hunting down that one-line
change to communicate to their team what was involved with tracking that down.
Everyone can learn from a single person's deep dive. An engineer shouldn't
feel like they're doing something risky for their career by carefully working
through a hard problem with unimpressive code results.

If the engineer can't convey why it took a week to find that one-line, they
should work on their communication skills. A good manager can help set
expectations for an engineer who has underdeveloped soft skills.

I just spent a week and a half tracking down a bizarre issue in a 3rd party
library and filed a fix for it. It was simultaneously frustrating and
fascinating, but I never once was worried that the team didn't support my
effort because I kept the team in the loop during daily standups. I've also
been lucky to have excellent managers who believe in letting the engineers
work.

~~~
Rapzid
Agreed. If it takes a week to make a line change it'd be very unusual IMHO if
the entire team were not aware by that point of some the challenges involved.
It may even warrant a short presentation on the technical challenges and how
the issue was tracked down or solved; good learning opportunity.

On the other hand, if somebody is constantly disappearing for a week+ with a
low complexity ticket, gives cagey standup updates, and then submits a PR that
looks like it was thrown together in an hour.. That's a red flag that needs
attention.

------
bmsleight_
"Don’t make decisions unless you have to. Whenever possible, allow the team to
explore ideas and make decisions on its own."

Spot on, a good leader does not make all the decisions. It is counter-
intuitive to popular culture, but this is stop on.

I would go on to say minimising your decisions, also helps to spend more time
on a key decision when it is really necessary.

~~~
samlittlewood
A variation on this is not swoop in and make discoveries that the team is very
close to finding - let them enjoy the thrill (even if you have to nudge them a
bit in the right direction).

------
joshuaswaney
The emotional side of management goes so much deeper than what's covered by
this list. Develop a vision and a strong sense of purpose in your engineers
and they'll develop a mindset of building the future instead of maintaining
the present. Foster a "we're all in this together" atmosphere and your
engineers will develop a fanatical drive for success - either we all succeed
or we all fail, it's not every man for himself.

The deep emotional drive is also what causes startups to succeed where big
companies fail, despite their massive resources.

------
kator
I always say management is they easiest job because you only have four things
to do, and I'm sure your team has more than that to do:

1) Provide Air Cover

2) Provide resources

3) Provide direction

4) Get the F __* out of the way

Don't over think it. Empower your teams, trust them. They'll make mistakes
just like you do. It's not how bad you F* Up it's how well you recover.

Originality in mistakes is the best I can ask for. Let's learn, progress and
do better together.

I've been in tech for 35 years, if you think you've seen it all, you haven't
and neither have I, so let's figure it out together and get some S*t done.

~~~
khazhoux
Wow, that sounds like a lazy shitty manager.

Every engineering team has problems they can't deal with on their own, either
because it's out of scope, it's high-level organization, or whatever. A GOOD
manager spends a significant chunk of their week ACTIVELY fixing problems. Not
getting-the-fuck-out-of-the-way!! They should help clear the way. They should
help fill gaps in the team, plan, or execution. Talk to other teams and see if
everyone's on the same page. Make sure everyone agrees on priorities. Make
sure your team's work integrates with what everyone else is doing. Be aware of
_everything_ going on around you (esp with other orgs, etc) so you know how it
all fits together and your team doesn't waste time.

Don't just listen and nod during 1:1s and then give some off-the-cuff
suggestions. Don't just "get out of the way". And you don't need nearly that
much Air Cover when you're team is aligned with the rest of the company, so
make sure THAT happens instead of trying to "protect" the folks that happen to
report to you.

If a great team's manager can't point to what they ACTIVELY DID to get the
team to success, they're disposable.

~~~
OpenDrapery
Sad truth is that coding and problem solving and getting your hands dirty is
low status work. I've had managers that new the application they were
responsible for, and could speak coherently about technical things.

I've had managers who couldn't demo the apps that their team worked on.

Which one is better to work for as an engineer? The technically savvy one.
Which one has higher stature and seems to be more highly regarded by his
superiors? The non technical one.

In other words, that "lazy shitty manager" is probably playing the game
better.

------
Bahamut
I am learning a lot about engineering management through turmoil, and I think
the most important lesson for me is to avoid doing too much.

There are many things that can often use improving, especially at smaller
companies. Process, architecture, deployment system, reduced meetings of team,
optimizing the SLM software...it's easy to get overwhelmed, especially if you
have a large team, or in my case, doing the job of a tech lead and engineering
manager. It is a lot to swallow. Prioritizing the most important points on
what is being tackled and communicating why is very important.

------
jasode
This is a fine list and there's nothing too controversial that people would
disagree with.

That said, I only counted 6 items out of 44 that's specifically _"
engineering"_ related. (5, 7, 10, 12, 14, 15)

The other 38 bullet points are _universal_ lessons that also apply to _non-
engineering_ managers such as a director of a creative team in an ad agency,
or project supervisor of a construction crew, or a showrunner in charge of
scriptwriters for TV episodes, etc. Empower your team and make decisions when
necessary, etc.

------
pacaro
Did I miss something? I see nothing on this list that touches on mentoring or
growing. I do see a line about firing underperformers. I've heard a metric
that it costs between 2.5-5 time annual salary to replace someone. Sometimes
an under performer is just in the wrong role, or on the wrong team; when this
is the case they probably know it. Ask them!

------
AlexCoventry
I read this recently and found it very insightful because whereas most
software management essays seem to have an agenda of advertising the author as
a great person to work with, this one seems like a pretty straightforward dump
of lessons learned.

------
tempz
Sadly, exactly 50% of engineers are below average, so hiring the best all the
time is unsustainable. Thinking that you hired the best, however, is
sustainable.

The art of managing relies on the capability to get work done by all kinds of
engineers. The talent is rarely universally allocated. Some very 'bright' ones
will never properly finish the work. Some 'slow' engineers may have remarkable
attention to details.

~~~
rileymat2
50% are below the median. I am not sure 50% are below average.

------
tootie
I guess it varies by company, but my job is more about managing the team's
exposure to outside forces. I work with product and client teams to make sure
we're delivering the right solution and we're promising something achievable.
That's at least half my job.

------
boltzmannbrain
\+ a meta-point: Learn these through experience, not in a classroom. Having
managed engineers in industry and also gone through a masters program in
engineering management, 90% of what makes me a decent manager/leader/coach
today can be attributed to the former.

~~~
douche
The dirty secret is that 90% of all formal education is a waste of time, and
is just signalling hoop-jumping.

~~~
mcginleyr1
I thought it was helpful when I was doing it the first time. I saw things it
made the human capital and self assessment courses much more useful to
everyone when I could ask meaningful questions. So really I see leadership
masters being helpful when you're first attempting to manage not later or
before.

------
mratzloff
"When you do X, it makes me feel Y."

I saw this phrase several times in this article and the linked article on
"non-violent communication," but I don't think it's a particularly productive
phrase.

Consider the possibility that no one can "make you" feel anything, and that
you are ultimately responsible for your own emotional state. For example, you
can't command me to feel happy or sad. My emotional response is something I'm
a party to, in combination with my own unresolved fears and insecurities.

Instead, I suggest phrasing it in the present tense: "When you do X, I feel
Y." That is observational and avoids any accusation or blame, so you can focus
on the core issue at hand.

------
kuharich
Prior discussion:
[https://news.ycombinator.com/item?id=8406507](https://news.ycombinator.com/item?id=8406507)

------
guilt
Big Companies have management who cash in at the expense of young exploitable
engineers.

Personally I'd like to see the top management get fired.

------
gcatalfamo
Number 11: you are probably talking about _authoritativeness_ and not
authority

