
Manager Can’t Code? They Shouldn’t Be Your Manager - lanecwagner
https://qvault.io/2020/07/14/your-manager-cant-code-they-shouldnt-be-your-manager/
======
paxys
Managers should be technical enough to understand what is going on, but
claiming that an effective manager needs to be coding 80% of their time (as
the article says) is idiotic. Why be a manager at all at that point?

I've personally had _much_ worse experiences with managers who wanted to
micromanage every technical decision and every line of code vs. those who just
trusted their team with it and focused on people management, clearing
organizational blockers, roadmapping, project management, communication to
executives and other stakeholders, shielding us from company politics and lots
more.

~~~
Aperocky
To be exact, the article said

> coding, architecting, or doing technical work that requires engineering
> prowess.

As a software engineer, I don't even spend 80% of the time working coding, in
fact it's more like 30%. But I do spend almost 100% of the time doing the
stated things above.

However, I do agree with you (mostly). My position is that having an
understanding of computer science make them much more efficient in the
activities you described, some of which falls into the stated camp.
Micromanagement is universally regarded as bad.

~~~
paxys
Still, all those should be the responsibility of senior engineers on the team,
not management.

~~~
Aperocky
I think you have a point. But should making decision that require an intimate
understanding of the technical stack be part of those activities? Should
drafting new features be considered under architecting? I understand that my
managers are heavily engaged in these activities and their decisions are
challenged by very technically minded people before they are put to work.

~~~
falcolas
New feature requests are certainly within a manager’s purview, but designing
how those features are implemented is not - that’s your engineer or
architects.

Of course, if your organization expects a manager to also be a tech lead,
that’s something else entirely (and not common in most non-startup companies).

------
uberman
I believe the author of the article is confusing "manager" and "tech
lead/senior developer". I think the author has projected things they think are
important in a manager onto the roll and those things probably don't align
with what senior stakeholders think are important.

I would certainly expect the technical lead to do a good amount of coding in
addition to design and mentoring, but expecting the CTO to code as the article
suggests seems wrong. I guess this might be true at a 25 person startup, but I
think this is an unrealistic requirement for larger organizations.

By a similar argument, would the COO be reasonably expected to work on the
assembly line and repair hvac on a regular basis? Again, perhaps at a company
of 25 but seemingly (to me at least) absurd at a larger company.

~~~
lanecwagner
I'm certainly blurring the lines a bit, but I would argue that in most cases
there isn't a need for both. The tech lead can be the "manager".

"Managing people" isn't a full time job in most cases. It all depends on how
the organization is structured and how many non-technical tasks are being
assigned to the "manager". Sometimes a manager is responsible for product,
marketing, or HR tasks and all that will be dependent on the company in
question.

~~~
LeoTolstoyJr
A managers job isn’t necessarily to manage people but outcomes. People are
essential for that, of course, but there’s often a lot of other moving parts
to it that warrant a full time manager. The problem is often that building a
good management structure is not only extremely difficult but also exceedingly
rare, meaning many of us have either worked with bad managers or with managers
that were poorly equipped to do their jobs effectively.

------
bob1029
I don't know about this. For me it always boils down to "it depends". I've
seen situations unfold where a non-technical manager steps into a technical
clusterfuck and promptly sorts out the mess in such a way that makes everyone
happy.

I've found that simply by being an expert in some area, it can be extremely
difficult to let certain things go and refocus on other objectives.

For me, there is definitely some yin-yang balance between the technology and
business evangelism. Having 2 different humans with 2 wildly different
perspectives many times yields a far better result than 2 different humans
with 1 unified perspective.

~~~
potta_coffee
You're correct, but I think the other argument is correct as well. I've seen
teams where a manager is so technically incompetent as to be useless in their
role. I've also seen teams where the developers were caught in technical
minutiae while not contributing actual business value. I don't know if there's
a cut-and-dried answer here.

~~~
bob1029
One other way I look at this is as a balance of forces between technology and
business. The developers are delegates to the technology while managers are
delegates to the business. Assuming they can both arrive at some common middle
ground, then you should have something viable to work with.

Sometimes I have to stop my other developers from getting upset with project
managers when they are having bad days. If your managers are unhappy, it's
very likely that the customer is unhappy as well. Developers should use this
as a signal that they may want to re-prioritize efforts or schedule deep-dive
meetings with their managers to sort out customer & business concerns.

The exact same idea applies to the technology. If the developers are in a bad
mood, its quite likely that they are struggling with some abstract
technological foe such as a legacy code base or broken devops process.
Managers should recognize this as an opportunity to pause the process and try
to allow room for the developers to work through whatever technical
difficulties they are having.

If you have this perspective where everyone involved is a delegate to some
other ultimate authority, you may develop a greater sense of empathy for your
fellow human.

~~~
potta_coffee
I agree, it mostly boils down to "human" or organizational problems.
Technology or code problems aren't stressful in the absence of stress from the
organization (time pressure / higher expectations than the team can deliver,
etc).

------
badrequest
Attitude is key here. My manager hasn't written non-trivial code in ages, but
is deferential to my team when we provide estimates around how difficult
something will be to implement, or how long it will take.

> Contrast the idea of a competent boss with the all-too-familiar experience
> of going to a non-technical middle-management type with an engineering
> problem, only to be stuck in a teaching session because the boss has never
> heard of a pub-sub system.

Since we're being reductive, why not posit that if you can't explain your
systems to someone who doesn't write code, you shouldn't be building such
systems?

~~~
whatshisface
> _Since we 're being reductive, why not posit that if you can't explain your
> systems to someone who doesn't write code, you shouldn't be building such
> systems?_

If we _really_ want to be reductive, then there's no reason to hire a manager
that shares a language with their subordinates, because if you can't teach
English to someone who hasn't learned it, what business do you have talking?
Clearly, this is absurd, which means there must have been some reasonable grey
areas that got left behind along the way...

------
devalgo
Legitimately confused by this. Is it really common that truly non-technical,
as in can't write code at all, people are managing Software Engineering teams?
I've certainly never seen it, at least until you get to Senior Exec levels of
leadership. I've only been in the industry for <10 yrs but I still find it
hard to believe it's that common.

~~~
vikramkr
There are non software companies with software teams

~~~
devalgo
Sure, I work at one. But my manager is a former tech lead/architect who writes
code everyday and he reports to a former Startup CTO with a CS Degree from
UIUC. Are English Majors with no tech chops seriously managing engineers in
2020?

~~~
ciceryadam
MBAs, mostly.

------
Aperocky
I agree with the gist of the article. The point is not to throw manager into
actual coding task, but for them to have a background understanding of how
everything works either through formerly being a software engineer or
$(multiple ways one can educate oneself on the principals of computer
science).

My anecdotal evidence have strongly pointed that for a software project,
managers that have an understanding of computer science have a strong edge on
communication and decision making.

------
abakker
Alternative POV: if they're not an engineer, then they NEED to be good at
something else. I can imagine a situation in which a really excellent,
organized, project manager with excellent ability to run interference with
other teams/management was a valuable manager. This seems that the argument is
more like, "Managers who do not code should not pretend they know how to
code". Maybe, in that situation developers should look for technical review /
help from their peers on the team?

------
mkozlows
Hard disagree. Some of the best managers I've had are non-coders. I think a
technical manager needs to be able to understand technical concepts at a high
level, but actually writing code? Nah.

(Some of the worst managers I've had, contrariwise, were people who started as
coders and kept trying to work their decades-old knowledge into conversations.
No, this service didn't "ABEND," thanks.)

~~~
curiousllama
As a kind-of technical person (tech degree with limited professional
application), I think you're exactly right. After going tech role > non-tech
role > non-tech-but-managing-tech role, I found it was often most valuable for
me to stay at a buzzword level. My team was always happiest when I could take
their mostly-natural output and keep the monkeys off their back.

------
siliconc0w
I find it really rare to find managers who regularly code. Even if they once
coded, after a year of two of not coding and they've lost all context and
familiarly with the codebase or tooling that they probably shouldn't be coding
anyway. Managers should be technically competent but largely be neutral
arbiters that encourage and support their teams (ideally you have a 1
manager:2+ team ratio or they tend to micromanage). They should really only be
making technical decisions if the team is deadlocked and there needs to be a
tie breaker (which should be relatively rare and it's likely both directions
are reasonable at that point).

Senior engineers should be kept around to mentor younger engineers to provide
that valuable feedback and there should be a career path that doesn't require
them to go into management (a lot of companies try to do this but I've never
seen it done well and the managers always seem to have broader reach, better
compensation, and more promotion opportunities).

------
jmcgough
I've only experienced a non-technical manager once - maybe this more common in
older, more traditional companies.

I don't agree that a manager should spend 80% of their time coding, though.
Maybe for smaller teams at early stage startups. But for even a team of 4-5,
there are typically things they should be doing that are a better use of their
time. It helps to code part of the time (maybe 20%) to understand the
codebase, your level of technical debt, and proposals from engineers, but
coding can be a trap that keeps you from doing what you need to do to enable
your team.

In a worse case, technical managers can become micromanagers, and their
opinions can have so much outsized influence that they lead to bad decisions.

------
RodgerTheGreat
In software, I think that there is a qualitative difference between managers
who _have programmed_ \- at any level of experience, even if it was a long
time ago- and those who have not. Some exposure gives them a more realistic
notion of what is hard, what is easy, and what is bullshit.

Beyond this, programming skills and specific technical knowledge can be useful
as a manager, but I'm dubious that they are as essential as this article
implies.

I further imagine that a similar pattern holds for other technical fields- you
need some basic grounding, but do not need to be a technical expert to manage.

------
sulam
This rubric is fine at a certain level of scale, but as a company grows, both
in size and complexity, it becomes hard to apply except possibly in the leaves
of your organizational graph (and not always then).

Personally I manage a team of 400+ engineers. They do the full range of
embedded systems across multiple platforms, iOS and Android native
development, full stack web development, backend systems, and data science. We
go all the way from device drivers that are deployed to 10's of millions of
devices to Spark jobs running in a reasonably scaled up cloud infrastructure
(5 digit CPU counts, not 6 or 7).

Needless to say, I am not competent in all of these domains. I do my best, and
when decisions get to my level I know how to make them in a way that doesn't
leave me as the weakest link, but fundamentally I can't possibly be an expert
in all of what we do. There aren't enough hours in the day or days in a life.

Compounding that problem, at this level of scale, I believe in cross-
disciplinary ownership. We don't have an iOS team that throws things over the
wall to a site team, or a FW team that only thinks about how to optimize their
part of the world. That means many of my managers are also managing engineers
who know orders of magnitude more about their discipline than the manager
does. It turns out this would happen anyway, because the manager shouldn't be
making most of the technical decisions, and they don't have enough time in the
day to stay expert in even one discipline at the level a senior IC is expected
to.

You can't expect your managers to be the ultimate expert across the domains
they manage, and even if they happen to be, you can't expect them to be able
to keep that position (our industry changes too rapidly). What having been a
practicing engineer does for them is to give them a perspective on what
matters, to ask the right questions, to help the team develop an ownership
culture so that they don't rely on the deus ex machina of a manager know-it-
all who tells them what to do. Very few of the skills they need relate to
having been the best Javascript engineer on the team at some point in time.
They need to know how to _develop_ the best engineers, not continue to occupy
that role themselves.

Last thought here -- this compounds when you get promoted into a role of
managing managers. For many managers, this is a harder transition than moving
into management in the first place.

~~~
lanecwagner
Great insight, thanks for sharing. I believe your example is a good one. I'm
still a believer that someone in your position should have a solid
understanding of the architecture of your system, and likely experience with
at least a part of it. That doesn't mean you need to be an expert in every
domain, obviously, as that would be impossible.

------
yllus
I'm curious about a related question: Does a manager need to be the best coder
on the team? How much does it help/hurt if they're not?

~~~
lanecwagner
No, but IMO they should be one of the more technically competent people.
Managing is not a full-time job, at least for a good manager its not a full
time job.

~~~
managementthrow
I think you're underestimating how much work there is at the management level,
especially in larger organizations. When management is doing their job, it
won't be visible to you or your team. Things will just "align", and work well
- but if things are moving smoothly in an organization with multiple teams,
your management is working well.

There is a lot of systems thinking required in managing team structures,
interfaces between those teams, managing communication between teams, hiring,
setting technology standards & architecture, and so on (review the rest of
this thread).

I do agree with your thesis though - a manager should be highly technical. I
just don't think you can depend on their contribution to features &
deliverables. Not because the work is "below" them, but because Engineering
Management is a support role and should NOT need to choose between an IC-type
task and helping unblock/support a member of their team due to a deadline :)

------
peter_d_sherman
>"In this study from Harvard 35,000 employees from the US and Great Britain
were polled about their job satisfaction, and metrics were gathered about what
influenced their happiness at work.

The results showed that

 _the single greatest influencing factor on employee satisfaction was whether
or not their boss was technically competent._ "

------
yalogin
I have been thinking about something else. What is the exact function of a
manager other than the annual reviews and hiring? I would like to ask the
managers here, what does your day to day look like? How involved are you in
the technical things your team does?

~~~
lanecwagner
Author here: this is something I wonder often. In companies I've worked at
that had non-technical leadership in the engineering department I'm suspicious
that they just played Bloons TD 4 all day. They certainly never seemed to have
anything to do other than hire, fire, and go to meetings to have things
explained to them.

~~~
curiousllama
That's not it at all - a year ago, we actually defined a new strategic
initiative to migrate the legacy userbase to BTD5, and the CEO herself gets
regular readouts.

------
fortran77
So Steve Jobs shouldn't have run Apple?

