This actually sounds like a meaningful change, unlike proposals from the peanut gallery "to fire the CEO for layoffs," instead demand more output from those you keep in exchange for a job.
That is interesting. I've been working in the field professionally for 22+ years and I've never had a manager that had any technical skills. None of them could even begin to do my job.
That must suck (unless you're really senior in which case it's normal). Hilariously enough, I learned so much more from my one non technical manager at FB but having leaders that understand what you do is incredibly helpful.
Pretty much all my Google managers were ex-ICs who would have been fully capable of jumping into the codebase if they had to. Some of them still did, if they could squeeze it in.
Yeah, I've never worked for a FAANG company. I do work for a Fortune 100 company, but it is not a tech company (When I was hired, I was once in a meeting where I heard the founder of the company say that we would never have an IT department because we were not a tech company. We do have an IT department now, but that happened after the founder gave up the reigns.)
Kind of my thoughts as well - it's "cool" there are technical managers out there and engineering managers should be technical "enough" but I'd never expect them to be competent with all the ICs' jobs
Sure, neither do I (now). At that point in my career though, it was incredibly helpful and levelled me up significantly in a relatively short space of time.
But agreed that your manager should set goals rather than plans. Fun fact, at FB at the same time all ICs came up with their own goals rather than these being passed down from management.
> I've been working in the field professionally for 22+ years and I've never had a manager that had any technical skills. None of them could even begin to do my job
Technical skills may or may not be required, but understanding is...
"Each of my managers explained carefully his own theory
of what had gone wrong and all the theories were
different. At last, there breezed into my office the most
senior manager of all, a general manager of our parent
company, Andrew St. Johnston. I was surprised that he
had even heard of me. "You know what went wrong?"
he shouted--he always shouted--
"You let your programmers do things which you yourself do not understand."
I stared in astonishment. He was obviously out
of touch with present day realities. How could one person
ever understand the whole of a modem software product
like the Elliott 503 Mark II software system?
I realized later that he was absolutely right; he had
diagnosed the true cause of the problem and he had
planted the seed of its later solution. "
That is interesting. I've been working in the field professionally 20 years (I'm not including grad school or postdocs) and every manager I've had had technical skills (deep ones) although most of them couldn't have done my job exactly the same way I did. Some would have done it better. Others, worse. Even others- would have cancelled the project, or morphed it into something else entirely.
The managers I enjoyed working for the most came up through the ranks and were better at my job than I was. But that was only maybe 25% of the time in the 20ish years I spent as an IC. The worst for me were the ones with no understanding of how I did what I did.
Wow, in my 15 or so years I've never _not_ had a manager who had engineering chops. Admittedly, I prefer working for smaller companies so this has often been a hands-on CTO, and I was filtering these job opportunities for technical leaders that I respected.
At Netflix I can't think of a single manager at any level managing engineers that didn't start as one, all the way up to the CEO. In some cases they couldn't necessarily do their employee's job, but they at least understand the technical aspects well enough to make useful contributions to technical discussions.
I want my career path as a developer to never be anything but individual contributor. I like teaching newer Devs but I don't want to manage them. Maybe I'm being naive?
>I want my career path as a developer to never be anything but individual contributor. I like teaching newer Devs but I don't want to manage them. Maybe I'm being naive?
You can do this, but you will have to accept the plateau. There's really nowhere to go beyond Staff/L6, unless you're some super genius full of brilliant ideas or luck into being involved in a game changing product launch. Everything beyond that becomes politics.
The same applies to being a manager though. You're not going to get promoted forever in any role, at some point you'll hit a terminal level, whether that's in an IC track or a management track. And it's not a problem as long as you find your work fulfilling.
It depends. If you're able to side-step the middle manager doldrums to Director/VP, and you know how to play the game, the sky's the limit. But IC's are pretty hard capped at L6 short of being involved in the creation of a new business.
Well I guess the difference is that the top of the technical leadership track is ostensibly CTO, which is a “higher” role than you’d typically see on the IC side.
That said I totally agree with you overall and think the argument you are responding to is a little silly. You can have an absolutely fantastic career staying IC forever. The fact that you might cap out at “staff/principal/whatever engineer,” a hugely influential and generally very well paid role, should not be viewed as a downside to that track.
Well, in terms of the org chart, you’ll always be higher at an equivalent point in the management track compared to the IC track (starting from team lead, who will report to the team manager), but that’s not necessarily mean there’s not that as room for growth.
Even the CTO can have incredibly senior engineers reporting to them as a consultant of sorts. Sure, the probability of arriving at that role is low, but then so is the probability of becoming CTO.
I've been working professionally for 22 years and am still an individual contributor. I've refused all attempts to move me into any kind of lead/manager position.
The principal engineer role usually comes with expected impact on a big organization or even the whole company. Having that kind of impact is impossible as an “IC” in the traditional sense. Unless you are in some very cutting edge area, or get very lucky, your principal role will involve a big dose of the same leadership and management tasks that a manager or director would have.
> The principal engineer role usually comes with expected impact on a big organization or even the whole company.
Yes, but you're not managing people. It's a lot of collaboration and leadership, certainly, but not doing any of the HR-adjacent bureaucracy that comes with being management.
So what is your vision of IC "in the traditional sense"?
Most senior engineers at organizations require a significant amount of coordination and people-skills. If you're not managing a team, you're definitely managing the relationship with your manager and coworkers/project teammates.
My vision for a "traditional" IC is someone who sits in front of a computer and writes computer programs. This kind of role ends at senior, or if you are lucky, staff. A principal engineer is much more likely to be in a meeting heavy environment, coordinating with many teams and driving alignment towards some vision. While this is not strictly managerial work, at least to me, it seems to fall much closer to "senior manager" than "software engineer".
Thats totally fine for folks who thrive in this kind of role. However, it does take away the ability to grow your career if you want to keep developing software. So for example, if you program for 20 years, and keep improving during this time, you would expect to be rewarded with some career progression for the progress you've made in years 10 - 20.
But as it stands, these days, if you run into someone who has been programming for 20 years, you can assume their career has mostly stagnated, and might even count them off as a low performer because they failed to grow. So it's almost a self fulfilling prophecy - staying a "true" IC has no growth, and therefore there is an incentive to just sit back and stop growing.
my advice is to keep doors open. You will age and your needs and expectations may change. You can always start a transition to take on more managerial duties while doing individual contribution.
Some people spend their whole careers like this, there is nothing wrong with it. I personally avoided management for years, until I was offered a lead role over a team of roughly 4 people in Feb 2020. I had been working on the product for years and knew all the ins and outs and had a vision for its future. Cue the pandemic and everyone going remote - and the project ballooning to 25 people across three organizations. I absolutely thrived. I realized I’d done everything coding wise that I was really interested in, and that job had grown stale. I have matured, and found I have more social skills than in my 20s and early 30s. I found that not everyone could or would be interested in driving things where they needed to go to successfully ship a product. You may someday surprise yourself at how your interests and capabilities evolve.
I've been in a role like this for many years in a small company. I doubt it would really work in a rigid FAANG environment with formalities like levels and performance reviews and all that - it would get too political and competitive.
Other managers will always try to change your mind on this. When layoffs come around, they usually are more likely to get laid off and their tech skills are now stale and they have to rely on their 'network' to get another management job if they're lucky. Not a position I want to put myself in.
This is a pretty well-defined role in FAANG. Usually the promotion criteria to become more senior as an IC will require demonstrating mentorship.
Separately, there is also the Tech Lead track, where you don’t get reports, but rather final say over an increasingly larger area of influence and drive cross-team/org projects.
Staff Engineer¹ is the path for you my friend. If you don't want to manage people, focus on creating maximum impact on your project.
I think the term IC is a misnomer and is detrimental to our field. Afterall the code you write, the designs you make etc are part of the larger puzzle which completes the project. No work you do is in isolation.
How far along on that career path are you? You may find that teaching newer developers is not all that different from formally managing them.
As for a technical track, read the stories on staffeng.com. And read between the lines when you’re viewing them. There are plenty of folks with technical track titles who spend most of their working hours in meetings of questionable value. And you will definitely find folks with management track titles that spend more time doing hands on work than their peers with technical track titles.
The ugly option you can try is good old-fashioned sandbagging. Knock out every technical assignment in record time, or quality, or whatever seems to be your leads KPI. Then tank any assignment which seems remotely conducive to management. Bonus points for explicitly indicating a desire to move into management. Your own leadership will think you are so miscalibrated as to believe they are doing everyone a favor by keeping you off the management track.
Edit: I realize you did not explicitly ask how to stay off the management track. Consider the last paragraph as just some idle, slightly sociopathic musing.
The vast majority of the managers I've worked with wouldn't be particularly good ICs, not so sure of the wisdom of this move. Maybe it's a way to slow roll a bunch of layoffs.
Harsh, but potentially fair. I think that pre-2016, there was definitely more expectation that managers should be graduates from IC ranks, but that got lost around one of the (many) doublings of headcount FB experienced over the last decade.
It can't be that difficult to contribute to the achievement of absolutely tanking the company's value by investing in a dead-end VR-for-work platform that was always just a distraction to avoid responding in any way to Congress pressing him about election interference.
I absolutely don't know why Facebook balked at making their own phone back in the day. Facebook's entire value prop about 10-15 years ago was the fact that you could find anyone on there who you even remotely knew.
Imagine (10 years ago) being able to use an FB version of Siri/Alexa to "connect me to that girl Megan from my 5th grade classroom". Sure sounds compelling.
Instead FB released a half-assed "dailer app/widget" and forgot about it. Today that window of opportunity closed.
I think Facebook didn’t have the kind of capital to do it at the time they would have needed the captial to make a phone. Keep in mind that the Windows phone was reportedly pretty good but came out in 2010 and it turned out the smart phone space didn’t give out prizes for third place. People always underestimate the cost of developing a smartphone, even when working with modern OEMs, never mind working in the 2008-2010 time frame.
They tried to make their own phone but it just didn't work out. So they ended up releasing something just so they could show something after all that investment. Of course teh company was much smalelr then.
> I absolutely don't know why Facebook balked at making their own phone back in the day.
Because it's really hard to make good hardware cost-effectively. The only companies that have succeeded in the phone market are practiced hardware companies, except for one software company that focused on making a adaptable OS for hardware companies to use.
> I absolutely don't know why Facebook balked at making their own phone back in the day
Microsoft and its phone story is enough to explain why.
Facebook needs a new platform that they control themselves and Phone is D.o.A because they have to compete with other companies (Apple, Google). Nobody wants to have 2 phones and nobody wants yet-another-Android phone "just for Facebook".
> Imagine (10 years ago) being able to use an FB version of Siri/Alexa to "connect me to that girl Megan from my 5th grade classroom". Sure sounds compelling.
I agree that fbs value was/is the social graph. But you’re saying that there was a lack of voice UI? Or lack of a capable mobile experience? I don’t see how any of that could have been more than marginally helpful in reducing the friction of adding a friend on a social network.
No, Facebook tanked their own valuation. They monetized user data without a care for how those users might eventually feel. They became entitled about having that data and the revenue streams attached.
Apple took the opening Facebook left unguarded by realizing people actually do value privacy in their products, and made technical and marketing investments in it.
> Apple took the opening Facebook left unguarded by realizing people actually do value privacy in their products, and made technical and marketing investments in it.
Yeah, and that's why Apple's ad revenue has grown massively since ATT was introduced. Because Apple care about privacy /s.
Depends on the company, of course (and I've no idea how it works at Facebook), but some companies make their EMs out of ICs (much like Pokemon, I assume touching a special rock is required to effect the evolution) and it's somewhat common for EMs to re-IC-ify on their own anyway.
When the EM becomes an IC, how does this help the team grow their own skills and not get distracted by problems the EM should be moving out of their way?
When the EM is an IC, what stops them from either interfering with small stuff (I had an EM -- back then we called them "managers" -- stop us for a week trying to determine whether we should use List or Vector in Scala. Nobody was happy) or taking the big interesting problems for themselves?
Eh, not necessarily demoted; many companies, and I'd assume Facebook, would have IC levels parallel to their EM levels. They might be looking at... sidemotion?
> would have IC levels parallel to their EM levels. They might be looking at... sidemotion
Sure. Many companies do this too. Like Senior Engineer at the level of Engineering Manager and Staff at the level of Senior Engineer Manager.
They don't have direct report and they still write code.
Same payband and leveling but different job function.
But at the end of the day, the ICs still have to "report" to Management: Senior Engineer even if they have same payband and leveling still have to report to an actual Manager.
I don’t really understand the first question, but do you mean that the capacity of an EM to spend time on growing team skills is reduced? There is a limited amount of time a manager can spend on that. If it’s a small team, then they could do a good job at it whilst doing small bits on the side.
For the 2nd, I imagine that if you are a manager and an IC on the side, then you don’t have the time to spend on big projects. It’s more likely you’ll be filling in gaps or doing the uninteresting but necessary work. There’s nothing stopping you from attempting to hoard the interesting projects, but then your performance on either role or both will likely suffer. That’s not really a new failure mode - any manager can be bad.
As a manager + IC, you shouldn’t be leading projects, since that’s a useful skill for your reports to develop. I guess there may be exceptions if your team is particularly junior. Ideally, if you are not micromanaging, you only participate on a big project if required or asked, not because you want to. Your main role is the people management side and to help with planning, prioritisation and communication.
> do you mean that the capacity of an EM to spend time on growing team skills is reduced? There is a limited amount of time a manager can spend on that. If it’s a small team, then they could do a good job at it whilst doing small bits on the side.
Yes, that's part of what I mean (but also: dealing with red tape, bureaucracy, and removing impediments) and no, the amount of time that can be used for this is basically unlimited: it's a full time job. "Small bits on the side" is not a good use of a senior IC, that's for the more junior members of the team.
I don’t think you treat the team manager as a senior IC. You treat them as a mid-level IC with a part-time job. If you are a manager you can’t also be considered a full-time senior IC (except in very specific cases, which should be transitionary) for the purposes of work allocation, because you can’t dedicate your full time to the job.
I don’t think management is unlimited work, at least not always. There are a fixed set of people on the team doing a fixed number of things who can only grow at a fixed rate. I agree that it could be a full time job or more, but I think that depends on the specifics. Obviously managers shouldn’t be forced to be ICs in all situations. If management is taking up all your time, you can retract from the IC pool. However, I think it’s valuable to consider and push for organisational changes to allow yourself to enter the IC pool again (maybe handing off some responsibilities to a new team etc.).
> failure mode driven by two conflicting goals
Again, I think this strongly depends on how you allocate yourself. There is room for a pre-emptible IC, that is not always available. However, it’s situation dependent whether this is useful or not. The conflicting goals theory only applies if you try and optimise for both. Your IC performance can suffer, whilst still being a net positive, again depending on the specific situation. That’s kinda upto you as a manager to quantify though. The article is more good advice on how not to approach this dual situation. If you know how to prioritise being a manager though, the points don’t apply.
On the flip side, sometimes your management performance HAS to suffer to meet critical deadlines because the entirety of the normal IC pool has other critical deadlines. It’s also upto you to avoid these situations, and if they happen then strongly push back on your leadership to prevent them happening again.
Your primary goal as a manager is to ensure team productivity and deadlines. If you can’t recognise that you are a detriment and step back (or at the very least step back when you get feedback from others who do), then that suggests that other aspects of your management are lacking as well, so it seems like the same failure mode.
The benefit to keeping yourself in the IC pool is that you can keep your skills at least slightly fresh. Even if you are no longer a full senior IC, not having any technical skills means an inability to make technical judgements if required.
All I can say is that in my experience I've only witnessed (and on occasions been, sadly) the dysfunctional kind of EM+IC. I've never witnessed it working well, which is what I'm basing my objections on.
The best managers I had were full-time managers (with an engineering background, which meant they understood the technical constraints); the worst managers I've had were either 100% non-technical, or EM+IC roles which just couldn't keep their paws away from coding.
> When the EM becomes an IC, how does this help the team grow their own skills and not get distracted by problems the EM should be moving out of their way?
Well, generally the team would still have an EM, just not that EM.
> When the EM is an IC, what stops them from either interfering with small stuff
> Well, generally the team would still have an EM, just not that EM
If there is an EM role, I don't see the problem. I took TFA to mean "become an EM who also codes".
> What stops any IC doing that?
Nothing, but an IC has by definition time to tackle big problems. Also, other ICs are their peers. An EM+IC has no time to tackle big problems -- or if they do, then they are neglecting their management role -- and so by default will tend to focus on nitpicking or small tasks. Tasks that are best done by junior level ICs.
> When the EM becomes an IC, how does this help the team grow their own skills and not get distracted by problems the EM should be moving out of their way?
Meta EMs do people-management only, which neatly side-steps interference on tech issues.
"Here's an option you'll hate—take it, or leave" is a tried-and-true way of making people quit. "You've been re-assigned" is a common form for it to take.
No, because these positions are genuinely being offered as an alternative to being laid off. If you choose not to take the new position, then you have terminated yourself.
Anyone non-tech I know would just call it "labor", as opposed to management. The people who mostly do the things that make the stuff, rather than mostly telling others to do the things to make the stuff.
Again, people'd just say "labor" in other contexts. Or maybe "workers". I'm not sure where "IC" came from but I've never seen it outside of tech, and that, mostly online.
I think “labor” is associated with repetitive or at least well characterized jobs
In tech, any two given workers are much less likely to be doing the same thing. So they are clearly not just laboring but contributing at some creative and self-management level as well
Individual contributors is just a fancy name for a software engineer without direct reports. Aka you'd stop being a manager and just write code (for the most part).
Non-managers, they aren't responsible for anyone but themselves. I know nothing of Meta's specific titles but I'd expect that e.g. the first level of full time engineering manager would convert to a full time senior or staff engineer.
If an actual layoff is the alternative, rather than being fired for-cause (after failing at being an IC, perhaps) or quitting, then yeah, it's not really constructive termination. I can't read the article to see if that's the case, though.
Well the details are important here - are they being laid off, or is Meta suggesting they quit and then forcing them into a new role? The beginning of the article just says they're "asking" them to leave the company, not firing them, and I can't read the rest so it's a bit unclear what they're doing.
Yep. Used pretty often. Attempting to fight things like that without a union backing you is scary and risky enough (plus lots of people just have no clue what the law says—which, who can blame them when it hardly matters?) that it usually works just fine. Probably a little more dangerous with employees as well-paid as at FAANG, but then again, if they ever want to work at that level anywhere else, they're not gonna want to rock the boat that way.
I love management and, after over 17 years in an IC capacity, find that it fulfills me in a way that writing code stopped doing. I was also a manager at Meta in a past life, and really didn't love the experience due to the nature of the company and roles of manager. I do think I'd really like being an IC there, due to the high level of autonomy and focus on doing impactful work.
To be slightly less cynical, I think they just mean that individual engineers at Meta are responsible for large chunks/vertical slices of work, so your work has a lot of individual impact on getting things out into the world.
This is the "correct" interpretation. Of course, it's sometimes a perverse incentive since getting something out and moving a needle or getting another team to use your work is also "impactful", and leads to many of the negative (intentional or not) issues caused by the apps.
Okay I'll feed the troll. There are only a few places where if you implemented, for example, an effort to reduce "body dysmorphic disorder", it could instantly improve the lives of 3 billion users worldwide. Meta is one of those places.
I don't see their comment as trolling. Reducing the negative impact Meta already has is a more accurate description. Given their track record so far, you'd be a tiny minority to even get to work on that instead of ad/user engagement optimization for example.
For every teen with poor body image issues there are likely 5 people served by Facebook in some way that they deeply appreciate. I talk to family members in Algeria who I'd never be able to reliably keep in touch with otherwise, and friends in Europe love FB marketplace. Yes, a service for 2-3 billion people has drawbacks. It's disingenuous to say that it doesn't improve the lives of hundreds of millions of people, though.
Facebook's algorithms fueled the genocide in Myanmar. How many muslim lives is FB marketplace worth?
Do you talk to family members in Algeria through FB or WhatsApp? WhatsApp would have been just fine if Zuckerberg didn't buy it before US regulators rolled out of bed.
I think it's hard to argue that anyone's life is improved by a company that shows such a lack of respect for its users. We could have social networks that respect us, but Zuckerberg systematically purchased them or squashed them in the cradle.
>Facebook's algorithms fueled the genocide in Myanmar. How many muslim lives is FB marketplace worth?
FB marketplace didn't cause those bad things.
FB has done bad things due to perverse incentives, but for individuals working at the company you can't deny that at least some people can have a positive experience making positive impact to the world.
The lungs plead their innocence, “We give life!" But the blood they oxygenate feeds the mitochondria that fuel the muscles that power the claws that tear into the lamb's soft belly.
I just genuinely don't understand why someone would consider working there as a positive thing.
So I would like to know!
But I have no way to figure it out as I know zero people who work there, and talking to a human who works at these companies is impossible because their websites are geared towards not allowing you to talk to them.
So now that I just saw someone in the wild to ask, I figured I should use the opportunity to figure something out which I absolutely do not understand.
> There are only a few places where if you implemented, for example, an effort to reduce "body dysmorphic disorder", it could instantly improve the lives of 3 billion users worldwide. Meta is one of those places.
It surely is a zero-sum to fix the problem which your company has created in the first place???
It's hard to believe you're not trolling when you present "millions of teenagers with body dysmorphic disorder thanks to Instagram" as the only kind of 'impactful' work.
What about people working on WhatsApp, or infra, or people working at FAIR or people building React, etc? The list goes on.
Meta creates a shit ton of positive impact which is not at all related to "millions of teenagers with body dysmorphic disorder thanks to Instagram".
They said that was the first thing that came to mind. The first thing that comes to my mind is fueling a genocide in Myanmar[1], but as a parent of a girl, I couldn't care less about Meta's development of React when their own research showed that they "make body-image issues worse for one in three teenage girls." Then there was the Facebook–Cambridge Analytica data scandal. It's been clear for years that to work for Zuckerberg is to do anything that he thinks will make him rich, the consequences for our children, our democracy, and the rest of the world be damned.
If you look at the actual leaked documents from FB (via the WSJ), then you can see that over 1/3rd of girls had their body dysmorphic issues improved by IG.
Oddly enough, this didn't get reported on very much by the media.
Somebody at Meta worked really hard to make sure that when I'm using Facebook on my phone to read someone's post or comment thread, it punishes me for taking a call or answering a text message by reloading my feed with a set of completely different posts when I re-enter the app, and then making it impossible to find the previous post or thread again.
No other app has gone to such extraordinary lengths to make sure you can only view a piece of content once, and then hide it from you forever after.
I use FB via browser and have not experienced this behavior there. But I do see it in the LinkedIn app all the time. Even if you click into a posted article, when you exit from the article you won't be able to find the post so you can comment on it!
I use FB via browser and this is constant on iOS. If I am going through my feed and I click a link to another site, it opens a new tab and when I return to the FB tab I see it reload the page and I lose my spot. If I try to scroll down to find the same item I clicked on (because for example I feel like commenting), it's almost always gone. Nowadays I just take it as a reminder that FB is either deliberately manipulating me or just doesn't care about the UX, so I close the FB tab. I'm not doing extra work to make up for their user-hostile decisions.
have you met the desktop version of tiktok ? they went out of their way to make it not possible to click multiple suggested videos in new tabs and all others kind of anti desktop measures.
Meta's has a corporate value for "Focus on long-term impact" which is trying to counter short-term gains that don't produce over time. They also talk about how you can make a "big impact" as an IC there, which from what I know is true since you can work on big projects, but they aren't necessarily the projects you'd want to work on if you have some form of value system that includes empathy.
Years ago, I met someone that boasted about doing auto-play for videos in your feed so that get sucked into related video after related video. He was particularly proud of implementing a feature (he worked it out with the PM) where you could only delete one video at a time from your history instead of in batch. The goal was to make it harder to purge your data and frustrate the customer so they give up. Ultimately they wanted more data on you so that they could further "optimize" the app to better suit/manipulate you. Pretty sure this is what they mean by their company core value of "focus on long-term impact."
Even if you don't think that some people find value in Meta apps, Meta engineers work on all types of project, lots of them are open source (see https://opensource.fb.com) and are impactful beyond just supporting Instagram.
Schools have caused many millions more teenagers to have such disorder, is there no impactful work to be done in schools?
In fact, the same research that likely was used to see such an opinion for you about Instagram in fact showed that it was more likely to improve stuck disorders than to make them worse.
> There must be something else which you are thinking about when wording it with this positive connotation?
A surprising number of teams are NOT involved in things like news feed, story ranking, "engagement", etc. Some teams, like my own, were building foundational technology for things like AR/VR, wearable devices, mapping & navigation, etc. A concrete example of "impactful" work done by such teams was just posted on LinkedIn, which is a focus on building maps geared towards pedestrians walking around, not cars driving. This is a building block for eventual AR use cases, among other things. The team building this then enables other teams up the food chain to use this in building what eventually becomes part of an end-user product.
Thank you for taking the time to answer my question! :)
I suppose it's a matter of weighing "a set of many small utilities which make life a bit easier for N people" against "two big dangerous social networks which make life a lot harder for M people". Because the money from the former helps the latter as well.
What a 'brilliant move' to purge the middle management! At many places, all but the super smart love to climb the management ladder. This strategy will force them out.
I know the general view is middle management sucks and I can see asking first level managers to become ICs may make sense in some cases, but that also means someone else is managing x times the number of employees. How is that supposed to scale?
I mean, if there are lots of managers at Meta who only have 4-5 direct reports, you could see this scaling decently well -- turn two teams into one, and that's not so bad.
But I don't think one person can constructively manage more than about 20 engineers at the absolute maximum.
Management is just a way to coast. I don't understand why we need to "manage" grown up adults. What we need are team leads who code and architect. Then give them the autonomy to run teams.
Resolving interpersonal disputes and guessing how much you have to pay someone to get them to stay, and software architecture, are two (three?) totally unrelated skillsets.
You don't need to "guess" how much to pay someone. The market dictates that. HR has pay bands. Raises are always in a narrow band. I don't know what kind of disputes you're talking about.
If you ask any manager - describe your responsibilities succinctly, they will most inevitably fail to do so.
I can imagine a company that had pay bands so narrow and bonuses so small that managers had no tools to reward high performers, and although I agree that it would take away a lot of what allows managers to do their jobs, I don't think that is the usual situation.
Running teams is management. Not everyone wants to be doing the roles involved in managing teams, so it's a designated job title. If you get rid of the hierarchy entirely, then what happens is that they form implicitly and everyone is completely confused as to who leads what, and that only gets worse as teams grow and the number of projects grow.
Some management is bullshit, but literally "run teams" is the important part. But if you get big enough, you do wind up with departments. It grows like a fractal.
Managers are an organisational necessity past a certain scale. If you have not felt the need for them I can only guess you've not been in a company big enough.
Think of it as trying to run a big country with direct democracy. Can it be done? Maybe. But there are good reasons why democracies become indirect after a certain scale.
"Managers are an organisational necessity past a certain scale." That sounds like a dubious claim, I'm sure there are exotic ways to run an organisation that doesn't need managers.
For example, Pirate ships ran with a Battle Commander, Accountant and Crew.
Pirate ships frequently had crews of about 50, and the biggest ones never exceed a couple of hundred. Do you have real world examples of large organisations (in the thousands of employees) being managed in a flat hierarchy? Because I don't.
Please note I'm not saying you can't be overprovisioned in managers. I'm replying to the parent comment that sees no need for managers.
What exactly is an "individual contributor"? I'm confused. This term has come out of nowhere in the past 5 years, and it sounds like you're referring to someone who backed a kickstarter campaign. If this is the new term for "employee", I'm out. I can't stand that companies refer to their customers as "consumers".
AFIACT, it's intended to distinguish between employees who manage people and those who don't. I.e. "the set of employees is the set of managers plus the set of individual contributors."
It's recognition over the last few years that the standard eng -> sr eng -> manager isn't actually a path that all engineers want, does not always suit the employee, and does not always benefit the company.
Individual contributor means people who directly write code (individuals who contribute), as opposed to people who manage (managers and project managers).
It all came from the industry wide shift to make sure that software engineers were even more just cogs in a machine that could be hot swappable.
The growing concept of "IC" goes hand in hand with the increased focus on "leveling" for engineers, as well as the rise of delegating all product related decisions to the rising class of PMs. All of these create a structure in which every team, even across companies, starts to look more and more the same and any individual can be trivially swapped out for another with the same role and level.
In the early days of the startup boom, ~2008, engineers at startups had a lot more control over the product process. Typical startups where a CEO with some general vision of the product and a knowledge of fundraising and a technical cofounder who would handle the real implementation of the product. CEO would make sure the company was health, CTO/tech cofounder would make sure the product was built.
But this lead to a class of labor that was a bit too powerful. As you likely remember engineers used to contribute a lot more than purely churning through tickets.
Today you can think of IC as a prefix to a more complicated part number: IC-SRE-4, IC-DEVOPS-2, IC-DS-6. Then you just have to find someone claiming to be the part and send them through a leetcode grinder to verify the build quality, then plug them in and go!
> If this is the new term for "employee", I'm out.
Can you please explain what's that offensive about calling somebody an Individual Contributor?
It's a little bit of weird jargon, but it acknowledges 2 important things (they're a person, and they're actually working) which is infinitely more respectful to the people that actually do the work than "Resource" that also gets used.
To me, using the word "Resource" to refer to people is by far the most dehumanizing term I've seen seriously used in an office.
Individual Contributor is problematic in that it implies that contributions are primarily made by individuals rather than team efforts. It also implies that manager roles are not contributing which is also often not the case.
It's quite individualistic. Much like "talent" which is the latest attempt to imply people are resources without using the word resources.
(Not directly answering the question asked, because sibling comments already did.)
FWIW, I've heard and used it in FAANG for well over a decade.
Usually I see HN comments using "IC" followed by someone asking what "IC" stands for. Makes a change to see someone asking for an expansion of the expansion :)
I've been a manager once- only because of necessity while working at a rapidly growing startup- and it's not a role for me. I loved being an IC at Google and other employers, and no matter how much I tried, I couldn't convince myself that by being a manager I'd have more impact, or achieve more of my goals, or be happier.
I'd like to see more people-managers who aren't also product-managers and tech-leads: people whose job is to manage people, not work on the technical side of what the managed people work on. Some people are really good at this and should focus on it, to the exclusion of coding.
> I'd like to see more people-managers who aren't also product-managers and tech-leads: people whose job is to manage people, not work on the technical side of what the managed people work on. Some people are really good at this and should focus on it, to the exclusion of coding.
I’ve worked with managers like this but they were pretty rare ime. Most of the time it’s either a product person or someone who is subpar engineer grabbing the power seat bc that’s the only way they ever going to have any say in anything
I had cautiously gotten into management because I wanted to learn the skills of delegatin and really building through others and growing/coaching others. I thoroughly enjoyed this. But over time what I had realized was the role had been changing (not sure if it was just for pandering) towards being a mouth piece for leadership and hr - having to relay decisions I didn't believe in (perf seasons, promo rationales, layoffs anybody?) As if they were on purely my own. Given Ive always enjoyed building this may actually be a good forcing function to go back to IC and just ... Build!
It because a theory of mine that a large part of my job function was to simultaneously water down accountability from above, while adding enough complexity to the layers below me to discourage them from changing the status quo.
The double edged sword being, without that authority, that same power structure is forced on me, and now I’m more aware of it.
I have a feeling being in middle management leads to that squeeze.
If you're closer to the doing, you are more isolated from the companyspeak nonsense. If you are in the upper part of the food chain, you get to enjoy more influence, freedom, a better risk/reward tradeoff, with costs you mention.
In the middle you're kind of screwed from both ends.
I had a couple of accidental ah-ha moments about this. Before I got into management all managers (fully up the stack) seemed like pointy hairs bosses. But what is easy to miss in Dilbert is that the PHB is really part of exec suite and rarely your front line manager. A hated front line manager might be usually incompetent or just inexperienced than evil!
The other thing was demonization of front line managers. There was always a terrible (there are definitely terrible traits) managers but never terrible "leaders". Even worse was you'd see articles by hr "influencers" expounding this. Where are the same hr loud speakers now that "leadership" is the one inflicting these layoffs and ridiculous policies?
In general, if you want your reports to accept company decisions, it is in your interest as a manager to align your stated opinions with company policy. Openly disagreeing, or just trying to take a neutral position will only reduce faith in the company and sow unrest for which you will be held accountable.
Isn’t that the entire purpose of being a manager? If I were just going to repeat the company line and not advocate for my team then I might as well be a rock.
"I don't like it either. Here's what I'm doing to try to get them to change course. In the meantime, we need to do xyz, and I need you to do abc as part of that"
I have absolubtely had managers that did an excellent job of making us feel like we were in it together. In fact I'd say its one of the key skills of being a manager at all?
> Is this actually the expectation at the places you work?
Can you imagine a manager saying, "I don't agree with these decisions, but you need to do A, B, C." This might be being frank and open with your reports, but at the same time you reduce their motivation. And if top management learns about this, they won't be happy.
So yes, there is such unspoken pressure to at least not to distance oneself from the things you ask others to do, whether they come from you or from your boss.
Yes, it happens all the time. Each time we get a new form we have to fill out to do something or some extra hoop to jump through. If the manager I worked for didn’t act like a normal person that thought that shit was stupid I would absolutely hate working with/for that liar/crazy person.
> Can you imagine a manager saying, "I don't agree with these decisions, but you need to do A, B, C."
Some of my best managers, on well-regarded teams, have done exactly that. Those managers are doing me a favour by flagging that it's a waste of my time, emotional energy, and political capital to argue with decisions that neither they nor I can affect, and that it will be better if we just get on with it.
I’ve been a manager for decades and this is the way to handle it sometimes. Life is full of things that suck but you have to do them anyway, like paying taxes or cleaning your bathroom. Why should we try to pretend that work, of all places, is exempt from that?
Wrapping it in pink wrapping paper fools no one but kills personal credibility, which is the most important asset a manager has.
Top management often does not give a shit if people are happy about the thing (who is happy about layoffs?), just that it gets done satisfactorily. So yeah, sometimes I tell my team “this sucks but just get it done and then we can get back to the interesting work.”
This is how I operate when I have a close trust with my team and boss. But I have also been in very transactional environments where I was "ratted out" for my frankness!
Imagine this from a military perspective. The general/field marshal etc makes the call that you're going over the top and as a smart Major or whatever you know this means most of your men are going to die. Are you going to say to your men:
"Hello gents, we have our new orders, we're going to go over the top tomorrow at 8am and try and take the village one mile down the road, however, I think this is a horrible idea and you're all probably going to die."
Even if you really believe this is the case, it's a bad idea to tell your men as it means the plan (which is going to happen anyway) is even LESS likely to succeed. That is, if you can make your men believe the plan is genius and they're going to destroy the enemy easily, it may give them more confidence and leave more of them alive at the end of it.
By explaining your reasoning in every situation you can will build trust, so that on the rare occasion that you need them to act without sharing, they will trust you enough to do so. For example, when in an execution environment where response time matters.
And in practice, this is how good commanders I've worked with have operated. And this is explicitly a principle of the US Army, by understanding the objective and it's purpose units are able to continue acting to fulfill their objectives even if they are cut off.
The upside of explaining whenever you can let them build a mental model to know how you would likely handle an unexpected situation, allowing them to act in your absence.
It is unusual to have a team emotionally mature enough to handle actual transparency. You only have to read HN to know people live with extreme cognitive dissonance between wanting their high salaries and hating the business practices that enable them.
My experience has always been that certain employees get marked as "adults in the room" and are given real transparency in 1:1s.
This is true. Especially extending it to opinions and emotions.
But understanding the purpose and why of a decision/plan is only a small piece of full transparency. And is always achievable. This is the minimal amount I consider functional. Less than this is dysfunctional.
The reset is extremely rare for teams (I’ve only had this on a team once and it was magical), but happens regularly individually 1-1.
I'm not a manager, but at the very least it seems like an implicit expectation associated with the role. I wouldn't be surprised if it was explicit at some companies.
> towards being a mouth piece for leadership and hr - having to relay decisions I didn't believe in (perf seasons, promo rationales, layoffs anybody?) As if they were on purely my own.
The role doesn't change though. It has been like that forever.
This is another part of Management (whether you like it or not). Management should be seen as a cohesive "Leadership" unit because if the leaders aren't on the same page, what good are them?
The other thing about Management/Leadership is that they should be able to relay the message in the right format and at the right level for their direct reports. C-level typically have OKR/Objective in 3-5 bullet points (the bigger the company, the more bullet points) and it's the VP and Dir jobs to break these individual points to high-level goals for their Organizations. It is the Manager's job to distill it even further to their level + their direct reports.
It's one way to keep ICs on the same frequency with leadership and to execute for a common goal.
Most ICs don't want to attend meetings, don't want to hear "high-level goals", and more importantly, don't have the skill to consume those high-level goals at their level. They need help from various layers of leaderships. Sure, there are those exceptional ICs that wouldn't mind to be involved at that level and understood the social/human aspect part of the work but let's be frank here: majority of ICs just want to bang keyboard, produce clean code, and marvel at the end results (ignoring everything in between).
The best thing you can do in these roles is protect your team. It's your primary job to ensure they can build and with minimal wasted efforts. If you view it as building for the company, your team is a victim to all the dysfunctions of the organization and nobody wants to be on that team. The mouthpiece part is tricky, I always try to give the official message with a dose of my personal candid opinion on it even if it's in opposition. You just can't lay it on too thick and try to find a way to spin it to a positive as to not be demotivating for the team, "it might be challenging, but at least we'll learn X and they're aware of the risks that are at top of your minds."
Agree. Their decision is made. The way I manage I tell upper management what risks their decisions have, then don’t let them blame my team for when those eventualities occur. My teams don’t work overtime to meet a deadline when some decisions was made that screwed up the schedule. Those kinds of things. That’s protecting your team.
I've recently held a senior management position then left and obtained a technical position at a different organisation.
Not kidding, I nearly cried with happiness moving away from SM and into a tech position again. I was GIVEN work to do. I had NO responsibilities for others. Moreover, I was DISCOURAGED from attending unnecessary meetings. I arranged no meetings! Not one!
Went from 7 direct reports to zero. No more approving holiday requests. No more performance reviews. No more management town-halls. No more arguing strategy with anyone. It was brilliant. 'Please write a procedure that does X. Return it by Thursday.' 'Please optimise this statement that hangs during the overnight run'. Yes, absolutely, more of that please.
I too went from management back to coding (freelance) since the start of the pandemic and I also love it. Today I happened to notice that Google Calendar was reporting an anomalous week in terms of meetings: I had 2.5 hours of meetings in my calendar this week, while my average right now is 1.2.
I average less than an hour and a half of meetings per week! I have so much more time in my life for the things I love, it’s crazy.
Depending on the company saying I don't believe X gets relayed back up your chain with eventual unpleasant consequences (hey so and so doesn't agree with this management decision so they must be a misfit and can't be trusted to put the company first)
Absolutely. There is no disrespect anywhere here. I don't need to agree to do my job well. Just that I don't feel safe enough to be vocal about sharing my thoughts -)
At Meta many engineers tried management and then went back to being an individual contributor. I'm not sure of the exact numbers but it was a very common career path. It did build up empathy for management on the senior IC side and meant that teams didn't get stuck with managers that didn't actually want to be a manager. If the company is not growing headcount this move makes perfect sense.
That's a pretty common thing once ICs reach a certain age. I've seen it everywhere I've worked. Sometimes it's because they fear age discrimination but more commonly I've found it caused by the organization not providing a great career path beyond a certain level. With wisdom comes the ability to accept that it's OK to stick at an engineering career level for years at a time.
Zuck has it right. All the worst managers/directors/VPs in engineering I've seen are people who don't contribute anything to the codebase. They actively discourage managers who want to write code from writing code. They instead encourage them to focus fully on process and sprint management. Lots of backwards ideologies in tech perpetuated by B-players who got a little too comfortable with "people management". I would think that the role of an "Engineering Manager" or "Tech Lead" or "Team Lead" etc. should all be pretty interchangeable, or at least have very high overlap.
Anyone without intimate knowledge of the product they are working on is useless IMO. I was in the code daily when leading a team and don't respect any development team leader who isn't.
Absolutely. Of all the companies I've worked with, the one with absolutely the most effective management was the one where every manager was also a part-time IC. The head of mechanical engineering had to design a product while managing the team. The shop manager was also working as a machinist for most of their shift, or working on jig design and metrology. The head of accounting, of course, spent most of their time accounting, and only part of it managing the accountants. The head of software also wrote software, although not as much as their subordinates, and they were reviewing the codebase all the time. Of course none of the managers would chew through their IC work as quickly as people who could devote all their hours to it, so they mainly picked up tasks that weren't critical-path to avoid becoming blockers to their team.
The CEO rotated through positions, spending several months working in customer service, inventory, accounting, and even working directly on the production line. He mainly put himself on whichever team was most short-handed, although it was more to learn firsthand what their challenges were, and how the company could allocate resources to solve them. Fortunately he was a multitalented guy who could pick up those roles productively, and also humble and down-to-earth enough to not intimidate his colleagues too much when he took over the neighboring desk.
Aren't Product Managers & TPMs considered ICs? They don't have direct reports but aren't writing code either. I imagine this will be a more common option for these Engineering Managers who are managing other managers
Product Manager can refer to an individual contributor IC or someone who also manages other Product Managers (and sometimes even adjacent functions) e.g. a Group Product Manager. The titles are not very standard though. Many of these roles are hybrid as well. For example, a Product manager who will be responsible for a Product portfolio and some products in that portfolio as an IC, while managing/supporting the work of PMs working on other products in that portfolio.
Same for TPMs. They can be ICs or managing other TPMs.
the managers who want to write a lot of code usually are so focused on their contributions they fail their other responsibilities.
The ones who are trying to set product direction are usually harmful, too.
The managers I've had the best experience with are the ones who focus on helping their ICs navigate the larger organization, dealing with human issues, and helping the ICs understand organizational priorities, and evaluate risks.
Don't ask me why in heavens that term makes any sense outside one that is myopic or only works with extremely fresh out of school junior engineers and unskilled workers.
Edit: P.S. Not sure why a couple of people decided to downvote this opinion.
Also to other commenters: it sounds to me less as a be a team player title (like the soldier one suggested) and more like an isolated resource that makes interchangeable contributions.
Anyways, I think that there is a distinction between "(Team) Lead" and Manager with the Team Lead usually classified as an IC says everything for most organizational approaches.
I am not sure. It has been around for at least 5 years I would say. I guess at some point they needed a nice sounding alternative category to people not becoming managers.
so i guess that managers are not individuals and don't contribute? might be true. but i've been a manager and an individual and contributed code. well, who knows?
The point is that ICs are judged based on their individual contributions, i.e. their own code, design docs, etc, whereas managers are judged based on their team's contributions
Why are you being so pedantic? At this point it seems like you're trolling.
> so i guess that managers are not individuals and don't contribute?
> i have never, ever come across a programmer working on a system of any complexity that did not depend on contributions from other programmers.
No one said non-ICs aren't individuals, and no one said they don't contribute. No one said that ICs don't work with others or depend on others.
What has been said, several times, is that their contributions (i.e. the code they produce, artifacts they create, etc) are largely individual contributions. They are the ones creating the thing, and are not responsible for others.
This gets a bit murky as you move up the IC chain, in that your contributions become less tangible and are in part measured on how you lead others and make those around you more efficient. But your performance is still largely judged on what you produced.
the nuance you are missing is that individual contributors are responsible for their own work and judged based on that. they are not responsible for the work of others. managers are of course responsible for the work of those they supervise
Lots of people who aren't part of the "working class" do plenty of work but that's the nomenclature society uses for some reason so if you want to communicate with everyone else, you have to go along with it.
Just in the past week "IC" has appeared in 2 front page stories on HN.
Are you US based? Beginning my career in the mid 00s I was exposed to "IC" pretty much day 1 starting at Microsoft.
Other people around me in adjacent sectors also use the phrase to refer to non-managers, it is pretty common daily parlance, I am 99% sure I can ask any of my knowledge worker friends and they'll know what I am talking about.
Google trends show "individual contributor" has been a pretty popular phrase since at least 2011.
> no, i am not us based, though i have worked there. but so what?
Every country, and even different regions of a country, has linguistic differences. This is true even if all the countries being talked about have the same national language.
For example, nobody in the US tech sector is going to know what a Boffin is unless they read The Register.
Even on the west coast of the US, vocabulary is different between California and the Pacific Northwest, although things started to merge together when the Silicon Valley based tech companies began opening offices up in Seattle.
as a matter of interest what, as vaguely as you like, do you work on? because you seem uninformed to me and it is not obvious to me that you know what you are talking about. there is one tech giant that has always been based in seattle. well, make that two.
You seem to be the one who is uninformed, considering you've never heard the term IC.
Yes, everyone knows there are two tech giants based in Seattle. What this person was saying is that other large companies have also opened/grown Seattle offices in the past decade and vice versa, which has caused usage of corporate vocabulary to merge.
Maybe you should reflect on the fact that you don't seem to understand what people in this thread are talking about and stop acting like you do.
I actually like the term as it seems pretty accurate to me and I don’t know if a more accurate term.
There’s many types of “managers” who are actually individual contributors (eg, sysadmin, project admin).
When you get into principal engineer and architect titles, sometimes those positions manage people and sometimes they don’t.
I think it also highlights how one version of contributor isn’t better than the others. Some people only produce value by being part of a team, some produce value by managing, and some produce value direct from themselves.
I've always like the term soldier. It's what organized crime syndicates, armies, and ant colonies all use. The worst is when someone gets called a "resource", but I can't get too exercised about IC.
As a consultant, I've become accustomed to being referred to as "the resource" by operations people. However, the day an engagement manager refers to me directly as "resource" is the day I openly start referring to them as my secretary.
Nobody has IC as a title, it’s a whole class of job families that don’t require/revolve around managing other employees. Data Scientist, Software Engineer, Data Center Technician are all ICs. It’s just a more positive way of saying “not people manager”, especially when you are trying to build a culture that going into people management shouldn’t be the only career path.
why do you need to say "not manager"? most people are in the nature of things not managers. and if you do need, for bad, bad reasons want to differentiate them, how about NMs? oh, but that would be to obvious for the current crop.
Others have answered what the words "IC" mean, but let me add that this is the usual name for the technical career track, i.e. the not-management track, meant for people who do not want to manage teams of people.
Strictly speaking, the roles of Engineer Manager and IC are incompatible; you cannot want to manage people and at the same time want to stay out of it. So in this particular context, "EM+IC" is a misnomer for "EMs who also need to be able handle tech/coding tasks themselves".
True! I meant the usual name now. For me it's the same as Engineer Manager: it seems to have come out of nowhere but it's the standard now. Before we called them simply "managers" (or sometimes "team leaders" of the non-technical variety).
PS: are you by any chance the same Izkata as the one in scifi.se?
I also never saw this until pretty recently. At first I assumed people were talking about independent contractors because it was the first thing that came to mind, it possibly fit the context I saw the term used in and nobody explained the acronym they just dropped it there like I was supposed to know what it meant.
Took a bit longer to realize they meant individual contributor.
I've been hearing it for about 5-7 years now, usually in the context of career paths. I think it became popular when companies realized that non all developers are made for management and you need a separate career track for people who want to advance, but don't want to be a manager.
Principal engineer, architect, etc all fall into the IC career path, while, manager, director, VP of eng, etc all fall into the management track.
It's more project management than people management. You likely have to lead projects and maybe a team, but you're usually not responsible for anyone's career growth (other than your own).
what does TLM mean? i wish that all you folks out there would understand that nobody outside your bubble knows what these daft abbreviations stands for, much less mean.
TLM (at Facebook) stands for Tech-Lead Manager - it’s a hybrid role, with engineering duties and people management duties.
From what I remember, it wasn’t intended as a long-term position, but was used in stop-gap circumstances (manager quits, tech lead temporarily takes on some people management duties) or for when an engineer was considering transitioning to the management track.
Yeah, it's an "M0" role. Generally folks who transition from senior engineer into management become TLMs. Staff engineers transition to "M1" or a full-fledged manager.
TLMs still have individual contributor responsibilities. M1s don't. The reason for that is generally that (especially junior) ICs aren't likely to push back against poor technical decisions knowing that the person they're pushing back against is also in charge of their rating. This feels quite fair based on my experience and as such I'm quite skeptical about TLMs in general.
Not true, TLMs can be D1+ level too at FB/Meta. Higher level TLMs more often than not tend to occur in more research-oriented organizations though (where the TLM is effectively a "principal investigator" type for some research area).
It’s honestly getting out of hand. It’s almost as if one requires a dictionary to communicate these days. Even though I know these abbreviations it’s just off putting.
To clarify, EM stands for Engineering Manager not Engineer Manager. EMs are generally expected to be technical, but not be engineers writing code on top of being a manager.
I often make this mistake because English is not my first language, and I confuse "engineer" with "engineering": in both cases it sounds to me "a manager who manages engineers", not "a manager who is an engineer him/herself". Kind of like a "Product Manager" is a manager who manages the product, not a manager who is a product!
Writing code as a manager is my number 1 stressor.
As a manager, I have to deal with so much random bullshit. I don't mind it, but it's extremely difficult to manage that bullshit alongside code and sprint commitments. "I couldn't deliver" is remembered far more clearly than "I couldn't deliver because I was helping the team with X other thing that was far more important.".
You are very fortunate to have had that experience.
Usually, when a manager/director/etc decides to write a lot of code, the result is barrages of rushed pull requests made between meetings. You will be lucky if the code in any of those PRs was actually run, and you can forget about enforcing test discipline, so you have to scrutinize them much more carefully and clean up when they get merged without incorporating your suggestions.
Agreed. I'm a manager who doesn't write code anymore (at work) and, at best I'm adding log statements or updating documentation. I'm still encouraged to write code if I can, but it just doesn't make sense.
When I had a single digit number of developers on my team, writing code was still possible. When I started closing in on double digits, I realized that I had so many other things to do that, at best, I was only going to have a few scattered 30 minute or 1 hour blocks each day to write code. Also, a lot of my job is to handle the unknowns that come up, so I also couldn't really commit to any hard deadlines.
That means, best case scenario, I could only pick up work that wasn't high priority and that didn't require long periods of uninterrupted time. I still love writing code, but my philosophy has always been to focus on the things that only I can do. Low complexity projects that no one is waiting for can be done by just about anyone. My "staying in touch with the code" time is better spent doing PR reviews or reviewing design docs.
I have worked with some fantastic "people managers" in my career who don't write code. But they usually faded into the background most of the time, except for when they needed to communicate something or I needed their help with something.
The bad managers were always working hard to schedule more meetings, force extra process into every step of our work, make decisions about how we did our work, and to change our priorities to work on their pet projects.
The bad managers occupied 10X more of my time than the good managers. It only took one or two bad managers to completely derail productivity of an entire group.
> I have worked with some fantastic "people managers" in my career who don't write code. But they usually faded into the background most of the time, except for when they needed to communicate something or I needed their help with something.
Yep, that's familiar. Good "people managers" have always been the ones that removed obstacles, and didn't become one themselves.
> They instead encourage them to focus fully on process and sprint management.
Thats literally the point. Its totally fucking batshit that somewhere like meta still uses spreadsheet to plan. This is why properly trained people should be doing management.
Project management at scale is not something you "dip into" its a full time job to project manage and people manage. Its not something most ICs should be doing.
A <Edit> consultant[1]</Edit> surgeon leads a team, but they don't manage the timesheets of the juniors, nurses and assistants. Meta very much expects that a consultant surgeon not only does surgery, but fills rostas, recruits nurses, does some marketing and works on the legal policy for negligence.
The issue at meta is that with the growth there is no "leadership". What is a lowly IC supposed to work on? "create consensus" and "drive from the bottoms up". That doesn't work when you have 11 layers of management, all pissing about talking about impact, but not actually driving projects.
> I would think that the role of an "Engineering Manager" or "Tech Lead" or "Team Lead" etc. should all be pretty interchangeable, or at least have very high overlap.
You should try it. Its pretty clear you've not managed people at any level of scale or formality. Not everything is code, babes.
(No. I'm not a manager at meta, thank fuck, it sounds pretty shitty.)
Chief surgeons do all those things you describe. Check out the job description [0] as they are basically department heads doing recruiting, budgeting, supervising, etc. Chief Surgeon doesn’t mean best surgeon.
But it is a bad analogy, as you've implied. What I was trying to get across is managers should be specialised, they should be someone who might or might not have been a programmer, but is now specifically managing people, or projects.
Managers who code, do exist, as to engineers who manage. But its better at large companies to have specialists to manage projects and people. With support, training and performance management, you tend to get a better outcome.
What’s interesting is that all chief surgeons were once surgeons, probably really good. So there’s idea that you have to do the thing to manage the thing.
Medicine is strange in many ways, but I think this isn’t a bad practice.
I’ve worked for non-dev managers and sometimes they are good. But I prefer to work for someone who at least once was a dev as I think they understand better what is possible and how to coordinate and lead.
When I managed teams I always tried to do something useful in the codebase. I don’t think it is possible to manage well and work deeply enough to make great software. But it’s possible to at least be able to do my own builds and at least test out different techniques.
Pournell's Iron Law¹ in action. The administrators will always hoard the power and control promotions etc in an organisation.
Studies have shown time and again that small autonomous teams is the most optimal setup for software development. Having a layer of Director, SVP and VPs on top of EMs is just Pournell's Iron Law manifesting itself.
You're pretty much just repeating the constant engineer gripe of "What do managers even do". The point of management is co-ordination and direction. They're not there to contribute to the codebase, they're there to ensure people are contributing the right things to the codebase. If you really think these managers/directors/VPs are useless, describe what you think they're meant to be doing, and how it would get done without them.
This is the sort of thing that you don't recognize until you become a manager, and then you do and you watch everyone on your team run around like a bunch of kids chasing whatever caught their attention that day and it all becomes a lot clearer.
"Why are we doing this" and "how does it align with the business's goals" and more pointedly "what are we not doing so we can do this instead" and "is that the right trade-off" are all questions even very technically gifted engineers seem to have a really hard time answering.
The issue is most managers don't tend to think this specific way. They think of how to align the business goals to suit their specific needs (i.e. getting promoted).
Every single re-org I've been involved in was bureaucratic mess to give a manager a higher salary. There was no explicit reason why we needed to re-org, and no org change ever made a difference in terms of productivity. Our individual teams still operated the same.
It's not that they are useless, it's that there are often too many of them.
At a previous SV org I worked for, they had roughly 1 "dev manager" for every 4 engineers. You could have 1 for every 10 and achieve the same result.
I’m not sure if that’s true. 1 dev manager for 10 engineers might be tough. The sheer number of 1:1s would be insane, much less keeping track of the career trajectory of 10 different people at 10 different parts of their lives. I guess this would be less difficult if everyone was already at senior or staff level, but you’d still have so much of that managers time sucked into 1:1s, reviews, and team retrospectives. I’m not even a manager and I start to feel neglected as an engineer once my manager juggles more than 6 other people, because I see they start to forget what I’m working on, and those 6 start to compete for attention to get promotions…
I think it can go either way (and at Meta, I have no idea), but team size tells you nothing. You can have a team of 4 highly productive engineers working on a specific project with limited scope and 1 manager can manage that very effectively. But you can't have that manager manage two teams, you're literally just splitting their focus (and with 4 people the manager can be hands-on). On the other hand you have plenty of teams that were at one point 4 productive people, grew to a team of 10, now the manage is very productive! Managing a team of 10 people, but in reality that team of 10 is now struggling to work efficiently and are probably producing the same value as the previous team of 4. The management structure is entirely determined by the underlying scope of the work that needs to be done - and yes, very often it goes astray, but in every direction.
You are right about team size, but in many companies, the "dev manager" is certainly not hands on, even with small teams. The last team I was on, the "dev manager" never even set up his development environment. He always claimed he wanted to get more involved, but probably had too many other priorities. If you are managing a team of 4, not making any technical decisions, not writing any code either, in my opinion, it is a bad sign. You are too out of touch. Hands on is necessary with small teams.
In those environments, all the technical work and decisions are delegated to a tech lead / staff / principal eng. The "dev manager" is there for people management and high level sprint planning. Planning can be done with very little technical knowledge since the team itself does the sizing and scoping.
Obviously not every company is the same, but that was my experience at a mid-size SV tech company.
I understood the role of managers after I joined a chaotic startup which hired a bunch of people but didn't think of management. It was a complete mess. Senior engineers didn't want to manage, or didn't know how to do it. And good managers are very hard to find.
> If coding is beneath you, working in software is beyond you.
maybe the problem you are trying to solve isn't code.
> ICs do not need managers, managers need ICs.
Given the level of infantilisation at meta, and big tech in general, I think this is clearly not the case. "self management" (ie bottoms up management) stopped working at meta many many years ago.
> Some managers have negative productivity.
So do a lot of ICs "I'm rewriting x in NEW_LANGUAGE because its faster" & "just read the code, that's where all the answers are" & "no you're doing it wrong, just re-write this major system to make it do something completely different because I've not taken the time to listen to your problem" Meta is a massive pile of "not invented here" tech debt, that was half arsed for impacc and then abandoned. Most of that is IC ill disciplined "oh but I'm BORED I'm going to make a new x".
Don't get me wrong. I've had some complete bellends of managers, but that's not a function of them being a manager, that's a function of no training and ineffective performance management.
Writing code is easy,
Writing good code is not so easy
Reusing other people's code is hard
Making an entire company reuse code is fucking difficult.
Getting prima-donnas to document code so that other people can use it quickly, super fucking difficult.
Managing programmers so they don't start gnawing at the furniture, rebuild everything every six months, wank over the interns and getting them produce a viable product, one that they can't/don't/wont use is top level hard. It's something I don't want to do.
If you think developers are prima donnas wait until you hear about managers. Compared to developers, many of them fit much more into the prima donna description.
Most managers don't document anything and when they do, it is of low quality and goes unmaintained quickly.
Most managers out there are redundant and have no idea about what leadership is. They just get an orgasm each time they say no and conflate that with being a true leader.
The reason hackathons produce amazing results is because it is what happens when managers get out of the way for 1 day: improvement driven by builders that care about the product, not office politics.
You're assuming that I've never really worked anywhere with managers, good or otherwise.
> Most managers don't document anything
yup, and they are insufferable dicks for not doing it. But, in big companies you need to have presence, so managers that are successful tend to have a documented paper trail of "their" successes. Whether its useful documentation is very much another matter.
> Most managers out there are redundant and have no idea about what leadership is.
There are two issues here, lets do leadership first. Yes, leadership is not taught properly, and that annoys me greatly. Leadership can be taught, and its not to challenging to do. But on the flip side, leadership isn't just about keeping people happy, its about taking hard decisions and getting people to understand what they need to do.
Again, there are lots of bad examples out there.
Now as for redundant, if that was really the case, and that most manager are redundant, then surely they are ripe for "cost savings"? After all capitalism is mostly ruthless when it comes to staff costs.
The problem is that good managers increase productivity. However what "good" is can depend on where you sit on the hierarchy. If your CEO/CTO only talks to managers, then your manager controls the information flow. this is a company culture thing, and is closely coupled to how managers are expected react.
> The reason hackathons produce amazing results is because[..]
...of exposure bias. There are loads of ideas in hackathons, and lots of them are shite. But! the ones you remember are good, thus there appears to be a great signal to noise ratio. I've organised and participated in loads, they are good fun. But you can't run a company permanently in hackathon mode.
My experience is the exact opposite. Managers who code are usually talking about minutia bordering on micromanagement, never put or have enough time to develop people skills, ignore career development and growth, have little to no project management skills, do a terrible job with cross team planning etc.
My experience is just the opposite. Most of the really technical people who were promoted to management that I’ve worked with don’t know how to fight the political fights for their reports or get the raises, recognition or promotions that their reports want.
>Zuck has it right. All the worst managers/directors/VPs in engineering I've seen are people who don't contribute anything to the codebase. They actively discourage managers who want to write code from writing code. They
Wow. And these "good" managers coding, how do they meaningfully pursue strategical tasks that benefit the team and organization? Do they have time for these, 1:1s, team meetings, unblocking the blocked, translating the untranslated, and generally, um, managing?
I think this is a great move. My understanding is that some reporting chains in facebook have 12 links between IC and Zuckerberg, which is crazy inefficient. Enormous organizations are able to run effectively with 5-6 links from IC to CEO. Managers managing managers managing turtles all the way down is a horrible form of "administrative bloat". You see bloat like this in enormous organizations like colleges, governments, and now monopolistic tech companies. This is besides the point that I don't think that big tech has successfully groomed many managers into people are capable of actually managing businesses; they don't drive value, they preside over decisions and make a case for higher headcount in the next planning cycle.
Wow. I'll say that even in the Army, famous for its bloat, there are arguably fewer than 12 links (following the legal chain of command) between the lowest ranking private and the President of the United States...
Of course we also pad that with a lot of senior enlisted advisors, executive officers, chiefs-of-staff, deputy commanders, etc. who can effectively be additional buffers between each echelon.
If you want a flatter org structure, it seems like it would be easier to achieve this if manager/IC roles were distinct. If a manager is also writing code, then they won't have the time to manage as many other employees, and the total number of managers/layers would need to increase.
yea, I don't think the manager/IC thing is a point of leverage TBH. I think the real issue here is that you have senior managers that manage 4 ICS and 1 manager of a 6 person team, and that manager should just report to a director and the senior manager should be retitled "manager" and manage 8 ICs instead of 4.
They might be pushing hybrid manager/coders to move back to full IC / tech lead type roles, while keeping the dedicated managers with bigger spans of control. That would have the effect they want, anyway.
IC reports to tech lead manager (link 1). TLM reports to senior manager (link 2) senior manager reports to other senior manager (yes, this happens, link 3), senior manager reports to director (link 4) director reports to senior director (link 5), senior director reports to VP (link 6) VP reports to SVP (link 7), SVP reports to C level (link 8) C level reports to CEO (link 9). I saw these reporting chains when I worked at FAANG, and I can imagine its pretty easy to stuff 3 more links in here to hit 12.
I have seen such chains at Amazon. IC -> Manager -> Sr Manager -> Director -> VP -> SVP -> CEO of AWS -> CEO of Amazon.
That's only 7, but some links repeat. For example, I have seen Sr Manager report to another Sr Manager. Likewise, a VP report to another VP, and a Director report to another one.
I've said it before on here: being a lower-level manager in a large company is worse than an entry-level job.
No one cares about your job experience (all those painful internal tools you now have to use to manage and report on your team) so you're just expected to grit through all the broken processes and inefficiencies (kiss your evenings and Sunday afternoons goodbye), and you are mostly powerless, particularly in orgs with centrally managed budgets.
I was an engineer, then a manager, and now I'm transitioning back to about 80% IC work. There were a couple big obstacles.
- Getting your skills back means getting hired to do engineering in the absence of sharp skills. I had to fake-it-to-make-it for a little while.
- Moving from manager to IC is a risky story on your resume, where you want to show continuous growth. You can't take just any IC role. In some way it has to show a positive career trajectory.
Now that I'm over the hump things are great. I love engineering and am glad to do it all day.
Every company should set a 6 month trial period on engineers turned managers. I only know one or two engineers who ended up enjoying it. It's far, far more likely to dip your toes into it with enthusiasm and realize you hate it. It's not about not trying hard enough, about social skills, or it being "a totally new job with a new skill set and you're not used to it yet". It's about your personality type.
Ask yourself:
Do you like being in charge of people, or do you like being in charge of the codebase?
Do you like solving your problems by asking people to do specific tasks for you, or would you rather solve a problem yourself?
Would you rather take a breadth first depth first approach to you work?
Are you good at planning, logistics, and deadlines, or are you more comfortable with going with the flow?
673 comments
[ 2.6 ms ] story [ 51.7 ms ] threadThis is definitely a good move, as I've heard some horror stories of management bloat at FB since I left in 2018.
Anecdotally, I've never had a manager that wasn't super technical. They wouldn't last.
I just need my manager to know they don't know how to do my job and stop telling me how to do it.
Tell me what needs to be done. Trust me to figure out how.
But agreed that your manager should set goals rather than plans. Fun fact, at FB at the same time all ICs came up with their own goals rather than these being passed down from management.
Technical skills may or may not be required, but understanding is...
"Each of my managers explained carefully his own theory of what had gone wrong and all the theories were different. At last, there breezed into my office the most senior manager of all, a general manager of our parent company, Andrew St. Johnston. I was surprised that he had even heard of me. "You know what went wrong?" he shouted--he always shouted-- "You let your programmers do things which you yourself do not understand." I stared in astonishment. He was obviously out of touch with present day realities. How could one person ever understand the whole of a modem software product like the Elliott 503 Mark II software system? I realized later that he was absolutely right; he had diagnosed the true cause of the problem and he had planted the seed of its later solution. "
- C.A.R Hoare, 1980 Turing Award speech
Technical skills are DEFINITELY required to be an IC. Understanding without the ability to implement makes for a lousy IC.
You can do this, but you will have to accept the plateau. There's really nowhere to go beyond Staff/L6, unless you're some super genius full of brilliant ideas or luck into being involved in a game changing product launch. Everything beyond that becomes politics.
It depends. If you're able to side-step the middle manager doldrums to Director/VP, and you know how to play the game, the sky's the limit. But IC's are pretty hard capped at L6 short of being involved in the creation of a new business.
That said I totally agree with you overall and think the argument you are responding to is a little silly. You can have an absolutely fantastic career staying IC forever. The fact that you might cap out at “staff/principal/whatever engineer,” a hugely influential and generally very well paid role, should not be viewed as a downside to that track.
Even the CTO can have incredibly senior engineers reporting to them as a consultant of sorts. Sure, the probability of arriving at that role is low, but then so is the probability of becoming CTO.
More importantly, why would one always want to "go beyond" any specific role, assuming the pay is good?
Yes, but you're not managing people. It's a lot of collaboration and leadership, certainly, but not doing any of the HR-adjacent bureaucracy that comes with being management.
Most senior engineers at organizations require a significant amount of coordination and people-skills. If you're not managing a team, you're definitely managing the relationship with your manager and coworkers/project teammates.
Thats totally fine for folks who thrive in this kind of role. However, it does take away the ability to grow your career if you want to keep developing software. So for example, if you program for 20 years, and keep improving during this time, you would expect to be rewarded with some career progression for the progress you've made in years 10 - 20.
But as it stands, these days, if you run into someone who has been programming for 20 years, you can assume their career has mostly stagnated, and might even count them off as a low performer because they failed to grow. So it's almost a self fulfilling prophecy - staying a "true" IC has no growth, and therefore there is an incentive to just sit back and stop growing.
Other managers will always try to change your mind on this. When layoffs come around, they usually are more likely to get laid off and their tech skills are now stale and they have to rely on their 'network' to get another management job if they're lucky. Not a position I want to put myself in.
Separately, there is also the Tech Lead track, where you don’t get reports, but rather final say over an increasingly larger area of influence and drive cross-team/org projects.
I think the term IC is a misnomer and is detrimental to our field. Afterall the code you write, the designs you make etc are part of the larger puzzle which completes the project. No work you do is in isolation.
https://staffeng.com/
As for a technical track, read the stories on staffeng.com. And read between the lines when you’re viewing them. There are plenty of folks with technical track titles who spend most of their working hours in meetings of questionable value. And you will definitely find folks with management track titles that spend more time doing hands on work than their peers with technical track titles.
The ugly option you can try is good old-fashioned sandbagging. Knock out every technical assignment in record time, or quality, or whatever seems to be your leads KPI. Then tank any assignment which seems remotely conducive to management. Bonus points for explicitly indicating a desire to move into management. Your own leadership will think you are so miscalibrated as to believe they are doing everyone a favor by keeping you off the management track.
Edit: I realize you did not explicitly ask how to stay off the management track. Consider the last paragraph as just some idle, slightly sociopathic musing.
And that's presumably why he wants the Metaverse, so he's not just a sharecropper on someone else's digital platform.
Imagine (10 years ago) being able to use an FB version of Siri/Alexa to "connect me to that girl Megan from my 5th grade classroom". Sure sounds compelling.
Instead FB released a half-assed "dailer app/widget" and forgot about it. Today that window of opportunity closed.
if you only look at the tech then yeah it's compelling. but in reality it's creepy and people don't want it.
Because it's really hard to make good hardware cost-effectively. The only companies that have succeeded in the phone market are practiced hardware companies, except for one software company that focused on making a adaptable OS for hardware companies to use.
Why would that have gone any better for them than it went for Amazon and Microsoft?
Microsoft and its phone story is enough to explain why.
Facebook needs a new platform that they control themselves and Phone is D.o.A because they have to compete with other companies (Apple, Google). Nobody wants to have 2 phones and nobody wants yet-another-Android phone "just for Facebook".
I agree that fbs value was/is the social graph. But you’re saying that there was a lack of voice UI? Or lack of a capable mobile experience? I don’t see how any of that could have been more than marginally helpful in reducing the friction of adding a friend on a social network.
No, Facebook tanked their own valuation. They monetized user data without a care for how those users might eventually feel. They became entitled about having that data and the revenue streams attached.
Apple took the opening Facebook left unguarded by realizing people actually do value privacy in their products, and made technical and marketing investments in it.
Yeah, and that's why Apple's ad revenue has grown massively since ATT was introduced. Because Apple care about privacy /s.
If he were making SVPs become ICs, I'd credit this move to him. Otherwise, it's just the big-business org doing big-business things.
When the EM is an IC, what stops them from either interfering with small stuff (I had an EM -- back then we called them "managers" -- stop us for a week trying to determine whether we should use List or Vector in Scala. Nobody was happy) or taking the big interesting problems for themselves?
These SDMs won't be an IC _and_ manager. These SDMs are demoted.
Sure. Many companies do this too. Like Senior Engineer at the level of Engineering Manager and Staff at the level of Senior Engineer Manager.
They don't have direct report and they still write code.
Same payband and leveling but different job function.
But at the end of the day, the ICs still have to "report" to Management: Senior Engineer even if they have same payband and leveling still have to report to an actual Manager.
For the 2nd, I imagine that if you are a manager and an IC on the side, then you don’t have the time to spend on big projects. It’s more likely you’ll be filling in gaps or doing the uninteresting but necessary work. There’s nothing stopping you from attempting to hoard the interesting projects, but then your performance on either role or both will likely suffer. That’s not really a new failure mode - any manager can be bad.
As a manager + IC, you shouldn’t be leading projects, since that’s a useful skill for your reports to develop. I guess there may be exceptions if your team is particularly junior. Ideally, if you are not micromanaging, you only participate on a big project if required or asked, not because you want to. Your main role is the people management side and to help with planning, prioritisation and communication.
Yes, that's part of what I mean (but also: dealing with red tape, bureaucracy, and removing impediments) and no, the amount of time that can be used for this is basically unlimited: it's a full time job. "Small bits on the side" is not a good use of a senior IC, that's for the more junior members of the team.
Also, playing both roles is less than ideal, see: http://blogs.newardassociates.com/blog/2023/player-coach-fal...
> That’s not really a new failure mode - any manager can be bad.
Agreed that any manager can be bad, but I contend that this is a new failure mode driven by two conflicting goals.
I don’t think management is unlimited work, at least not always. There are a fixed set of people on the team doing a fixed number of things who can only grow at a fixed rate. I agree that it could be a full time job or more, but I think that depends on the specifics. Obviously managers shouldn’t be forced to be ICs in all situations. If management is taking up all your time, you can retract from the IC pool. However, I think it’s valuable to consider and push for organisational changes to allow yourself to enter the IC pool again (maybe handing off some responsibilities to a new team etc.).
> failure mode driven by two conflicting goals
Again, I think this strongly depends on how you allocate yourself. There is room for a pre-emptible IC, that is not always available. However, it’s situation dependent whether this is useful or not. The conflicting goals theory only applies if you try and optimise for both. Your IC performance can suffer, whilst still being a net positive, again depending on the specific situation. That’s kinda upto you as a manager to quantify though. The article is more good advice on how not to approach this dual situation. If you know how to prioritise being a manager though, the points don’t apply.
On the flip side, sometimes your management performance HAS to suffer to meet critical deadlines because the entirety of the normal IC pool has other critical deadlines. It’s also upto you to avoid these situations, and if they happen then strongly push back on your leadership to prevent them happening again.
Your primary goal as a manager is to ensure team productivity and deadlines. If you can’t recognise that you are a detriment and step back (or at the very least step back when you get feedback from others who do), then that suggests that other aspects of your management are lacking as well, so it seems like the same failure mode.
The benefit to keeping yourself in the IC pool is that you can keep your skills at least slightly fresh. Even if you are no longer a full senior IC, not having any technical skills means an inability to make technical judgements if required.
All I can say is that in my experience I've only witnessed (and on occasions been, sadly) the dysfunctional kind of EM+IC. I've never witnessed it working well, which is what I'm basing my objections on.
The best managers I had were full-time managers (with an engineering background, which meant they understood the technical constraints); the worst managers I've had were either 100% non-technical, or EM+IC roles which just couldn't keep their paws away from coding.
My 2 cents, anyway.
Well, generally the team would still have an EM, just not that EM.
> When the EM is an IC, what stops them from either interfering with small stuff
What stops any IC doing that?
If there is an EM role, I don't see the problem. I took TFA to mean "become an EM who also codes".
> What stops any IC doing that?
Nothing, but an IC has by definition time to tackle big problems. Also, other ICs are their peers. An EM+IC has no time to tackle big problems -- or if they do, then they are neglecting their management role -- and so by default will tend to focus on nitpicking or small tasks. Tasks that are best done by junior level ICs.
I don't _think_ that's what they're saying. I read it as "we have too many EMs; would some EMs like to un-EM, please?
Meta EMs do people-management only, which neatly side-steps interference on tech issues.
Again, people'd just say "labor" in other contexts. Or maybe "workers". I'm not sure where "IC" came from but I've never seen it outside of tech, and that, mostly online.
In tech, any two given workers are much less likely to be doing the same thing. So they are clearly not just laboring but contributing at some creative and self-management level as well
The point is that the company doesn't need the managers.
Do you talk to family members in Algeria through FB or WhatsApp? WhatsApp would have been just fine if Zuckerberg didn't buy it before US regulators rolled out of bed.
I think it's hard to argue that anyone's life is improved by a company that shows such a lack of respect for its users. We could have social networks that respect us, but Zuckerberg systematically purchased them or squashed them in the cradle.
I'm not trying to troll.
I just genuinely don't understand why someone would consider working there as a positive thing.
So I would like to know!
But I have no way to figure it out as I know zero people who work there, and talking to a human who works at these companies is impossible because their websites are geared towards not allowing you to talk to them.
So now that I just saw someone in the wild to ask, I figured I should use the opportunity to figure something out which I absolutely do not understand.
> There are only a few places where if you implemented, for example, an effort to reduce "body dysmorphic disorder", it could instantly improve the lives of 3 billion users worldwide. Meta is one of those places.
It surely is a zero-sum to fix the problem which your company has created in the first place???
What about people working on WhatsApp, or infra, or people working at FAIR or people building React, etc? The list goes on.
Meta creates a shit ton of positive impact which is not at all related to "millions of teenagers with body dysmorphic disorder thanks to Instagram".
1. https://www.amnesty.org/en/latest/news/2022/09/myanmar-faceb...
Oddly enough, this didn't get reported on very much by the media.
There are other js frameworks.
"Meta" does not do any good that comes close to outweighing all the bad they do.
No other app has gone to such extraordinary lengths to make sure you can only view a piece of content once, and then hide it from you forever after.
Years ago, I met someone that boasted about doing auto-play for videos in your feed so that get sucked into related video after related video. He was particularly proud of implementing a feature (he worked it out with the PM) where you could only delete one video at a time from your history instead of in batch. The goal was to make it harder to purge your data and frustrate the customer so they give up. Ultimately they wanted more data on you so that they could further "optimize" the app to better suit/manipulate you. Pretty sure this is what they mean by their company core value of "focus on long-term impact."
In fact, the same research that likely was used to see such an opinion for you about Instagram in fact showed that it was more likely to improve stuck disorders than to make them worse.
A surprising number of teams are NOT involved in things like news feed, story ranking, "engagement", etc. Some teams, like my own, were building foundational technology for things like AR/VR, wearable devices, mapping & navigation, etc. A concrete example of "impactful" work done by such teams was just posted on LinkedIn, which is a focus on building maps geared towards pedestrians walking around, not cars driving. This is a building block for eventual AR use cases, among other things. The team building this then enables other teams up the food chain to use this in building what eventually becomes part of an end-user product.
I suppose it's a matter of weighing "a set of many small utilities which make life a bit easier for N people" against "two big dangerous social networks which make life a lot harder for M people". Because the money from the former helps the latter as well.
How you decide to judge this is up to you :)
I mean, if there are lots of managers at Meta who only have 4-5 direct reports, you could see this scaling decently well -- turn two teams into one, and that's not so bad.
But I don't think one person can constructively manage more than about 20 engineers at the absolute maximum.
"running teams" is literally management
Some management is bullshit, but literally "run teams" is the important part. But if you get big enough, you do wind up with departments. It grows like a fractal.
Think of it as trying to run a big country with direct democracy. Can it be done? Maybe. But there are good reasons why democracies become indirect after a certain scale.
For example, Pirate ships ran with a Battle Commander, Accountant and Crew.
Please note I'm not saying you can't be overprovisioned in managers. I'm replying to the parent comment that sees no need for managers.
AFIACT, it's intended to distinguish between employees who manage people and those who don't. I.e. "the set of employees is the set of managers plus the set of individual contributors."
The growing concept of "IC" goes hand in hand with the increased focus on "leveling" for engineers, as well as the rise of delegating all product related decisions to the rising class of PMs. All of these create a structure in which every team, even across companies, starts to look more and more the same and any individual can be trivially swapped out for another with the same role and level.
In the early days of the startup boom, ~2008, engineers at startups had a lot more control over the product process. Typical startups where a CEO with some general vision of the product and a knowledge of fundraising and a technical cofounder who would handle the real implementation of the product. CEO would make sure the company was health, CTO/tech cofounder would make sure the product was built.
But this lead to a class of labor that was a bit too powerful. As you likely remember engineers used to contribute a lot more than purely churning through tickets.
Today you can think of IC as a prefix to a more complicated part number: IC-SRE-4, IC-DEVOPS-2, IC-DS-6. Then you just have to find someone claiming to be the part and send them through a leetcode grinder to verify the build quality, then plug them in and go!
Can you please explain what's that offensive about calling somebody an Individual Contributor?
It's a little bit of weird jargon, but it acknowledges 2 important things (they're a person, and they're actually working) which is infinitely more respectful to the people that actually do the work than "Resource" that also gets used.
To me, using the word "Resource" to refer to people is by far the most dehumanizing term I've seen seriously used in an office.
It's quite individualistic. Much like "talent" which is the latest attempt to imply people are resources without using the word resources.
> It's quite individualistic.
A team always exists, but humans are not exactly the Borg.
I think it's ok to recognize that individuals with differences exist.
Feel free to dislike the term individual contributor if you want to though. That's your right as an individual contributor to HackerNews.
FWIW, I've heard and used it in FAANG for well over a decade.
Usually I see HN comments using "IC" followed by someone asking what "IC" stands for. Makes a change to see someone asking for an expansion of the expansion :)
I'd like to see more people-managers who aren't also product-managers and tech-leads: people whose job is to manage people, not work on the technical side of what the managed people work on. Some people are really good at this and should focus on it, to the exclusion of coding.
I’ve worked with managers like this but they were pretty rare ime. Most of the time it’s either a product person or someone who is subpar engineer grabbing the power seat bc that’s the only way they ever going to have any say in anything
It because a theory of mine that a large part of my job function was to simultaneously water down accountability from above, while adding enough complexity to the layers below me to discourage them from changing the status quo.
The double edged sword being, without that authority, that same power structure is forced on me, and now I’m more aware of it.
If you're closer to the doing, you are more isolated from the companyspeak nonsense. If you are in the upper part of the food chain, you get to enjoy more influence, freedom, a better risk/reward tradeoff, with costs you mention.
In the middle you're kind of screwed from both ends.
The other thing was demonization of front line managers. There was always a terrible (there are definitely terrible traits) managers but never terrible "leaders". Even worse was you'd see articles by hr "influencers" expounding this. Where are the same hr loud speakers now that "leadership" is the one inflicting these layoffs and ridiculous policies?
Is this actually the expectation at the places you work?
I have absolubtely had managers that did an excellent job of making us feel like we were in it together. In fact I'd say its one of the key skills of being a manager at all?
Can you imagine a manager saying, "I don't agree with these decisions, but you need to do A, B, C." This might be being frank and open with your reports, but at the same time you reduce their motivation. And if top management learns about this, they won't be happy.
So yes, there is such unspoken pressure to at least not to distance oneself from the things you ask others to do, whether they come from you or from your boss.
Some of my best managers, on well-regarded teams, have done exactly that. Those managers are doing me a favour by flagging that it's a waste of my time, emotional energy, and political capital to argue with decisions that neither they nor I can affect, and that it will be better if we just get on with it.
Wrapping it in pink wrapping paper fools no one but kills personal credibility, which is the most important asset a manager has.
Top management often does not give a shit if people are happy about the thing (who is happy about layoffs?), just that it gets done satisfactorily. So yeah, sometimes I tell my team “this sucks but just get it done and then we can get back to the interesting work.”
"Hello gents, we have our new orders, we're going to go over the top tomorrow at 8am and try and take the village one mile down the road, however, I think this is a horrible idea and you're all probably going to die."
Even if you really believe this is the case, it's a bad idea to tell your men as it means the plan (which is going to happen anyway) is even LESS likely to succeed. That is, if you can make your men believe the plan is genius and they're going to destroy the enemy easily, it may give them more confidence and leave more of them alive at the end of it.
https://www.americanrhetoric.com/MovieSpeeches/moviespeechgl...
By explaining your reasoning in every situation you can will build trust, so that on the rare occasion that you need them to act without sharing, they will trust you enough to do so. For example, when in an execution environment where response time matters.
And in practice, this is how good commanders I've worked with have operated. And this is explicitly a principle of the US Army, by understanding the objective and it's purpose units are able to continue acting to fulfill their objectives even if they are cut off.
The upside of explaining whenever you can let them build a mental model to know how you would likely handle an unexpected situation, allowing them to act in your absence.
It is unusual to have a team emotionally mature enough to handle actual transparency. You only have to read HN to know people live with extreme cognitive dissonance between wanting their high salaries and hating the business practices that enable them.
My experience has always been that certain employees get marked as "adults in the room" and are given real transparency in 1:1s.
But understanding the purpose and why of a decision/plan is only a small piece of full transparency. And is always achievable. This is the minimal amount I consider functional. Less than this is dysfunctional.
The reset is extremely rare for teams (I’ve only had this on a team once and it was magical), but happens regularly individually 1-1.
Much easier to see through that bullshit and be cynical.
The role doesn't change though. It has been like that forever.
This is another part of Management (whether you like it or not). Management should be seen as a cohesive "Leadership" unit because if the leaders aren't on the same page, what good are them?
The other thing about Management/Leadership is that they should be able to relay the message in the right format and at the right level for their direct reports. C-level typically have OKR/Objective in 3-5 bullet points (the bigger the company, the more bullet points) and it's the VP and Dir jobs to break these individual points to high-level goals for their Organizations. It is the Manager's job to distill it even further to their level + their direct reports.
It's one way to keep ICs on the same frequency with leadership and to execute for a common goal.
Most ICs don't want to attend meetings, don't want to hear "high-level goals", and more importantly, don't have the skill to consume those high-level goals at their level. They need help from various layers of leaderships. Sure, there are those exceptional ICs that wouldn't mind to be involved at that level and understood the social/human aspect part of the work but let's be frank here: majority of ICs just want to bang keyboard, produce clean code, and marvel at the end results (ignoring everything in between).
Not that I expect them to do anything with it…
Not kidding, I nearly cried with happiness moving away from SM and into a tech position again. I was GIVEN work to do. I had NO responsibilities for others. Moreover, I was DISCOURAGED from attending unnecessary meetings. I arranged no meetings! Not one!
Went from 7 direct reports to zero. No more approving holiday requests. No more performance reviews. No more management town-halls. No more arguing strategy with anyone. It was brilliant. 'Please write a procedure that does X. Return it by Thursday.' 'Please optimise this statement that hangs during the overnight run'. Yes, absolutely, more of that please.
More money too, oddly.
I average less than an hour and a half of meetings per week! I have so much more time in my life for the things I love, it’s crazy.
Why could you not say "I disagree with X, Y, and Z, but I am going to follow through with it because 1, 2, and 3"?
This is a normal thing. There's a normal fluidity based on what someone wants to do, IC or manager. There isn't really a pay difference.
Being a Meta manager is a lot of work, especially the formality, structure, and data-drivenness of performance reviews.
Almost anyone can move back and forth if they want and have some interest.
The CEO rotated through positions, spending several months working in customer service, inventory, accounting, and even working directly on the production line. He mainly put himself on whichever team was most short-handed, although it was more to learn firsthand what their challenges were, and how the company could allocate resources to solve them. Fortunately he was a multitalented guy who could pick up those roles productively, and also humble and down-to-earth enough to not intimidate his colleagues too much when he took over the neighboring desk.
Same for TPMs. They can be ICs or managing other TPMs.
the managers who want to write a lot of code usually are so focused on their contributions they fail their other responsibilities.
The ones who are trying to set product direction are usually harmful, too.
The managers I've had the best experience with are the ones who focus on helping their ICs navigate the larger organization, dealing with human issues, and helping the ICs understand organizational priorities, and evaluate risks.
Don't ask me why in heavens that term makes any sense outside one that is myopic or only works with extremely fresh out of school junior engineers and unskilled workers.
Edit: P.S. Not sure why a couple of people decided to downvote this opinion.
Also to other commenters: it sounds to me less as a be a team player title (like the soldier one suggested) and more like an isolated resource that makes interchangeable contributions.
Anyways, I think that there is a distinction between "(Team) Lead" and Manager with the Team Lead usually classified as an IC says everything for most organizational approaches.
I agree more with the Meta take here.
> so i guess that managers are not individuals and don't contribute?
> i have never, ever come across a programmer working on a system of any complexity that did not depend on contributions from other programmers.
No one said non-ICs aren't individuals, and no one said they don't contribute. No one said that ICs don't work with others or depend on others.
What has been said, several times, is that their contributions (i.e. the code they produce, artifacts they create, etc) are largely individual contributions. They are the ones creating the thing, and are not responsible for others.
This gets a bit murky as you move up the IC chain, in that your contributions become less tangible and are in part measured on how you lead others and make those around you more efficient. But your performance is still largely judged on what you produced.
Very common phrase in the tech industry.
Are you US based? Beginning my career in the mid 00s I was exposed to "IC" pretty much day 1 starting at Microsoft.
Other people around me in adjacent sectors also use the phrase to refer to non-managers, it is pretty common daily parlance, I am 99% sure I can ask any of my knowledge worker friends and they'll know what I am talking about.
Google trends show "individual contributor" has been a pretty popular phrase since at least 2011.
is "knowledge workers" still a thing? it was meaningless when it was introduced in the 60s, even more so now.
another bubble creature, i guess.
Every country, and even different regions of a country, has linguistic differences. This is true even if all the countries being talked about have the same national language.
For example, nobody in the US tech sector is going to know what a Boffin is unless they read The Register.
Even on the west coast of the US, vocabulary is different between California and the Pacific Northwest, although things started to merge together when the Silicon Valley based tech companies began opening offices up in Seattle.
Yes, everyone knows there are two tech giants based in Seattle. What this person was saying is that other large companies have also opened/grown Seattle offices in the past decade and vice versa, which has caused usage of corporate vocabulary to merge.
Maybe you should reflect on the fact that you don't seem to understand what people in this thread are talking about and stop acting like you do.
The labor group that requires significant creativity and autonomy to be effective. The artifacts they create are a minority of the value they create.
Mostly they became a real thing because traditional management techniques fail to work well with knowledge workers.
I've been in the industry since 1998. The first time I saw it was on HN a few years ago (maybe 3 or 4).
Hah!
I would just love to see that thread - may it is also filled with "What's an IC?" :-)
There’s many types of “managers” who are actually individual contributors (eg, sysadmin, project admin).
When you get into principal engineer and architect titles, sometimes those positions manage people and sometimes they don’t.
I think it also highlights how one version of contributor isn’t better than the others. Some people only produce value by being part of a team, some produce value by managing, and some produce value direct from themselves.
zab zonk
the resource
zab zonk
individual contributor
jesus wept
Strictly speaking, the roles of Engineer Manager and IC are incompatible; you cannot want to manage people and at the same time want to stay out of it. So in this particular context, "EM+IC" is a misnomer for "EMs who also need to be able handle tech/coding tasks themselves".
I dunno if it's just me, but it seems like the term came out of nowhere just a couple years ago.
PS: are you by any chance the same Izkata as the one in scifi.se?
Took a bit longer to realize they meant individual contributor.
Mine was "integrated circuit" which was like a really dystopian version of "human resources".
Principal engineer, architect, etc all fall into the IC career path, while, manager, director, VP of eng, etc all fall into the management track.
From what I remember, it wasn’t intended as a long-term position, but was used in stop-gap circumstances (manager quits, tech lead temporarily takes on some people management duties) or for when an engineer was considering transitioning to the management track.
TLMs still have individual contributor responsibilities. M1s don't. The reason for that is generally that (especially junior) ICs aren't likely to push back against poor technical decisions knowing that the person they're pushing back against is also in charge of their rating. This feels quite fair based on my experience and as such I'm quite skeptical about TLMs in general.
Not true, TLMs can be D1+ level too at FB/Meta. Higher level TLMs more often than not tend to occur in more research-oriented organizations though (where the TLM is effectively a "principal investigator" type for some research area).
I often make this mistake because English is not my first language, and I confuse "engineer" with "engineering": in both cases it sounds to me "a manager who manages engineers", not "a manager who is an engineer him/herself". Kind of like a "Product Manager" is a manager who manages the product, not a manager who is a product!
edit to add "in my experiences" I have also seen good evidence via HN that not all management/admin is as dilbert like as I have seen.
As a manager, I have to deal with so much random bullshit. I don't mind it, but it's extremely difficult to manage that bullshit alongside code and sprint commitments. "I couldn't deliver" is remembered far more clearly than "I couldn't deliver because I was helping the team with X other thing that was far more important.".
Usually, when a manager/director/etc decides to write a lot of code, the result is barrages of rushed pull requests made between meetings. You will be lucky if the code in any of those PRs was actually run, and you can forget about enforcing test discipline, so you have to scrutinize them much more carefully and clean up when they get merged without incorporating your suggestions.
When I had a single digit number of developers on my team, writing code was still possible. When I started closing in on double digits, I realized that I had so many other things to do that, at best, I was only going to have a few scattered 30 minute or 1 hour blocks each day to write code. Also, a lot of my job is to handle the unknowns that come up, so I also couldn't really commit to any hard deadlines.
That means, best case scenario, I could only pick up work that wasn't high priority and that didn't require long periods of uninterrupted time. I still love writing code, but my philosophy has always been to focus on the things that only I can do. Low complexity projects that no one is waiting for can be done by just about anyone. My "staying in touch with the code" time is better spent doing PR reviews or reviewing design docs.
The bad managers were always working hard to schedule more meetings, force extra process into every step of our work, make decisions about how we did our work, and to change our priorities to work on their pet projects.
The bad managers occupied 10X more of my time than the good managers. It only took one or two bad managers to completely derail productivity of an entire group.
Yep, that's familiar. Good "people managers" have always been the ones that removed obstacles, and didn't become one themselves.
Thats literally the point. Its totally fucking batshit that somewhere like meta still uses spreadsheet to plan. This is why properly trained people should be doing management.
Project management at scale is not something you "dip into" its a full time job to project manage and people manage. Its not something most ICs should be doing.
A <Edit> consultant[1]</Edit> surgeon leads a team, but they don't manage the timesheets of the juniors, nurses and assistants. Meta very much expects that a consultant surgeon not only does surgery, but fills rostas, recruits nurses, does some marketing and works on the legal policy for negligence.
The issue at meta is that with the growth there is no "leadership". What is a lowly IC supposed to work on? "create consensus" and "drive from the bottoms up". That doesn't work when you have 11 layers of management, all pissing about talking about impact, but not actually driving projects.
> I would think that the role of an "Engineering Manager" or "Tech Lead" or "Team Lead" etc. should all be pretty interchangeable, or at least have very high overlap.
You should try it. Its pretty clear you've not managed people at any level of scale or formality. Not everything is code, babes.
(No. I'm not a manager at meta, thank fuck, it sounds pretty shitty.)
[1]https://www.rcseng.ac.uk/careers-in-surgery/surgical-care-te...
edit I meant uk consultant surgeon, thank you to commentor for pointing out my mistake
[0] https://www.betterteam.com/chief-surgeon-job-description
But it is a bad analogy, as you've implied. What I was trying to get across is managers should be specialised, they should be someone who might or might not have been a programmer, but is now specifically managing people, or projects.
Managers who code, do exist, as to engineers who manage. But its better at large companies to have specialists to manage projects and people. With support, training and performance management, you tend to get a better outcome.
Medicine is strange in many ways, but I think this isn’t a bad practice.
I’ve worked for non-dev managers and sometimes they are good. But I prefer to work for someone who at least once was a dev as I think they understand better what is possible and how to coordinate and lead.
When I managed teams I always tried to do something useful in the codebase. I don’t think it is possible to manage well and work deeply enough to make great software. But it’s possible to at least be able to do my own builds and at least test out different techniques.
Studies have shown time and again that small autonomous teams is the most optimal setup for software development. Having a layer of Director, SVP and VPs on top of EMs is just Pournell's Iron Law manifesting itself.
1: https://www.jerrypournelle.com/reports/jerryp/iron.html
"Why are we doing this" and "how does it align with the business's goals" and more pointedly "what are we not doing so we can do this instead" and "is that the right trade-off" are all questions even very technically gifted engineers seem to have a really hard time answering.
Every single re-org I've been involved in was bureaucratic mess to give a manager a higher salary. There was no explicit reason why we needed to re-org, and no org change ever made a difference in terms of productivity. Our individual teams still operated the same.
There is no way you can manage 10 engineers and still have good technical knowledge of what they do and provide directions.
Also, I want to add that the team with the manager of 4 engineers, he provided no technical direction. That was my job as the "tech lead."
In those environments, all the technical work and decisions are delegated to a tech lead / staff / principal eng. The "dev manager" is there for people management and high level sprint planning. Planning can be done with very little technical knowledge since the team itself does the sizing and scoping.
Obviously not every company is the same, but that was my experience at a mid-size SV tech company.
I understood the role of managers after I joined a chaotic startup which hired a bunch of people but didn't think of management. It was a complete mess. Senior engineers didn't want to manage, or didn't know how to do it. And good managers are very hard to find.
If you are a people person and love helping people so much, go work as a social worker, no?
Managers are employees same as ICs. An IC can have more impact than a manager.
http://programming-motherfucker.com/
maybe the problem you are trying to solve isn't code.
> ICs do not need managers, managers need ICs.
Given the level of infantilisation at meta, and big tech in general, I think this is clearly not the case. "self management" (ie bottoms up management) stopped working at meta many many years ago.
> Some managers have negative productivity.
So do a lot of ICs "I'm rewriting x in NEW_LANGUAGE because its faster" & "just read the code, that's where all the answers are" & "no you're doing it wrong, just re-write this major system to make it do something completely different because I've not taken the time to listen to your problem" Meta is a massive pile of "not invented here" tech debt, that was half arsed for impacc and then abandoned. Most of that is IC ill disciplined "oh but I'm BORED I'm going to make a new x".
Don't get me wrong. I've had some complete bellends of managers, but that's not a function of them being a manager, that's a function of no training and ineffective performance management.
Writing code is easy,
Writing good code is not so easy
Reusing other people's code is hard
Making an entire company reuse code is fucking difficult.
Getting prima-donnas to document code so that other people can use it quickly, super fucking difficult.
Managing programmers so they don't start gnawing at the furniture, rebuild everything every six months, wank over the interns and getting them produce a viable product, one that they can't/don't/wont use is top level hard. It's something I don't want to do.
If you think developers are prima donnas wait until you hear about managers. Compared to developers, many of them fit much more into the prima donna description.
Most managers don't document anything and when they do, it is of low quality and goes unmaintained quickly.
Most managers out there are redundant and have no idea about what leadership is. They just get an orgasm each time they say no and conflate that with being a true leader.
The reason hackathons produce amazing results is because it is what happens when managers get out of the way for 1 day: improvement driven by builders that care about the product, not office politics.
https://youtu.be/fj0hpsJvrko
You're assuming that I've never really worked anywhere with managers, good or otherwise.
> Most managers don't document anything
yup, and they are insufferable dicks for not doing it. But, in big companies you need to have presence, so managers that are successful tend to have a documented paper trail of "their" successes. Whether its useful documentation is very much another matter.
> Most managers out there are redundant and have no idea about what leadership is.
There are two issues here, lets do leadership first. Yes, leadership is not taught properly, and that annoys me greatly. Leadership can be taught, and its not to challenging to do. But on the flip side, leadership isn't just about keeping people happy, its about taking hard decisions and getting people to understand what they need to do.
Again, there are lots of bad examples out there.
Now as for redundant, if that was really the case, and that most manager are redundant, then surely they are ripe for "cost savings"? After all capitalism is mostly ruthless when it comes to staff costs.
The problem is that good managers increase productivity. However what "good" is can depend on where you sit on the hierarchy. If your CEO/CTO only talks to managers, then your manager controls the information flow. this is a company culture thing, and is closely coupled to how managers are expected react.
> The reason hackathons produce amazing results is because[..]
...of exposure bias. There are loads of ideas in hackathons, and lots of them are shite. But! the ones you remember are good, thus there appears to be a great signal to noise ratio. I've organised and participated in loads, they are good fun. But you can't run a company permanently in hackathon mode.
Wow. And these "good" managers coding, how do they meaningfully pursue strategical tasks that benefit the team and organization? Do they have time for these, 1:1s, team meetings, unblocking the blocked, translating the untranslated, and generally, um, managing?
Or do they work 80 hours?
Private -> Team Leader -> Squad Leader -> Platoon Leader -> Company Commander -> Battalion Commander -> Brigade Commander -> Division Commander -> Corps Commander -> Combatant Commander -> SECDEF -> POTUS
Of course we also pad that with a lot of senior enlisted advisors, executive officers, chiefs-of-staff, deputy commanders, etc. who can effectively be additional buffers between each echelon.
So, no, you haven't seen 12? Just imagined them?
That's only 7, but some links repeat. For example, I have seen Sr Manager report to another Sr Manager. Likewise, a VP report to another VP, and a Director report to another one.
No one cares about your job experience (all those painful internal tools you now have to use to manage and report on your team) so you're just expected to grit through all the broken processes and inefficiencies (kiss your evenings and Sunday afternoons goodbye), and you are mostly powerless, particularly in orgs with centrally managed budgets.
- Getting your skills back means getting hired to do engineering in the absence of sharp skills. I had to fake-it-to-make-it for a little while.
- Moving from manager to IC is a risky story on your resume, where you want to show continuous growth. You can't take just any IC role. In some way it has to show a positive career trajectory.
Now that I'm over the hump things are great. I love engineering and am glad to do it all day.
Ask yourself:
Do you like being in charge of people, or do you like being in charge of the codebase?
Do you like solving your problems by asking people to do specific tasks for you, or would you rather solve a problem yourself?
Would you rather take a breadth first depth first approach to you work?
Are you good at planning, logistics, and deadlines, or are you more comfortable with going with the flow?