11 ms·
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
by gfodor 6y ago
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
- ta988 6y agoInterstingly 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.
- dhanna 6y agoI’m dealing with this right now with my manager and it’s infuriating.
- halfmatthalfcat 6y agoThat'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.
- Koshkin 6y agoIn the other universe: 1. Do not become an engineering manager. 2. If pushed (e.g. by not getting raises), move on.
- dominotw 6y ago> 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.
- meddlepal 6y agoDon'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.
- rhombocombus 6y agoI 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.
- ghaff 6y agoYou'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).
- codegeek 6y agoBut that's true almost everywhere unless you become a consultant/freelancer (but then you are now running a business and have to find customers)
- ghaff 6y agoSure. 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.
- lumost 6y agoI 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.
- PragmaticPulp 6y ago> 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.
- gfodor 6y agoI 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.
- fatnoah 6y ago>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.
- bg117 6y agoDon'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?
- gfodor 6y agoYeah 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
- nomy99 6y agoThough 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.
- revel 6y agoThis 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.
- yaml-ops-guy 6y ago2b) 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
- acconrad 6y agoAre you interested in being an engineering manager? If so send me an email we're hiring
- camjohnson26 6y agoI keep seeing this IC term here but never saw it before, is that “Independent Consultant”?
- webloem 6y agoIndividual Contributor
- deleted 6y ago[deleted]
- ska 6y agoIt 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.
- shoo 6y agoless seriously: indentured chattel, information curdler, integration cobbler, indigent craftsperson, imaginative collaborator, introverted creative, incredulous cynic, inventive clerk.
- blacktriangle 6y agoI 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.
- camjohnson26 6y agoFor 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.
- blacktriangle 6y agoNot 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.
- gfodor 6y agoNo, 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.
- Osiris 6y agoWhat does PHB stand for?
- ht_th 6y agohttps://en.wikipedia.org/wiki/Pointy-haired_Boss https://en.wikipedia.org/wiki/Pointy-haired_Boss
- secondcoming 6y agoI 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.
- gfodor 6y agoI'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.
- durzagott 6y ago"Leaders aren't born, they're made" [1] [1] https://coachingforleaders.com/ https://coachingforleaders.com/
- holoduke 6y agoToo 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