
Why Good Developers Are Promoted into Unhappiness (2007) - spking
https://robwalling.com/2007/06/27/why-good-developers-are-promoted-into-unhappiness/
======
wjossey
I’ve been reviewing a lot of career path documents recently for different
engineering orgs, and every one is fairly uniform in that you either progress
into management, team leadership, or architecture (or some blend of the
three). If not, you’ll stagnate at a pretty high level, but stagnate none the
less.

I’ve been noodling on this for a while, and I think maybe a fourth track at a
lot of organizations should be special projects. Small teams (3 people max)
given autonomy and clear objectives (revenue goals, user growth goals, etc).
For a pre existing company, this likely means “hacking” on an existing
product, experimenting on something new, tackling huge debt... Pick your
poison.

This is a fine middle ground for someone with a lot of experience who doesn’t
want to manage, but still wants some growth opportunities. For many people who
don’t want to manage or be an architect, autonomy is the number one thing I
regularly hear. So, give them the autonomy and some ground rules, then let
them loose.

~~~
jasonkester
A better fourth path is to transition to running your own business. You still
get to write the code, and you remove the salary cap.

People sweat about all the “Business Stuff” you have to do in addition, but I
find it’s not really any more of your day than the normal boring admin stuff
of being a rank and file developer. Certainly less than being a manager at a
bigco.

It also does away with ageism concerns.

~~~
scarface74
So instead of going into management because you don’t like management and want
to stay an individual contributor, you now become not only the manager of your
own company, now you have to worry about marketing, finances, etc.

I go to bed every night not worrying about whether my company remains
sustainable. If they don’t, as long as it is a microeconomic issue (company
failed) and not a macroeconomic issue (economy is in the toilet), I reach out
to my network and get another job relatively quickly.

The same amount of money appears in my account every other week whether I go
on vacation, call in sick, etc.

And I’m 45. Ageism is way overblown if you keep your skills current with the
market and your network strong.

~~~
ses1984
One. 45 is the very beginning of when ageism starts to show (at most
companies). There are certainly some companies that would be biased against a
45 but maybe you don't work there. Just wait.

Two. You're not going to multiply your salary by 2x-20x unless you start to
take on more responsibility, like worrying about sustainability.

~~~
Veelox
>You're not going to multiply your salary by 2x-20x

Well damn, I guess I am going to have to make do with 200k being a rank and
file developer at a FAANG company.

~~~
ses1984
If you're happy with that, great. I am. But we're not really the subjects of
this thread are we?

------
democracy
You stay in the company long enough and you write less code and spend more
time managing people and processes as now you own your projects as the most
knowledgable person for these projects.

You start hating it (I did) and look for a pure programming role. But you are
not in your twenties any more and you have to align with and follow someone
else's designs and decisions and you can't since you are experienced and know
more and you have to push back and argue and end up going to lead/architect
role again and writing less code again.

~~~
gitgud
George Hotz once mentioned in an [1] interview; Managing people just another
abstraction in making software. You can think of people kind of like an IDE
that you can use to create things... I thought it was an interesting way to
view management.

[1] [https://softwareengineeringdaily.com/wp-
content/uploads/2018...](https://softwareengineeringdaily.com/wp-
content/uploads/2018/08/SED649-Self-Driving-George-Hotz.pdf)

~~~
marmaduke
Yeah my boss certainly sees me and my colleague as a technical problem solving
API: he says “now that I have told you what the problem, it is no longer my
problem, and I don’t want an update unless it’s the solution.”

I think this is sort of ok at a high competence level, but fails when the
people you work with are less experienced. One could say the same of an IDE I
suppose..

~~~
Aeolun
At a low competence level, this leads to non-solutions that still have to be
used because of deadlines.

~~~
spockz
I would argue that the how is up to the team and it is the boss/managers level
to ensure the right competencies are present in the team. Having the boss join
the team is not sustainable.

------
netmonk
This is what happens when management is valuated more glorious than any other
activity. Systems and hierarchies therefore tend to reward good performances
with what they considers as good recompense: management position.

This mindset bias is everywhere, first i noticed it in my european university,
where the good teachers were promoted to high responsabilities position,
meaning more and more administrative workload and far lesser time for
teaching. Leading to the vicious situation where the teacher was not teaching
anymore and not happy with his position, and studend loosing a good teacher
and having to face less capable teachers. Using management position as a
reward should be only used for wanabee managers.

~~~
mooreds
> This is what happens when management is valuated more glorious than any
> other activity.

Why might management be more valued by the organization? Perhaps because it
produces more value for the organization?

A manager who enables 10 developers to achieve a goal (as mentioned in the
post) is going to be more valuable to the organization than the same person
who cranks out a bunch of code. That's the reason for the prestige and money.

Now, there are two answers to my argument. Either the organization is correct
in valuing managers more highly, in which case if you want to stay an
individual contributor, you should accept less pay and prestige.

Or the organization is incorrect. The costs to the organization of people
being unhappy or leaving are such that the additional value from them leading
a project evaporates (in the long run). In which case this should be revealed
and hopefully good organizations will make adjustments. As other people have
pointed out in other thread, Google does something like this.

------
burlesona
I think it has a lot to do with wanting to have your cake and eat it too.

Supposing you literally “just write code,” there’s a ceiling to how much
impact you can have. One person can only hold so large of a program (or so
many small programs) in their head, and if you are on a project that reaches a
certain size you have to start working with other humans to maintain it, and
thus the need for technical leadership and/or people management begins.

One of the basic ideas of _good_ management is that a good manager is a
multiplier. Suppose you have a team of ten, and individually they can each
ship 8 “points” of work in a week. If you turn one of those people into a
great manager you lose 8 points of direct work, but everyone else now ships 12
points per week, and you’ve gone from 80 to 108 points in a week. You could
now say the manager is responsible for the 28 point gain.

Similarly with a technical leadership role, doing the architecture and
teaching work can multiply the effectiveness of many other people, leading to
greater impact than any one individual could have.

When you look at it like this, it’s obvious why these higher impact
“multiplier” roles get more prestige and pay than the best individual coders.

And I think that’s the dilemma. The real question - for many of us, anyway -
is do you gain more satisfaction from the higher impact role and the perks
that come with it, or from the sheer joy of the hands-on work that got you
into this field in the first place.

Its really difficult.

I saw some other posters talking about rotating the responsibilities around -
ie. leading sometimes and working in the trenches sometimes, and I really
understand the appeal of that. That said, I’m not sure if it’s practical
beyond the first “rung of the leadership ladder” or so, because leadership is
itself a very challenging craft that takes a lot of focus and effort to
master.

What appeals to me more, but I haven’t seen yet in practice, is for orgs to
let their technical leadership (both on the architect and people management
sides) take periodic “coding sabbaticals,” or something along those lines. The
main idea being that periodic returns to the hands-on work will help keep you
sharp, up-to-date, and effective as a technical leader. The biggest problem
with that is that it’s not always easy to just plug a “substitute leader” into
the org chart while you’re on sabbatical.

~~~
revvx
> Supposing you literally “just write code,” there’s a ceiling to how much
> impact you can have

I'm don't see why a single person can't have a ton of impact merely as a
coder.

I mean, this whole website is dedicated to (mostly) discussing tech startups
and how (mostly) software disrupts and help scale outdated business models.
Isn't the software-making business model also ripe for that disruption, at
least in a smaller scale?

Couldn't a single coder (or a small team) help an organization get some
competitive advantage when it comes to tools. Or even programming languages?
Why does ALL the innovation has to come from outside in our industry?

Fred Brooks talks about "The Toolsmith" it the "Surgical Team" chapter in
Mythical Man-Month, and how "the tool-builder will often construct specialized
utilities, catalogued procedures, macro libraries".

Facebook made React, Apple made Swift, Google has dozens of those. And the
teams doing those tools aren't that huge. Why don't we try new things instead
of letting good coders go away or making them stop coding?

~~~
badfrog
> Couldn't a single coder (or a small team) help an organization get some
> competitive advantage when it comes to tools. Or even programming languages?

Sort of, but:

1) Knowing _what_ to build requires deep knowledge of that the other engineers
in your company are struggling with. Figuring this out requires a lot of time
spent meeting with people and doing other things that would be considered more
management than coding.

2) If the thing you build is good, it's going to start getting a ton of
feature requests. Your company will decide that it's worth investing in, and
suddenly you're either managing a team or somebody else is managing you and
running "your" project.

~~~
revvx
Then get someone to help you run the team, instead of a boss.

------
revvx
A solution for that is promoting the best developers that don't want to manage
into technical leadership roles. They can still create things and impact the
team positively, and will not suffer with managerial tasks.

> if Willie Mays played for your baseball team would you promote him to
> manager?

I don't know who Willie Mays is (not in the US), but I'm pretty sure elite
athletes get top notch salaries, a lot of times bigger than managers or
coaches.

People shouldn't need hierarchy just to remain professional and follow someone
else's lead.

------
eight_ender
I wrote code like a madman and then went into management. I like management,
but I understand what the author of this article was getting at.

I had an identity crisis early on doing management. I liked to tell people
what to do, because I had a big map in my head of where things should go.
Because of this developers sort of organically gravitated to me for guidance
even before I had the official job. However, I also liked to write a lot of
code.

Once I was promoted to management I quickly realized just how much "not
coding" that job requires. I struggled with not coding as much. I struggled
with wanting to micro manage my staff. I struggled with wanting to write their
code for them. I had juniors on my team and I wanted to snatch the keyboard
from them and write their code for them.

The defining moment for me was one day, while watching one of my developers
deploy something magnificent, that I realized I don't necessarily like to
"build things", I like to "see things built". I like to see people succeed. I
like to see a scribble on a napkin become a tangible piece of software. Code
was a means to an end for me.

I won't lie and say I don't miss coding full time. I still get right in there
when I can, but I step aside when I know my management duties are going to let
the team down. One thing I don't feel is guilty about not coding as much
anymore.

~~~
ramraj07
So how DO you deal with people under you writing code under you that just
boils your blood? Especially if you instinctually see that their contributions
are always more counterproductive than not, but everyone else (including their
people manager) thinks they're alright?

~~~
jklm
There are a couple ways you can look at this situation:

\- There generally isn’t an ‘optimal’ solution, but there are a lot of
solutions with tradeoffs.

\- Everyone has their strengths and weaknesses, and gravitate towards
different molds.

\- People aren’t born perfect, but what they can do is grow. How can you help
them do that?

------
macando
Every time this topic surfaces project management in the form of politics and
pushing tickets through Trello is presented as the only option available to
engineers. To me, a more natural progression is going into product management.
It's a nice intersection of management, product design and engineering. From a
job description:

" _We’re looking for a product leader to join a fast-paced and
transformational start-up to manage various fraud and identity initiatives.
While managing product development, The Director of Product, Fraud and
Identity will analyze, investigate, and identify solutions to mitigate and
prevent fraud and identity compromises. This individual is responsible for
developing features, platforms, models, and capabilities to proactively
identify sources and patterns of fraud and minimize the company’s total
exposure to financial and reputational risk. The product leader will develop
and execute a long-term vision that will establish Lyft, and its systems, as
the industry leader in fraud management, mitigation, and identity-based
capabilities and services._ "

Are engineers not interested in product management? Or are those roles not
available to them?

~~~
mixmastamyk
Can’t say definitively, but know that these days if your resume has X and they
are looking for Y it’s a no-go. Even when X overlaps Y significantly. Hard to
even get a job as a programmer in one language with experience in another.

------
dub
This feels like a variation of the Peter Principle
([https://en.wikipedia.org/wiki/Peter_principle](https://en.wikipedia.org/wiki/Peter_principle))

The Peter Principle says people who are good at their jobs will keep getting
promoted until they reach a role they're not good at.

In this variation, people get promoted until they reach a role they don't
enjoy and eventually leave.

------
cryptica
I cannot relate to this article at all. It's the polar opposite of my
experience.

I've been desperately trying to get into a management position for years. I
started programming at age 14 and am now approaching 30. I created projects
using basically every major programming language, created and maintained a
complex open source project which now has over 5K GitHub stars and several
tens of thousands of weekly downloads.

I have experience managing the community around the source project and doing
peer reviews. Feedback from the community is overwhelmingly positive. I can't
even make a consulting business around the project because it works too well,
the documentation is good and the community is very helpful.

I got passed up for promotion many times - In spite of consistently delivering
beyond all expectations and despite my background as a long time open source
developer. I've had people younger and less experienced than me get promoted
above me twice! First time this happened, I quit the company about 1 month
later (they were very upset/regretful when I handed my resignation).

Then it happened to me again at my current company - In spite of the fact that
they are using my open source software as the core of their product (since
before I joined). Even the biggest competitors of my current company started
using my OSS project. Still no promotion. WTF do I have to do to get promoted?
I've told the CTO multiple times that I want a promotion so it's not like they
don't know.

~~~
dyeje
In my experience, people are usually promoted into management when they
demonstrate leadership. I see you talk about your technical ability a lot, but
that is generally not the core competency of an engineering manager. I suggest
working on those abilities. It is very much so one of those situations where
doing the job will get you the title.

~~~
pbourke
> In my experience, people are usually promoted into management when they
> demonstrate leadership.

Really? In my experience, people are often promoted into management when they
demonstrate political ability.

Often the people who I consider the true leaders - engineers who everyone
considers competent, good advisors, mentors and role models, etc - continue
quietly being engineers.

Several times, I’ve seen organizations reward people who were adept at
deflecting and spinning projects, goosing metrics and hiring quickly (despite
a lack of fit/competence in their hires). The teams that they led were
demoralized and rudderless, but you’d hardly know that from how they were
rewarded and promoted.

~~~
jondubois
Agreed. The definition of leadership that most leaders have in mind is very
superficial. They just want people who look and talk like a leader but they're
willing to compromise on everything else (all things that actually matter in
terms of producing value). Most software companies either are mini-monopolies
or they are able to keep securing VC funding through social connections so
they can afford to have mediocre leaders who can talk but don't deliver.

------
United857
Thankfully, many if not most top tech companies in the valley realize this and
have parallel management and IC tracks (at least for software engineers), with
compensation the same.

That said, even as an IC, at higher levels the scope of impact you're expected
to deliver at some point exceeds what one person working alone can have, so
there's still lots of people _leadership_ skills needed to advance: working
cross-functionally and setting direction, communication, and ultimately
influencing others to jump onboard and help you out.

(Note that this is different from people _management_ \-- e.g. formal
coaching, performance reviews, dealing with HR/org/budget issues, etc.)

~~~
opportune
Many in theory have parallel tracks but in practice it seems either the vast
majority choose to go into management or that it takes a more exceptional
individual to progress in the IC track (my money is on #2). IMO you don’t
really need to be an above average person to reach the second layer of
management, just put in your time and not fuck up, but everyone I know who hit
the same level as IC was exceptionally bright and was like that long before
they hit that level

~~~
maxxxxx
In my company it's certainly the case that in order to progress on the
technical track you need to be extremely good and more importantly on the
right projects. I see a lot of mediocre people advance on the management track
but only very few advance above a certain level on the technical track.
Considering that salary is directly tied to a person's rank I think it's a
very rational decision to go into management even if that's not your
inclination.

~~~
twblalock
This really depends on the company. I know senior ICs who make a bit more
money than the managers they report to.

~~~
opportune
But my guess is that in 5 years their manager will be making more than the
senior IC

------
Aloha
For many developers, they turn out to be good at project management, its not
much different conceptually than being an architect, this issue is, once you
'level up' you're expected to stay there, rather than moving back to develop
for some period of time, and letting the next guy get tapped for project
management - It think more companies rotated those roles around, they'd see
greater retention, greater employee happiness, and probably lower costs - as
an engineer, I don't want to be a PM forever, but I might be happy spending
1/3rd of my time over a given long term period wearing that hat.

~~~
orthoxerox
> its not much different conceptually than being an architect

I don't know where you are from, but in my experience the roles are very
different.

As an architect you have to provide technical guidance over a domain that you
know like the back of your hand.

As a PM, you have to manage a project that straddles multiple domains, some of
which are completely alien to you, and you are explicitly limited by the
scope, deadlines and your budget.

As a PM, you have to trust (and goad) multiple experts if you want to get
anywhere.

------
Al-Khwarizmi
Funnily enough, it's the same thing in academia/research. You get into it
because you like doing research and you (think you) are good at it. And if you
are really good (and have a healthy dose of luck), eventually you progress to
being a professor, you are principal investigator of some projects, and you
find out that your job now consists mainly of managing a group of people -even
if you aren't especially good at management and haven't been trained for it-
and writing grant applications, and you have almost no time for actual
research.

The difference is that in academia is not an explicit promotion that moves you
from research to management, but more of a boiling frog kind of situation
where you gradually do less and less research and more and more management -
or at least this has been my experience.

------
tracer4201
I’m in a senior level engineering role at one of the big tech companies. I was
more than happy to receive the promotion, but the time I spent coding has
certainly decreased a large chunk. I spend a lot of my time now facilitating
projects across organizations, providing guidance to more junior engineers on
architecture, sending emails and status updates, etc. at least that’s the norm
on my current team.

Not long ago, I would be heads down in code all day everyday. My world was
laser focused on getting out 1-2 code reviews a day, shipping small features.
It paid substantially less, but I really wasn’t responsible for projects or
deliveries. Business people want a feature? Great... here’s a t-shirt size
estimate. Heh.

------
dang
Discussed, a bit, at the time:
[https://news.ycombinator.com/item?id=32752](https://news.ycombinator.com/item?id=32752)

------
bartimus
I'm surprised how these traditional organizational structures still exist so
strongly today. It sometimes feels like the whole agile/lean revolution (with
self-managed teams) never happened.

~~~
jaabe
The agile revolution never happened because it’s just not how people buy
things. Hell, I don’t even think it’s how we build them.

I love the analogy of a burger joint and ordering a burger with fries, because
from a buyers perspective, that’s exactly how we want to buy software. We
point out some items on the menu, and we expect them to be delivered together,
on time and to our specified demands. The person taking our order, and making
it happen is the project manager who makes the different cooks do their stuff
in coordination and also the person who puts shit together on a tray.

That’s exactly how people buy software, or at least how they expect to buy it.
Only software is more complicated, and developers keep failing to deliver the
ordered project on time. Agile was supposed to help on this, but it hasn’t. I
mean, it’s anecdotal, but I work in the public sector, we track and benchmark
the hell out of these things for a bureaucracy that probably never reads the
reports. Anyway, agile suppliers fail as often as non agile suppliers, and
they have the added problem of wanting to sell us promises.

I mean, a true agile contract can’t specify requirements, cost and time at
once, but how the hell can you ever enter a contract that doesn’t? So they
typically end up mixing non-agile sales with agile development. I’d like to
note, that we have actually entered into truly agile contracts. Being a
digitisation unit in an organisation that largely doesn’t understand
digitisation gives you a lot of freedom after all. Only agile wasn’t better,
in fact it’s been a lot worse, every time.

In our decade long experience, the only thing that truly works, is when
management or project management knows how to make the damn burgers. Which
unfortunately means that you need to promote a few developers into
unhappiness.

~~~
bartimus
> I love the analogy of a burger joint and ordering a burger with fries

I would like to argue that the burger joint is actually very agile. The person
taking the order isn't the project manager. He just has the role of placing
the order on the kanban board. From hereon the rest of the people all take
their self-managed roles to fulfill the order. You can point out such agile
(lean) processes throughout the entire delivery chain.

> Agile was supposed to help on this, but it hasn’t.

My experience has been exactly the opposite. Those companies that managed to
achieve a true agile process (or achieved an agile bubble inside a structured
organization) were making the best progress. What I do see, however, is many
companies misinterpreting agile. Especially Scrum. They see Scrum as a method
for ticking off the to-do list provided by the product owner. I've seen
project managers posing as scrum masters and project managers posing as
product owners. It's still top-down management and the team is expected to
follow orders. They don't seem to understand the principles of the sprint goal
or how it's actually the development team that ought to own the sprint
backlog. They never really did scrum.

> I mean, a true agile contract can’t specify requirements, cost and time at
> once

This is indeed a challenge. You can - at most - sell sprints. With agile you
say: "You have the dev team for this amount of time". It's an uncertainty for
the client. But in my experience this has always led to the most bang for the
buck. I'm surprised you haven't experienced these results?

> Which unfortunately means that you need to promote a few developers into
> unhappiness

This perhaps is an argument in favor of agile. Those project managers indeed
need to know how to make those damn burgers. Then why not just make them your
lead dev (chef-cook)?

------
yaniv_aknin
I think it's pretty common to talk about "management career path" and "tech
lead / architect career path", and I think it's a mistake. I think there
should be three paths: manager, TL/architect, and individual contributor.

I wish Google (I work there, opinions my own) had three ladder flavours for
engineers, not two. If we did that, in Google terms (ref.
[http://levels.fyi](http://levels.fyi)), I think: \- the IC ladder should go
from L3-L6, maybe L7 \- the TL/architect ladder should go from L5-L11 (note
overlap with IC) \- the Management ladder should go from from L5-SVP/CEO (I
don't know the numbers for SVP, but I'm guessing ~13 or so...).

------
gumby
Some companies specifically work to avoid this by having two "tracks": a
management track and a technical track. The management track has many titrated
ranks (manager..assistant director...) while the technical one still has
salary increases and fewer ostensible title "promotions". So an IBM fellow is
as prestigious as being a Sr VP or maybe GM, yet the holders didn't climb the
"greasy pole" required of traditional management.

I believe IBM was the originator of this approach, but could be wrong.

------
the_arun
Nowhere it says - we cannot program when we become a manager. What if managers
continue to make 0s & 1s dance - half of the time if not full time? Wouldn't
that be productive & fun? I would say world is changing towards this side. I
have heard stories where VPs & SVPs in big enterprises write code & lead their
teams by example.

~~~
burlesona
I think this is a question of scale and hours in the day. In my experience
when the team grows past 5 it gets difficult to do all the leadership things
that “clear the road” for the team and also have enough focused time for
effective programming. But at the same time, once you’re at that point, if you
stop coding you can now handle another 5-10 direct reports. So you have to
chose between keeping independent teams quite small with team leads who code,
or with allowing bigger teams with a dedicated manager.

The scaling characteristics of those two patterns are different, because
inter-team collaboration is pretty much always worse than intra-team, so the
small teams are more effective if they are as independent as possible. If not
you end up needing an extra manager to coordinate amongst the small teams...
and now you have managers who don’t code.

------
makecheck
“Promote developers who demonstrate management skills instead of top notch
development skills.”

 _Instead of_? No, that would just make developers think that software skills
aren’t valued at all.

There should be multiple equally-prestigious paths so that there is _some_ way
to publicly recognize star developers without turning them into managers.

------
ianrathbone
I remember starting as a developer wanting to be respected by my elders, and
just looking to become senior as soon as possible. I got it and didn't feel
very different.

I jumped at an opportunity to manage the software department and enjoyed the
managerial side and representing the team within the rest of the company. I
didn't like the politics and I didn't like knowing what I started to know
about the company itself. A pretty big weight that took it's toll.

Most of all I missed coding, I wasn't doing it enough and I started to fall
behind on the industry.

The idea of a Lead role is something I courted but then realised it may not be
rewarding. I'd like to know how other lead's find their role...

~~~
ido
When I worked as a lead most often I would:

* sit in a lot of meetings with management/other departments

* try to filter company politics from my team (thus absorbing it myself)

* would try to find what work would be most suitable and rewarding (considering interest & future growth) for each of my developers, thus in practice ending up with the most boring bug-fix & other maintenance tasks myself

* participating in a lot of project-management as well as people-management of my direct reports (weekly one on ones, conflict resolution, planning career growth, etc)

In practice I found the role of Principle Developer much more rewarding.

------
biofox
Whenever this topic comes up, I'm always reminded of James T. Kirk after his
promotion to admiral:

[https://www.youtube.com/watch?v=CL9Dl0i1Ef8](https://www.youtube.com/watch?v=CL9Dl0i1Ef8)

------
austincheney
I actually enjoy management even when it means more administration at
sacrifice to writing code.

What I don't like is when I am mentoring a junior on best practices or
techniques to increase their performance or the performance of their code and
they get defensive to the point of becoming an insubordinate ass. I understand
there is a lot of defensiveness in development, but in the corporate world I
expect everyone to be an adult. I also expect junior developers can read,
write, and follow simple instructions but I have been surprised by that as
well.

~~~
badfrog
It sounds like you're not a very good manager, unfortunately. One of the most
important things a manager does is understand how to communicate productively
with each of their reports. If you have reports whom you believe cannot
"follow simple instructions", your first response should be to re-evaluate the
way that you provide guidance to that person, not to decide that they're "an
insubordinate ass".

~~~
austincheney
Should I use crayons and coloring books? That was actually a half serious
question. For what developers are paid basic literacy is a safe assumption.

~~~
option_greek
Just trying to be helpful:

You come across as a know-it-all and patronizing in the above two comments
alone. May be you can start by recognizing that developers are not your extra
sets of arms to code stuff. You should limit your self to clearly
communicating objectives and measuring them rather than guiding devs (micro-
managing ?) at every step.

------
rurban
In my previous company all the senior engineers took a few juniors under their
umbrella and had very informal one-on-ones with them, just to bypass the
troubles with non-technical managers. Hereby I as senior could give practical
advices, eg how to deal with politics, without having to go into politics,
excel and powerpoint and meeting-hell by myself.

This way the good senior devs didn't had to be promoted to management roles
they didn't want, and the bad devs didn't get promoted to senior not to fuck
up the juniors with bad advice.

~~~
mk89
You kind of described a highly disfunctional company, where you as a senior sw
engineer literally had the power and authority to choose who would get
promoted and who wouldn't.

~~~
JAT123
I think what he is saying is not particularly uncommon.

Several of the orgs I have worked at have expectation that a senior developer
will help juniors, whether that's formalized as a line management and 1 to 1s
or informal mentoring.

Tbh expecting to be a senior developer and not give any time towards leveling
up the next generation of software practitioners is both selfish and short
sighted.

------
Jach
The machine is a companion and safeguard against swallowing too much of my own
BS, or the BS of others that I get involved with. I'm unhappy without that
level of feedback being frequent. Even declaring for Crocker's Rules doesn't
get you really honest feedback from humans.

It's really gross that the higher you go up the tech IC ladder the less you
code. Your opinions also somehow matter more even though you're furthest
removed from knowing if they're valid.

------
alkonaut
I have rejected any calls for leadership positions which would mean I’d code
less than 90% of my time. It might have cost me some money but it sure means I
can do what I love and I have less than 1h of meetings every week. I still try
to do _technical leadership_ (architecture, coding standards, evaluating new
products etc) but not _people management_.

------
dugluak
OP should consider working on some coding side projects and keep his passion
alive. Consider the day job as just a means to pay bills.

~~~
tenaciousDaniel
In my experience, this works when you're younger, but as you age, you tend to
accumulate responsibilities that take up a lot of your remaining energy. YMMV
though.

------
qetuo13579
My boss is engineering manager at our company of 60 people (he leads 16
engineers) and still finds time to get down in the weeds solving tech problems
in addition to managing us. I’m his number 2, based in another country and am
responsible for managing/supervising 7 engineers. I too am expected to do
development work AND management of the team.

------
narnianal
If you are a good developer, you are probably smart, right? So why would a
smart person let something happen to him that he can't fix? Would it be
possible for a dev manager to apply as senior dev in another company?

I think they are not unhappy. They just don't want to admit it. Either they
really enjoy this additional human interaction, or they actually really found
coding stressful or meaningless. But of course it helps them bond with their
engineers more if they can show that despite their +120% income and despite
their more beautiful house and wife, and despite having more power they
actually suffer because they are not a fellow developer anymore.

One can also argue that the developer who stays developer his whole career is
actually not someone who was overlooked at promotions, but someone who really
enjoys the coding grind, the low amount of visibility and the low amount of
responsibility. But the bonding with their friends is much higher if they can
hate on the management together instead of admiting that they actually like
what they do and how they do it.

Altogether these realizations made me more relaxed about life. In the end it's
not that the world is full of suffering, but we actually choose the suffering
that makes us most happy.

------
billions
When you understand how few lines of code create the business you work for,
you realize the value is in taking risks on new product lines, which, are
politically discouraged by most companies. for example, google.com could fire
all employees tomorrow and still dominate search $ for 10 years based on an
idea from 1999.

------
2sk21
Make a lot of money doing boring management work for a large company. Save as
much of it as you can and retire early. Then code as much as you want - thats
my plan at least :-)

------
jrochkind1
What do people think about "technical lead" roles?

------
GnarfGnarf
I've been writing code since 1965 and have been fortunate to have evaded
management. I'm still writing code and it's the funnest job there is.

------
ravedave5
I've enjoyed the challenges that each level of promotion bring. That said my
company has always allowed coding all the way up to top-level architect.

------
zerr
But eventually he jumped into marketing.

------
giorgioz
The author Rob Walling co-hosts the podcast Startups for the rest of us:
[https://www.startupsfortherestofus.com](https://www.startupsfortherestofus.com)
which is the best podcast I know of about bootstrapped startups.

