
On being an Engineering Manager - RPeres
http://codeplease.io/2018/01/15/on-being-an-engineering-manager/
======
gregdoesit
>On the other hand my ability to focus on a task has dropped considerably. I
am no longer able to code for 1h straight. I would say that 15 minutes is a
victory. This is a problem I will try to fix somehow during 2018.

My suggestion is: don't try to fix it. As an engineering manager with a team
of more than 5 people, coding is no longer the most impactful thing you're
doing. Making people and the team do better is far more leverage. As a fellow
EM who also loves code, I've stopped coding at work. I find there are many,
lot more impactful activities I can do: from hiring activities, onboarding &
training, making oncall better, spending more time with my high & low
performers and building bridges with fellow EMs, PMs, executives and other
stakeholders and so on.

Also, you've not mentioned 1:1s. With a team of 12, 1:1s take a lot of my time
(I do weekly 30mins - this is a lot, but has been essential to spot issues
early and support people better)

Good luck for 2018!

~~~
base698
How do you get another job if you've stopped coding? Most jobs I've seen, even
in management, still require the interview song and dance.

~~~
cbm-vic-20
According to the "HN Who's Hiring" monthly post, nobody hires Engineering
Managers. At least, not the kind of companies that post to that thread.

~~~
sidlls
Or they come to HN to recruit individual contributors and not managers. You're
wrong, though: every month I've looked there have been one or two posts
including open EM positions.

~~~
bendmorris
One or two out of hundreds of openings. For a definition of "nobody" that
really means "next to nobody", you're making the parent comment's case.

------
gopalv
I mostly break-down leadership tasks into 4 groups

1\. delegation

2\. negotiation

3\. vision

4\. inspiration

A typical EM only needs to do two of those well, same with higher up the
ladder, though not the same two through the ranks - in my experience, great
ones hit all 4.

Delegation is mostly about tasks, negotiation is about interactions (either
salaries with HR, deadlines with PMs or even figuring out what a specific
employee wants out of a job, because not everyone responds to just money or
prestige).

Vision is more complex - a manager needs to be able to guess the rate of
funding for the current project, read the way the wind is blowing and navigate
the team.

Inspiration is so rarely seen, because it is hard to connect the results to
the actions (the "be positive" part of the blog) - but I've had engineering
managers who've made me feel that I'm in a "safe space" to do interesting
things, instead of the reality that I'm in a closely watched, judgemental
situation with large sums of money attached to each action and reaction.

~~~
gdubs
Management is not always equal to leadership. They can be very different
roles. (And, they can of course overlap.)

One is more focused on tactics, the other on strategy. One is deciding which
direction to sail, the other is making sure everyone is keeping the boat going
in that direction.

------
bonniemuffin
"giving to other engineers features that I would like to do myself" is one
that I struggle with as a data science tech lead. If I'm leading a team of
people and deciding who does what, I want to give my team members the
interesting work and not hog all the cool stuff myself, but I don't think it's
a good use of my time to be doing only the tedious stuff. I'm not sure how to
strike a balance there.

~~~
huebnerob
This is a gross oversimplification, but why not just dole out the good
projects round-robin, where you're just one of the members of the cycle?
There's no reason why a manager should _never_ be able to contribute work,
just that they probably shouldn't _always_ take the 'good stuff'.

~~~
pugworthy
Because as a lead, they may know a lot more about something, or have
experience with it, or have thought about the specific problem space a lot
more.

Sometimes it's that classic, "I can do it in 4 hours, but you will take 2
days. You do it, and learn something, and next time we'll be equals" kind of
thing.

------
darioush
> On the other hand my ability to focus on a task has dropped considerably. I
> am no longer able to code for 1h straight. I would say that 15 minutes is a
> victory... > When coding I try to be out of the critical path...

Sorry, you are no longer coding as an engineer on the team and are losing
insight into how the codebase functions with a speed you are probably
underestimating. Engineering isn't about writing code that eventually works,
it's about consistently delivering good-enough code on time.

> ... the company comes first, the team second and the individual third...

I think if you focus on building the team, there is no way the company and
individuals do not benefit. Plus, high functioning teams often stick together
across companies and employees follow managers. I'm not a manager just my
2cents.

~~~
slivym
I completely agree on your second point, obviously in the long run everything
has to be for the company, but hands on the team is number 1. Particularly in
larger organisations the only way to manage is to focus on your team and its
sphere on influence because often there is no "best for the company". The best
thing you can do is build a great productive team.

------
toolslive
Managing engineers is different from managing a manager (yes, they need to be
managed too) : you don't approach your manager with a problem, you approach
them with a choice in possible solutions. The trick is to make sure that
whatever they choose, it's going to work out fine. An engineer is different:
you don't approach them with a task or a solution, but with a problem
optionally with constraints.

~~~
aalleavitch
This is definitely the biggest pitfall I’ve run into both as a managed
engineer and as a manager. It’s intuitive to think delegation involves forming
a specific task and giving it to someone else, but that’s a waste of their
brain power. Giving them an open problem to solve is going to result in
freeing up your mental energy and will make them happier due to increased
agency. In general, you want to give workers as much agency as they can
competently handle.

------
lbotos
>As a manager, the company comes first, the team second and the individual
third.

I think managers should take a little more nuance into this equation.

As a manager you sit between the interests of the business and the interests
of your reports. Depending on the context the hierachy might actually be
individual/team/company.

If you keep the model of company/team/individual, you will be seen as great at
"managing up" (in this case also you might be seen as a "suck up"), decent at
managing across departments, and your team will probably think you could care
less about them.

There will be many times where this hierarchy changes and knowing when/how/why
those changes happens will take you to next level management.

E.G. In a 1:1 with your report _they_ are a priority. (managing down)

In a company wide address on team performance, the needs of the company+the
team need to be addressed. (managing up and across)

In an executive meeting, the needs of the company are paramount (managing up)

etc etc.

~~~
RPeres
I do care deeply about the team and each individual, some of them are my
friends. Ultimately, in order for all of us to have a job, the company needs
to succeed. But I agree with the nuance. Thanks for the feedback.

------
beilabs
While I hold the title of CTO for a funded startup I feel I have taken much
more of an engineering manager role.

Ticket review, deployment, product development and general firefighting seem
to be the order of the day; We have a team of 12 engineers, my biggest issue
is being able to let go of the important tasks and be able to trust my team
that they can deliver in the 9-5 schedule they enjoy (Entirely the opposite of
the life of a founder).

Being able to hire someone to just take some of the devops tasks off of my
plate is my immediate priority. I have certainly found that my skills are
getting a little rusty as I'm no longer in the trenches cutting code each and
every day, much more in a review / implementation position.

------
DoofusOfDeath
> Having awkward conversations, about missing a deadline, a particular
> behaviour, or some other thing, has created a psychological burden in me. In
> some cases it actually keeps me awake at night, thinking about some
> displeasing situation, which of course has ramifications in my overall
> performance later.

The best solution I've found for this is to start reading books related to
managing teams, having difficult discussions, etc.

Once I did this, I found these kinds of discussions to be more of an
intellectual exercise, opportunity for experimentation, etc. I.e., it gave me
a level of personal detachment that made the discussions much easier, and
hopefully more productive.

~~~
fprct
> The best solution I've found for this is to start reading books related to
> managing teams

Any particular position you would be willing to recommend?

------
twobyfour
> A manager should be optimistic. A team's moral compass is highly influenced
> by their lead. I am skeptical and pessimistic by nature, I find it to be
> somewhat of a struggle to keep a positive outlook. In this particular point,
> I failed.

I find this challenging too. Any suggestions from other pessimists/skeptics
for presenting a more positive outlook?

~~~
wmij
I also find this challenging. One thing I can suggest that has helped me on my
current project, is to do a morning standup. It's always brief but I use this
time to set a mood/tone for the day. I try to lead with something relevant for
the team or business, hopefully good news, but still try to motivate with a
sense of direction towards what we're working on and where we're going. We'll
each give our status and have an opportunity to bring up blocking issues,
successes, or anything else. But I've found that my team looks for this ritual
to assess my mood. I try to stay optimistic towards the effort, our business
and the opportunities we're all working towards. When it gets slightly
frustrating on a day to day basis where the "business" side may not be meeting
the "engineering" side, I try to make dry light humor where we can laugh a bit
during standup knowing that we're pointed in the same direction. Not an exact
science, but on the day to day, try to find something to laugh about. This
usually finds people willing to pair up together to take on "the cause" or
whatever the team needs to get done.

~~~
swap32
> One thing I can suggest that has helped me on my current project, is to do a
> morning standup

I've found that this is the only sane way that works if you're trying to
manage a team of 15-20 people.

~~~
kingnothing
15-20 people is 2-3 teams in any sane organization.

------
andrewljohnson
I disagree that something a manager should be chastening developers for at a
product company is missing a deadline.

When your only stakeholder is the user, deadlines are all artificial. It might
be different at a consulting company.

I'm not saying companies shouldn't estimate and schedule work, but missing
estimates is almost never an individual developer's fault, it's systemic
and/or a failure in management.

If a developer isn't productive enough for their seniority level overall...
that's something a manager has to address. But if a developer misses a
deadline, it's probably the manager's fault. It's probably the manager who
needs to be working on their estimation and tasking methods.

------
vram22
When I was doing management in software companies, I found Management By
Wandering Around (MBWA) [1] to be useful.

Being an unstructured activity (but still planned, in the sense that you knew
that you were going to do it now and then during the day or week), you tended
to get more out of it in terms of information about progress, status, issues,
and being able to help team members, technically or otherwise.

[1]
[https://en.wikipedia.org/wiki/Management_by_wandering_around](https://en.wikipedia.org/wiki/Management_by_wandering_around)

It was supposed to have originated, or at least been used early on, at
Hewlett-Packard (and also earlier by Abraham Lincoln :) see [1]).

Although I worked for a while in a company that was a joint venture with HP, I
did not learn about MBWA there, but later on, in another company where I was
doing management. Read about it in a management book, thought it was a good
idea, and tried it out; turned out that it was useful.

~~~
AllegedAlec
Not to detract from your experience, but this sounds a lot like micro-
management.

You should not have to check up on the status of ongoing projects; you
assigned those projects to someone with clear deadlines, etc. etc. If you
don't trust that person to be able to finish it: why did you assign it to him?
If you do trust that person to be able to do what you asked: why are you
bothering him about the status of the project?

~~~
vram22
Thanks for your comment, I am open to discussion or disagreement, although I
may or not agree with the specific points raised - on a case to case basis.

>Not to detract from your experience, but this sounds a lot like micro-
management.

In this case, I disagree that it is micro-management, although I do think that
if overdone, it can degenerate into that. It is a matter of degree and also of
how it is done.

See my replies and quotes of excerpts of your comment below.

>in the sense that you knew that you were going to do it now and then during
the day or week).

So the emphasis is on "now and then" (and "now and then during the day or
week" did not mean "multiple times during the day with the same person", at
least as I used to do it).

Once a day with a few people (not every member of the team per day, e.g. in
the case I am talking about, I had a team of 10, and might have had the one-
on-ones with say one to three of them per day, and not every day either), and
that would be enough, unless there were some serious issues, in which case
more management or help or guidance is definitely needed, or the manager is
not doing his/her job.

Also, it was not like I was grilling them on goals and deliverables each time
I talked to them - it was more like sitting down next to them and asking "how
is it going?" and only if they mentioned any issue or problem, would I delve
into it and see if I could help. Sometimes they would themselves tell me that
they had an issue and ask for advice/help. It was not an antagonistic
relationship. In fact the chief accountant of the company, who sat in a
section next to us (this was a company with cubicles, ha ha) once said to me
(presumably he could overhear us talk since he sat near us) that "you have a
good team". I took that as a compliment.

Actually I also used to informally (as in, not a formal code review, although
we had those too) look at the code they were working on currently, and
sometimes would spot issues (could be small ones like redundant computations
like checking the length of a string being looped over, in the for loop
itself, instead of before it (aka code hoisting - see Writing Efficient
Programs by Jon Bentley).

It was technical and project management, BTW, not MBA-type management.
(Project management might have a different connotation in Indian companies
from some Western ones, in case you don't know that. In Indian companies it
tends to be a blend of both technical and project management (as US people
understand the latter term). (I've worked in/with both Indian and US startups
and large companies (all 4 combos), that is how I know this.)

Also, in this particular team, they were all freshers, just out of company
training after being recruited, so more management was needed. [1] But I think
MBWA can be helpful even with more experienced people who report to you -
maybe at a lesser frequency.

Multiple issues with your comments below:

>You should not have to check up on the status of ongoing projects;

Sorry, wrong, IMO. A manager's job is to manage (though not micro-manage;
hell, even micro-management may be appropriate in certain situations,
depending on the skill and experience level of the managed people, and a host
of other factors.

Please don't generalize. And checking on status is a normal part of management
duties.

Repeating:

>>You should not have to check up on the status of ongoing projects;

That is so far off the mark that I am almost at a loss for words (but not
quite :) If an employee cannot handle the fact that the status of their work
has to be checked on, then they are violating the contract that they
voluntarily signed up for when they joined the company (except for free-
wheeling companies where they may be no such agreement), because in most
employment agreements, it is a standard clause that the employee has to follow
the instructions of their managers (obviously, only regarding work, not
anything else, and within reasonable limits, but status reporting and checking
is very much a part of reasonable limits).

As I've heard it said, a project or a company is not a democracy. Just check
out real democracies if you want to get an idea of what chaos can happen if
you run a project or a company as such, ha ha. That does not mean that it has
to be a command-and-control situation and everything is to be decided top-down
either - that often does not work too. It just means that there can be a
reasonable amount of discussion about how to do things, what to do, etc.,
between the team members and the manager, but ultimately the manager's
decision has to be final (mostly - and any enlightened manager who does not
have ego issues should/will accept the suggestions of team members if they are
better than what he/she thought of). Of course there can be incompetent or
evil managers, for that the remedy is to go report the issues to higher levels
or other options (including legal), as needed and makes sense.

And:

>>You should not have to check up

The manager carries the responsibility for the results of his subordinates, so
he definitely can and needs to check up. I am not sure, but based on your
comments, you might be coming from the background of _some_ small US startups,
where everything is on the fly, free-wheeling, "cowboy coder"-style, etc, or
might not even have worked much in real companies. I don't mean to denigrate
that approach in total, but in many cases, it does not work. I have been on
both sides of the fence, for non-trivial periods of time, both working
for/with small and large (so-called "enterprise") traditional companies, as
well as small free-wheeling US- and Indian-based startups, at different times
in my career, including switching from one type to the other and then back
again, so have seen both (or rather multiple) sides of the picture, and have
come to realize that there are pros and cons to all those approaches.

In fact I have even worked in traditional (aka non-startup companies) of both
the free-wheeling / "cowboy" as well as the more formal / process-driven kind.

>you assigned those projects to someone with clear deadlines, etc. etc.

Who said the deadlines were clear? Were you involved in that particular
project, so that you know?

>If you don't trust that person to be able to finish it: why did you assign it
to him?

Even this statement shows you talking about stuff you do not know about. Who
told you that _I_ assigned it to him? Can it not be the case that I was given
a team to work on for the project, and had no say in the choice of people?
Does that seem impossible to you? Do you always get to select your team
members, if you are or have been a manager? (Then you might not be much aware
of business realities, which are not always (or even mostly) aligned with what
people involved would like things to be like.) That was the case here, in fact
- I did not get to choose the team. Stop making so many unfounded assumptions.

>If you do trust that person to be able to do what you asked: why are you
bothering him about the status of the project?

See reply to above point (too). Sorry, I'll have to call that a very
idealistic and impractical notion. In business, to quote a saying: It's not
the things that are expected that get done, but the things that are
_inspected_.

[1] There is more that I can say, including some shockers, but this comment is
getting long, so I will just give a hint or two:

The company used software engineering practices (it was not a startup, BTW),
and required software engineers to use checklists for different phases of the
s/w dev life cycle.

I have seen (example of shockers) team members do things like dutifully place
a printed copy of the checklist for, say, program spec creation or unit
testing, on the desk at the side of their PC, and then proceed to happily
ignore it while doing the actual work!

Another and worse example: a dev on my team (actually saw this on his screen)
wrote an if statement to check for an error after some operation, and then
happily printed a message that there was an error, and _went on to write the
code for a following operation (after the if statement and error message
printing) that depended on there being no error_. IOW, print the error
message, but then go on as if no error happened!

I rated him the lowest of the team during appraisals, because that error of
his was avoidable by sheer common sense; you do not even need to understand
anything about programming to avoid it. I mean, it's like saying: I see a deep
ditch in front of me, I yell out a warning about it, then proceed to fall into
it!

Of course this was an outlier, but you may be surprised about how often such
kinds of blunders can happen, even at somewhat higher levels in companies.

(Edited for typos and re-wording.)

------
DoofusOfDeath
> Improve my ability to focus.

Depending on how bad this is, and how long it's been a problem, you might
consider getting tested for ADD.

I waited _way_ too long to do that, and I had decades of unnecessarily reduced
productivity.

~~~
DoofusOfDeath
Or even without ADD, you might wish to look for a correlation between your
attention span vs. how well you slept the night before.

Getting a good night of sleep seems to get more difficult as we get older.
Lack of sleep impacts many aspects of mental performance, including attention
span IME.

------
Chyzwar
The direction is most important, everything else is secondary. I can develop
better code if I know what is coming in following months. I can optimize where
it is needed or hack quick solution when I know technical debt cost.

Being a team cheerleader is nice but leading in the right direction is
critical. And yes, you need to be technically sharp if you want to make any
assessments on individual performance. Code reviews, architecture design,
post-mortem and sprint reviews should be EM main thing.

------
jlengrand
So happy to hear that I am not the only one suffering of #6 \o/. This has been
really bumming me over the last months.

