Hacker News Reader

Comment by gfodor | Hacker News Reader

1. Become an engineering manager

2. Stop coding

3. Do well for a few years until you become out of touch

4. Watch your team stop respecting you on technical subjects because you’re behind the times and too rusty but don’t know it so look foolish and are ignored when you give suggestions, which radically undermines your relationships with them as well as your ability to lead

5. Watch as your role morphs from a manager with chops and respect into a PHB, unless you happen to have been born with natural leadership skills (you probably haven’t)

6. Realize you are now just a mediocre manager who can no longer return to the engineering track since you cannot compete with other candidates

7. Drag yourself to retirement by slogging through life as a relatively poor middle manager

View on HN

> unless you happen to have been born with natural leadership skills (you probably haven’t)

Leadership skills are important, but I disagree that leadership is something you’re either born with or not. Leadership can be taught, learned, and practiced.

The real issue is that a lot of people who are pushed or drawn into management roles don’t actually like managing or leading. Some are pushed into management because they’re the most competent IC on the team. Others are drawn to management for the perceived prestige or possible career advancement.

Some common failure modes for engineers turned managers:

1. A person who enjoys quietly coding alone for hours at a time is not going to like being removed from the code to do management work

2. Anyone who dismisses relationship building and diplomacy as “office politics” or “brown nosing” is going to struggle to build the required relationships to get things done as a manager.

3. People who get exhausted from context switching or juggling multiple topics will hate the manager’s schedule.

4. People who loathe meetings are going to be miserable as managers.

5. Anyone who struggles to have difficult conversations, broach uncomfortable topics, or confront people who are causing problems is going to struggle to lead.

6. People who assume they’ll naturally be good at leadership or management won’t learn the necessary skills fast enough, unless their company forces it on them. There are many good resources for learning management and leadership skills, but it’s not uncommon for first time managers to assume they’ll learn it on the fly.

I would argue pretty strongly that if you are not a natural leader, the road to development of leadership is paved by domain knowledge which lets you get respect “for free” to leverage to ratchet up those skills. So I’ll adjust what I said to mean you are racing against your engineering skill atrophy to develop those leadership skills. Once you can’t code anymore, it gets a lot harder to do so.

>The real issue is that a lot of people who are pushed or drawn into management roles don’t actually like managing or leading. Some are pushed into management because they’re the most competent IC on the team

I think this is spot-on. People, for whatever reason, view management as the next step of a career when it's actually a career change. Yes, it's in the same domain, but it's a totally different job.

I've done the transition from IC to Manager, back to IC, and then back to Manager again. Unless you like and want to do "manager" things, you're going to have a bad time.

I'm curious. Multiple back and forth seems to indicate that you missed your previous role. Was that why you made multiple shifts? Or were they just different opportunities?

I agree here to that this is the exact issue.

I will also add though that I think there is another dimension as well. I think much perceived middle manager "incompetence" stems from middle management juggling direction/pressure/expectations from senior management, and the realities of the program and the engineers. The best managers are capable of managing expectations from above while keeping their team shielded from all that overhead and just keeping the team chugging along and being productive. Other managers seem to have the ability to weigh their team down by allowing too much of the "managment overhead tasks" to leak down to individual engineers. I've seen this vary across programs and managers, and can't say I know all the answers, but I do know I much prefer the role of the IC....

How have you found success balancing these things? It’s been my experience that managers of the first group eventually become unintentional members of the second group, even despite their best efforts to maintain productivity of their subordinates with intentional prioritization and grooming exercises because the business wants that new feature yesterday, and not getting it means lost revenue, angry customers and negative performance reviews.

What happens though when the business puts these types of middle managers in the impossible position of not being able to say “no, this isn’t a priority right now” but still expected to maintain the same amounts of engineering productivity and feature throughput?

I didn’t write this article, but it sums up my headspace, currently: https://www.linkedin.com/pulse/stop-doing-more-less-2019-mat...

> not getting it means lost revenue, angry customers and negative performance reviews

Staying in exactly the same place won’t affect revenue, customers or performance reviews at all. It’s when people work under the mistaken assumption that they have to increase at all costs that you have a problem.

> business wants that new feature yesterday, and not getting it means lost revenue

That's just plain bad planning on a business side of the company. They should either fix that, or face gradual departure of their workforce, from best to mediocre.

Organizations should strive to:

- reduce Peter Principle and pyramid org-chart building

- retain, train, and invest in good managers as a profession, not a will to power

- hire more administrative and secretarial people to navigate the minutia to unblock highly-paid employees from finding answers in the bureaucracy and doing unnecessarily-dumb paperwork

I don't agree with this. I enjoy management and coding. However, when I'm in a manager role, I consider contributing with coding to be an essential part of the job, to maintain my ability to lead the team with credibility, truly understand what their job is like, and differentiate myself relative to other managers, who by and large have bought into the narrative they can't and shouldn't try to code.

This cuts directly against the narrative by the article, and the narrative of the article is the common one. The argument seems to be "you just don't have enough time to do both well!" but in general, there's no free lunch here, you are choosing between different trade-offs. Management is hard no matter what, but if you already have the skill to contribute to a team's efforts, you're not just leaving money on the table you're lighting it on fire by abandoning it by letting yourself atrophy into becoming a manager who's skill stack is shallowly scoped to people management and leadership skills. Whenever you see a commonly held narrative like this that has clear negative consequences to those acting on it, all other things being equal it pays to be contrarian as long as you don't fall into the obvious traps, since you're going to differentiate yourself.

I'm surely not the best manager and I'm sure I suck at a lot of it, but everyone does somehow. I'll go head to head anytime with an engineering manager who doesn't ship anything anymore any day of the week in terms of who engineers would rather have as their leader when building something difficult.

I would like to add my perspective as an IC who is reporting to a technically-focused manager. I feel frustrated that my manager does not spend even 10% of the time they spend coding on coaching/guiding/giving feedback to me. I feel that part is more important aspect of being a manager compared to churning out code. I understand the need to keep on top of the codebase, especially when coding is something you really like. But if you don't spend enough time on the growth of your reports (amongst other responsibilities of a manager), why bother becoming a manager?

Edit: Just to clarify, the question in my post is kind of directed to my manager and not to parent commenter :)

Yeah I think this just shows the trade-offs. The path forward for your manager here is to grok they need to turn the dial, at least in their relationship with you. What I reject is the idea that the dial needs to be dialed all the way away from coding, especially permanently, or that doing so is not without immense costs.

It certainly makes the job of a manager harder when you are forced to reckon with the fact that you can't just throw out coding without it undermining your ability to be a good manager. In practice, I would try to ebb-and-flow with the teams' needs - it's a dynamic, challenging process.

Also, there's a tricky issue of, as a report, being able to identify what is intentional vs unintentional. Your manager is probably failing you, but there's also a chance they are forcing you to grow by disengaging a bit and letting you fall into a few ditches. Sometimes a good coach will just shut up and let you make mistakes. Until you see the net effect of their behavior on you over an extended period, you can't know if you have a good coach who is pushing you in a way that you can't see, or a bad coach who is just failing you. A lot of people with good coaches resent them in the early days for being too hard, too disengaged, or other things, which forces them to push themselves harder.

I agree with you that I don't want my manager to completely stop coding (especially if it is something they like a lot). I just want them to realize that there are higher priority items on their list of things to-do. And spend at least some amount of time figuring out how to help their reports grow.

Also, this depends on the experience level of a manager's reports as well. If all of them are quite experienced and have clear goals regarding their career, the manager does not have to spend much time on career coaching. They can focus most of their time on coding. But if that is not the case, then they'll have to balance their time accordingly.

That's a good point you make regarding intentional vs unintentional. This point had not occurred to me earlier. After thinking about it though, I am confident that its not applicable for my scenario :0. I will have this in mind for future situations so that I don't come to wrong conclusions.

> And spend at least some amount of time figuring out how to help their reports grow.

I hear this an awful lot, but either as a manager or IC, I have no idea what it means.

From my perspective, if you leave me alone to do my thing and don’t interrupt me with random shit all the time, I’ll grow naturally. But the manager doesn’t have to be involved in this beyond shielding me from the bullshit, so I guess people are talking about something different.

>From my perspective, if you leave me alone to do my thing and don’t interrupt me with random shit all the time, I’ll grow naturally. But the manager doesn’t have to be involved in this beyond shielding me from the bullshit, so I guess people are talking about something different.

That's what _you_ want, but it's not what everyone wants. Some people want or need much more active participation in their growth, and it's a manager's job to find what's right for each person. A common failing new managers make (and one I made as well) was assuming everyone wants to be managed like I want to be managed. I was very much in that "leave me alone and let me do my thing" mindset, and that caused a lot of problems much later in life.

Technical leads should be helping ICs. It doesn't always have to be the manager in particular.

I think it depends on how each org or company defines its team structure and the responsibilities of the different roles. We don't have a separate tech lead role in our team.

Even so, wouldn't a tech lead be focused only on technical aspects. Say if I want feedback on some customer interaction I had or maybe regarding a meeting I ran, it is not the role of the tech lead to do so I think.

Many companies want to save a buck and figure their best talent can become good-enough managers and still be that technical lead. It rarely works out.

A lot of technical leads who become managers assume they're doing a good enough job on the management side and that they have to master every technical detail, when the truth is they're only convincing themselves that their split allegiances, attention, and priorities aren't a problem of trying to work two jobs.

An engineering manager who was technical, listens to their staff, and delegates can still be respectable and has the time and focus to help the team in a greater capacity with non-technical things proactively rather than reactively.

An engineering manager who can setup an HA database is as useful as a fireman who can play chess. It's all well-and-good, but it doesn't add value to the management of the team if someone else has that duty. Technical leads yes, but not managers.

You've clearly stated an opinion, but not an argument. You've also smuggled in the claim that an engineering manager who ships stuff is performing two jobs. I argue that engineering managers who cannot ship stuff are performing half a job. (I don't really, but you can see why this is a fallacy in both directions: it's an argument around definitions.)

Your opinion is the same on made in the article and is the consensus view. To me, the consensus view is there for a lot of reasons, one of which is that it's a common anti-pattern for formerly technical engineers to become managers and let themselves get drawn into the code at the cost of management. In all things, balance. The other, more general anti-pattern is to see a failure mode and then presume the diametrically opposed opposite is the global optimum. If engineers are prone to be bad at management because they get sucked into building stuff, then whatever benefits may come from that should to be ignored: they should abandon it altogether. (This is a common error in other domains, like the canards "ideas are nothing execution is everything", "you should never pick stocks, and only invest in index funds", etc.)

It also turns out it's much easier to believe that engineering managers who ship code are worse managers, because it means that you can feel good about deciding you're going to stop coding: you're doing it to do your job better. You already have so little time anyway. But what if it turns out being able to ship stuff actually helps you in being a manager? Now it's harder: you have to decide where to draw the line. And so, it's a much more difficult thing to come to terms with since it means there are no easy choices and you actually have to live with the fact you are always going to suck at this in one way or another.

I argue that, all other things being equal, having the ability to ship with the team makes you a better manager. The question is if that is true or not, and if so, at what point does the trade-off stop making sense to maintain that ability. Creating false hypothetical situations like "setting up an arbitrary HA database" doesn't prove much of anything about the actual, local, domain knowledge I'm referring to that you get by continuing to perform IC-like work alongside the team you manage.

Sandbagging. Also an opinion. You're being inconsistent and defending your ego rather than being open to the bigger picture.

Then you're a technical lead and a technical manager; don't conflate the two as the only possible configuration.

I replied elsewhere a longer form argument, in the form of concrete examples, why I feel being able to ship code confers benefits to engineering managers. I'm not going to argue about titles. Titles are useful for internal political signalling and are basically minimally-transferable cultural norms, but less useful for determining how to best take care of your responsibilities. For the purposes of this discussion I consider an engineering manager's responsibilities will be to maintain the velocity, mental health, and general happiness of their reports. People who argue about the role a person has and what they ought to focus on based upon their designated title, or in this case derive it in the opposite direction, to me, are mistaking the map for the territory.

Also, if you think I'm writing this to defend my ego, you ought to become a psychologist since you are able to read minds over the internet.

Then why are you writing? Why are you unable to interact without respect and curiosity but with adversarial hostility? Are you going to escalate to name-calling since you don't have an argument, only rationalizations to reinforce your worldview or the inability to consider approaches outside of your own? Maybe curiosity and self-reflection would help improve the quality of your conversations rather than promoting a religious doctrine through snide defensiveness.

Interesting that you’ve now accused me of arguing to protect my ego and being snide in the same breath as saying I’m the one being hostile. All I said is that you expressed an opinion, not an argument, which is explicitly true based on your first reply, and explained why if your argument was going to be about why actually there is no trade off why I disagree with it - based on your further responses it feels like you may have taken that personally. It wasn’t personal.

If you’re going to accuse me of a lack of curiosity then you need to explain why anything you have written actually does more than repeats the claims in the article I was explicitly rejecting, or why my claim that you leaning on titles to form your argument is just debating over definitions is false.

I was pushed into it because they needed a supervisor in that position. I might be a decent leader from a technical standpoint, but not a good manager after a year into it.

Yep. It doesn't scale well. Technical lead != technical manager. It's also myopic because it's two jobs and two completely different professions.

What is a technical manager?

Manager of technical people.

I guess we could recast the term "technical manager" as "one who attempts to both do and manage."

Guess it all boils down to management vs leadership. I just wish we could go back to not calling every second employee a manager of something.

„manager of technical people“ is great example. You would expect a technical person who the team respects with equally great management skills, farsight and vision.

Ugh and it's not usually their fault. Too many orgs are promoting this by making manager pay higher. In a sense higher pay is the career goal. Why stay in coding when you can get a 30k bump for coding plus whipping people?

I don't get it, doesn't everyone dislike/struggle with these things? Who likes context switching, office politics, sitting in meetings and having difficult conversations

"There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy."

The truth is that if you’re a manager who has no other marketable skills, you can only hate pointless meetings so much since without them you’d probably be putting your resume in down at the local Starbucks. Clear an engineer’s calendar and you probably make a more productive engineer, clear a manager’s calendar and regardless of the consequences to everyone else one thing is sure: that person’s job function is no longer obvious.

If you’re in sanitation, you have a more nuanced relationship with trash than those who aren’t, even though everyone dislikes trash.

Good managers should abhor pointless meetings as much as anyone else - their task is to make useful meetings. Anything else is just a waste of time and wasting everyone’s time is not exactly the hallmark of a good manager. Now, there’s people that hate all meetings and regard them all as a waste of time and if you’re one of those, you’ll never acquire the skill to actually make meetings useful - this is a skill which needs training like any other skill does.

If you work in an organization where such meetings are the norm, please share what led to such a magical place. I've heard Amazon is such a place but I'm very skeptical. My general presumption based upon years in the industry is that by far the majority of scheduled, large block meetings are not worth the opportunity cost of having them. Effective meetings don't come from an individual transforming normally ineffective ones into effective ones by some form of wizardry over everyone else in the room, they come from a culture where everyone makes them effective together through shared values. In a large enough organization, this seems basically intractable to maintain. IMO the only way to win is to not play and move most meetings to short, unscheduled ones with timeboxes in conjunction with asynchronous communication tools.

> My general presumption based upon years in the industry is that by far the majority of scheduled, large block meetings are not worth the opportunity cost of having them.

I entirely agree with you here - I disagree with the notion that "managers" (should) like those meetings any more than other folks. Most large block meetings are ineffective, the more effective ones have a strict agenda and someone moderating them with that agenda in mind. They can be useful for announcements or large-scale alignment, but most of them should be struck from the calendar with no replacement - and good managers recognize this and strive to do so.

> Effective meetings don't come from an individual transforming normally ineffective ones into effective ones by some form of wizardry over everyone else in the room, they come from a culture where everyone makes them effective together through shared values.

The person leading a meeting can make a substantial impact - being prepared, making an agenda and a plan, setting a clear goal for the meeting, deliberately limiting the number of people attending, requiring others to come prepared and enforcing that (possible adjourning the meeting if it turns out to be ineffective), time boxing. There's no magic place where all meetings are effective or feel effective for everyone, but there are places that try to improve and there are techniques that make improvement possible.

Point taken - I think to drill into my point more is that very few meetings are objectively "pointless" - and managers are much more likely to see a meeting as having "value" than the engineers, in part because of the effect I mention where their jobs are defined by meetings, not in spite of meetings. (Sometimes this is not the case, eg a manager may see the latent value of literally just having two people in the same room together and talk to one another who would otherwise not, for political purposes, that the engineers cannot understand.)

To cut it in the other direction, your average testing engineer will have a much harder time agreeing with the idea that most of your test suite is useless and should be thrown out, even if it is useless, because to do so would be to admit that their entire job is less credible as a concept if it is true.

I disagree that a managers job is (or should be) defined by "meetings". A mangers job is to facilitate certain aspects of shared work, for example alignment on goals, ensuring availability of resources (financial, time, expertise, ...), recognizing and possibly removing obstacles. Meetings are one tool that can be put to use, but they are not an intrinsic goal. The same holds true for a good QA engineer - their goal is not writing a test suite. The same should hold true for a programmer - the code is not the goal. Removal of useless code is a good thing. However, there are people that fail in all of these professions - I've seen enough coders that write complex code for the love of complex code, DevOps folks self-managing kubernetes where a simple virtual machine would have been sufficient and managers hiring people just to increase the headcount of their department and increase their perceived standing.

I don't think implying that QA engineers being biased in favor of having unnecessary automated tests is the same thing as saying that QA engineers have a goal of writing tests. It's just the nature of the beast. My point is jobs inherently favor artifacts or actions which (perhaps ceremoniously) justify their existence, and often resist attempts to remove such things since they've integrated those things as core to their job function (even if their motives and goals are in fact not to create those artifacts.)

I do, for one, and I truly love my middle management job. It is really compatible with my brand of insanity!

I really honestly dont mind context switching all that much. It makes me less productive or course, but it does not make me angry or annoyed.

There are plenty of meetings I honestly dont mind at all. Some I do mind, but it is more about how those meetings are moderated then hating on meetings in general.

I really don't get it either because I hate all of those things, but that probably is why you and I don't want to be managers.

No. Some people like relationship building and diplomacy. Building the business. Having meetings fleshing out direction and staffing needs. And many others will put up with it for the increase in compensation and tell themselves it's not that bad.

> Some are pushed into management because they’re the most competent IC on the team.

So Plato's Republic describes how this comes about since ancient times, I wrote something a bit more detailed[1] about it.

But here's the TL;DR - the punishment is that he who refuses to rule is liable to be ruled by one who is worse than himself. And the fear of this, induces the good to take office, not because they would, but because they cannot help ... because they are not able to commit the task of ruling to any one who is better than themselves, or indeed as good.

Some are pulled into management because of the existing mastery and a looming management vacuum.

This isn't something new in tech - it has always been that competent people leave their mastery work to do management (rather politics of ensuring funding), because they see no other choice.

Until I found a manager who was better than I was (and once I understood how they did it and what they did all day), I did think in very similar lines, a little bit aided by the "I'm a smart guy" ego clouding my judgement.

[1] - http://notmysock.org/blog/philosophy/leading-up?h=1

This is definitely true for me. I cannot imagine wanting to inflict some of the managers I’ve had on the members of my team. Better me than the chance of someone worse (and I’m pretty bad, I just judge the chance of someone worse taking it up if I stop to be higher).

Do you have recommendations for how to go about 6?

I've been moving into a more manager-like role and your list makes me a bit worried, though I was already considering this to be somewhat temporary. So far it's been a valuable experience though (harder than I thought).

About 2 - I actually really enjoy relationship building. However, if you have issues like nepotism or problems around equity in the organization, I think it can be really hard to have to work with people who make decisions that you find distasteful. That's the main thing that makes me miss the solitude of coding.

Yep.

One of the biggest hurdles is most people don't want to be responsible for thinking for themselves, their judgment, and their decisions.

And then poo-pooing things outside of their current role that they either don't understand or don't appreciate.

In large orgs, I think one day a month staff should have to intern in a random department to appreciate what others have to go through to build morale and empathy.

A good leader is a humble, messianic therapist, salesperson, and accountant.

2b) Start coding again because your superiors promote you to management but treat you like you’re still an IC and ask why you haven’t contributed any points to the latest sprint while actively shutting you out of the kinds of discussions and decisions an EM would be making in most other orgs—-while somehow simultaneously asking you to also be the bearer of frequently changing and poorly communicated business priorities for your subordinates

Yes it’s happened to me, yes I’m a bit bitter about it, yes I’m looking for a new job because of it

I keep seeing this IC term here but never saw it before, is that “Independent Consultant”?

Individual Contributor

It means "individual contributor" , and implies you don't have any reports. As opposed to "tech lead" or "player-coach" (currently in vogue) which implies you are supposed to be effective as a technical contribute but also have a formal manager relationship with at least one person. Let a lone a classic manager who doesn't do much or any direct contribution technically.

There is some confounding in this thread of manager-of-people roles and manager-of-things roles, which also causes confusion.

less seriously: indentured chattel, information curdler, integration cobbler, indigent craftsperson, imaginative collaborator, introverted creative, incredulous cynic, inventive clerk.

Haha the cherry on top if so: were you paid the same?

I sardonically feel like you already know the answer to this ;)

(but yes)

Heh, I also fell into this trap once. (I no longer work there.)

Just as much coding work as before, plus becoming the interface between the developers and the actual management, with no pay raise of course. Not able to change anything, but regularly reminded that I am responsible for the results.

What was your solution? Just get a new job? I find myself in this situation now..

Can we start a support group?

I’ll bring snacks

Are you interested in being an engineering manager? If so send me an email we're hiring

I always feel bad when I see someone who was pulled to the management track early in their career. They often never acquired the technical skills or even knowledge of the technical skills of their more senior engineering counterparts.

It really does a disservice to pull someone into management 3-5 years into their career. People will often take the role as it looks like a promotion, but ultimately it's a lateral move with slightly better pay in most environments.

Though I thoroughly enjoyed reading this dark path, in reality the bar is set so high in top companies that an engineering manager is usually an architect/senior engineer/and a people manager.

So most don't make it, and those who do have a tremendous career that's fulfilling and financially rewarding.

This is a great observation. At Amazon it's quite possible to become an L5 manager after being an SDE II for a while, but most of the people who do find it very challenging. They don't have the organizational clout to get things done because nobody respects a manager at that level and because more senior technical folks will steamroll over your technical opinion. To be a successful EM there you pretty much have to have made it to SDE III before switching over.

In the other universe:

1. Do not become an engineering manager.

2. If pushed (e.g. by not getting raises), move on.

> move on.

move on to where? managers get paid more than IC on average everywhere.

Sure, if you are staff level stellar IC you might get paid on par with management but most ppl aren't.

Don't sell yourself out for money unless you need to. Figure out the amount of money you would like to make then if your at not getting paid that at CurrentCo go find a darling SV company, unicorn, or a FAANG+Microsoft and switch to an IC role at one of those companies and get paid better.

Going into management for money is a terrible reason to become a manager...

Unless of course your goal is executive management... but that's very different from engineering management.

I agree, and I think you should only go into management if you like managing. You can be a good IC and a good leader and a good manager, but more than likely you will be better at one or two out of those three.

You're sort of arguing though that, if you don't want to go into management, you should become an extraordinary IC (or just accept you'll get paid less money).

But that's true almost everywhere unless you become a consultant/freelancer (but then you are now running a business and have to find customers)

Sure. Absolutely nothing specific to tech. In fact, many big tech companies have a much better IC career ladder, mostly but not entirely for engineers/devs, than non-tech companies do. Sales is the main exception I can think of.

My intuition for this is leverage. As a people manager, the team's output is your output. When you manage a large team, small changes in IC output can quickly exceed 1 FTE. These multiplicative productivity improvements are why Managers get paid more.

There's tons of ink spilled on the idea of the 10x engineer. Let's assume that exists. Even if an extraordinary single person can deliver 10x output (call that 10FTE), a good manager can deliver a similar productivity boost by merely 2x'ing the output of a 10-person team of average ICs (10FTE output -> 20FTE output for a delta of 10FTE, same as hiring a 10x engineer, which is hard to do.)

If you have a 10 person team of 10x engineers, a good manager can deliver that 10FTE bump by increasing team performance by just 0.1x (10x 10FTE/person = 100FTE -> 10 x 11FTE/person = 110FTE team output, for a 10FTE boost). THAT is why good managers are worth paying.

"Leaders aren't born, they're made" [1]

[1] https://coachingforleaders.com/

That's exactly why I was adamant (on condition of taking my current manager role) that I was always going to be coding. But I agree with most of these steps and when I was solely an engineer, I resented managers in 4 - 7. It was my goal to never be like that.

Don't think people are born with leadership trait. Its the experience that one goes through in work and life and along with the thinking that goes with it that makes a leader.

If people are born as leaders, how come world history is full of bad kings/emperors?

Yeah I should have wrote “born or developed sufficient leadership skills in step 3 to offset your skill atrophy” but it would be confusing to edit now

Interstingly I found a similar career path in many scientists. Some of them are getting completely out of touch (you never see them in a lab, they don't learn new techniques, they rigidly defend things they learned before but that is obsolete) and just presenting their students/postdocs works and editing papers.

Too pessimistic. Many ways of having a successful and happy live. You can teach, mentor or become an advisor. You can also start your own company. Or you can find something entirely different in a different industry. Going up career wise isn't the goal you should pursuit

I hope your realise that the days of being a white, middle aged programmer are coming to a close. If anything, get some management/leadership skills under your belt if you get the chance.

I've managed several teams at this point (maybe poorly?) and have been hearing this warning for at least the last decade from the other managers who can no longer ship software because they bought into the idea that being able to do so meant they were choosing to be worse managers and therefore harm their team. (I don't know what being white has to do with it.) I'm pretty sure the tendency to instill this kind of fear in others often comes from the need to rationalize the choice such people made to leave behind their hard-earned ability to build and ship software. Since if it wasn't the case the people like me would eventually come to realize their profound error, now ruined by their mistake to prepare for their eventual undoing (due to age? AI?), it would mean that they gave up something that presumably made them happy, that they can't get back easily. I was told this will happen to me when I got married, bought a house, or had a family. Those events did not have the effect, so I presume when people told me this it just meant they had those changes in their lives force them to decide their coding days were behind them.

For the most part these people are now never going to be ICs again and must find a path that lets them hop from one VP of Eng job to another. It's a lucrative gig but feels a bit like a house of cards ready to crumble at any time, at least that's how it would feel to me if it was my only forward-looking career path. When belts tighten they're the first to go.

I’m dealing with this right now with my manager and it’s infuriating.

What does PHB stand for?

https://en.wikipedia.org/wiki/Pointy-haired_Boss

I seriously question #4. While the popular tools and languages and techniques churn, there are no fundamental revelations in software development that cannot be understood at a higher level by somebody who stopped programming in the 70s. If anything, not being obsessed with the churn helps these managers step back and ask fundamental questions that are often ignored by magpie developers.

It is very possible to keep up do date on all the new tech coming out at a surface level, ie enough to manage engineers and ask questions, without spending the time to deep dive into the nuts and bolts of each new tech.

For 3, you can keep yourself informed without coding on the job. Continuous education is a common part of many professional careers. Just code a personal project every couple of years and read the tech news and you’ll be fine.

Not to mention just sitting in on code reviews and listening to the developers will help keep you continuously educated. Take notes and read up on any debates that come up that confuse you.

No, I'm not talking about those kinds of skills per se. ("Fundamental revelations.") I'm talking about:

- Grokking what actually sucks about the tools, languages, frameworks, etc in use. And grokking what complaints of suckiness are shallow or misplaced. The former is an opportunity to deliver empathy for the team's suffering and propose good solutions, the latter is an opportunity to remind engineers (esp junior ones) not to be overly-cynical or see problems where they don't truly exist.

- Ability to participate as a true peer in technical discussions, which deepens the bond you have with your team. If you are able to contribute one or two concrete, correct, and actionable ideas that unblock developers or the project's construction every quarter, it pays dividends imo in counteracting dynamics where you are considered an "other" in certain contexts given your position. I'm not talking about things like "maybe you should write some tests" but "maybe you should ditch that testing framework because the problem you are hitting is a non-issue if you just write a special harness yourself. You can start from mine." It's no silver bullet, but it helps. If you literally save a week's worth of effort for a team member by cleverly reframing the work they are doing to a better MVP they can handle (via your domain knowledge and intuition about implementation difficulty) they will be unlikely to care if you accidentally forgot to send them a birthday email. If you don't do that regularly, and basically are a full people manager, the missing birthday email could be a big problem.

- If you aren't in the trenches at all, lots of problems will crop up over time that are insidiously hard to see once you've exited having the domain knowledge. For example, you won't be able to assess talent well enough to flag bullshitters who manage to sneak past your team's interviews. (Given you are the manager, you probably tilt more towards having the people skills needed to detect bullshitters which your team lacks, but without domain knowledge, neither you nor your team may have the total sum of skills needed to detect them.) Or, when giving overview discussions of how the software systems work to other managers, your team members might have to start biting their tongues when you're explaining things in a way that is objectively incorrect but coherent in your (now shallow) mental models. Having to regularly hear your manager saying something that is totally wrong is demoralizing, because it means you either have to "educate" your manager, which is awkward, or you have to effectively endorse what they are saying by staying silent.

All of these come from a loss of literacy in the local domain of the work your team is doing, not in general principles. These are totally different forms of literacy, and the latter one is dynamic and requires effort to maintain (and losing it comes opportunity cost.)

Edit: Also, people saying sitting in code reviews is good enough are fooling themselves imo - to believe that you also generally need to believe that you can become a good programmer on a project by just doing code reviews enough and then instantly be able to execute as a top-tier team member. This is objectively false. So the question is what margin is needed between "code review level literacy" and "building literacy" to get the benefits I mention. I'd argue it's a pretty big margin.

Trust. What you're really talking about is trust.

If you're not coding 100% of the time on important value add tasks, you're not ever going to be as technical or as current on the details as your team. As a manager being the technical lead IS NOT YOUR JOB. You have people for that. Empower them, listen to them, arbitrate between them, enable them to get their job done.

It is not your job to decide what technology is best, your team is the one with that know how and will offer you choices and tradeoffs; if you need to decide you'll need to trust their information to choose the best set of tradeoffs for the business strategey. Trust them to give you the right data. Nurture the team so they don't lie to you; if they're lying to you, there are much bigger problems to solve than the technical details.

I completely agree with you. How do you prevent this happening? I've relocated from a team where I used to be a software engineer on the team (and therefore had a peer-level understanding of the systems) to one in a different company where I'm starting from day 1 as a manager. How do you maintain/build that localized domain knowledge? It doesn't feel like it's solvable by doing a week of coding now and again.

Reply on news.ycombinator.com