
How to fail as a new engineering manager - andygcook
https://blog.usejournal.com/how-to-fail-as-a-new-engineering-manager-30b5fb617a
======
sytelus
I as a manager “kept coding” and it made me a better manager 100% of the time.
It allowed me to understand low level issues team had been facing that I
couldn’t have from 35,000ft. Team members didn’t felt need to dumb down
complex concepts so I “get it”. People didn’t had to prep PowerPoints all the
time because I could only grasp pretty pictures. I much better understood the
complexity of workitems, costs, collaboration opportunities, scheduling and
skills required which allowed me to do much better estimates and task
assignments. I didn’t had to find “deputy” who I delegate everything while I
am just busy in meetings and emails. Ancient Greeks like called this type of
management as “leading from the front”. Chinese called it working shoulder to
shoulder with your team mates instead of trying not to get your hands dirty
because, you know, you are too “busy” and a level up high. Being able code
(not in just imagination, but _really_ code) puts “Engineering” in the
“Engineering Manager”.

~~~
lmm
I'd be interested to see whether your subordinates agree with that assessment.
One of the better programmers I've worked with was promoted to our manager and
tried to "keep coding" and it made her one of the worse managers I've had: the
team was constantly blocked because her tasks got delayed when she (as is the
nature of management) was pulled away for meetings with higher-ups or other
unexpected work. In turn that meant there was pressure not to interrupt her
when she was at her desk so it was hard to bring problems to her, even though
that's a manager's primary responsibility.

~~~
fatnoah
I realized early in my management career that I should keep coding, but I
should a) never let it interfere with my management duties and b) should only
be for non-critical path stuff. I focused on quality of life type improvements
such as sprucing up a dashboard used by ops personal, refining the CI/CD
process, simple utilities to extract/transform data, etc. Another key
requirement and benefit is that by letting your team do the "real" work,
you're showing your trust and letting them grow.

The place where I continued to actively participate was in architectural and
system level planning discussions. In that capacity, it was to mostly ask
questions, ensure focus on objectives, and very occasionally offer advice.
It's mostly facilitation and mentorship.

------
slivym
One thing I think this misses that is REALLY worth knowing as a new
engineering manager: you might not want to be an engineering manager. People
often view it as a seniority step or a power step or a salary step, but there
are three things that go on- especially at large organisations:

1\. You have no power. You really don't have the freedom to change salaries,
you don't have final say on promotions, you often don't have final say on work
commitments, often a lot of work needs to be done that simply isn't exciting.
It's a killer to have a development plan for someone that's totally un-
acheivable because that's simply not what your team does.

2\. You are the shit shield for your team. Especially working in a remote site
decisions will be made that totally screw your team and you're responsible to
deal with that. Whether it be other teams breaking fundamental dependencies,
or senior management forgetting why your team exists and deciding it can be
cut, re-assigned, re-prioritized. Often being the person who gets the brunt of
that is incredibly difficult to deal with.

3\. Your job is now 100% political. Whether it's the expectations your team
puts on you to deliver them pay rises at the end of the year, or your product
manager putting expectations on you to deliver releases at certain times a lot
of what you're doing is politics. Especially in large organisations there'll
be projects that are going to fail, and learning how to protect your team from
the fallout is essential. It's a shit part of the job but in large
organisations it's essential.

~~~
mabbo
> You have no power > You are the shit shield > Your job is now 100% political

By any chance do you work at Amazon? Or is that just common everywhere?

~~~
eikenberry
This is the standard at pretty much every large company. If you want to escape
it you have to go to small/mid-sized companies. While they will still have
politics but not near the soul crushing levels it is at large companies.

------
nxc18
Every software engineer needs to read this. Managing people is it’s own skill
all its own. Programming skills don’t translate.

Business folks: please create parallel technical and managerial career paths.
This can go all the way to the CEO (CTO) level - great devs can be great devs,
great people/business folks can be great at managing.

I see it daily:if your manager is programming, he’s not managing. Of course
there are exceptions, but as a rule, if you’re a senior dev, you’ve probably
been focusing your attention on tech and not people for a long time. There’s a
crazy amount of nuance, self awareness, humility, patience (!!!), empathy, and
conscientiousness needed to be great at managing.

Underperforming manager -> underperforming devs

HR management should be taken seriously as an engineering (as much as software
is currently) discipline and not just an afterthought for devs to pick up.

~~~
enraged_camel
>>I see it daily:if your manager is programming, he’s not managing.

Management does not have to be an “active” job.

Great managers find out what obstacles are standing in the way of their team
members, then figure out how to remove those obstacles. How much time this
takes greatly depends on the company.

IMO a senior dev is different than a manager. Senior devs mentor junior devs;
that is where their team productivity multiplier comes from.

~~~
watwut
> Management does not have to be an “active” job. > Great managers find out
> what obstacles are standing in the way of their team members, then figure
> out how to remove those obstacles.

Finding out obstacles and removing them is an active job.

But also, the saying about merely "removing obstacles" is not really correct.
I am not even sure it is so in the happy flow where every employee is super
great and full of initiative and is at exactly the right position. Managers
are expected to coordinate, set priorities, negotiate about deadlines and
scope of project, plan and re-plan, explain why we are going to be late,
handle communication outside of team, clean up tracker, make sure testers are
available, collect reports about who worked on what.

If all manager is focusing on is "finding out obstacles and removing them",
you all have high chance of ending up in long term crunch and chaos.

~~~
lmm
> Managers are expected to coordinate, set priorities, negotiate about
> deadlines and scope of project, plan and re-plan, explain why we are going
> to be late, handle communication outside of team, clean up tracker, make
> sure testers are available, collect reports about who worked on what.

Much of that can and maybe should be done reactively. Set priorities when your
employees need them. Negotiate deadlines and scope when they're needed for a
decision. Communicate when it's needed. Etc.

You may not be literally twiddling your thumbs - I'm sure there's always
something to be improved even in the quietest periods - but IMO the most
important part of the manager role is to be available to resolve issues that
do come up, and I'd take a manager who can do that well over one who's great
at planning but can't react. As a technical analogy it's more like
sysadmin/ops than development.

~~~
watwut
Ideally, deadlines and scope are negotiated continuously as the pressure on
typical team is constant and as there is constant flow of incoming
requirements. Being unprepared means higher chance of crunch or buggy releases
(as team cant cope with what becomes expectation).

Same with priorities. Those are not just for employees, but also for people
outside the team. When you are asked about priorities and future, it is best
to have reasonable answer at that time - not two weeks later when you finally
reactively done reading and thinking.

Employees often dont really ask about priorities. They assume priorities based
on their previous experience/opinions, everyone different which leads to
misunderstandings and waste of time. You have to sync them before they ask.

If the primary role of manager is to constantly react at suddenly appearing
problems, then the company needs more planning and more organization. Those
suddenly appearing problems are consequence of chaotic environment. Good
manager reorganize so that they don't appear anymore or looks for them before
they grow big and sudden.

~~~
lmm
> deadlines and scope are negotiated continuously as the pressure on typical
> team is constant and as there is constant flow of incoming requirements.

Incoming requirements aren't actually continuous; indeed in practice they tend
to be quite bursty. When you get a new batch of requirements is the best time
to evaluate their priorities and schedules.

> When you are asked about priorities and future, it is best to have
> reasonable answer at that time - not two weeks later when you finally
> reactively done reading and thinking.

Two weeks later the priorities will likely be different. Long-term planning is
usually wasted effort.

> Employees often dont really ask about priorities. They assume priorities
> based on their previous experience/opinions, everyone different which leads
> to misunderstandings and waste of time. You have to sync them before they
> ask.

If employees don't know where to look for priority information that's a
problem to be fixed.

> If the primary role of manager is to constantly react at suddenly appearing
> problems, then the company needs more planning and more organization. Those
> suddenly appearing problems are consequence of chaotic environment.

The world is chaotic. Reacting to change is often cheaper and more effective
than planning and organisation.

~~~
watwut
1.) Requirements sometimes come in batch, but even then the following
discussion and clarifications take weeks and months - depending on size of
project.

2.) If your priorities are changing every two weeks, then you have no
priorities. This is literally what management is supposed to avoid.

3.) The point was that employes are not aware they have priorities wrong. They
are not asking, because they all assume they know what to do. Again, which is
why you are supposed to clarify it proactively.

4.) If you have same sudden problem fifteenth time, then it is not change. If
all of your projects end in crunch surprisingly and none of your plans work,
you are doing it wrong.

~~~
lmm
> If your priorities are changing every two weeks, then you have no
> priorities.

Nonsense. Two weeks is - or should be - plenty of time to make a useful
improvement to your product.

> The point was that employes are not aware they have priorities wrong. They
> are not asking, because they all assume they know what to do.

So fix that problem. Make sure they know when they should be asking about
priorities. Don't just saturate them with priority information, that will
annoy the ones who knew when to ask, and the ones who think they know won't
pay attention anyway.

> If you have same sudden problem fifteenth time, then it is not change. If
> all of your projects end in crunch surprisingly and none of your plans work,
> you are doing it wrong.

If most of your plans succeed, you are not taking the risks that you need to
make the big wins.

------
klenwell
Whenever this topic comes up, especially developers or engineers transitioning
to management, I point to this Hacker News thread from years ago:

[https://news.ycombinator.com/item?id=3407643](https://news.ycombinator.com/item?id=3407643)

There's a lot of overlap with this article but it covers a broader range of
experience and also includes some good reading recommendations.

It's been invaluable to my own career.

------
purplezooey
Most of my engineering managers are usually just lieutenants for the next
layer up. That person brought over his/her stooge collection from their
previous company or collected over the course of their career. When you see a
stooge collection forming, you know it's time to go. Not addressed in the
article.

~~~
marsrover
Could you talk a little more about this? I’ve never encountered a stooge
collection but when I interviewed for a job right out of college the CTO of a
company told me that “this lead dev had a few friends follow him here since
he’s so good.” Is that likely a stooge collection?

~~~
mharroun
As someone who has seen others do this as well as being a manager who tends to
rehire people, again and again, I would say "it depends".

Leaders tend to build connections with people who have personalities, goals,
and/or work ethics that are similar or compatible with that leader. So if you
like that particular leader/manager it's more then likely those followers will
be good. The opposite is also often true.

As people move into more senior management roles there is an expectation that
you have built some form of network.

------
NPMaxwell
One way to avoid 4. Expecting without expressing, is to make sure that you
have confidence that anyone on your team can fill in for you in a meeting you
can't make, and correctly report your objectives, plan, strategy, and
reasoning. If they can, then they know your thinking, and you have expressed.
A side benefit is that they may know a lot more about their areas than you do,
and they can correct your mistaken ideas -- but only if they know what your
ideas are.

------
jetako
> 1\. Keep Coding

Hardest pill to swallow, but it's mostly true. The old adage, "If you want
something done right, do it yourself" is a subversive kind of fallacy, because
it's half correct. Yes, you could probably get it done better and sooner, but
every minute you spend doing it yourself could have been invested in
empowering your team.

~~~
rb808
Yes it is mostly true if you are going up the career ladder all the way to
executive level.

However I've seen a bunch of people hit middle-management then stop and its a
really vulnerable place if you're looking for a new job. I think its really
important to be able to keep some coding in new technologies as they become
popular.

Perhaps the best is to work with your developers code - write integration
tests, evaluate checkins, research new tools.

~~~
bonniemuffin
+1, I think it's critical to stay technically sharp, but that doesn't have to
mean pushing user-facing code to production. I can only recall one time I've
actually checked in production code since I transitioned to manager (and I
definitely felt like I was shirking my manager duties by sinking a day into
it), but I stay close to the code in 2 ways:

(1) I review the majority of the code that the team writes, and I also read
other people's reviews to evaluate our code review practices.

(2) I hack around with new tools & technologies to evaluate them. This has
resulted in some code bits in wikis documenting "here's how to get started
with this thing", but not touching any prod systems. I usually save this kind
of thing for our "personal projects"/hackday days at work.

------
jamifsud
I’m less than one year into my first management role. The job often feels like
the early days of my software engineering career when I was pushing code as a
junior dev with an extremely high internal bar and little experience (read:
had no idea what I was doing).

The experience has been fun and exciting but its a mental and emotional grind
more often than not. Knew it would be difficult, but I've found the learning
curve to be far steeper than I expected. Its really helpful to read some of
the hard earned lessons I’ve been thinking about recently expressed so clearly
(#3 and #4 especially).

Thank you for posting.

~~~
theshadowknows
I recently transitioned to architect from lead engineer and it’s been very
jarring. My day to day went from leading a few meetings here and there and
smashing hard bugs to near constant meetings with people higher and higher up
the food chain (just yesterday I was presenting to the president of our parent
company). Where as 3 months ago I would say “sure, I can do that” and then
fire up vim and go to town. Now I’m fighting with sr. Directors and asking
them “What is this in service of?” And I do very little coding outside of
producing proof of concept work. I do like it but it’s just entirely different
work from what I’ve been doing the past 8 or so years.

------
allsunny
I agree with the general idea that the most important skill is managing
people, not technical, with engineering management. However, my advice is to
never go full manager. If you can, jump in from time to time and help dig the
ditches.

I like the idea of playing a supporting role on the team. You're there to help
the team get done what needs to get done. Most of the time that's going to
broader organization meetings, planning, providing growth opportunities etc.
However, when there is technical work that needs to be done, I'll gladly jump
in and help out as much as my technical skills allow me to. By the same token,
if I'm overbooked, out of the office, etc, I'll ask my team to help out with
organization meetings, planning and similar activities. I want folks to know
that we all play a role and have skills that allow us to participate in some
activities more effectively than others, but at the end of the day our greater
success comes with our ability to execute as a team, not as individuals.

------
Eduardo3rd
I’m a big fan of “Mistaking directing for leading” here. So often I see new
leaders mistake their new responsibility for results with a need to be in
charge of every decision. There’s a big difference between leading and simply
being in charge. Don’t base your own habits on the poor management styles
you’ve seen in the past.

------
ggm
_7) Avoiding hard conversations_ This is the one I failed at hardest. Well..
my teams might say that accepting arbitrary deadlines was worse, but this is
what I personally took as the signal I wasn't suited:

 _I just couldn 't give negative feedback during performance review_

~~~
rejschaap
You probably shouldn't give negative feedback during performance reviews
anyway. Feedback should be given as soon as possible.

Not giving feedback at all is a problem though, first get comfortable with
giving positive feedback. Don't move to giving negative feedback too quickly
as a new engineering manager.

~~~
jaegerpicker
I, excuse the language, called my technique "a shit sandwich" for getting
comfortable giving negative feedback. I'd establish with both the employee and
myself a pattern of giving both negative and positive feedback at the same
time, instead of only negative. I'd give something good, something bad, and
then something good hence the sandwich. I've found that if you are all
negative it's too easy to lose an employee and there motivation. By using the
sandwich you so that you notice the good and the bad and that you are pulling
for them to fix the bad.

~~~
Joof
That's how you're supposed to do it. My manager had a nack for only giving the
negative feedback 3 or 4 times.

~~~
saltyhiker
If you build a good rapport with everyone, this is unnecessary and you can
simply provide constructive feedback without sugarcoating it. The best
engineers will see right through this.

------
ilyanep
I realize this isn't really the main point of the article, but it's something
I've been thinking about a lot recently: Can someone explain to me why I
should _want_ to become good at management? I think most people on here (but
sadly few company structures) would agree that engineering and engineering
management are two nearly orthogonal skillsets, but for some reason we insist
on "promoting" people who are good at the former into positions that require
the latter.

As someone with about five years of experience as a professional software
engineer, I'm really still looking to level up my IC chops, along with a
healthy dose of mentorship (mentoring interns or new hires on my team) and
what I'd call "tech leadership" (advising on engineering reviews, making
technical decisions about how to best build things). I would basically worry
about stunting my development as an engineer if I switched to focusing on
management, and I'm not even convinced my role models for career development
are really in primarily "managerial" roles (I'm thinking of both famously very
good backend devs both at my company and at the big SV companies).

Separately, I have relatively little interest in being in a role where my
output is judged as the output of a team of people who aren't me. I get that
that's the best way to judge managers, and that managers do very valuable
intangible things in unblocking their team, but I'm skeptical that I'd be able
to feel satisfied by this. If anything, it kind of feels random: at an
equivalent level of my unblocking the team and being a good manager, if I have
an amazing 10x engineer on my team then the output is just going to be higher
than if I have an average engineer. So in less clear-cut cases, how can I tell
if I just did a good job at unblocking or if my engineers are really good?
(This is not to say that I don't feel satisfied doing mentorship-style things
or architectural advising-style things, but that feels separate to me. I think
I prefer empowering other engineers by leveraging knowledge and writing good
platforms/tools/APIs rather than doing the organizational empowering thing).

I write all these things, because it really seems like a foregone conclusion
of both this article and the industry as a whole that an engineer will
eventually become a manager. Is that what I most likely have to look forward
to in my career if I wind up working at the well-established/mature companies?

EDIT: I'd also just appreciate being told if I'm thinking about everything
entirely wrong or something here.

EDIT2: This also isn't to knock people who _do_ enjoy doing these things, but
it's not for me and I imagine it's not definitionally for every good engineer.

\-----

Unrelated to the above, point 8 feels a little bit in contradiction to point
1. How does one keep learning their craft without direct experience?

~~~
ryandrake
What I've seen a lot is lots of companies do not have a meaningful Individual
Contributor technical career track. You join as a junior developer, then 5
years later you are a "Senior Software Engineer" and that's it. Your salary
flatlines, your project responsibility/impact is capped, with no further
opportunities to grow career-wise. Join another company? Fine you get a 5-10%
pay bump but you're still at the highest level: The dreaded "Senior Software
Engineer". OK, so some places have a "Staff Software Engineer" or "Principal
Software Engineer" or whatever they call it. It's still basically the end of
the road for a non-manager. So few places offer anywhere to grow after
reaching this level, besides management.

These companies then say, "Hey, engineer XYZ, you seem to be smarter than the
average bear. We would like to reward you with career growth, but we are not
imaginative enough to come up with something beyond Senior Software Engineer.
How about instead we make you a manager? Go, here is a team of people, go off
and learn this entirely different skill set and manage people! What could go
wrong?" That's pretty much how most places make engineering managers, and it's
tragic. Here we have some of the smartest, technically competent people. I
mean they rock as individual contributors and should be thriving. But they're
not because they don't want to be managers, they just want a software
development career!

To me the solution is to simply let coders code and hire managers to manage,
and provide equal career and salary growth to each group!

~~~
tlarkworthy
How can a lone engineer scale their impact after senior? I literally think the
career ladder flatlines there because business value flatlines there too. It
be nice if companies had work above it but I think it's hard.

~~~
gesman
Here is a hint for you - don’t only show your boss what you can do - show the
world what you can do.

Then 10% pay raise may suddenly evolve into 100% at way cooler place

~~~
tlarkworthy
My point is not about pay. It's that I can only do so much, and the only way I
can acheive more is by having a pyramid of engineers underneath me doing the
coding.

~~~
sidlls
Then you need to be a manager. Organizations where there is a tech lead who
does people management, or where it's "flat" (i.e. no managers) tend to
develop informal, unspoken, or hidden political structures that fill the role.

------
zoomablemind
When offered to 'move up' into a Manager's role - the first thing is to
understand what has changed in the Team or Company.

If the position has been vacated by someone who just left, you may see what
expectations on the role have stayed in the Company. These may be 'projected'
on the new Manager (no matter what the job description says). This would
impact the ability to meet your own vision of success in that role.

If this is a new position, created just for you - again, there might be some
unexpressed reasons based on what has led to that decision. If one knows the
history and the decision makers, one could measure degree of freedom to have
any impact in that role.

As others here pointed out, it's a move from a Senior Dev to a Junior Mgr. As
such you are Junior on someone's Team, with all the baggage that comes with
this.

Politics does not begin at Manager's level, but failing to see how the
politics works there is what effectively dooms a new Manager.

Article lists many practical points that are team-facing. My personal
favortite is #4 (express your expectations). Equally crucial should be the
management-facing points.

I find that for someone with a strong technical background one of the hardest
management side to adopt may be a _negotiation ability_ and a capacity for
compromise, especially with the very little leverage as a Junior Mgr usually
has at her disposal.

------
Rowaway45
I wonder where do you get those mentoring managers with one on ones. Coaching
and all thut stuff. No one has time to do it.

It is always: here is your job that are requirements. No meaningful one on
ones. It is not only in work, I just all life have to figure out taxes,
relationships, learning, work. What is even better when I was trying to pay
for advice of accountant they did not take my money and no advice. I got
advice from attorney but it was useless, I figured out later on my own.

Oh I got some advice from relatives like uncle or grandma but that was like
outdated and totally not true anymore. Almost got fined for trying to apply
that.

So my point is no one cares about one on ones and mentoring, and someones
advice on life or carreer because probably they still have to figure all on
their own, and they think they are smarter. so better keep track of tickets
and that stuff is rolling, keep obstackles away from team and don't say yes to
everything.

------
breckenedge
> Expecting without expressing.

Absolutely this. You have to let people know what you expect and where they
stand, and with honesty and compassion.

I'm surprised this article doesn't mention setting boundaries. As a leader
(and coder), the best thing I've learned to do is set aside regularly-
scheduled time to meet with individual colleagues. People no longer walk into
my office or ping me on Slack when they run into technical problems. They take
the time to think through things before bugging me and often come up with
solutions on their own. It works wonders. Don't be a jerk about it, but don't
be as available. If someone interrupts you with a technical problem, tell them
that both of you should set aside dedicated time to discuss and explore it.

------
kixpanganiban
So much solid advice in here. As a new engineering manager myself, thank you
for posting this.

~~~
vvanders
If you're looking to expand on this I can highly recommend rands[1] as a great
source of a wide range of engineering topics. Good stuff not just for managers
but anyone involved in the well-running of a team(which is everyone!).

[1] [http://randsinrepose.com/](http://randsinrepose.com/)

~~~
JimDabell
There's also the Rands Leadership Slack: [http://randsinrepose.com/welcome-to-
rands-leadership-slack/](http://randsinrepose.com/welcome-to-rands-leadership-
slack/)

------
lifeisstillgood
I think a lot of the time we should learn from good/successful OSS projects

\- Have clear rules about code quality, how to get code in, enforce rigorously

\- Have open, written discussions about what is going to happen next (Agile
can do this, most of us take the lazy option)

\- discuss ad nauseum

\- try out new things - lots of spikes. The spike to new code ratio for a
mature product should be large

\- then and only then worry about the way you fit into politics and people

------
profalseidol
For more of this, I recommend this podcast:

[https://softskills.audio/](https://softskills.audio/)

Called Soft Skills Engineering Podcast. It's hosted by two seasoned developers
whom experience becoming managers. It's hilarious.

I listen to it when I commute with earpohones, then and suddenly laugh like a
wirdo.

------
patsplat
Find that much of my IC work as a Tech Lead is spent protecting my team from
requests that distract from their goals.

That and keeping the build running smoothly.

------
karmakaze
Excellent summary with one caveat: balance (1) and (8):

    
    
      1. (don't) Keep coding
      8. (don't) Stop learning your craft

