
Engineering Managers Should Code 30% of Their Time - kungfudoi
http://www.drdobbs.com/architecture-and-design/engineering-managers-should-code-30-of-t/240165174
======
crazygringo
This is ridiculous.

Yes, engineering managers absolutely should _understand_ how to code, and
understanding concepts like technical debt, unreliability of estimation, etc.
goes without saying. And it's awesome for a manager to be familiar enough with
the tools and work to be able to implement a quick critical bugfix or similar
when unexpectedly necessary.

But if they're a good manager, it's far better for the organization for them
to be spending their full time managing. Let coders code and managers manage,
as long as they're both good at their jobs. The author's argument makes as
much sense as saying a professional baseball coach should be spending 30% of
his game time actually playing with his team.

And honestly, this is just BS:

> _Once a person stops coding for a significant portion of time, critical
> connections to the concerns of developers atrophy._

Citation needed. It sounds as fake as supposed facts like we only use 10
percent of our brains, or other hogwash.

~~~
jasallen
Your argument sounds good in theory, but a lot of us have the experience that
'good managers' are unicorns.

Before my start-up, I was a dev manager. And a damn good developer. I knew
what technical difficulties my team had, and understood them, because I was
the first place they came for an extra set of eyes. I ran defense from upper
management because I knew the concerns, and I was the one with the voice.
Because I'm also an open-book style manager I didn't play the "they don't need
to know" card, but I could handle those things _without_ them first having to
mount a case to me every time.

I've watched _A LOT_ of "I used to code" managers, and almost to a man, they
are a disasters.

~~~
dxbydt
Exactly this. If you are a PM at a Valley outfit & can't code _right now_ ,
your team simply pretends to respect you, while going off & doing its own
thing. Its just one of those empirical things. Doesn't matter if you "used to
code" once upon a time. Things are moving at a breakneck pace & if you don't
keep up, you are really going to get left behind. I will also say that if you
are a PM at a non-Valley outfit like a bank or one of those outsourcing firms,
the exact opposite holds true. You should probably not code & spend all of
your time managing. IBs especially frown at MDs & VPs taking on hands-on roles
instead of managing & filling out gantt charts. My Manager at Goldman used to
write compilers using javacc to automate risk algebras - he regularly got the
stink eye. He used to tell me "they just want me to run the spreadsheets" :)

~~~
badclient
Being _able_ to code is very different from coding 30% of your time at work.

~~~
peterwwillis
Seriously.

A manager is responsible for controlling, administering and maintaining the
work being done by their subordinates. A big chunk of that is determining what
work is yet to be done, if it's on time, what needs to be done to support the
existing work, communicating with other teams, doing research, quashing
harmful discourse and building morale. They organize, prioritize and double-
check the tasks assigned and meet with their subordinates to ensure everything
is going smoothly. They plan, develop, monitor, communicate, and assess their
employees and their work. And of course they attend countless, constant
meetings.

If as a manager you can do all that and then have 2.5-3.5 hours a day left to
write code, bravo.

~~~
wisty
OK, but how do they know what needs to be done?

A baseball coach knows if the pitcher isn't doing so well, because he's
watched the games. How does a manager know if the new API is unwieldy, or if
errors in one component are causing serious grief?

I mean, you can ask employees to blame their peers, but some won't want to,
and some will be a little too eager.

~~~
peterwwillis
There is more going on in baseball than that. Similarly, there is more going
on in software dev team management than that.

[https://en.wikipedia.org/wiki/Coach_%28baseball%29](https://en.wikipedia.org/wiki/Coach_%28baseball%29)

------
hkarthik
I think this works as long as the engineering managers follow a few
guidelines:

* Don't code 20% of a full solution with your 30% time and expect the other engineers to pick up your work and finish the other 80% to make it production ready. If you can't cross the halfway point with a task, don't take it on.

* If you do need an engineer to make your code production ready or fix a bug in it, don't act like you did him/her a favor by "getting it off the ground". They are doing YOU a favor by finishing your work for you!

* Be humble and expect to take massive amounts of criticism from engineers who take a lot of pride in their code and spend their careers perfecting it.

* Avoid becoming overly defensive and asking engineers to relax their established code quality guidelines or test coverage to accommodate your compressed schedule.

~~~
patrickmay
Good guidelines. I'd add:

* Spend some time on bug fixes and paying down technical debt. You'll get a better understanding of the challenges your team deals with day-to-day.

~~~
toadi
When I ran my own company as technical co-founder. I wrote POC's to
demonstrate something was possible or what I wanted to habe built. I had no
issue in throwing away all this code.

I didn't write production code. I fixed bugs or refactored...

------
ChuckMcM
This is a fascinating thread to read. I would love to know when people comment
if they also consider themselves a manager, or have managed in the past. The
reason is that I find management is a very different skill set than coding,
and spending 30% on something that isn't making you a better manager would
seem to be counter productive.

That said, I totally get the angst over managers who have never been coders.
Sort of like Scully relating the sale of computers to being similar to selling
'colored water' (Pepsi vs Coke). Not so much in my experience.

There is also the question of scale, if you're a 20 person company I can
easily see everyone writing code as well as doing other things, 50, 100, 2000
person company? Not so much.

And there is the question of perspective, a solid engineer is there to make
the best thing they can, within the constraints of available CPU, memory, and
storage resources. A solid manager is there to take a limited amount of money
and time and ship the best thing their team can make within those constraints.
So sometimes managers decide things one way, and engineers argue for a
different way, it's always helpful to be able to see the problem from the
other person's shoes. And yet my experience is that line managers, often drawn
from the ranks of engineers, are more able to see the constraints the engineer
is working under than the engineer is able to see the constraints the manager
is working under.

I don't know if there is a 'right' way to blend those two roles. I suspect
that if you're in a large company as a manager and spending a third of your
time coding, you might want to check with your manager on how they perceive
your performance. If you're in a small company and write no code you might
want to check with your team to see if they feel they have it covered or not.
But I can't imagine there being a 'blanket rule' like spend X% of your time
coding that would have anything close to universal applicability.

~~~
pjmorris
In the main, you say a lot of wise things.

I have a couple of quibbles

> spending 30% on something that isn't making you a better manager would seem
> to be counter productive.

You're assuming coding doesn't make you a better manager... what if it does?

>There is also the question of scale, if you're a 20 person company I can
easily see everyone writing code as well as doing other things, 50, 100, 2000
person company? Not so much.

Bill Gates shipped code up until 1989 [1]. Microsoft was between 3000 and 4000
employees at the time. Sure, he may be the exception that proves the rule, but
maybe there's something to the notion that coding managers have a better sense
of the technical market... of course, it depends on what market you are in.

I've spent most of my time as a coder, but have managed from 1-12 people from
time to time.

[1] [http://www.quora.com/When-did-Bill-Gates-last-write-code-
for...](http://www.quora.com/When-did-Bill-Gates-last-write-code-for-products-
that-shipped)

~~~
ChuckMcM
Its a fair point, certainly understanding what the code is doing makes you a
better manager. Sometimes that understanding is best done by coding up some
things to test your understanding. I would be concerned though if, as the
manager, your code was required to be complete prior to shipping the product.
That would be a red flag for me.

------
easy_rider
The worst manager I've had, tried to often pretend he had any idea what he was
talking about when pitching some gibberish during the 10min standup talk. He
would often make suggestions like "and if you use Apache Solr? ". My face
would be like ":/" and had to explain a subtle no (cause he was paying my
salary). If he wouldn't be putting up that act, and just work the team
dynamics without trying to provide technical solutions to experienced coders
who will be like ":/", he would actually fare pretty well I think.

But I must say if you are presented with a tough technical problem, and human
resources to solve it, but you fail to comprehend the problem and how you
should direct your resources in solving it, it's going to be a tough cookie to
make any impact other than wasting your time, and precious developer hours
trying to do something you can't.

The best one I've had I worked with for a long time as a colleague freelancer,
and 0 hour contract directly under him until we expanded to a 15-20 workforce.
He was an experienced PHP'er, and would argue even a better salesman and
networker. He would almost never write any code, but when push came to shove
he would provide the fix within minutes time after a client made an upset call
after hours. Most importantly: Other than being able to point out strength and
weaknesses of his employee's, he was never afraid to acknowledge his own, and
always assumed our expertise over his. ( unless someone really f'd up of
course :) )

------
kabdib
I would much rather my manager (if I had one, which I don't) be a good
/manager/ and a non-engineer, rather than being a bad manager and a bad
engineer.

I want my manager to have a great engineering background, but not be
interested in the actual engineering except for purposes of helping the
engineers get their jobs done. In other words, build a good team, remove
obstacles and get the heck out of the way.

~~~
crbnw00ts
This is the correct answer. The manager's job is to manage the _people_ , not
the project. That's what a tech leads and PMs are for.

A good people manager works to keep their employees comfortable, aims to avoid
conflicts (and resolves them if they arise despite these efforts), mentors and
coaches people to develop new skills, and shields them from politics. Doing
the work of an individual contributor just gets in the way of that. The
manager should be familiar with and understand what their people do, but leave
the actual performing of that work up to them.

------
nickmain
Between all the meetings and other nonesense in a large corporation an actual
engineer is lucky to be coding 30% of the time.

------
mabbo
God, this is relevant to me today.

Today, I quit my team because of the manager. Nice guy, but zero knowledge of
our code base, no interest to learn it, and no connection to what the problems
we, as developers, were encountering. He didn't know, and didn't want to know.

With each proposal to address major technical debt issues, he had no context,
no understanding, and would only reply with demands that we prove to him that
our projects were impossible without addressing technical debt. (Side note:
nothing is impossible, as long as you're willing to add _more_ technical
debt).

Between this, and other major problems, I'd had enough. I needed out.

I told him that I was taking vacation for the rest of the week (5 day weekend,
wooo) and when I come back Monday, his manager and HR are going to help me
find a new team (as they had previous agreed to). I'm fortunate to work for a
company where that is possible.

Having a manager who codes 30% of their time might be asking too much, but
having a manager working with developers who does not even read the code is
not enough.

~~~
dinkumthinkum
I hate this term "technical debt." I understand where it is coming from but it
sounds like made up fairy dust and can be a little hard to take seriously.

~~~
mabbo
It's a good enough analogy to what the problem is. You are buying a solution
today at the cost of continued payments when you try to make solutions
tomorrow.

Is it always bad? Hell no. When you need something right now, then you take a
loan from the ol' technical debt bank. You get your product today instead of
in a week. That can make or break a product.

But failure to acknowledge what it is, debt which you pay interest on in terms
of time and effort, is a recipe for doom.

~~~
dasil003
Sadly I think the term has been diluted a bit through overuse. I even hold
myself to blame in sometimes referring to things as technical debt that are
more accurately described as bit rot or just useful version upgrades (the ruby
is particularly insidious about this).

------
endlessvoid94
As the cofounder & CTO of a 14-person startup, how in god's name do you find
time to spend 30% of your time programming?

There's just too much other stuff that's more important.

------
hcho
I am in the "You can't manage what you can't do" camp but 30% is a bit steep
for anyone managing a team.

------
fingerprinter
I don't know where to begin with this. This is just nuts!

This might work for some snazzy valley startup with 16 people all working on
the same code base, but this is just completely, shall I say, naive and
shortsighted. It smacks of someone who hasn't been involved in anything big,
complex or been in the industry for any length of time.

Some people don't like to use sports analogies, but I do so I will.

An NFL team typically has a head coach, an offensive coordinator, a defensive
coordinator, a special teams coach, QB/WR/RB/DB/LB/Oline/Dline coach as well
as a strength coach, among some more in certain cases. Then there are the
players. Offensive, defensive, special teams.

Imagine you are the head coach. Should you spend 30% of your time doing
ANYTHING any of the players are doing? Should the OC or DC being doing the
drills or what not? Maybe, maybe working out, but probably not like the
players.

My position is akin to the OC on an NFL team. I'm in charge of teams of teams
of people. Developers (in different areas/focuses), QA, infra, release, ops
etc etc. This is LOTS of people. So, if I'm "coding" 30% of my time, I'm
effectively looking at only one area. Should I be spending 30% (or some %
number) of my time doing jobs in those other areas? And do I want my managers
in those areas to do those things? Well, probably not. I want them to
understand them, yes, have done that job previously, yes. More over, I want
someone who can 1. engage the team 2. direct the team 3. hold the team
responsible 4. tell me (or others) "no" and intelligently show the way for
their area and 5. lead up and down. Coding is literally so far down the list
it isn't funny.

So, no, a manager shouldn't be coding 30% of their time. If they want to and
it doesn't get in the way of their actual job, fine, but that is not their
job. Their job is to set or enact direction, lead and protect their team.

To go back to the NFL example. If I'm the head coach, I want the OC to know
exactly the type of offense I want to run, put in the system in place, coach
the coaches on that system and make sure everyone is on the same page. I don't
want them running routes with the WR or practicing blocking drills with the
linemen.

------
elwell
> Get a real machine to work on. That MacBook Air you love for meeting
> hopping? Not it.

Why do you think he said that?

~~~
crazygringo
Because he doesn't know what he's talking about.

Some people say they need dual 30" monitors to code, I'm not going to disagree
with their personal preferences. But other people (like myself) see zero
difference in productivity between that and a 13" Macbook Air screen, which
I've been coding on for years.

The whole "real machine" thing is just ridiculous cowboy posturing, unless
you're doing video game development or something. A Macbook Air is just _fine_
for web development.

~~~
shubb
Tiny screens, especially high res ones, are fine for coding. But working on
laptops all day isn't great.

If you code all day, you will probably develop back problems if you don't sit
with good posture.

You need to sit straight in a good chair, and look at a monitor at eye level
about 2 arms lengths away. You need to type on a keyboard with good typing
posture.

If you don't, then you will be okay for a few years, and then you won't.

I've seen RSI write off good programmers. It's pretty horrible - they build
their lives and self esteem around a job, and then they can't do it. Bad RSI
means that you can't touch a keyboard.

~~~
dreamdu5t
I've never seen any solid research linking slouching to back problems later in
life. There's plenty of studies that correlate "bad" posture with discomfort,
but none that I'm aware that correlate slouching with future back problems
controlled by a group that does not slouch. I'd love to be corrected though.

~~~
shubb
You are right - I am basing this on my subjective experience.

Also, I suspect that this is a problem if 80% of your time you are at a desk
typing, but if you move around a lot, it's not going to be such a problem.

That said, if you are coding at a desk all the time, a quick google finds
research that backs up the posture -> injury thing.

------
JackMorgan
I remember reading once that doctors who manage other doctors still practice
medicine part of their day. If so, why, when they have a business that also
changes quickly and is actually life threatening, is that the case? Perhaps
they realize remaining in touch with your field is valuable. Here are some
papers with findings that indicate how practicing doctors as hospital
administrators improve the quality of their hospitals above those hospitals
that have just business managers.
[http://www.amandagoodall.com/papers.html](http://www.amandagoodall.com/papers.html)

Why then is it the norm that so many developers who move into management do so
to "get away from developing"?

It seems unique to development, or maybe just uniquely easy to see when
someone is clueless about technical matters.

Anecdotally, all my worst managers were "out of touch" but thought they still
were hot stuff technically. My best were either completely non-technical and
trusted their team, or were developing at least 1/4 of the time (and he worked
mostly automating all the crap work we hated and fixing bugs).

------
lucisferre
If you have to be told you should still be writing code you've probably
already lost it (or never had it to begin with). I'm surprised by the people
here arguing so strongly against something that is just common sense to anyone
who truly cares about software development. Sure the 30% figure is debatable,
but you're splitting hairs if that's what you think this is about.

There are too many people who are completely incompetent in management
positions who effectively hide their lack of knowledge and skills because they
are never put to the test. Moreover one shouldn't want to completely lose
touch with the processes and techniques of development and design of software.
How much involvement in code is required to be effective is perhaps debatable,
but that you should be involved definitely shouldn't be.

------
nevi-me
From following Mongo on JIRA, I have noticed that Elliott spends time coding,
and could venture to say that he is led/allocated work by Dan Pasette (who is
the SERVER team leader). A lot of recent Mongo releases have been delayed by
over a month, with some features and fixes being delayed to 2.8.

If Elliott wasn't involved in the coding I doubt he would understand the
pressure the team deals with, and how realistically would his explanations to
say $150 million investors be (not disregarding that Dan and other team
leaders would provide details status reports)? Of course this is a grand
assumption, but when I read his article last week, I came to agree with it. In
my field of work, I see it all the time, over time a lot of managers lose
respect from us subordinates. They no longer make accurate project estimates,
their staff planning is unrealistic, they lose some of the peronism solving
skills that got them there, etc. I don't expect them to go down and do the
dirty work, but I acknowledge that sometimes if such was possible in our line
of work, they would benefit a lot in keeping in up with us subordinates

------
edwinnathaniel
I'm lucky enough to have managers that care about the people under them and I
think that's good enough so far.

They would listen to advises/opinions, they would try to diffuse stressful
situation, they would try to communicate what's necessary, they do negotiation
fairly (got to give something to get something back).

As a result, I would give more to them (within limits, of course). At the end
of the day, it's a win-win situation: I make them look good, they make sure
I'm happy and not burn-out.

Background: both managers code before, one has MSc in Quantum Computing, the
other does a lot of infrastructure/big-enterprise system (batch processing) so
their backgrounds varies with the only commonality between them is that they
both come from *NIX background and understand DB/Infrastructure rather quite
well.

It's very hard to be an engineering manager (lots of examples in this threads
why they don't like their managers or their previous bad experiences) and if
you found a "matching" one with you, priceless. Of course, nothing is
forever...

------
bane
This sounds more like what a Senior Developer/Engineer should do, not an
Engineering Manager or a PM or a TPM.

I seem comments here that "used to code" managers were either the worst or the
best manager they ever had. However, it's the job of the Senior Developer to
represent the engineering concerns of the team. It's the job of the Manager
type to sit between the Engineering Team and the Senior Management, deal with
paperwork nightmares, prioritize major work units, set deadlines and manage
both up and down.

The Senior Dev should sit at a high level of the actual business of the
engineering, dip down from time to time to spot shoot thorny issues, but they
should prioritize the specific engineering items and keep the team well fed
with work. It _is_ a management function, with expertise in very hard
engineering problems.

Sometimes the Senior Developer might represent that some work item is
problematic for whatever reason and try and keep the team off of it. The
manager, knowing the strategic priorities of the upper management, can either
chose to manage this up, or override the Senior Dev and manage this down
depending on the situation.

This is something that Senior developers aren't in a position to understand.
Representing only engineering up means that unpleasant shit work is often just
not done. It sucks, but needing to press your team into doing work they don't
want to do is how things get done.

It may sound like overspecialization, and on small teams it is. But with large
engineering groups, you don't want to tie up the Senior Dev, who's basically
the guy who beats the drum on a slave ship, with being the ship captain.

This is _really_ hard to understand until you've been in a medium to large
sized organization and had to manage there. Managing takes an incredible
amount of time. Most managers don't stop working when they leave work. Hell
putting together a decent proposal might take 2 or 3 months of 50-60 hour
weeks.

------
SubuSS
At least from a big company perspective: This breaks down. Any set % for
coding doesn't work because there are so many 'big company' problems to deal
with already that take up enough of their time. Either you will end up fixing
trivial stuff that a coder would have done in 10% of the time you took or you
will spend too much energy on this and lose track of your actual job.

Ideally I want managers who can code / have coded for a long time in their
history so that they understand the software development world. But I actually
want them to do time management, people management, expectations management,
customer co-ordination, issue prioritization etc.

IOW - Engineers can code. Engineers usually can't do those other things
without flinching. Leave engineering to the Engineers and management to the
Managers.

------
jeremyt
Yes, and developers should manage 30% of the time and do design work 30% of
the time. You know, because good management and good design is essential to a
good product, and just saying that you have "done some" design or management
in the past isn't good enough.

~~~
zeroonetwothree
It's common for engineers to do some simple design work. And every employee
does some management.

~~~
jeremyt
Yes, but the point being made here is that managers should do more. They
should spend all of a whole 30% of their time coding, which presumably
includes real coding projects, not "some simple" coding.

After all, if all you're doing is checking in bug fixes occasionally, how are
you really going to know the advantages and disadvantages of redis or puppet
or any of the other tools used on a daily basis on engineering teams.

------
daveslash
I suppose it depends on what you/your-organization views as the realm of
"management". I like Joel Spolsky's suggestion that they should just be moving
furniture out of the engineers' way. Of course, he cites Microsoft, and I know
how many of us feel about that company.

"At Microsoft, management was extremely hands-off. In general, everybody was
given some area to own, and they owned it. Managers made no attempt to tell
people what to do, in fact, they saw their role as running around, moving the
furniture out of the way, so their reports could get things done. "

src:
[http://www.joelonsoftware.com/articles/fog0000000072.html](http://www.joelonsoftware.com/articles/fog0000000072.html)

------
puppetmaster3
As a coder or a CTO, I say you can't do both.

Code 30% of time? You know nothing of coding. Can't be done.

~~~
icedchai
It can and it should. I've worked with CTOs that do this.

~~~
gaius
You can average it out at 30% of the time, but in a given week, you can't
commit to it, because a greater responsibility of your job is being available
to manage the unexpected. That makes it difficult to integrate someone in that
role into a team in terms of dependency management.

There is also a risk in being in a position of power and being seen to assign
yourself the most interesting work. I have seen this happen in one team, our
manager was a good guy, but somehow he always used to get the sexy work like
playing with new kit, and the team got the gruntwork. It led to resentment and
undermined his authority (tho' because he was a good guy, as soon as he became
aware he was doing this, he stopped).

~~~
jasonwocky
> You can average it out at 30% of the time, but in a given week, you can't
> commit to it, because a greater responsibility of your job is being
> available to manage the unexpected

I'd argue that your job is to teach others how they can best manage the
unexpected. Then you should only be involved in the really exceptional
circumstances, allowing you more time to tend to your (metaphorical) garden at
work. If writing code is part of that, so be it. But the bulk of time, I'd
argue, ought to be in mentoring others.

The best managers I've worked with don't run around like chickens with their
heads cut off, constantly responding to fires.

~~~
gaius
Depends what you mean by "fires". If a customer comes along with a new
requirement, how do you predict that? Then your job is figuring out if it can
be done, the best way to do it, if you have people free to do it and test it,
if doing this for customer A will have any impact on customers B-Z, if there
are any currently in-progress features you could or should cut to work on
this, whether to push back on the customer and say, not in this release and
how to do that without disappointing them too much, etc etc etc.

Basically a manager's role includes being the interface between his team and
the outside world, and the outside world is by its very nature chaotic.

------
pjmorris
I've personally seen horrific technical judgement calls made by managers who
used to code (usually not in an environment like anything they're actually
managing). There's a huge, dangerous class of problem where you think you know
what you're doing, but you don't.

"It's not what you don't know that hurts you. It's what you know that just
ain't so." \- Satchel Paige

When the fates of a whole team of individuals rest on your judgement, it's
best if it is grounded empirically or at least humble enough to account for
the possibility that you could be mistaken.

------
KiwiCoder
Ignoring the dubious points of this article (30%, MacBook Air) I think a vital
question being overlooked is whether a newly promoted manager actually _wants_
to continue coding. Some will, some won't.

------
eternalban
The atelier system seems to be a good match for this field (given that what we
do is effectively arts and crafts.)

Regrettably, the facile access to information by the current crop of
practitioners of this craft has blinded the clearly novice to the necessity of
donning the disciple's apron.

\--

[http://en.wikipedia.org/wiki/Atelier](http://en.wikipedia.org/wiki/Atelier)

(*: there is very little science and engineering in the practice of software
development.)

------
syntern
My best managers were the ones that could and did code occasionally. Not just
a side project of their dreams, but the same product we were working on, to
feel the same pain, to understand the reasons of our decisions.

I have had good politician-managers who were excellent in corporate politics,
but that is not the same as having an eng-manager.

------
lifeisstillgood
According to Junio Hamano he does 45% Communication, 50% Integration and 5%
coding (Scratchin own itch)

So 30% is rather high. A manager is not a coding position. If you are either
you need to hire more people, or its not actually a manager role.

If you are not allowed to hire more people, its not a manager role. If you
can, do so now.

~~~
ryanbrunner
You're not really making a point, besides "a manager is not a coding
position". This article is explaining why the author thinks it _should_ be.
It's not enough to say that managers shouldn't code, you need to demonstrate
that either the authors points are wrong, or that there's a greater risk by
spending 30% of your time coding.

FWIW, I spend probably 30% of my time coding, I manage 13 developers, and I'm
capable of hiring more people. If you're not good at pushing autonomy down on
your team, you'll make yourself a bottleneck and have no time left to code. If
you hire great people, and trust them to make the right decisions, a lot of
traditional management overhead vanishes.

~~~
lifeisstillgood
Ok, that's fair.

If I am going to give myself wriggle room, its that the vast majority of
problems I have seen in poor software management have not come from a ex-
Developer who has lost touch with the codebase, but from the other issues you
/ OP make - delegation, focus on team growth, structure and process
improvement etc.

If someone is self-diagnosing and saying "aha the reason this is all falling
apart is because I am not coding more" its unlikely to be the correct answer.

------
mathattack
This is very true, but to be a good engineering manager, it's hard to fit all
the other things in: Representing the team in dreaded meetings, coaching,
hiring, fire, career advice, direction, etc.

It is a very fine line to balance. 0-10% is too little. After 50%, you're no
longer a manager.

------
auctiontheory
Many developers, especially here on HN, think that managers don't understand
what developers do.

Perhaps so, but it's even more true that many developers don't understand (or
respect) what managers do.

------
Daviey
I used to manage an engineering team, and probably did spend that much time
coding. Often, it was protyping or proving concepts to then pass on the
engineers on the team to complete.

------
_random_
Engineers Would Spend 70% of Their Time Fixing the Result

------
radley
And answer customer feedback at least 4-5 hours / week.

------
ommunist
Agree. But first they need to learn touch typing.

------
cmollis
yup..

