
Coding as an Engineering Manager - gergelyke
https://nemethgergely.com/coding-as-an-engineering-manager/
======
JimDabell
I think a lot of organisations (and people) fall into the trap of thinking of
an engineering manager as a more senior tech lead, when in fact they are very
different jobs with very different modes of working.

As soon as you start taking on managerial work, your development productivity
starts to fall rapidly. I've never found a happy medium, nor have I seen
others achieve it. People who try to do both quickly settle on ~80% of one and
~20% of the other. Which is fine if you acknowledge that you can only do ~20%
of the other, and that the shape of it is likely to look very different to
when you were spending 100% of your time on it.

As others have mentioned, if you are an engineering manager and you still want
to dedicate some of your working time to development, you have to take
yourself out of the critical path. Nobody wants to hold up a release because
you were working on an important part of it and you've been constantly
interrupted all week with managerial work and meetings.

Instead, pick things that are either tiny or decoupled from the release
process. Things like refactoring, non-critical bug fixes, documentation,
tests, spikes. These are the kinds of things that won't fall apart if your
development productivity is unpredictable and the kinds of things that are
easy to put down and pick up again. As an engineering manager, you're
interrupt-driven which is incredibly disruptive for focus. If you do write
code, then it has to be the code that works within those constraints, or
you'll end up being a blocker for the rest of the team and your managerial
work will suffer as well.

~~~
deanCommie
Agreed with everything you said, and will add 2 major points:

1) God help you if you choose 80% coding and 20% management. Your team will be
very unhappy. Maybe you'll take care of the HR/Admin work that noone else can,
but their career growth will stagnate, and morale will be low.

2) If you do pick 80% management, and 20% engineering, understand that your
growth as an engineer will completely plateau. Yes, you can still participate
in design reviews, even weigh in on code reviews, and ship the occasional bug
fix/perf improvement/nice-to-have feature or some operational tool that will
save your team a bunch of time and make your oncall happy.

But without hands on struggle with a new paradigm or scaling challenge, you
won't grow. And given the choice between improving as a manager or improving
as a hands on techie, you have to make the choice to work to improve as a
manager, and start doing all the invisible things you never realized a manager
does (least known and most annoying is managing UPwards)

SOURCE: Just spent a year stepping into a vacant engineering manager role on
my team, tried to do the 80-20, didn't love the management role, am back to a
full time senior engineer, and am frustrated with my skills that appear to
have atrophied.

~~~
cyrux004
what kind of managing do you do ? I dont spend more than 1 hour a week with my
manager, so I am not sure where your time goes ?

~~~
JimDabell
Off the top of my head, these are the kinds of things engineering managers
often have to deal with:

Hiring:

\- Writing job specs.

\- Dealing with recruiters

\- Reading CVs/résumés

\- Interviews

\- Onboarding

\- Outreach

\- Who do you need to hire next quarter to avoid capacity problems?

People:

\- How do you level up your developers? What new responsibilities can you
delegate to them so that they can grow without swamping them? Are you
available enough to them so you can help them take these new tasks on?

\- Evaluating training courses / conferences etc.

\- Are there any personal or interpersonal problems that need sorting?

\- What can you do to help your team gel better and feel like they are part of
a team?

\- Where are your team members' careers heading and how can you help them get
there?

\- Your team has grown too large to manage effectively by yourself. How do you
split things up?

Process:

\- What is everybody working on? What will everybody work on next?

\- What are people blocked on? How do you unblock them? What is likely to
block them next?

\- Can you do things in a better way? How?

\- You've got a lot of bugs in the backlog. Is there a root cause? Are there
any patterns?

\- You aren't performing as well as you thought you were. Where is the time
being spent? What's the cause? Are the estimates wrong or the performance?

\- Some people want to shift their hours or work remotely. Can you accommodate
this? Do you have to adjust process and if so, how?

Line management:

\- Approving invoices

\- Approving holidays

\- One on ones

\- Salary review

\- Getting people back to work after sickness / parental leave / sabbaticals

\- Disciplinaries / performance problems

\- Firing / redundancies

\- Exit interviews

Planning:

\- How well is your team performing? How do you measure this and how do you
improve?

\- Do you have enough capacity?

\- If not, which features do you bump?

\- Are there any bottlenecks in the pipeline?

\- What are you telling the shareholders you're delivering next quarter?

Product:

\- Does marketing know what you are building next? What information do they
need from you to sell it?

\- Do CS know how to support your customers with the new features?

\- Feedback from the rest of the business about the product and how the tech
team works.

\- Are the specs precise, correct, complete, and achievable?

\- Features have been requested. Are they technically feasible? What's the
general size of it and what quarter can we deliver it by?

\- A big customer has a major problem with your product. It's not your fault,
but it has a disproportionate affect on the customer. How do you prioritise
solving this problem?

External:

\- A shareholder owns a business with a related product that they want
integrated ASAP. How do you deal with that pressure without disrupting your
plan?

\- One of your suppliers has a data breach that has leaked your data. How do
you deal with that? Have you defined processes for reporting security issues?

\- A supplier is failing to perform adequately. Can it be fixed? How do you
move away? How soon? Where does the work fit into the schedule?

\- A supplier has changed their pricing structure. Do you have to move? How
soon? Where does the work fit into the schedule?

\- New legislation has been passed and you have to make changes to your
product. What are the requirements?

\- A complaint has been made about the accessibility of your product. Does it
have merit? What's the impact of fixing it, and how urgent is it?

\- A big prospective customer is on the verge of signing, but they must have
one feature that you weren't planning on building until next year. How do you
rearrange things to get the customer with minimum impact?

\- A service you use is changing their API. What's the risk of staying on the
deprecated version until it can be planned in?

~~~
shard
Amazingly thorough list. Did you compile it from your experiences? What field
of engineering are you involved with? Hopefully you did not experience all
these problems personally.

~~~
JimDabell
Yeah, virtually all of it is from personal experience, although the most
negative ones are fortunately rare! I manage a team working on a platform that
lets non-technical people build communities through web & mobile apps, so the
tech we're dealing with is roughly Rails / PostgreSQL / VueJS / Swift / Kotlin
/ AWS and you could loosely describe us as a social media startup.

I guess if I could summarise the above, it's that there's an awful lot of very
ill-defined and irregular things that need deciding about and acting upon, and
it's an engineering manager's job to corral that into some sort of order and
make sure it all happens. Lots of spinning plates and dealing with things that
don't really fit neatly into a job description, especially at smaller
companies.

------
leothekim
I used to be dislike the idea of being an engineering manager and wanted to
stay in the code. Interestingly enough, having children completely changed my
perspective on management. Some important management skills - e.g. patience,
delegation (babysitters!), investing in someone's overall productivity and
long-term success (Schools! Extracurriculars! College!), prioritization
(family comes first!), sometimes cleaning up after someone else's messes (with
kids, literally!) - come from being a parent.

I'm half joking, but only half! I believe part of being a good engineering
manager is having had hands-on software development experience so as to better
keep a check on velocity, code quality, and overall tech decision-making. Much
in the same way, I feel like I can be a good parent and can teach my kids how
to process their world because I've lived it before.

~~~
vanadium
Having a kid during my transition to management (in the absence of existing
management) brought me to the exact same thought process, and it's a dead-on
observation I live every day six years later. It becomes much less about the
executional skill, and much more about the aspects you listed above. The
skills involved in parenting and managing are one big feedback loop of sorts.

Having someone that can see the forest for the trees and chart/change course
as a team is, additionally, crucial. It's just that, at home, it's not just
me.

------
lordnacho
I always make sure I can still compile and execute the code. If I can't, I get
someone to update the README files so that I can. That also helps me make sure
new members can be onboarded.

I also do off-critical-path features and bug fixes. That said, I did write a
fair bit of the code base before taking a more managerial role, and I
contribute to discussions about what will make the thing faster.

~~~
ansgri
Compiling and running your team's code could be the most powerful excercise to
stay connected with the engineering part. Way too often I would discover that
some functionality declared as 'done' cannot be demonstrated in any way, and
such discoveries initiate discussions leading to meaningful decisions.

~~~
lordnacho
Yeah exactly. I see it as a form of QA. It's not serious if discovered early,
but I've come across times when there was some new dependency I didn't have,
forcing me to google how to install it. So then I tell the team and someone
will update the docs.

Basically, if only the people who wrote something can compile/execute it, it
isn't done.

------
mwfunk
I've worked in organizations that promoted engineers into management, rather
than bringing in outside managers or managers without engineering backgrounds.
For highly engineering-driven orgs this can make a lot of sense, and depending
on how it's done and the people involved, it can produce great results.

However: when those managers hold on to their engineering responsibilities,
their teams suffer for it. There's a negative stereotype among engineers that
managers don't do anything anyway, so maybe the team just needs a designated
engineer to play manager in order to go to meetings, approve days off, etc.-
the bookkeeping parts of management, but not the managing parts of management.
There's a perception that the other engineers on the team are super self
sufficient, what do they need a manager for anyway?

Often these managers would be allowed to continue doing engineering as a
motivator- they didn't really want to be managers in the first place, let's
just let them keep doing their thing and throw some more money at them and
everybody will be happy. But it really feels like an antipattern.

Working on different teams where managers didn't do any coding was a breath of
fresh air. I didn't know what I was missing. Managers can do the most good by
focusing on things that allow their engineers to be as focused on their work
as possible, and as unblocked and undistracted as possible. It makes a huge
difference. It doesn't matter how incredibly self-sufficient an engineer
is...if they get stuck doing a bunch of extra non-engineering stuff because
their manager doesn't manage, their work and happiness will suffer for it.

So, at least based on my own experiences, I've come to see teams where the
manager still has engineering responsibilities on their own team as a red
flag. Anecdotal and highly contextual to where I've worked, but that's been my
experience.

~~~
wasted_intel
Can you provide specific examples of things that you found the most useful
when you finally had a full-time/non-coding manager? Having somewhat recently
transitioned into an engineering management role, I'm curious if there's
anything (or situation) in particular you'd highlight.

~~~
mwfunk
This is all in the context of large tech companies, so YMMV. Things like,
going to high level meetings so engineers don't have to, and making an effort
to keep engineers from getting sucked in to too many meetings period (at
least, ones where their presence isn't critical).

Helping with bug management and task prioritization, minimizing engineers'
multitasking to maximize productivity, and guiding the team towards long term
goals. Engineers tend to be super focused on their immediate and short term
tasks- what they're supposed to be doing right now. That can make it hard for
a team to collectively maintain trajectories towards long term goals over the
course of months and years. IMO a good manager will be the ultimate maintainer
of the long term goals, and can helpfully keep everyone on track as they
individually focus on shorter term stuff.

Also, enabling their engineers' professional development. Many engineers
really thrive when they're tasked with something that involves learning and
using some technology that they don't know, but are curious and excited about.
As much as possible, if it aligns with team goals of course, it's great if
people get a steady trickle of these kinds of tasks. Only if they'd want them,
of course. It feeds their curiosity and creativity, and helps the whole team
keep their technical edge. But these things are unlikely to happen unless the
manager picks up on the interest and potential, and explicitly tasks someone
to do it.

Finally, it might sound silly, but making a point to do pleasant team building
stuff like bringing in bagels or donuts for everyone once in a while, or
having the occasional team lunch at a cool restaurant (assuming there are cool
places nearby). Also t-shirts. :) Quality t-shirts provide a surprising amount
of bang for the buck in terms of goodwill, at least in large tech companies.

~~~
wasted_intel
These are great; thanks for the insight!

------
ilovecaching
We don't let managers code where I work. We also don't let them do anything
technical besides match employees to work they want to do. Your manager is
just there to make sure you can focus as much as your time as possible being
productive.

I really like this approach, it's extremely bottom up. It's not that I think
our managers don't have technical skills. They all have impressive backgrounds
as SWEs etc, but this setup is for the best. The alternative at other
companies I've worked for ended up with managers who slowly lost their
technical skills and essentially fossilized, and couldn't make rational tech
decisions, and managers who intertwined their management success with the
product and drove it to ruin because they weren't making the best technical
decisions for the product.

So please, if you're a manager, stop coding. Manage people, unblock them, make
sure they are happy. Empower them to do the coding for you.

~~~
jimejim
"We don't let managers code where I work."

"...ended up with managers who slowly lost their technical skills and
essentially fossilized, and couldn't make rational tech decisions"

There's a connection here. A technical manager can't make reasonable tech
decisions unless they do some tech work, but perhaps we just need to be more
clear that what you want is a pure project manager to check off boxes.

I think a good tech manager still respects a bottom up approach most of the
time, but should have enough experience to push back when the group is
steering in the wrong direction. A generic project manager isn't going to do
that.

~~~
jkaplowitz
I've had a primarily technical career so far and am working on switching to
engineering management in the foreseeable future.

Once I'm done with that switch, I don't _want_ to be frequently making
technical decisions, rational or otherwise - that should be the job of the
tech lead on my team, with input from everyone else.

I will, of course, need to remain technical enough that I can understand
whether my tech lead is making good decisions, as you say. I'll also need my
team to respect my credibility enough to know that I relate to what they're
dealing with, and to be able to effectively keep them unblocked.

But none of this requires sustaining continued technical contributions within
my day job past the initial transition period, at least not once the company
is above a certain size.

One of the best managers I've ever worked under (indirectly) was not technical
and didn't pretend to be. What she did know was people and organizations.

When have you ever heard of a large org making a re-org to solve real problems
after substantial consultation and with anything close to universal buy-in?
She managed that, and well enough that she correctly used arguments from the
rank and file to explain the re-org to other parts of the company.

That's the kind of mentor I'll want to learn from as a manager.

~~~
PopeDotNinja
> I will, of course, need to remain technical enough that I can understand
> whether my tech lead is making good decisions, as you say

A lot of stress has been created for teams I'm on by semi-technical managers
chiming in. By telling yourself you'll remain technical enough, I'd encourage
you to define what that actually means. Thinking you know stuff that you
actually don't is going to be a huge pain in some one's ass.

I once had a boss who kept pushing for us to to do things in a certain way
using a remote API, but the API client didn't support the features needed to
do the things my boss insisted we use. The boss wouldn't allow for a
discussion on extending the API client because he was 100% certain he was
correct when he was in fact 100% wrong. I started looking for a new boss after
that.

~~~
jkaplowitz
Completely agreed. Knowing the limits of one's knowledge and accepting
feedback when one is misinformed are important skills. I believe I already do
that and I certainly don't plan to stop.

If I have a competent tech lead under me, I wouldn't be pushing for a certain
technical way to do things except if the requirement came from some external
constraint like the business or another team, and I would accept the limits of
technical possibility.

I might share my technical input if it happened to relate to my area of
expertise in a way that wasn't otherwise sufficiently present, but I want my
team to know their stuff, not to defer to my technical knowledge out of some
personal need to be the expert. Also my input != final decision, with respect
to technical decisions, if I'm not tech lead on the task.

Even if I had to push for or against something, I'd do my best to defer to my
tech lead (i.e. not me) to actually come up with and lead the solution. It's
not a manager's place to prevent a tech lead from conducting a discussion on
technically how to achieve the goal within the applicable constraints.

------
Waterluvian
I really like the "work on bugfixes and small features".

There's lots of coding work that is easy to drop at a moment's notice and not
mess up other work, schedules, etc.

Tooling is another one. Find processes that could use a nicer tool.

~~~
maxxxxx
We have some managers that help in reproducing bugs. For me as a dev this is
super valuable and saves me a lot of time I can spend on looking at the code.

~~~
gergelyke
Oh that's a great! Are you okay with me adding it to the article?

~~~
maxxxxx
Sure. The good thing about this is that they were often very good devs so
their insights are really good.

------
gtsteve
I'm a CTO (of a company quite a bit smaller than Uber) and I do basically
everything in this article.

One thing missed here (or that is out of scope of the article) which I think
is actually very important is that engineering managers should get involved in
QA. It's not glamorous but running through a couple of manual test scripts
yourself gives you insight into features you might not know too well (if the
product is very large) and also to personally assure yourself of the product's
quality.

I find myself incrementally tweaking the QA test script every now and again
when I do this, it's a great way to continuously improve the process.

~~~
zandl
Totally agree on the QA side, you need to see first hand what’s coming out of
your team to understand where your team is at.

------
agentultra
I think people should be able to swing back and forth; manager for a year or
two, engineer for a year or two. I don't believe everyone can be happy with a
prescriptive path to follow -- I can't only be one or the other for the rest
of my life. I like leading, mentoring, and developing teams. I also have
strong inclinations towards inventing solutions and developing the future
generation of technology.

I think businesses need to be able to adapt people to different roles and be
comfortable moving people around and let them change over time. Otherwise
we'll have people hopping off to new companies every few years as we tend to
and taking all of their domain knowledge with them.

~~~
timtyrrell
Great article on that here: [https://charity.wtf/2017/05/11/the-engineer-
manager-pendulum...](https://charity.wtf/2017/05/11/the-engineer-manager-
pendulum/)

------
shados
Lots of anecdotes here...I'll add more.

I worked primarily in 2 type of companies as far as this topic goes.

The first (and in my sample, more common) kind was engineering managers as
pure managers. You had tech leads which were really DRIs on technical
projects, but very much software engineers in their day to day roles, and
Engineering Managers which handled money, people issues, and made sure the
tech leads did their jobs. At some companies, teams have both. Often each team
has one TL and an engineering manager may look over multiple teams. Not always
though.

That works, but there's a bit of a disconnect. The person who decides if you
should get promoted or get a raise (or fired!) very much relies almost
exclusively on second hand information. They may have been an engineer in the
past, but they're not anymore, and may only have a loose understanding of what
is truly happening. They're usually a bit better at handling people issues
though.

The other kind is the "your boss should generally be able to do your job.
Maybe not as well, definitely not as fast, but in a pinch, given enough time,
they could". So engineering managers are just a higher form of tech leads that
ALSO have the whole people/money/management responsibilities. They code (a
little...maybe 5-20% of the time max) and can fully understand the problem the
people they manage are dealing with (not just because they did it 5 years ago,
but because they deal with them too in the present). That's a lot of work.

Much, much fewer people are qualified to do this so to scale, you either have
to be a very competitive organization, or actively train/manage/promote
engineers into those roles (or steal people from the rest of the organization
and train them as engineers. That works too!).

I personally much prefer the later (even though another post mentions it as
being a potential trap, I saw it work very well when handled properly). It's
infuriating to have to explain to a manager that the company's darling
engineer actually suck, but the managers only see the end result (without what
happened to get there or without being able to analyze the cost) and have
significant decisions be made around it. But again, it's very hard to build an
organization that way.

~~~
opportune
>It's infuriating to have to explain to a manager that the company's darling
engineer actually suck

Holy crap, yes. Well it’s not always that the darling TL sucks but often that
they themselves are in a role where they aren’t familiar with some of the tech
the people working in their team are working on, so they don’t know how to
properly make the large scale time estimates that get reported to the manager
(and why would you ever ask the people actually working on specific tasks how
long something would take? That makes too much sense and they might not tell
you what you want to hear). But when they’re the darling and you’re working to
meet the darling’s time estimates that were never realistic in the first
place, you get thrown under the bus to the manager when time estimates fail.
This actually just happened to me today.

This power structure also allows the manager/TL to play good cop bad cop on
their employees where all bad news/orders from manager to employee goes
through the TL but all good news/orders goes directly through the manager.

You can’t really win in a finger pointing game like this. The only fix is to
just leave

~~~
shados
> Well it’s not always that the darling TL sucks

While I've definitely seen instances of the darling being a TL, my biggest
issue is when its an individual contributor. I've had to deal with cases where
the company's "ninja" was some dude who just hid in a corner pumping shitty
code 18 hours a day, ignoring all pagers, requests for help, his teammates, or
even his own TL. But he shipped software that kind of sortoff worked (well, as
long as his teammates handled every pager notification that came every time it
failed). Management loved him because of his "productivity" and hated how
everyone else was so slow (because they were deleting with the fallout of his
crap).

It was awful.

------
encoderer
Here's how I do it:

1) I manage a team of fullstack engineers where I do very few coding tasks but
also can sometimes chip in on large efforts or when senior people are out of
the office.

2) Code liberally on weekends and on my bus ride in the morning on OSS and a
SaaS I've built over many years.

Staying engaged technically makes me unquestionably a better manager, but I
will impede my team's development if I take tasks in the team sprint.

------
bojo
This article is pretty close to my own situation. I’ve found that the worst
thing I can do is work on features that could potentially block everyone, and
the best I can do is grease our code ecosystem by updating libraries, compiler
versions, and low level code which doesn’t affect business logic.

------
bwanab
Exactly why I quit managing altogether. One can code or one can manage, but
doing both means both are compromised.

------
segmondy
I swing back and forth. I go for months without touching the code, then I go
for months where I stay in touch. It's easy to think a code base is decent
when you stay close to it. Diving into a new code and unfamiliar code base
allows me to see how new engineers will approach the code base, what's the
onboarding/setup docs? Is it automated? install.sh or containeriazed? Are
there tests? FAQ? user documentation, maintenance document? architectural
documentations? If I can jump in the code fast and get moving, it's great. If
not, I know the team is slacking and I figure out why and cover that area.

If pressed for time, then I might do the test/bugfixes cycle.

I code multiple times a week at home, so I'm not really pressed to program at
work

------
Hippocrates
Good perspective. In my experience an engineering manager must be flexible. An
engineering manager can really help the team excel by building productivity
tools, prototyping new concepts documenting, or even fixing small bugs. With
that, a manager should not let technical tasks get in the way of managerial
duties.

I like the author's advice about not taking on work that may block your team.
That is truly risky and can backfire. I've seen this firsthand -- But a
manager absolutely must keep their head in the game technically. They need to
be able to interface with other engineers and managers on a deeply technical
level. They should have an awareness of their project's codebase that is best
gained through being in it. An engineering manager without technical ability
is a more like project manager.

In my org, I have seen the expectations of what a manager does shift quite a
bit. With the addition of a tech lead role, it seems managers are silo'd into
less technical, and less hands-on work. I feel that any sort of hard
expectation or assigning percentages to management vs engineering time is
ignoring the nuances of team dynamics, and individual personalities. A manager
who can also effectively contribute code should do that. Likewise, an engineer
who can boost team morale, mentor, help recruit/staff the team should. Take a
look at the team dynamics and determine what mix works.

------
ElBarto
"Work on Bug Fixes / Small Features"

That's terrible advice, in my view.

In your job you should always do what is the most useful and productive use of
your time.

As a tech lead/manager your role is to manage/lead and your time is extremely
valuable. In addition, your job as a manager is to allocate resources
efficiently.

A small feature is a good task for a junior engineer. It helps them grow and
their time costs less than yours.

Bug fixes should be the job of whoever knows the relevant part of the code
best, which is unlikely to be you if you're a manager but even if it is you
should aim to train and mentor others to acquire the technical expertise.

~~~
ummonk
Having first hand knowledge about the state of the codebase is helpful to
doing your job as a tech lead / manager. Doing bug fixes / small features is a
productive way to gain and maintain this knowledge.

~~~
ElBarto
You can/should have visibility of the code base through design specs and code
reviews.

There is absolutely no need to do a (potentially junior) engineer's job. It
might be 'productive' but it's not the best use of your time or your role, and
thus it is in fact a waste of time and money.

~~~
bearforcenine
If you only have 20% of your time available to write code, then I would much
rather you do not review code in which the person who wrote it had 90% or more
of their time to write code. The review will be less thorough, correct, and
timely than if someone else who regularly spends more time in the code.

These 'junior engineer' tasks are attractive for a manager who still wants to
be in the code. They are non-critical and small. Perfect for someone with an
unpredictable schedule. However, they also provide an opportunity for the
manager to have a better, but still imperfect sense of the codebase and
technology.

~~~
ElBarto
If you're a manager you don't have 20% of your time available to write code...
If you want to write code then stay in a position where it is your role.

------
drej
This is the worst class of managers I have ever experiences: engineering
managers with little dev experience. They rose quickly and became managers
fairly early on in their career. They got excited by the opportunity, but then
realised early on that they mostly attend meetings and write e-mails.

They miss coding, so they try and code between meetings, but without knowing
our engineering practices, code reviews, agile methodology, ...

------
keephere
I run an org of 20ish at a FANGish company. I have mgrs and a team of ICs
reporting to me. Myself and my managers are on the oncall rotation along with
ICs and we do light coding activities.

Pros- team morale, better tech decisions, skills stay up to date, oncall is
quiet

Cons- more time consuming, develops bias against other mgrs that do not code

To each his own...

------
azhenley
As a new professor it seems I am supposed to act more like a manager and do
less of the research/coding/data analysis myself. But I love to code! My goal
is to keep a small project for myself that I work on when I don't have
impending deadlines (basically never?).

------
purplezooey
If you choose non critical bugs to work on, your managers will say _wtf is he
working on that_ , and your next performance review will say "needs better
judgement on priority of tasks" and you'll be let go in the next round.

------
sharadov
I guess am going down that path, am on the database side though. It terrifies
me to be a people's manager, approving timesheets and crap.. I would love the
mentoring part, but I'd rather skip and go straight to being the strategy guy.

------
iaresee
I like writing metrics-related code as an EM. It’s valuable for me to be able
to understand our data that’s tracking our KRs and informing our KPIs. And I
get to stay sharp on some frameworks we use here for surfacing metrics to the
company.

------
CardenB
I find the bit about mentoring people outside your org interesting. I'm
interested in mentorship myself. Does anyone know if there are actually
rewarding mentorship programs on websites like meetup.com? Has anyone else
done this?

~~~
hodgesrm
Check with your local university or community college for mentoring
opportunities.

For example, the University of California at Davis has a senior design class
in their computer science program. You can submit a proposal for a project; if
it's accepted you become the mentor and work with the students a couple hours
a week over 4 to 5 months. I did this last year and found it extremely
rewarding.

Edit: fixed typo

~~~
tudelo
Did you have to pay money to do this?

~~~
hodgesrm
No, it was more like just write a good proposal. There was a problem related
to Swagger API specs that had been bugging me for a while, so I wrote it up
and sent it in. I was delighted when it was accepted.

I'm planning to submit another project this year. Working with students is
fun.

p.s., The class is ECS 193AB in case any folks living near Davis are
interested.

------
alexchamberlain
What do we mean by manager in this situation? Is the first level "team leader"
a people manager that engineers, or are we talking higher level managers?

------
Dawny33
What is the difference between a tech lead and an engineering manager?

------
known
As Engineering Manager I was doing Code reviews of my team;

------
ducklingslicks
That would be great.

------
purple_ducks
> Work on Bug Fixes / Small Features

With this, I disagree for 2 reasons:

1) If your devs had to prove themselves technically via hiring process and you
didn't, then your technical chops are potentially not up to scratch and devs
have to tolerate inferior noise. Ditto with architecture input.

2) The easiest fix isn't always correct. Not having day to day knowledge of
the code base means you're more likely to implement something substandard.

