
Engineering management lessons - coffeemug
http://www.defmacro.org/2014/10/03/engman.html
======
drblast
I think the don't section is far too specific and short. I also think you can
learn a lot more from failure than success, but I might be biased there. My
management experience is in large bureaucracies.

Here are my top ways to fail as a technical manager:

1\. You don't understand what the people who work for you do well enough to
know good work from bad work. This has all sorts of bad ramifications. You
can't be a leader if you don't understand what's going on. Does that mean you
should be able to write code? Maybe. . .it depends on the job. It does mean
that "Don't write code" is not universally good advice.

2\. People don't trust you. This might not be because of anything you've done
but things you've failed to do, like chat with people regularly and give them
bad news quickly.

3\. You don't manage the careers of subordinates so that they feel like you're
helping them succeed. This is particularly important for the typical
engineering personality type that finds "selling yourself" repulsive. Don't
have enough data to "sell" a subordinate at review time? See #1.

4\. You don't set a goal or direction. Details are the engineers' job. You
have to know about the details and understand them, but your job is to give a
clear overall direction and goal and help the team stick to it, and change it
when necessary. If you've hired good people who want to accomplish something,
they'll do that. Just make it clear what _that_ is.

5\. You forget that your success might occur in spite of you. Especially as a
middle manager, you're like an insurance company; if there's anyone on your
team that causes that team to be a success, you look like a success. A mostly
dysfunctional team (or a completely dysfunctional manager) may still succeed.
Understand that great people risk a lot more working for you than you risk
having them work for you. If you're successful, you should live in fear that
you're doing everything wrong and constantly check yourself. You also need to
hide this fear from everyone.

6\. You don't live to serve. Your goal every day should be to give your people
the tools they need to succeed.

~~~
ritchiea
What does managing careers of subordinates mean? Sorry to ask a basic question
but most of my experience is at startups that barely have structure to the
team. What specifically should managers be doing to support their team
members's careers?

~~~
quanticle
It means telling me what I need to do to get to the next level on my career
path.

Step 1 is asking what your subordinate's next position will be. Are the
looking to stay technical? Are they looking to transition to a more managerial
role? Do they not know? If they don't know or are uncertain, take a step back
and ask them about what they enjoy doing, present them with options and then
let them decide what their goal state is.

Step 2 is figuring out what you and they need to do in order to move to that
goal.

Also, like the original article states, a lot of engineers are really bad at
selling themselves. They won't ask for a promotion. They won't ask, "Okay,
what am I missing that's preventing me from getting an acknowledgement for my
skills and experience." If they're anything like me, they'll just look around
after a while and jump ship when they find a position somewhere else that does
give them what they want.

Finally, I should note that I am _not_ a manager, nor do I have any desire to
be one. But I've dealt with a fair number of managers, and the ones I've been
most comfortable with have been the ones who've been direct about asking me
(after 4-6 months) where I want to go in the organization. The worst feeling
is going to one-on-ones week after week, and just rehashing the same points
you go over in your daily stand-ups. Weekly one-on-ones should be about the
developer and the manager figuring out where the developer wants to go in the
organization and what needs to be done to get them there.

------
coffeemug
Author here.

These are the most important things I learned about engineering management
after five years of doing it. There are lots of subtleties between the lines,
so let me know if anything feels vague and I'll try to clarify it.

~~~
bcbrown
> [Don't] Personally fix bugs and ship features. You have to write code to
> remain an effective tiebreaker, but that’s where your coding
> responsibilities end.

How do you write code without fixing bugs and shipping features? What do you
mean by tiebreaker?

~~~
coffeemug
_> How do you write code without fixing bugs and shipping features?_

What I meant here is that you have to fix an occasional bug and ship an
occasional feature, but only in order to remain an effective tiebreaker.
Fixing things is no longer your primary job. During crunch time new managers
often feel that the best way to help the team is to dig in and fix things
themselves, but in reality they can help much more effectively by doing other
things.

So fix an occasional bug, but remember, you're only doing it to stay in tune
with the codebase, _not_ to ship things faster.

 _> What do you mean by tiebreaker?_

I'm talking about making decisions when half the team thinks "we should do X"
and the other half thinks "we should do Y". If the team can't reach consensus
_someone_ has to decide, and as a manager, that's you.

~~~
nawitus
>During crunch time

Is "crunch time" a good thing in software development? It's certainly possible
to deliver software without crunch times.

~~~
HeyLaughingBoy
No, it's a spectacularly bad thing. Unfortunately most dev cultures assume
that it will always be necessary. In pretty much all cases it's a management
failure.

------
TheMagicHorsey
I think there are different kinds of engineering managers and different kinds
of teams. I think it might be realistic in a large organization, like Google
or Facebook, for an engineering manager to not write code. There is enough
political busy work every day in those organizations to keep you occupied with
non-engineering tasks.

Working on small teams, in start ups, with just 3 to 4 other engineers, I
found it was more productive for me to tackle at least one or two small
technical problems with each release. For one thing, it helped me to
understand what kinds of shortcomings there were with our tools--and whether
we needed to invest more in them to improve productivity. Also, because I was
immersed in the code, it was hard for people to bullshit me about what they
were doing, and how long it was taking.

There is an attitude in Silicon Valley that everyone is always working for the
good of the organization, or has the intention of doing so. I think you can be
fortunate and put such a team together. But sometimes you get someone who has
either lost the motivation to contribute, or has never had it. You can try to
help such a person get another position, so you can hire a replacement, but
sometimes you need to get through a release before that can happen.

In such a situation, being able to have an honest conversation, where they
know they can't bullshit you about technical stuff, is important.

~~~
freshflowers
Has nothing to do with the size of organization, but the nature of the
context. A small org can have a lot of clients, stakeholders, external
partners or other communication overhead between the team and the rest of the
world.

~~~
TheMagicHorsey
That is true.

------
bcantrill
I had the same reaction to this as many others have, in that I think much of
this stuff is good/fine, but the advice that engineering leadership shouldn't
actually directly contribute in a technical fashion is wrongheaded. I have
elaborated on this in the past[1], but in particular, I don't think it's
reasonable to expect to be the "tie breaker" in what is (tautologically) a
sharp divide on an engineering team when you no longer contribute: as a non-
contributor, you will be relying on what people are telling you instead of
your own engineering judgement.

But my objection to the advice that management should not contribute
technically is actually deeper than technical conflict resolution. Software is
so hard that it becomes like child birth in that we have an overwhelming bias
to forget the pain: the second you stop writing software, you start rewriting
your own history. So as far as you can remember, it was all pretty
straightforward, you always hit your deadlines, etc. And with this, you have
started down the primrose path in which you just can't understand why this is
taking so long and can't you guys just get all of the bugs fixed?! I (like
many -- if not most -- software engineers) have seen this first hand: one of
the most technical people I've ever worked with ventured into management,
stopped writing software entirely, and -- with astonishingly short latency --
forgot over a decade of experience of pain. He forgot the inifinite complexity
of software, and instead assumed that bugs were due to a lack of urgency,
laziness, or worse. At one point, we were getting crushed by a very nasty
issue, and he called a meeting to spend an hour telling us how important it
was (oh, thanks!) and that he "didn't want to hear details; just get it
fixed". If he had only asked "what I can do to help?", I was ready with: "You
are -- or at least were -- a damned good engineer; you can help us debug it."

This brings me to a slightly broader point: as technical leadership, I believe
that direct contribution is essential, but you do need to be very careful
about how you contribute. The last thing you want is to be on the critical
path of some feature and have the team blocked because you've been called into
a board meeting (or a customer visit or an off-site or a planning meeting or
any of the other of zillions of ways in which organizational leadership must
spend some portion of their time). For me personally, the answer this is
particularly easy because it dovetails with what I love to do anyway: my way
of directly contributing to my team is to debug. By picking up bugs that no
one else is looking at, you're out of the critical path, but you are helping
the team, staying technically current, and reminding yourself -- constantly!
-- of the brutal complexity of software engineering.

[1]
[http://www.slideshare.net/bcantrill/surge2013](http://www.slideshare.net/bcantrill/surge2013)
video:
[http://www.youtube.com/watch?v=bGkVM1B5NuI](http://www.youtube.com/watch?v=bGkVM1B5NuI)

~~~
tjradcliffe
Managers should be able to build and run the application (assuming its an
application) and fix minor bugs, including going through review and check-in.
The size of the technical issues they should touch with their own hands scales
at least linearly with the size of the team. On a small team there is no
problem with the manager being deep in the code. On a team with more than five
people the size of things they should be dealing with starts to drop pretty
precipitously, and by the time they are up to 15 or 20 people they should be
doing not much more than the odd cosmetic tweak.

The reason for this is that life is a personnel problem, and as the team gets
larger than 5 you just don't have that much room in your brain to accommodate
the different modes of thinking required for dealing with people and code (or
maybe you do: I don't, but my brain is particularly small, or so I've been
told.)

With regard to the manager you described: they are simply a bad manager. Good
managers are always working to facilitate their team's progress. Doing things
like calling a meeting to harass over-worked people into working harder is bad
management, and no amount of technical hands-on will change that. So my
prediction is getting a person like that into the code won't help.

~~~
Jormundir
Based on my current experience, I would avoid joining a team that had a
manager partaking in programming / devops.

All different types of managers can be good or bad, my personal experience has
just been that managers who dive into technical tasks, even just bug fixing
and devopsy stuff, tend to neglect their managerial responsibilities just
enough to be a chronic frustration to everyone below them.

Having only been in the industry a few years, it's also extremely frustration
when a manager does not delegate responsibilities you're interested in taking
on. So my view now is that if you're a manager taking on technical tasks,
you're denying your employees opportunities to grow professionally. It
certainly depends on mood at the time, but in a negative cycle, this can feel
like a vote of no confidence from your manager.

~~~
d4nt
I find it strange that there's a debate about this. When it comes to cooking,
medicine, law, architecture, hairdressing, design or sales, the best people
manage a team and continue to practice themselves.

When a dev team manager doesn't understand the architecture of the systems and
exactly how everything works, they cannot be in full control of the team.

Businesses need crossover people. People who can code AND who "get it" at a
commercial boardroom level.

~~~
themartorana
I think the larger the team, the larger the managerial workload. We're so
small, if our client app manager stopped doing dev, we'd have to hire another
person. At a global company I started with after college, working with with a
team of 10, my boss split his time between managerial busy work (expected of
him by upper management, not self-imposed) and being as involved as possible.
He was always able to speak intelligently about the product and its code, and
was able to contribute in ways that set an expectation of quality. He always
had the respect of the team (and when not, someone got fired). I consider him
to have been a mentor - he got it right.

If you're managing a team of 40, being involved directly in code/execution is
likely impractical and perhaps even detrimental, but at any scale up to 15
people or so, direct involvement seems both practical and necessary to retain
the respect of your team, and assure a quality product in the end.

~~~
Jormundir
I've never been on a team larger than 12 people, and they still needed someone
solely doing managerial work. I think it's easy to say "my team doesn't need a
full time manager". Though the problems I've seen arise as a result of lacking
management are slow and quiet. Grouchiness slowly creeps its way in until a
group of good (usually the best) people quit with little warning. I can't
emphasize enough how much I think a good full time manager is vital to a
team's performance and endurance.

The role that's being described above is one I would consider a "lead
engineer", not a manager. The healthiest role division I've seen so far is
when a team has a full time manager, and also a lead engineer or two who are
ultimately responsible for making sure the needs of the business are being
fulfilled by the engineering team.

------
weixiyen
Agree with basically everything here. The biggest surprise about engineering
management is that it's less about making technical decisions and more about
nurturing other people to make technical decisions. It's almost entirely
people management skills that don't even specifically apply to engineering.

The other thing is the role is very rarely leadership and more service.
Leaders usually blossom from within your teams naturally.

------
sheepmullet
People management, product management, project management, strategic
management, and technical management (i.e. tech lead) are all separate roles
with their own best practices.

These roles are often conflicting which makes management advice articles
difficult to follow.

For example "[Dont] Personally fix bugs and ship features." is great advice
for the Product Manager, the People Manager, and the Project Manager, but
horrible advice for the Technical Manager.

A good technical manager needs to be right in the thick of it and the longer
they go without touching the code the worse they become. Trying to be a tie
breaker on a technical issue when you aren't qualified to make the call will
quickly result in the team losing faith in you.

------
polskibus
There's not much there about the management triangle - cost, schedule and
scope. The hard part in management is navigating between these vertices day by
day. It's great when you can take "cost" out of the equation (and often
partially schedule for some time at least) because of VC funding, but the
truth is that you have it much easier than most other managers.

HBR is full of similarly writted golden thoughts written by really experienced
managers and leaders, however it is hard to relate to them in normal business
scenario, where the customer is almost screaming at you because of deadline
approaching, the sales team sold something that doesn't exist, the cashflow is
close to negative (no VC).

~~~
ryoshu
That's a project management triangle, related to people management, but
something that good engineering managers shield their engineers from.

------
napoleond
_> Most intellectual arguments have strong emotional undercurrents. You’ll be
dramatically more efficient once you learn to figure out what those are._

What does this mean?

~~~
courtf
Not the author, but taking a stab at your question: I think it means that
regardless of how logically unassailable you believe your position to be in an
argument, that position is heavily influenced by your emotions (whether you
realize it or not).

This is I think a very good piece of advice to consider carefully. It is
common with engineers I've worked with to see people cringe when emotions are
brought up. Surely, the ideal state for an engineer is to be devoid of strong
emotion while assessing information and writing code? I'm sure we'd all like
to believe in the consistency of our own performance and our ability to remain
rational despite varying circumstances.

The truth is that without the powerful emotional signals in your brain, you
would be mentally crippled in practically all decision making tasks. There's a
good deal of science on this. A single paper can be found here:
[http://www.ncbi.nlm.nih.gov/pubmed/15134841](http://www.ncbi.nlm.nih.gov/pubmed/15134841)

If you can key in to the emotional state of team members, you may be able to
navigate arguments by understanding/anticipating their angles and
communicating in a way that is more likely to be heard/well-received.

------
mathattack
I don't think there is a universal answer here on "Should managers code?"
(Disclosure - I'm in an organization that does expect them to code)

One general observation that seems to be missed here though... If you do
choose to have engineering managers code, you have to be careful about a few
things:

\- That the managers don't confuse positional authority ("Do it because I'm
the boss") with intellectual authority ("Do it because I'm right")

\- That the spans of control have to be smaller since the engineering manager
has less time for care and feeding. In this sense, and idea that "Keeping
managers hands on, and the organization flat" actually results in added
hierarchy. If you have 8 employees per manager, you can have 64 engineers in 2
levels of hierarchy. If you have 4 employees per manager, you need 3 levels of
hierarchy.

\- Is there room for superstar developers to emerge purely as individual
contributors?

None of these is to say that one model is any better or worse than the other.
I think it's very situational.

------
sbarg
Lots of gems here, in my opinion. This should be very helpful for anyone
moving into management.

------
tenpoundhammer
A good in-depth list that clarifies the finer points of the job. These points
could fit into the more broad container of "treat people with love and respect
as if they were mature adults."

~~~
solipsism
Respect, yes. Love? That's kind of silly. The trick to being professional is
treating people who you do _not_ love, or sometimes even like, with respect.

------
andyidsinga
loved this ..having done a little bit of tech lead and people management.

see also "managing humans..." by Michael Lopp ( aka Rands ) ..its basically
the long form and much more entertaining version of the post :)

this is the only thing i didn't like:

> Dont't

> Personally fix bugs and ship features. You have to write

> code to remain an effective tiebreaker, but that’s where

> your coding responsibilities end

....bug fixing js a fantastic way to stay in the code, and also show that most
bug fixes don't require a re-architect.

------
AndyNemmity
I agree with the vast majority, however I will focus on what I disagree with
because what's interesting.

\- Your team looks to you for leadership. Have the courage to say what
everyone knows to be true but isn’t saying.

I don't look for management for leadership, I look at management to resolve
conflicts that due to a hierarchy they are the only one given the authority to
do so.

Leadership is found everywhere, and management doesn't have any more or less
of this quality.

\- Most intellectual arguments have strong emotional undercurrents. You’ll be
dramatically more efficient once you learn to figure out what those are.

I'm not sure what you mean here. If you mean by strong emotional
undercurrents, biases.. sure. That's extremely important to determining how
rational a decision is.

I don't think it's particularly emotional though.

\- Once everyone is heard, summarize all points of view so clearly that people
say “Thanks, I wish I’d thought of putting it that way.” List any points of
agreement with each view, and state what you’ve learned from everyone. Then
make your decision.

I don't think this is because, "I wish I'd thought of putting it that way",
and more to validate that you understand the issues and arguments. If everyone
can agree that you've at least stated the situation properly, we have a
foundation on which to make a decision.

-When disagreement gets personal or people don’t accept well-reasoned decisions, it turns into conflict.

Is that a lesson? When things are conflicts, they turn into conflicts.

-If the conflict persists after you’ve gone to reasonable lengths to hear everyone out and fix problems, it’s time for a difficult conversation.

What are you implying? Firing someone? What is this difficult conversation
you're talking about?

.... There's a difficult conversation section after this... I'm getting the
impression you mean, dealing with a conflict and telling them to suck it up.
Okay.

\- Occasionally someone will push too far. When they do, you have to show a
rough edge or you’ll lose authority with your team.

I don't need shown a rough edge. You have authority because the company gives
it, that's all that's required. Perhaps these are just the types of people I
don't deal with, and thus don't have this experience.

...

By majority a lot of solid advice and thoughts. In there are some odd
phrasings and issues. Perhaps many people take value in this stuff, it's quite
possible as a person I don't feel the need for much of it because I'm not the
type that requires it.

~~~
solipsism
_it 's quite possible as a person I don't feel the need for much of it because
I'm not the type that requires it._

By that you mean... you're not a manager of engineers?

~~~
AndyNemmity
No, I am.

------
seivan
More people need to read Yishan Wongs articles about this. Mostly because I
want more work places with his methods :(

[http://algeri-wong.com/yishan/engineering-management.html](http://algeri-
wong.com/yishan/engineering-management.html)

------
kuni-toko-tachi
I approach managing software teams the way a coach approaches winning games.
Top down leadership is not edicts from the top, it's about creating the
conditions from the top using the resources available (time, team, etc) that
lead to bottom up enpowerment and action.

IMO, any "manager" who asks the question "what are you working on today?" has
no business being in the role. This type of clipboard task master nonsense is
the hallmark of someone who doesn't have the emotional, intellectual, and
leadership chops for the job. You job as the manager is to _know_ what people
are working on, not to ask. A true manager doesn't ask "what are you working
on?", they ask "how are you getting along?". Daily status reports and "what
are you working on" create natural resentment and skepticism and rightfully
so.

