Live data from Hacker News

From engineer to manager: what I love, what I hate

thoughtspile.github.io

151–160 of 208 posts

Re: From engineer to manager: what I love, what I hate

#151
> First, you can easily take on a team with a wildly different focus — mobile developers, infrastructure, ML engineers. You'd need some time to get up to speed on the big-picture technical struggles of your new team, but most companies would take this shot. If you don't want to be an EM any more, you're well-positioned to move to a project or product management role.

Have to comment that this is just completely wrong and we need to stop telling ourselves this. I’ve experienced a lot of pain with EMs who have no idea what is really going on in a codebase because they have little domain expertise, no idea what tradeoffs are made by developers, and, crucially, do not ever punch the keys and commit anything. Why? Because frankly, they already have the job.

If you don’t ever interface with the codebase and don’t really understand what it does, but you still feel so inclined to steer the ship, you’re a product manager, not an EM. Possibly worse because there is more credence given to you? This is most likely advice for someone who just wants to issue vague edicts to a team that frankly does not need them.

Re: From engineer to manager: what I love, what I hate

#152

> Suffering from front-end fatigue? Can't keep up with the newest shiniest frameworks and tools? Management's got you covered! The "hot new" agile / kanban / scrum methodologies are 20–30 years old. The basic meeting types (demos, dailies, 1-on-1s) have been developing for centuries. > Frankly, after 4–5 years of working in a particular tech area, you can solve the vast majority of practical problems well enough. If…

Also, ReactJS is 11 years old and going strong. Not exactly the "new JS framework every 2 weeks" world I keep hearing about.

Re: From engineer to manager: what I love, what I hate

#153

Earlier quoted context omitted.

> The fact that you have to stack rank and pick an under-performer every half is just broken. I've sworn to myself, that the moment that this idiotic idea get introduced in the "performance management" process at the place I work, will be the day that I'll start to send out resumes. Even if it were handled lottery style ("the short straw") I would not cut slack to either manager or company for such an indignity.

IME in ~20 years I’ve never been on a team where there wasn’t someone underperforming (I acknowledge sometimes it was me!). So while I agree it’s stupid to force a curve, it also doesn’t seem realistic when every manager claims their entire team is great.

Your personal experience notwithstanding, I don't think that it can be generalized that there is always an under-performer on every team.

If I may offer my anecdata, I've seen several teams that could be characterized by stability and depth of expertise in their respective areas. You could say they always performed on a very high level, but never over-perform, because the high level is what is expected. Stack ranking those teams equates to killing them.

I also agree that a scenario where all individuals over-perform all the time is also rather unrealistic. But individual evaluation of performance is not stack ranking.

Re: From engineer to manager: what I love, what I hate

#154

Earlier quoted context omitted.

> The ladder isn’t really taller. In my company, I think it's roughly 2-3% at L7 or more. It takes really special skills to reach that level, not just years of experience. I don't know how it compares to EM though, but it's a tall ladder! > those of us happy to go back to IC roles have no trouble finding work My concern as an IC is ageism. I wish that I can say that when I'm 50+. I feel EMs are a little more immune t…

I think digging into the roots of SWE's not being respected is worth discussing. Are doctors, lawyers, or surgeons viewed the same way? I don't know those industries well enough to say. Some domains of software are very, very deep and require many years of study and practice. It feels like the root of SWEs not being fully respected simply comes back to the fact that they aren't considered as part of the org as much a…

When I see a doctor, I kinda want them to be in their 30s/40s. If they're in their 60s it's been a long time since they've been to med school and while they have continuing-education requirements things do change

Re: From engineer to manager: what I love, what I hate

#155
post #81
post #68

Earlier quoted context omitted.

> Finally, getting to L7 EM is maybe 30% in your control and 70% circumstances, but that ratio is IMO inverted for ICs. That sounds like a positive. As an EM, there's a good chance you'll be promoted to L7 via pure luck - with no abnormal amounts of effort, and with no outstanding talent for management. It sucks if you're in the minority which "deserves" the promo (is super hard working and talented), but for everyon…

That's... not actually how that 30/70 statement is meant to be read. Imagine as a simplified analogy, applying to get into Harvard. Imagine Harvard has 1000 spots to fill, and that there are 10,000 applicants with roughly equivalent credentials (because they all have: near perfect test scores, high GPAs, strong extracurriculars, etc.). In that environment, one might conclude that, for people who successfully get into…

When an external hire happens, they don't truly know what they'll be like unless they've already worked with them, so they could actually be of a lower quality who lucked into it

Re: From engineer to manager: what I love, what I hate

#156
post #130

Earlier quoted context omitted.

Are there any books etc that you could recommend on Linux internals. I am mostly write c# code, and I didn't do computer science, I mostly self taught. I recently set myself the task of learning some c as I was finding that I was hitting a brick wall when it came to trying to learn more lower level concepts. I want to work my way through computer systems a programmers perspective : https://www.amazon.co.uk/Computer-S…

If you're the kind of guy who likes to work through one 1000+ page behemoth at a time, I can recommend The Linux Programming Interface specifically. As a nice secondary bonus, the code examples are all in good old fashioned C, so you can compile and run them to test things out as you please. :)

Seconded and the book is https://man7.org/tlpi/. One can even reads parts of it digging deep into the area one is trying to understand better.

Re: From engineer to manager: what I love, what I hate

#157

> So, if you're tired of keeping up with the latest hot thing in tech, a management role can provide a well-deserved relief. Do keep an eye on what's happening on the tech side of things, but there's no urgency, and no need to get real deep. This is such a poor advice. In any company that has a dozens customers, your team is likely to face technical problems. When your team faces a problem and you are unable to solve…

> When your team faces a problem and you are unable to solve it, your team will notice that and they will stop looking up to you. In fact, any engineer who solves the problem will be the hero everyone admires.

This is quite revealing. Being a hero, or being looked up to, might be some people's goals. But definitely not everyone's.

Re: From engineer to manager: what I love, what I hate

#158
post #31

Earlier quoted context omitted.

There are many different ways to grow beyond staff engineer: - Become an expert in something hard. Fix bugs nobody else can. This requires sticking around for longer than most people, maybe 10 years or more. - Have impact across the industry. Maintain a kernel subsystem, run a C++ subcommittee, etc. - Be a TL for multiple teams, because you have experience and a plan the other TLs can get behind. - Wear multiple hats…

Most of your points are requirements for staff not “beyond staff”

I don’t think so - I’ve been in promotion committees to L7 and I feel fairly confident those are examples of L7 impact. Not by themselves sufficient maybe, but they’re the kind of stuff L7 SWEs do with their time.

I suppose I have heard that the L6 bar has lowered somewhat from ~2015, mostly in response to people complaining about being stuck at L5. But I wouldn’t have any first hand experience with that, other than my own promotions, which surprised me every time. So maybe the bar has been lowered.

Re: From engineer to manager: what I love, what I hate

#159

Earlier quoted context omitted.

Senior engineer is fairly low. At some point you may get tired of stagnating salary and being told what to do all the time. They are higher technical positions that have no or very little management responsibilities (up to senior principal engineer, architect, etc). It depends also on the company and how much they value you. Best I have seen is engineer with PhD and decades of experience be the research/architecture…

Agreed. It's nice to be "Senior engineer" when you are 28. Not when you are 38 and being lorded over and over-ridden by "Staff Engineers" with half your experience.

Not everybody wants to get promoted to their level of incompetence. Some of us want to stay at a level that we are good at, and not endlessly climb a ladder.

Re: From engineer to manager: what I love, what I hate

#160

Earlier quoted context omitted.

Well, it's well known that to become a team lead you must eat the previous team lead) To be fair, some managers over-optimize to protect against people undermining them, not sharing knowledge and responsibility and even actively removing top performers with leadership ambitions

Something I’ve noticed in the company I work for is that team leads which still write code is that they will take for themselves the high visibility projects.

Or worse, only do shiny and "fun" things that customers don't care about while ignoring all sorts of practical bugs/issues.
Post reply on HN