Meta to ask many managers to become individual contributors or leave
bloomberg.com
bloomberg.com
I used to despise managers, until I met two really good ones. This is after working with hundreds of them as a consultant. Actual, natural-born managers are such an incredibly rare species that you can go a long time without seeing any in the wild. It's basically the equivalent of the legendary 10x programmer — you hear about them, but it's rare to actually meet one, and there are sure a lot more people claiming to be one than who actually are.
My theory is that there are a set number of great managers in the world, and that number doesn't scale with the number of people who take on the role. They're just out there, being awesome, while a bunch of pretty lousy ones share their job title.
I am a massive sufferer of imposter syndrome, I do my best to help everyone and smooth over things and set direction in a clear way with as much freedom in execution as possible.
but i am always second guessing myself. I know I am almost certainly a middling manager (if not a bad one), but I would like to improve.
Not because I love doing it, but because I don't trust that anyone else in my position (or who would take my position) actually wants to improve.
They believe that supporting and developing their people is their main job. Execution is just a prerequisite to being able to do the rest.
I've never encountered a servant leadership styled EM that is not also a good IC.
The only thing I can think of is MBA disease. But that’s rent seeking not productive management techniques.
1. Psychological security.
2. Crystal Clear targets, planning, goals, written down. To paraphrase this, a top manager will write their ICs an 8-12 week JIRA backlog. Obviously, these goals will iterate. However, the ironclad clarity is essential.
3. Positive, effective, coaching and feedback at the principle skill the IC performs. Aka, coding.
4. Lead by example. Conspicuous, hard, effort, devoting majority of time and energy to managing down and shielding.
The issue is simple. All of the above requires sweat from the manager.
Manager's are lazy, and nobody is watching them manage their IC's.
but, I think the answer depends. If you are a really strong individual contributor, I presume getting an IC promotion is easier. If you are just decent, getting an IC7+ promotion seems incredibly challenging because IC7 requires an very high level of competence. If you are just decent as a manager, you can get luckier.
M1 corresponds to the same pay band as IC6 and M2 corresponds to IC7. D1 corresponds to IC8. (By level 6, I am referring to IC6 / M1.)
So for people with an innate need to join in the steering of the ship, there’s only one career path.
I hear senior VPs like Craig Federighi, Jeff Dean, and others, still write code (maybe 1 day a week but still), but also call the big shots
(and Craig doesn't waste his time)
It's not a waste of time if it makes them more effective at making decisions, gives them ideas, or keeps them abreast of what is actually going on.
What I meant what that there’s literal zero way someone can be an SVP and still perform any actual IC work.
Not really. Some managers are perfectly willing to include IC's in this if they don't want to be/are not suitable as people-managers.
There are ways to formalize this, like creating roles for tech-leads, technical project management, enterprise architects (and a lot of others, in non-tech industries).
For managers who have their strongest talents in the social/organizational domain, this can be a win-win, if their ego allows it. In some cases, nearly all the technical and strategic work can be done by the IC, while the manager can focus on ensuring funding and support for these strategies within the organization, as well resource management and HR related work.
Of course, for every IC that has the talents and interests that make them suitable for such influence, there may be 3-4 that want that power, but do not have the abilities, initiative, flexibility or willingness to put enough effort into it to make it worthwhile for the manager.
And from the other perspective. If you're such an employee, it may be that you need to look around a bit to find a team lead by this kind of manager. It may well be that only 10-20% will be into this kind of cooperation with a subordinate.
But if you do find the right manager to support in this way, and actually do contribute to his/her getting promoted more quickly, you may have a powerful ally among the higher-ups (or even in some cases be pulled along, and given some direct-report role directly under him/her).
Only at very small companies do I get to cross these streams.
I think this could have great benefits. If a manager's job salary is directly capped to the average of their ICs, then it's their benefit to make the best engineers and show that these engineers deserve an increase in salary - ergo the manager's salary is increased. At the same time, no one will be rushing to management just to get a salary bump.
If a company unilaterally cuts manager pay, they presumably won't get great managers, or at least not good managers who also want to be paid fairly.
It also means managers will only want to manage more senior IC's, so as to benefit from the higher salary, while it's the junior IC's who need more capable management.
I don't know how you'd ever make that change to a company structure though. The turkeys would have to vote for christmas.
Is there any reason to believe this? Other than just assuming that whatever companies do is optimal for their profits?
I suppose it’s possible there!s some totally novel idea nobody has tried but which would be hugely successful and revolutionize corporate practices. But I’m very skeptical there is an objectively more successful model just waiting for some company to stumble on it.
I don't remember the details but do remember there being certain "heavy weights" that didn't have anyone under them.
If you switch to becoming a manager, your salary increases a lot and you have many more opportunities for promotion. So a lot of engineers hit senior and say "screw that, I can just be a manager" which is a much easier path to high salary.
It's very common and we need to incentivize people to stay as ICs.
Feels like this is generally true in the past few years where org sizes have ballooned.
Is this still true today where hiring freeze and layoffs rule most of these companies? Is the reverse happening?
Tried management for a few years, dealing with the prima donnas and the deadweight on the team burned me out. Wasn’t getting paid more than I was as an IC, so it was not worth it for me by a long shot. As an IC I just have my own problems to worry about.
The broad version, that managers just don't contribute as much as the IC's they manage, doesn't hold much water in general - but may in a dysfunctional organization.
I really think we need more “reluctant leaders”: people who are good at leadership but don’t want to lead, and yet can be relied upon to lead because of their sense of duty, especially their duty to the team. People who say, shit, I really don’t want to do this but damnit if I don’t step up, this will be a failure.
If you pay them less than the people they are managing, they will not tend to do take the job.
So, paying managers less may weed out people on an ego trip, in theory.
I've been blessed with generally good managers, but they've all worked way more and way harder than me for less pay and it's honestly made me feel pretty awful for them.
And company processes should be engineered so that a bad/ineffectual manager can't break them, with everything that can be devolved to the team itself.
And hiring should be done on the basis that a new employee will likely be a manager at some point.
The best managers I've had were all reluctant, so selecting against people who want to be managers seems like a great idea.
Please, no. A good middle manager is a shit umbrella, a bad one is a shit funnel.
Most of the ICs I've worked with would not make good managers. Not because they are bad people, but because they don't currently have the skillset to manage.
I'd rather not have them spend 6 months developing their skills by managing me, only to be replaced by the next person in line.
The majority of these tasks could be devolved to the team itself, if an organization wanted to.
Without that political pressure, I'd trust even the worst IC on my team to serve in a manager role, because the consequences of them doing a poor job would be small.
Maybe the people producing the shit need to go too.
His manager, the various proxies for the customers, events outside of anyone's control.
> What productive purpose are those people serving if your manager’s job is effectively to work against them?
Everyone with power in a modern corporation is looking out for their agenda, and their interests rarely align with their peers, and even less rarely with the line people. Think of directors pursuing weird-ass pet projects, think of product managers that want to devote 0% effort on stability and 100% on features, think of some other org dumping work that they ought to be doing onto you.
Also, all of these problems exist on a much smaller, less dramatic scale, on a day-to-day in every firm that does anything of note. Everyone wants their asks done today, and its the manager's job to keep all the people asking for stuff playing by the rules, and reasonably happy, and civil.
They aren't bad people, they are just being rewarded for meeting particular goals, and they are working towards them.
> Maybe the people producing the shit need to go too.
Maybe, but whether they will or not is not under the control of anyone in the trenches. The modern corporation is an authoritarian institution, and if you don't have the ear of a decision-maker, you can't exactly get someone else fired for being bad at their job. Especially when their job is telling you what to do.
I've known a few of these. Power and money, usually. Mainly because they were born with money, and think they deserve as much or more than their parents accumulated.
I wouldn't say they're the most toxic people I know, but they're in about the 85th percentile.
I have been a senior/principal engineer, as well as a director/senior director. The fact is that being a manager or director is just fundamentally a much harder job than being an IC. It's not that it's inherently more difficult, it's just that the day-to-day is much more of a grind than being an IC. For people wondering why engineering interviews can be so obscure/difficult, it's often because the cost of a bad hire can be catastrophic to a manager. I had a great team of about 30 people, except for 1 person who just couldn't get along with others. I spent about 80% of my energy on that person, and it sucked.
So for people wondering why managers get paid more, it's just that it's a shittier job that fewer people want to do than program.
If I can be excused to ramble a bit...
I think the job is optimization? If so the hypothetical perfect manager would get it right really fast and have nothing to do but wait for the next dumpster fire that might never happen or some micro optimization that isn't worth much.
Measuring performance (at least in real time) seems hard if not impossible?
With a cashier it is easy, if they handle 100 products per minute, 6000 per hour, they get 12 per hour or 0.2 cents per product handled, on the average product it is a perceptional difference of zero. I, as the customer buying 100 products, don't care if I pay 20 cents or 2 euro.
I've had a hundred such jobs, did the math on many, it was spectacularly hilarious. Best one was 5 factory workers making half a million boxes of cookies in a 5 hour shift for 35 euro/day. They could easily pay 1000 euro/day, the customer wouldn't even notice it.
In stead it is really hard for them now, they cant find employees. They are far behind on schedule. Existing employees are made to work even harder.
Being unable to afford to pay more is actually not how it works. You add up what it costs to deliver a service or a product and then you conclude if its a viable business model.
It is not that the rent is to dmn high, parts or ingredients are to expensive, employees are unwilling to work for peanuts etc. There is no limit on how much a janitor costs. The market sets it, employees and employers are just dragged along - kicking and screaming if need be.
If we continue the story and say the employees want to much money we might end up back at their rent being to dmn high.
But surely no one would continue that story to the point where you cant find employees because the cookies got 1 cent more expensive?
I get 2 letters every year, one says my rent goes up by 5%, the other says my salary goes up by 1%. Both talk similarly about inflation. It's quite comical.
People who are lower down on the empathy scale don't have that problem and the fact that this generally makes them worse at the job doesn't reduce their pay.
I also find it far more plausible that managers are paid more because of the default fiefdom hierarchy.
You’re claiming that 80% of your time, 80% of your substantial pay, was spent managing the fallout of a single employee on a team of 30. It’s astonishingly inefficient and wasteful.
And while you’re emblematic of this behavior, it’s widespread in the tech industry. The vast majority of management is terrified of any sort of real conflict or intervention, so they become ineffectual and useless.
No shortage of kids at Stanford or MIT dreaming of GOOG bucks and name recognition, and willing to work 80 hour weeks. Hell, even with AMZN's terrible reputation I still know people @ UW Seattle chomping at the bit to get in.
Not hard to fire when it's easy to replace with solid talent. Much harder for someone like P&G or Clorox or Amtrak -- they either contract out or else get what they get.
Worse, they make the organization toxic for everybody else.
I've come to believe the most important job of a manager is to quickly identify these people and either fire them or neutralize them (i.e. put them in a closet and assign them a meaningless task).
This requires a culture shift in most organizations to understand that toxic people (e.g. bullies, narcissists, and those with other serious personality disorders) have an outsize negative impact on productivity and profits and can kill the company if you don't get rid of them quickly.
There's definitely folks that take all they can get, scream about unnecessary things, and are just general drama, but overall are basically an underperforming IC. (I've even seen one become "best friends" with a director which caused all sorts of chaos and disorganization in the org below them, with the director blissfully unaware because the toxic person was giving side-channel status update to the director outside of the org hierarchy.)
Neutralizing them by giving them unimportant tasks often enables them to be louder elsewhere.
There's also people who are loud because they're trying to make the company better. They'll make you uncomfortable as a manager, and they'll make you have uncomfortable conversations with your leadership. They're...probably the ones to listen to.
True leadership is knowing who to keep close—even if uncomfortable—and who to rapidly manage out.
A good manager can root cause these issues and then determine if the resolution is workable in a reasonable timeframe. A great manager keeps this in mind while coordinating all activities and requires their direct reports to assist them in doing this.
Finally, great leaders are sometimes not great managers. Another note - even managers can shift from good/great/bad over time.
I’d note shittiness of the job is not a compensation decision factor. Otherwise slaughterhouse employees and social workers would be paid better than any of us.
I beleive managers in a situation like this think that layoffs is a kind of God's grace.
Smart companies have been doing things like this for decades. The first company I worked for 20 years ago had distinct tracks for management and engineering staff once people got to a certain level.
1. All people who really want to be managers are good managers
Or even
2. Best managers really want to be managers
To put it another way, a lot of people would rather be IC than managers. Not all of those people would be bad managers. In fact some of those might be the best managers.
Or to put it yet another way. Everybody wants to tinker. Managing is a pain. And the higher up, the fewer of the sane people would want it :-)
But ICs making more than managers is not what should be normalized; building teams with structures that optimize for performance rather than "management by spreadsheet" will get you further than just one dimensional rules about comp, especially in larger orgs where the comp tiers are deep.
Reminds me of baseball. Many of the best managers weren't the best when they were players. Some never even made it to the major leagues. But as a manager/coach they're incredibly well-regarded.
Those well-regarded managers are often so because they create a whole greater than the parts. Average managers break even. Bad managers decrease value.
https://fivethirtyeight.com/features/most-managers-are-heade...
Do you think it can be trained into people? I do, but most companies are too lazy. Plus, it is not a one time exercise of X hours of training. It needs to be constantly monitored. In my career, I frequently see two-faced managers who say one thing when in front of the big boss, but do another when they are not around. (TL;DR: I call it: "The mouth moves, but the body doesn't.") It's always about the interpersonal clashes that drives away great ICs. The high performers get tired of the b-s from their manager and get hired away. Terrible loss for the company, but a (political) gain for the manager. (One less fly in the potato salad!)
Example: Below, someone mentioned "servant leadership". It is my first time to learn about term. It sounds brilliant. This idea seems possible to train into managers. Plus, the it is an interesting idea to strictly tie manager's comp to reports' comp. It would much better align the manager's incentives instead of today's world of "empire building".
It's a term from Agile/Scrum.
> Plus, the it is an interesting idea to strictly tie manager's comp to reports' comp.
Then the incentive exclusively becomes raising the reports' comp. That might be detrimental to organizational goals. Many salaries are structured as base + short-term incentive + long-term incentive, but clearly that obviously doesn't seem to work as well as it should, either. For companies, it's well-known that aligning objectives is complicated. After decades of 'Management Science', it doesn't seem to me that we are any closer to managing alignment across orgs ideally than we've been in the past. There may not be a silver bullet to this.
That said, thinking about OP's comments about natural-born managers, and how there are natural-born artists, and how generative AI like Stable Diffusion can deliver good results for those that are not natural artists, we may actually need to turn to generative AI to solve for managerial tasks in an optimal way across large orgs. That might even resolve issues with misaligned incentives. Training such an AI could be done on a curated corpus of HBR-type case studies. And you could actually test performance of different corpuses by measuring real-world performance of the corresponding business units in which these AIs operate.
What did they do that made them so special?
https://www.indeed.com/career-advice/finding-a-job/what-is-a...
It's not that there's a "set number of great managers", but we fail to train people, and many who could've been simply wash out because they were thrown into the deep end without any support. ("Hey, you're a good IC, you must be a manager")
And before somebody suggests it, no, MBAs are not the answer[2]. And I don't think we're fixing that if we don't manage to move away from a world where the ends justify the means. As a manager, your fundamental job is to care. Not to goose numbers, but to care enough about people that they feel safe enough to take risks and grow. In an environment that lives and dies by "what did you do for the metrics/the quarterly numbers", developing that care without losing the job or becoming a deep cynic is really, really hard.
If you have a good manager, hang on to them. If you're reporting to one, think hard about following them if they leave, because they are rare, and you might not get the experience again. And if you have the opportunity to become a manager, think carefully if the environment will allow you to care enough.
[1] https://fortune.com/2023/02/06/managers-impact-worker-mental...
[2] https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2962506
That aside, managers are a function of leadership. Got a bad manager? That means some leader is not doing their job.
Yes, there are few great managers, just as their are few great leaders.
My theory is, we could have more great leaders (or at least on average better), but we collectively use that word / title (i.e., leader) so loosely that in too many cases people get the luxury of wearing the crown without out actually doing the work.
If it doesn't walk like a duck...and it doesn't talk like a duck...yet it's still a duck?? That is creating a false sense of accomplishment.
So how do we replicate this ability in people? For sports, there are academies to surface and nurture sporting talent. As a society, at least to me, it seems we have not been able to do something similar for "management" at societal scale. Maybe because the whole domain requires a broader set of competencies in many fields, including the specific technical domain, the humanities, business skills, and political savvy, amongst others.
Maybe we no longer need to replicate this with people. Instead, repeating what I said elsewhere in the thread: consider how there are natural-born managers, and how there are natural-born artists, and how generative AI like Stable Diffusion can deliver good results for those that are not natural artists, we may actually need to turn to generative AI to solve for managerial tasks in an optimal way across large orgs. That might even resolve issues with misaligned incentives.
Training such an AI could be done on a curated corpus of HBR-type case studies. And you could actually test performance of different corpuses (reflecting different management styles, for example) by measuring real-world performance of the corresponding business units in which these AIs operate.
When I was younger I thought maybe that's what business schools did, but they produce a completely different kind of manager who's probably worse at managing people than they would've been had they not gone to business school in the first place.
1. Psychological security.
2. Crystal Clear targets, planning, goals, written down. To paraphrase this, a top manager will write their ICs an 8-12 week JIRA backlog. Obviously, these goals will iterate. However, the ironclad clarity is essential.
3. Positive, effective, coaching and feedback at the principle skill the IC performs. Aka, coding.
4. Lead by example. Conspicuous, hard, effort, devoting majority of time and energy to managing down and shielding.
The issue is simple. All of the above requires sweat from the manager.
Managers are lazy, and nobody is watching them manage their ICs.
On the other hand, I've had maybe 2 great managers my entire career. The majority were either bean counters or empire builders. The latter is particularly toxic - they don't manage down at all beyond the minimum required. They focus almost exclusively on external optics and climbing the ladder.
So given that, I can see an appeal to trim down on managers. Of course, choosing the right managers to let go or convert is incredibly challenging.
I've worked in a few environments where managers were replaced. Only then can you really make the distinction between great managers and bad ones. With one you think "wow this is such a tough business, the manager is doing crazy effort to keep things going", and then another manager jumps in and "wow, this is an easy project. Manager is taking a walk through the park. All seems like a piece of cake."
There is no such thing as a natural born manager. Like there isn't a natural born electrician, politician or nurse.
There are combinations of skills that make one person far far better than everybody else, for that job. Some adapt existing skills, some learn new ones. But no one is natural born great at anything useful.
Those skills are acquired, either with willed direction from internal intuition or very rarely forced via external environment. But still acquired, not handed down, not born with it.
Can anyone acquire skills and be great? No! No one knows the winning combination of skills. It takes a great factor of luck.
Evidence of this is found in abundance. Ask someone great "How can I make my son be as great as you" and see how tangential an answer pops out. You'd think its because they want to keep it a secret. Its because they don't know.
The claim is that people are born with different aptitudes for management that allow them to progress faster along the management skill curve per unit of effort.
I do still stand skeptical of natural talent contributing in any large part to managerial success, over acquired skills and serendipity.
that sounds nice (meaning, "I know what you are saying") but it's not really true. As organizations grow, they become less efficient. If a manager can keep a team of N working at N*1 productivity, that's amazing, but it's not a multiple. Now, people can be dragged down by poor communication, poor leadership, changing targets, stepping on each other's feet, bad attitudes, etc. and a good manager can get that 0.1 efficiency multiplier back up to something approaching 1, so it might feel like a multiple.
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"?
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.
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 Mythical Man-Month" seems relevant in any case.
It's called the Peter Principle [1] and it's pretty well-known.
I suppose Facebook's realized it's in a Peter Principle situation, and the remedy for it would, in theory, be to send some of the people back to previous jobs where they were competent.
The problem is that, in practice, it seems a lot like a demotion, especially if the original move was touted as a promotion, and the pay and prestige of your new old job is less.
It's a real puzzle how this can be done without demoralizing the affected employees into quitting -- especially the best ones, who presumably have lots of good career options elsewhere, and whose value is the entire reason for doing this in the first place.
I’ve also seen people who are great at their current role but lack the attributes to rise into higher roles.
So the premise of competence being rewarded by promotion doesn’t really seem useful in practice.
https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
... illustrates the fallacy of the Peter Principle.
You are supposed to retire or give way to top performers to take the top places.
Years ago playing Civ 4 I distinctly remember hearing Leonard Nimoy's voice say "The bureaucracy is expanding to meet the needs of the expanding bureaucracy". That's what management in these companies is like. It became a meme that every 6 months you'd get an email saying "your manager's manager's manager's manager now reports to a new manager". You'd never seen, heard of or let alone met any of these people.
A large company like this should ahve a structure that's really no deper than:
1. CEO
2. SVP
3. VP
4. Director and really high level ICs
5. Manager and high-level ICs
6. ICs
Any deeper than that is organizational bloat. The above will allow ~5000 ICs per SVP without any layer having two many branches (eg a manager should really have no more than 10-15 reports).
This is better than layoffs because mid-level management is more responsible for bad company strategy than any IC is. Even though this is a step in the right direction, Zuck still faces two way bigger problems:
1. There is no vision for the company's key assets (ie FB, IG, WA). All of these seem to be relatively stagnant (if not in outright decline) and facing pressure from new platforms, most notably Tiktok as well as the behemoth that Youtube remains; and
2. There is absolutely no product market fit for the metaverse, certainly none that justifies sinking tens of billions of dollars into it.
Disclaimer: ex-Facebooker.
Disclaimer:
Just curious: Is Civ something very popular at FB or something? I know Zuck himself plays Civ [0].
[0] https://www.facebook.com/civ/posts/thanks-mark-zuckerberg-fo...
Oddly, Civ seems to be very very popular amongst data scientists. I have no idea why.
How would you deal with the rest 30,000+ Full time employees that Facebook has?
[1] https://www.inc.com/jim-schleckser/how-many-direct-reports-s...
That actually sounds like pretty reasonable limit. There are very, very few organizations that should exceed this size in my view. In fact, even 16807 sounds far larger than ideal in most cases.
10101077 = 49000
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.
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.
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.
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.
This 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.
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
Imagine paying hundreds of people to hire thousands of other people and then saying "oops, we overshot by 6,000 hires!". How can any person in a leadership role that is responsible for that kind of misfire possibly keep their job?
The problem is, that you can never be quite sure which 20% to keep and which 80% to fire.
Big budgets allowed companies to play it safe. Not anymore, it seems.
I'm a founder of an 8 person startup and we're looking for an engineer right now. It's an exciting process for me to pitch the vision of the company to these candidates. It is also exhausting and time intensive - but not boring.
The overhead of stakeholder management is out of control. With this structure, the leadership wanted all roadmaps and planning to be bottoms-up, which just meant a lot of thrash as every layer tried to figure out what the layer above wanted.
I admire how Airbnb has switched to a top-down structure, which eliminates a lot of the unnecessary administrative bloat at companies. It means that the most experienced people are steering the ship. https://fourweekmba.com/airbnb-organizational-struture/
The best engineering teams need the latter but a lot of managers come up through the ranks looking for a role like the former. I know Meta played that game for a long time and I can completely see why they want to walk it back. They need their high performing ICs to actually do stuff again and start shipping diffs. The luxury of being there to level up the noobs is over, for now.
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.
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?
- 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.
I went back to being an IC because its so much easier to take the blame and praise for my work when I'm just coding. I wouldn't mind doing sales again either. But I don't ever want to manage a large team again. There's just too much bullshit ... and I'm also old now (nearly 50) and I feel like a lot of new engineers don't understand what having a job means within an org. Yes, I know you want to work on interesting things all the time, but sometimes all you get to work on is unexciting stuff. Its a job.
Am I missing something?
In all seriousness Netflix has approximately 10k employees. Meta is the smallest of the rest at 90k employees. The scale is radically different.
And this is not to say high employee counts are a good thing. To the contrary these behemoths struggle to operate.
We're finally pulling back on the "HRBP-sponsored" people-management hype train thats rolled through much of SV startups and FAANG over the last 5-10 years:
"Focus on your people, give them the support and mentorship they need to grow. Also 1-on-1s every week." - and all that bullshit.
Taking the cynical view, that BS is there for a reason. It makes it easier to performance manage people out very very quickly.
The optimistic view is that that BS enables people to never let their productivity drop below a certain level.
The extreme cynical view is to wonder why you are being performance-reviewed every 3 months but salary-reviewed every 12.
It seemed like we, as managers, were expected to turn a low performing IC into something magical with an indefinite timeline where we should have just pulled the plug after 6 months and moved on.
This "news" item mischaracterizes reality. It's not "many". It's "few" or "some" because no managers will get 20-50 IC direct reports of SWEs or PEs. It's flattening some spots of unnecessary middle management. That's it.
IMO the easiest way to solve this issue would be to normalize ICs making more than their managers. That way, only the people who really want to be managers are managing.
Wonder what this will do to what is left of middle management.
I've fluctuated between first-level manager and IC a few times in my career. The driving force most recently has been that my manager accumulated too many people, and I was moved from a "team lead" or "project lead" to an actual people manager with a small team. When you're only managing 1-3 people, it's very easy to be asked to do this on top of being an IC, so it's a bit like the company getting a "free" level of management without the overhead.
Of course, it never works out this way in reality, because your calendar fills continuously until you've gone from a maker's schedule to a manager's schedule.
<http://paulgraham.com/makersschedule.html>
Once you've hit peak calendar, it doesn't really matter how many people you manage any more, because your calendar can't get more full and you can't contribute less than zero individual work (ignoring countless Dilbert cartoons here).
Does this help the company? Well, maybe. It does mean your managers at least have the context of the work of their teams much better than someone who was hired in. But do it too many times, and pretty soon it's easy to have more people in charge than you actually have doing work. Does it help the contributor who becomes a manager? In my experience, not really. It's a different career path, and it's a bit like starting over. The pay won't necessarily increase significantly, the responsibilities climb, and I think most frustratingly, you're no longer recognized for your technical contributions. I'm also not sure it's all that great for the ICs under a manager with a small team. The best managers I've ever had have been the people who can dedicate 100% of their time to, well, managing. They're the ones who can give me air cover, keep me out of meetings, intercept unnecessary requests before they get to me, make the presentations for the near-constant status update requests, etc.
I know HN is can sometimes come across as 'management-phobic', and having been on that side of the fence there is a lot value that can be added by managers.
That said, I do wonder how many of these managers who have been asked to become ICs might actually be relieved. In an increasingly competitive economic environment, some could see this as a good thing.
Managers don’t just have 1:1s. They set direction, clear obstacles (both upcoming and here now), ensure quality work, etc. that scales somewhat linearly with team size, plus or minus depending on the individuals.
If you remove a bunch of managers making them ICs, now the remaining managers have that much more to wrangle, and stuff will get dropped.
In a smaller company (100 people) I was able to manage 10 people and still had time to write some non-critical code. That's because there was little overhead - just 2 PMs to work with, not many meetings.
Then in a large org (5,000+) it became much harder. Even though I had only 5 reports, I had to attend plenty of cross-dept meetings, had multiple stakeholders, and in order to get anything done I had to talk to 5 different people.
In order to "flatten" the organization, first this complexity must be tackled. If there's s lot of overhead to get things done, removing managers won't help, because now ICs will have to do the job that previously was done by managers
Personally, I think a manager's job (in a healthy organization) is important enough to let them of the hook in terms of individual contributions.
They should either prove themselves valuable or just leave.
High salary. That incentive ends in 6 months.
What is it exactly?
I mean in general, not necessarily at Meta.
Wish there were a way to flag comments.
Are they re-interviewing to be ICs? (paywall)
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.
"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.
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.
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?
I was out having a meal with old college buddies; most of us are developers, but some have become team leaders and managers. I will call it a statistical anomaly, but the worst engineers are now in 'people management' positions.
The discussion ended with a guy boasting about how his team has X people, and he's looking to grow it to Y this year. Naturally, we asked if he needed that much headcount. Turns out, no. It's their way of assessing value and getting promoted. He gave almost 0 fucks about the quality of the people employed and how adding them to the team would impact quality. The only thing on his mind was getting that number up to pump up his CV for the following position of managing people.
I'm gladly reporting that he managed to do that and has indeed been promoted, and I still can't say what he does for a living apart from 'enable engineers to grow their careers.'
I've also been in positions where my 'people managers' advised me against my interests. Unfortunately, I am my own people manager, so I took my own advice, which worked out wonderfully. I wake up from time to time thankful that I didn't follow the advice of my managers and was able to see some of them in the audience from the stage.
1 - I was working in a rich .NET environment; JavaScript was beginning to show its teeth and wasn't taken seriously by 'serious' programmers. I was going with my manager through the SMART objectives I needed to do for the year, and I mentioned wanting to learn about this new thing NodeJS and JavaScript on the server side. He kept pushing that I should do a presentation on our use of Entity Framework to get some clout against the Java department. I insisted that I was more interested in learning something new than just doing some presentation that has been done by almost every engineer on our team. He accused me of being an ego-driven engineer and wouldn't accept it. I learned NodeJS that year, did a presentation on it (it was fun, not a single senior thought this was worthwhile), and ultimately ended up using it a lot, and that headstart helped me.
2 - I was talking to the head architect in a large multinational, expressing my interest in joining the 'architect guild.' My manager informed me that I was too young (about 28 then) to consider this career move and that architecture is for older people. I found that to be rather stupid, and when I got offered a CTO role and the possibility to architect a system, I talked to my manager about it, telling him that I was very interested in being in that kind of role and asked if there's any way I could find it inside the company. He told me that 99% of startups failed and that my choice was between employment and ending up on the streets. I took the chance and couldn't help but smile, getting our first million dollars with him in the audience, front row seats paid by the corporation.
I've been an IC reporting to a manager, who himself reported to a manager (as opposed to director or senior manager), and while the second one was technically my skip it was more like I just had two direct supervisors.
Not true. At least not as of late. M2 promos can lean on different things, e.g. delivered impact, over established people scope. But the person trying to promote you need to be able to do that well. Source: Have done M2 promotions at Meta.
Possibly by not being singleminded or crazy about money.
Now I'm a mere peon, but this replicates up the chain increasing an order of magnitude each level, meaning up top you get VPs backstabbing each other to take over the victim's headcount and wrangle that sweet SVP promotion.
But, I've never seen that in practice. Maybe the politics of the C suite mean you want those office politics back-stabbing folks around to take those high level positions?
You also need a good way to tell apart the backstabbers from the good guys.
If you can't get good enough people, you're going to fail hard inevitably no matter what you do (if you've got a quasi monopoly moat it may take a long rot to get there).
Step 2: Realize that what you requested is impossible for sufficiently large organizations
Step 3: Negotiate a golden parachute for yourself. Don't hate the player, hate the game
Now one way to climb the ladder may be to grow the product or service, but in a larger org the ability to influence a product or service in a major way might be a bit limited, with decision-making at the business level being controlled by upper echelons. So the ladder-climbing process would select for different skills and temperament than founding/running a company.
Essentially, in a corporate hierarchy, we're asking people with ladder-climbing skills to become business people as they reach the top, and not everyone can make that transition successfully. In fact, I'd go so far as to say that very few can actually make that transition successfully.
Human brains learn through feedback [1]. To become a good business person, you need to run a business and get feedback just like a real founder/CEO, including business failures. Your question essentially becomes - how can a CEO structure incentives so that managers at all levels become good business people?
It's a great question, to which there is no simple answer that I know of. Would appreciate any pointers to potential solutions.
One way could be to treat each team at a certain level (say no more than 50 people) as a business of its own. It might not be the most efficient way for the corporation to deliver on its objectives, but it would likely create a lot of business-savvy managers. But now you have a pool of business-savvy folks that want to get paid like founders, and that might not be possible in a corporation. In terms of (in)efficiency, you could have duplicate teams that provide similar services, wasting resources, and adding costs to spin up new teams as existing ones fail or move on.
Something like this might be more feasible at a societal level - a capitalistic structure that encourages the growth of smaller size businesses while inhibiting the growth of mid- to large corporates.
Open source organizations actually seem to be the closest that I've seen that seem to operate this way.
Also, if you're working for any large company, you are a cog in the machine.
He seems like a ‘slave driving demon’. Best example how he treated the folks at Twitter or his other companies… demanding ‘hardcore’ hours and exactly like you said… he doesn’t care about people… doesn’t care whether they burn out or creating a culture where bullying is accepted.
I don’t think he really cares about solving big problems, it’s just a front to feed his big ego… he wants be seen as real life Tony Stark.
If he really cared about solving big problems like the climate crisis etc he wouldn’t have wasted his time with Twitter.
He wouldn’t have come with a stupid idea like the hyperloop and trying to derail a high speed rail project.
What he has achieved is he inspired more people to become engineers and problem solvers and have a positive vision of the future. But his big ego and narcissistic traits have ruined it and more and more folks see what he really is.
At the beginning his ambitions were probably more aligned to this vision, but he probably got more jaded over the years, realised it’s effin hard and his narcissism got the better of him.
It’s a shame the way he treated the Tesla founders. Also I never saw him credit his various teams, it’s always about him.
Tesla and SpaceX are successful despite his involvement, because ppl care about creating more sustainable solutions for humanity… it’s a great mission.
/rant over ;)
I would argue that administrative and organizations bloat is a very real problem across virtually every large business. The bigger the business, the worse the bloat problem.
Like this? https://www.theguardian.com/technology/2023/jan/03/twitter-s...
You can't do it, but you can fool idiots on the internet that you can!
- The orgs most susceptible to rampant empire-building are ones where execs seem disconnected from the product. IMO the best way to discourage rampant headcount growth is for upper-level execs to scrutinize hiring needs. Some orgs (especially pre-2022) have been apt to approve headcount growth without sufficient oversight as to what the new people are actually supposed to be doing, and whether or not they're necessary. Loose hiring policies result not only in corp bloat and high expenditures, but reward empire-builder managers more than product-oriented managers.
- To double down on that point, part of the problem is that in too many companies execs and managers don't speak product. The point of hiring is ostensibly to ship more/different/better product, but when execs themselves do not speak product hiring becomes divorced from this underlying goal. You hire so your seniors have juniors to mentor. You hire so a manager can get promoted. You hire to "expand your scope". But at the end of the day there is only one valid reason to actually hire: so the company can produce more/different/better products that it otherwise cannot do without hiring. This is especially true at companies like Google and Meta where the PM track and Engineering tracks are fully decoupled.
Sounds pretty miserable to me; I suppose that's why I've stayed at smallcos/startups my entire career.
Meanwhile there’s plenty of small, nimble, managed-by-best-practices would be disruptors not shipping much of anything.
It is not a do-nothing organization lost in paper-pushing. It ships.
The existentence of one or two enormous hidebound sequoias in a forest is not a good indication of its overall health.
Our team has a motto of "avoiding the cutting edge" because we don't want to bleed. We still have mainframes, because the cost of migration is prohibitive. We largely host on-prem though we have some initiatives to see how the various clouds might work for us. But these initiatives have been going on for 5-6 years. Mostly because our CTO doesn't want to miss out on the cool things.
We generally don't do layoffs, 2008 was the first time in the company's history, and that was like .005% of our company staff. We're very conservative, and when you have ten figures under management, you need to be.
Imagine if at $BIGCO they told you that in practice, you need to reduce headcount and run as lean as possible so that your team brings as much monetary value for the company with the least amount of expense instead...
The same impulse exists in individual contributors too, which is why you see people architecting giant sprawling armies of microservices for something that could be a simple program running on a single machine.
Some people like to just show off their ability to make big things without caring enough about what it's for.
In the last performance review, my boss complimented the amount of new services I put into production.
I hate software engineering.
I've been at companies which offer good IC tracks upward alongside management tracks upwards.
On the other hand, the company which you describe above are those which do not offer an acceptable IC track upward.
Metrics become about headcount rather than value/revenue delivered. The worst companies are those which will literally have headcount requirements for promotion, because such bright-line requirements drive the behaviour you're writing about.
It probably helps that I've only ever worked at small-ish companies, and it might also help that my managers have pretty much all been technical (either while managing or at some previous time)
I would guess, based on limited data, that like most other regressive culture problems this heavily depends on company size
Do you think it's a local vs. global maxima situation? I've had a moment in my life where I had to work 16 hours / day for two months, but in the end it was worth it for me. Time out would have been the wrong advice in that situation. I've also had situations where the whims of higher-ups were misunderstood by my direct manager and direct communication unraveled the mistery. Shielding would have been the wrong help in that situation.
What does small-ish mean? I find that most small-ish (what I consider small-ish) companies had a rather flat hierarchy. Managers if anything were contributors and their managerial role was aggregating feedback for the executives so they don't get every IC knocking at their door.
I'd guess this is more likely to happen with non-technical managers. Not sure, but that's a guess
> What does small-ish mean?
My current company (~300) is by far the largest I've worked at. Next-largest was about 100
> had a rather flat hierarchy
Yeah, that tends to be true in my experience and probably contributes to this
> Managers if anything were contributors and their managerial role was aggregating feedback for the executives so they don't get every IC knocking at their door
Most of my managers have had a tremendous amount of professional humility, which I think is key. The main jobs they've covered (in different portions at different companies, and sometimes with some IC thrown in too) were:
- People-manager: make sure people are unblocked, happy, not burning out, working on things that play to their strengths, feeling good about their career and work and not on the verge of leaving. Really a support-role
- Shield: go to the stakeholder meetings, field requests made toward the team, manage the jira tickets. Then take all that and digest it, bring it to the team to discuss capacity and direction, and then take the results back to the outside stakeholders and use managerial authority to push back if needed
- Product expert: stay in the headspace of the user, features, experiments, overall goals/roadmap, and represent those priorities to the ICs. This one's a fine line- it's easy for them to go off into the clouds and pass things down one-directionally. But when it's collaborative, and we're discussing things as a group with different individual focuses, it works fantastically
At my current company we actually have two managers per team- one of the first kind, one of the third kind. This can work really well
The most important component for all of these to work well is for the manager to see themselves as a team member, not a boss. These teams (when they worked well) did not operate on a hierarchy unless a tie had to be broken. Normally, we were all just collaborators with different specialties, who brought our different perspectives to the table and advocated for what we saw to be important. I can't emphasize enough how well this works when you can get everybody in that frame of mind
Did a bunch of legacy stuff for a while but ended up fine.
I've never had a bad manager, but I've never had a good one. Or rather I've never had one where I've really noticed what they actually did aside from doing a basic personal assistant / secretary job dealing with administrative paperwork, scheduling meetings, taking notes, conveying status reports between people and teams and tools.
I've never had personal issues with my managers and I've always got along well with them and I don't suggest its their fault that their positions exist. I just don't see the value in having organizations structured in a way that necessitates these roles.
> shielding me from the whims of higher-ups while making sure I don't burn out by encouraging me to take more time off, etc
See this is how they sell themselves, but what it really means is that your engineering firm has whimsical higher-ups who don't understand engineering or even basic people management such that they would kill your productivity and burn you out, forcing the firm to hire another layer of people to protect staff from incompetent upper management.
There could be a grain of truth to it, but it just makes the situation even more ridiculous.
And that is the kind of person that survives purges like the one Meta is doing. The managers that did not grow an empire, the managers that did their jobs and cared for their teams are the ones that will be removed.
When an organization incentivizes managers, directors and vice-presidents to grow empires, when the axe comes down it does it on the people that did not play the game.
I do not understand why some people gets so happy when management gets the axe. Do you think that good managers that cared for the team instead of their own career are the ones that stay?
I am not happy for any axing. In case this question was directed at me. I am happy for expecting managers to also be able to contribute to the product instead of just managing people.
As a code contributor, you’re not going to be able to keep your commitments because of management responsibility and as a manager you’re not going to have time to do either career development for your team or be in the room to play politics for your team.
The only time that I’ve seen that work is when my former CTO would do non production code as a research product or a proof of concept that he would give to someone else to make production ready.
Also, the people you report to aren’t going to be as willing to give you honest feedback.
As an IC, I can give a suggestion to my team and I have to convince them based on my ideas. They will free to push back. As a manager, many won’t.
I work with a lot of people who for whatever reason won’t say anything openly when they feel something is wrong. Even when it’s not their manager - ie a project manager.
I’ve never been afraid to voice my opinion and “disagree and commit” (how do you say where you work without saying where you work). But then again I’m older (49), more financially secure and not here on H1B [1].
[1] That last statement is not meant to rail against H1B visa holders. I think the entire H1B visa system sucks and is inhumane for the people who have to deal with it precisely because they have to deal with shit that they shouldn’t have to.
I'm done complaining now :)
If you care about total compensation, “grind LeetCode and work for a FAANG” (haha only serious)
I went from the Dev lead in 2016 in a medium size health care company, to a senior dev/de facto “cloud architect” at a startup to mid level “cloud consultant” at $BigTech. Each job came with more money - and the current one a step change in compensation - and less responsibility and less headaches.
"[He] enables engineers to grow their careers."
Just what exactly was accomplished here?
The other thing is team growth is a defensive measure against recession layoffs and probably keeps eyes off a team if they've recently grew. It's either grow or die.
Generally curious here - do you mind adding some examples/details? Looking back at my career I can't think of a time when any 'people manager' advised me against my own interests. I am no longer an IC and since I haven't experienced this, I worry it's a blind spot in how I'm interacting with others.
With a bigger empire, they're allowed to take credit for high impact engg in their chain, and including the low performers simple for total headcount. It seems like a win-win situation honestly.
They got around it by setting up multiple reporting chains and co-managers. If you were a manager at a certain level and you worked with certain departments, you got to say that all of the people in that department "reported to" you.
It created a laughable situation where there were only a few thousand people in the company, but I knew several dozen managers who had 200-400 people "reporting" to them. Individuals could technically "report to" a dozen managers, though they may never interact with those managers.
They all proudly display their number of reports on their LinkedIn profiles.
Is that a bad thing? The person worst at writing code is removed from doing it, and the (same) person managing engineers has at least done it. Unless the managers are pushing technical decisions on the team (does not sound like it), why wouldn't you want the worst engineers to become the people managers?
To say nothing of the common idea that engineering skill and people skill don't coexist often in the same people.
> , so I took my own advice
Always good! I've taken other people's advice over my own to my determent before. Of course I've also taken other people's advice and it worked out way better than my dumb ideas. Blending them is hard.
Any commonly given out advice you benefited from flatly ignoring?
> and was able to see some of them in the audience from the stage.
Sorry, the article implies this is an announcement of the program. It seemed like it was going to be done individually-ish. Was it a massive meeting instead?
The best engineers almost without fail are the ones who are passionate about it and don't want to be doing anything else. They'll tend to keep being engineers.
And corporations tend to recognize, value, and promote managers based on team size and growth as key metrics. Can't blame someone for doing what their employer tells them it wants. The problem here is not caused by line managers but by executives who set goals in this way.
And I don't really know what line managers do either. They seem to sell themselves to their reports as "dealing with all the corporate bullshit" which is kind of true, but if the corporation is generating so much bullshit that it needs to employ bullshit wranglers, it seems like the better solution would be fix it at the source rather than clean it up after the fact. I get there will always be some amount of administration and stuff that you don't want your engineers spending lots of time on, but that could be handled with a personal assistant type of role that should be able to handle dozens of engineers per PA, rather than a higher paid manager.
They're focused on me and the other engineers, we're focused on the product, and everyone is happy.
That contrasts with product focused managers, where I've seen a tendency to burn through engineers and be very stingy with raises and promotions. So the engineers need to take time to be their own advocates and set boundaries and lot of us aren't as good at that so it becomes chaotic.
First, tech and team leads are regularly pushed out of authority by management types, like the ones you described or worse ones who get promoted by slimming a team down.
Then there's the whole fabrication of accomplishments where managers will get promoted for the work of ICs while tech leads and ICs don't.
I'm not saying get rid of management, but the Bay really needs to reassess it's incentive and management structure. If anything, let the managers be a tool to the team rather than an authority figure. Then pair them with a competent tech lead to handle things the lead or ICs can't do on their own.
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 :)
"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.