It's too bad, because the best managers I've worked with were not good ICs, but they did multiply the effectiveness of the ICs they worked with, and so were absolutely invaluable to the company in a way that may not have shown up on paper. If those people exist in FB, as I'm sure they must, then they'd presumably get jettisoned as a result of this choice. That would be bad long term.
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.
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.
Not going to happen, fundamentally just due to supply and demand.
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.
I find it far more plausible that managers are paid more because of the default fiefdom hierarchy that you find in most corporate systems than because of anything inherent to the day-to-day job. CEO doesn’t think people lower on the totem pole should be paid more than them, so they hire people at lower income levels. Same for the VPs and the Directors and the layers of middle management until you get down to the ICs.
I mean, just look at comments around this topic whenever it comes up. People want ICs to get paid more because they don't want to work as managers. Heck, I most definitely agree with them - again, I was a manager, and I won't do it again either. That means I have accepted that I'll make less money, but I'm fine with that. Someone else can have that shitty job.
I don't want to clean toilets or man a register either, but people who do those things don't get paid more than me. There's something else going on with how managers get paid.
You don't, and not many people do, but the fact is that there are lots, and lots, and lots of people without the skill sets necessary to move to higher paying jobs, so it's still based on supply and demand. Of course, good managers should generate a lot more value than a janitor or a cashier, so there should be more available to pay them. Even if hardly anyone wanted those janitor or cashier jobs, there would still be a limit on what they could be paid based on value created (and indeed, the "labor shortage" you hear about all the time now in those lower paying jobs is due to the fact that not that many people want them but in many cases company owners can't afford to pay them more).
> Of course, good managers should generate a lot more value than a janitor or a cashier
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.
I’d say there are many people without the skills to be a top tier engineer. In fact I picked my IC to manager conversions based on their inability to progress as an IC but their empathetic and organizational abilities let them be a credible engineering manager. They weren’t great engineers but they were good enough to know what good work looks like. However the absolute best IC engineers that commanded the most money could easily have been a successful manager but enjoyed IC work more, and were much more valuable making engineering decisions than holding 1:1s and meeting with auditors. They were effectively matrix managers in many respects. That’s a much more rare skill, and you can’t mentor someone into being a top engineer. They’re born, and are born at the same rate as they always have been, and are there for much more rare as the industry and demand has grown.
It's a shitty job for conscientious people. I've seen the toll it has taken on some of them.
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.
In any organization somewhere between 1% and 10% of people will suck up 80% of leadership's time if you let them.
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.
I've witnessed this across a few people and across a few companies—both in terms of wasting time for the company, or pushing the company to be better.
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.
There is an additional dimension here - some people start off great and then become toxic due to external conditions (home problems, health issues, organizational strife). Sometimes those problems are resolvable (or mitigable). Sometimes your "problem child" becomes a stalwart after their situation is resolved.
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'm no manager but if you have a much larger salary and 80% of that money is spend on dealing with a single employee. Even I can figure out what should happen next. I cant imagine a justification for your 20% performance.
I fundamentally disagree, as a similarly senior person at various globo mega FAANG corps, my observation of the dynamics is managers are paid more at some companies because managers set compensation and there is a social barrier to paying subordinates more than their managers. At other globo mega FAANG corps you get paid what is required to retain you. Most engineers make less than there managers simply because the managers are more senior in their career and have a lot of options at competitors. But exceptional engineers are wildly rare and in demand breaking the highest pay bands. This also holds for other fields where there’s the two sigma IC who is a rain maker - sales, trading, etc. I’ve never seen a company that’s unable to fill even its most senior ranks readily, but I’ve seen many that can’t retain star traders or sales people or engineers and it’s usually an unwillingness to break the social taboo of “overpaying” an IC. Those companies don’t understand how markets work and generally their competitive performance is lower than the companies that pay what they have to pay.
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’m not saying ICs need to make double the pay of their manager. Really, just the tech leads need to make more and the manager should make on par with their middle tenured ICs because then ICs will feel like they have a solid career path outside of management
Working the line at McDonald's is fundamentally harder with respect to being a grind but that doesn't seem to reflect strongly on their pay. The reality is that you don't need to pay $300k/yr for a manager who is also a talented FAANG level developer.
Definitely said from someone that has never been a manager. FWIW, it's never that easy to fire someone, and it gets even more difficult when you need to worry about protected class issues.
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.
FAANGs generally don't have that problem, at least not until recently.
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.
I agree. Too often people feel becoming manager is the easiest way to advance their career (which most of the time equates to making more money). In many cases becoming manager is the only way to advance their career in the current org.
Management track is usually the only way to be in the room where decisions get made. Sure, the top engineers will be consulted and kept in the loop, but 99% of the strategy discussions and planning happens without them.
So for people with an innate need to join in the steering of the ship, there’s only one career path.
My org of 500+ has 4 groups in it. Our annual plan had 16 major priorities, 4 of them came from me (a PE, most sr eng) directly or initiatives I pulled forward. I was in the deep meetings for my direct group. I had many discussions for the 2 ideas in other groups (one was easy actually). I'm not sure how that would rate as "excluded". I gave comment on all of the org plans and priorities in the groups (many of them have a lot of priorities I'm not spun up on yet as they're well covered or out of my wheel house). I sat in the final reviews. I'm in the promo / rating meetings. Only thing I'm really not in is the budget meetings and ceremony goal reporting meetings except when needed. That seems like a plus.
This is your experience and it doesn't prove anything. I mean, the above comment clearly said "usually" and most likely that's the case. At least, from what I saw. There may be one engineer for 4-5 managers in the group.
> So for people with an innate need to join in the steering of the ship, there’s only one career path.
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).
This is the problem I’ve been wrestling with. I’m never going to get the control I desire, unless I give up on benefiting from that control. I can’t advocate properly for myself as an IC, and even as a lead or staff engineer I’m still likely to be coaching someone who goes to the meeting instead of going myself and having much gravitas.
Only at very small companies do I get to cross these streams.
I interviewed for FB once and I don’t believe this is the case there. I was told the comp levels ran parallel for ICs and Managers. They do value their ICs it seems. This was one of the main reasons I was interested in working for them. You can see it on levels.fyi
There is M1 and there is M2, and then there's Director. There's no level 6+ on the management track. I'll disagree with this statement by saying that I think the step function in skills between managing people and managing people who manage people is huge. There are larger gaps between M1 -> M2 -> D than IC6 -> IC7 -> IC8...
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.
It me. I’m a good Dev but was never going to be one of the greats. Making the jump to manager seemed like the next logical step… and in sone ways it has been, but it’s a very different job. (Now that I evaluate other people’s dev work, I was actually a lot better than I thought I was)
I've noticed that many of the best devs are constantly worried about their output and quality and the worst not worried at all. This is as a Sr. IC who gets pulled in to other teams on the regular.
This is the case in my company. My boss reluctantly went to the manager track as it was quite difficult to move up on the SDE track (from the level he was on) but much easier on the manager track.
Yes, absolutely this. Once you hit senior ranks in engineering at a big tech firm, it's actually very difficult to move upwards. Very few people are ever made principal engineers or senior staff or even staff level for that matter. The jump in technical ability for those levels is quite large as well and can take many years to get a single promotion since openings are pretty slim as well (some orgs will only get 1-2 staff engineers).
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.
I really don't understand this pattern at companies. It seems entirely feasible to simply let IC's take on more responsibility. It's easier to shuffle responsibility amongst ICs compared to managers without rocking the boat - why would orgs incentivize a "fixed" management structure?
It creates the problem of too many chefs but too few cooks. Too many people discussing how to best construct a thing vs actually constructing the thing.
But do you want managers who are people who want to be managers? It seems to me that many people who want to be managers are motivated by wanting to boss people around, i.e. they want power, not necessarily money. And some don’t want to do “the work” whatever that work might be.
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.
Middle management should be like jury duty -- something assigned randomly to a team member, then served for a set period.
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.
> Middle management should be like jury duty -- something assigned randomly to a team member, then served for a set period.
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.
A bad middle manager tends to be a bad middle manager because they're empowered to do dumb things: set upcoming workload, badger people about adherence to mythical project schedule, etc.
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.
Who in the rest of your organization is producing so much shit that your manager’s primary job is to be a shit umbrella? What productive purpose are those people serving if your manager’s job is effectively to work against them?
Maybe the people producing the shit need to go too.
>
Who in the rest of your organization is producing so much shit that your manager’s primary job is to be a shit umbrella?
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.
A majority of them may be like this, but eventually you’ll meet that one manager that actually seems to care and goes out of their way to help you. Then you’ll realize some people that are looking to be managers are not power hungry narcissists.
The problem is that then it tends to become a sort of charity work. I've had multiple managers who essentially felt like they were burnout martyring themselves into serious problems in their life to try to support my team.
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.
> It seems to me that many people who want to be managers are motivated by wanting to boss people around, i.e. they want power, not necessarily money.
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.
That already happens a fair amount. I've had two orgs where for stretches of time my top guys cleared more than I did, and I've known others in the same boat (they ran "rockstar" SME teams of various types). I wasn't offended by it either. I gave them air cover and they did exceptional work largely undisturbed, and periodically asked questions that made them not get too comfortable in the status quo. It was a fair trade off.
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.
That's an easy way to have zero managers and more problems than you started with. The vast majority of ICs are like children. It's not fun dealing with them. The only way one voluntarily takes on that role is for equal or greater pay.
I disagree. The vast majority of managers are nothing more than people trying to climb the bureaucratic rank and are not truly helpful in multiplying the efforts of the mid-senior ICs below them.
And that doesn't apply to ICs? I've worked with plenty of ICs just trying to show they "led a project" to make Staff or higher and did next to nothing to "multiply" any amount of effort from any other IC.
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.
That is pretty much the whole idea of the Staff+ Engineer track that mirrors the management track. The divergence normally happens after senior engineer level.
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 :-)
I think you are partially right, in that it should be normalized that some IC's may be delivering more value than their managers, and compensation should reflect that.
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.
The same way anything is normalized. One person/company does something, posts the outcomes of it, then other people follow. I don't think many companies have tested this logic out, as management style in tech is inherited from older corps.
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.
I still don't see how you beat the market-driven salary. Don't you have to pay market rate for good managers, and market rate for good IC's?
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.
You could drop manager pay and accept that it will mean "worse" managers, and perhaps hope to make up the difference by using the savings to pay more for ICs and hope that this will get you "better" ICs and the result will be better team performance overall.
I don't know how you'd ever make that change to a company structure though. The turkeys would have to vote for christmas.
I mean there are, what, millions of independently run companies in the world.
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.
That's not "companies find they are more profitable". That's "nobody does it and it's probably because some tried and decided it was better not to, and maybe the way they decided it was better was by comparing profits".
It's fascinating as it seems like most modern problems are the result of wrong arguments being just more convincing. Like, they're. A virus well designed to exploit the most number of human logical fallacies and heuristics.
Not sure if you're intentionally demonstrating by example, but you definitely nailed it. People are suckers for "there's this one simple explanation that explains hugely complex problems."
Bell Labs is a special case (afaik). My father worked for Western Electric (and I actually did a couple summer internships there). In any case, BL / WE had a special rank and pay structure. They understood they had talent that was more valuable not as management.
I don't remember the details but do remember there being certain "heavy weights" that didn't have anyone under them.
depends, in many hospitals the administrators have to keep their licenses (doctor one day a week) and are paid more overall... so what does that make them?
The problem with great managers is that you don't notice them. Things just work, no drama, no fires to extinguish, ... . It's also not clear why things are going that smooth, it just seems to work that way (clue: it's actually the manager that creates this environment).
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."
100 times this. If you have an incredible manager, most likely you as an engineer feel little pressure and a lot of freedom. That is because that manager has his back full of arrows he intercepted before they had a chance to hit you.
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.
It's remarkably easy. For some reason it's simply not taught at schools.
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.
The problem is that what makes a good manager for an IC does not make a good manager for the manager’s manager. They are fundamentally at odds unless you have servant leadership from the top down. (Which is nearly unheard of)
>the best managers I've worked with were not good ICs
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.
Managers don't have to have the hands on skills. What's more important is their understanding of the players, and making players better than they would be otherwise.
Those well-regarded managers are often so because they create a whole greater than the parts. Average managers break even. Bad managers decrease value.
Oh I completely agree with you. Good managers have an amazing multiplying effect on their team. People underestimate how important it is for a team to gel to be productive - although it's been said since the Peopleware days.
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.
You lament the decision by FB yet you say out of the hundreds of managers you worked with only two were good. You are saying most managers aren't good and it sounds like FB agrees with you and hence decision. I also think this might be a good decision because I do think managers need to be able to set up programming environment and at least be able to navigate the code. Kinder of like how some retail companies make head office staff spend some time at a real store so that they are aware of operating environment at the coal face.
Being a manager is hard and comes with a boatload of emotional responsibilities[1]. It takes a long term to learn, and our process of training managers is fundamentally broken.
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.
Hard agree, it's incredible that there's no systematic way to train such managers.
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.
It's remarkably easy. For some reason it's simply not taught at schools.
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.
> were not good ICs, but they did multiply the effectiveness of the ICs they worked with
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.
> Actual, natural-born managers are such an incredibly rare species that you can go a long time without seeing any in the wild.
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.
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.
You're taking OP's claim too literally. Obviously babies don't pop out of the womb ready to competently manage a team of 30 engineers.
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.
Yes, my comment does read pedantic and reactive. Hides the thought behind it. The natural born part kicked me into higher gear. I will be more mindful.
I do still stand skeptical of natural talent contributing in any large part to managerial success, over acquired skills and serendipity.
Managing is like any skill, if you want to develop it you have to work at it. For it to come naturally, is luck. That is, some collection of personal / personality traits, in the right place, at the right time. The problem is, few (are allowed / encouraged) to develop their manager-ness.
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.
Not strictly. Architects I think are generally considered ICs. An IC is basically anyone that doesn’t have people under them officially in the org hierarchy, even if they do thought leadership, like a tech lead or architect.
This is an incredible post with a lot of insight. Can you please (please!) blog some stories about what you have seen? You are lucky to "work[ing] with hundreds of them as a consultant".
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".
> Below, someone mentioned "servant leadership". It is my first time to learn about term. It sounds brilliant.
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.
I had cautiously gotten into management because I wanted to learn the skills of delegatin and really building through others and growing/coaching others. I thoroughly enjoyed this. But over time what I had realized was the role had been changing (not sure if it was just for pandering) towards being a mouth piece for leadership and hr - having to relay decisions I didn't believe in (perf seasons, promo rationales, layoffs anybody?) As if they were on purely my own. Given Ive always enjoyed building this may actually be a good forcing function to go back to IC and just ... Build!
I've recently held a senior management position then left and obtained a technical position at a different organisation.
Not kidding, I nearly cried with happiness moving away from SM and into a tech position again. I was GIVEN work to do. I had NO responsibilities for others. Moreover, I was DISCOURAGED from attending unnecessary meetings. I arranged no meetings! Not one!
Went from 7 direct reports to zero. No more approving holiday requests. No more performance reviews. No more management town-halls. No more arguing strategy with anyone. It was brilliant. 'Please write a procedure that does X. Return it by Thursday.' 'Please optimise this statement that hangs during the overnight run'. Yes, absolutely, more of that please.
I too went from management back to coding (freelance) since the start of the pandemic and I also love it. Today I happened to notice that Google Calendar was reporting an anomalous week in terms of meetings: I had 2.5 hours of meetings in my calendar this week, while my average right now is 1.2.
I average less than an hour and a half of meetings per week! I have so much more time in my life for the things I love, it’s crazy.
It because a theory of mine that a large part of my job function was to simultaneously water down accountability from above, while adding enough complexity to the layers below me to discourage them from changing the status quo.
The double edged sword being, without that authority, that same power structure is forced on me, and now I’m more aware of it.
I have a feeling being in middle management leads to that squeeze.
If you're closer to the doing, you are more isolated from the companyspeak nonsense. If you are in the upper part of the food chain, you get to enjoy more influence, freedom, a better risk/reward tradeoff, with costs you mention.
In the middle you're kind of screwed from both ends.
I had a couple of accidental ah-ha moments about this. Before I got into management all managers (fully up the stack) seemed like pointy hairs bosses. But what is easy to miss in Dilbert is that the PHB is really part of exec suite and rarely your front line manager. A hated front line manager might be usually incompetent or just inexperienced than evil!
The other thing was demonization of front line managers. There was always a terrible (there are definitely terrible traits) managers but never terrible "leaders". Even worse was you'd see articles by hr "influencers" expounding this. Where are the same hr loud speakers now that "leadership" is the one inflicting these layoffs and ridiculous policies?
The best thing you can do in these roles is protect your team. It's your primary job to ensure they can build and with minimal wasted efforts. If you view it as building for the company, your team is a victim to all the dysfunctions of the organization and nobody wants to be on that team. The mouthpiece part is tricky, I always try to give the official message with a dose of my personal candid opinion on it even if it's in opposition. You just can't lay it on too thick and try to find a way to spin it to a positive as to not be demotivating for the team, "it might be challenging, but at least we'll learn X and they're aware of the risks that are at top of your minds."
Agree. Their decision is made. The way I manage I tell upper management what risks their decisions have, then don’t let them blame my team for when those eventualities occur. My teams don’t work overtime to meet a deadline when some decisions was made that screwed up the schedule. Those kinds of things. That’s protecting your team.
> towards being a mouth piece for leadership and hr - having to relay decisions I didn't believe in (perf seasons, promo rationales, layoffs anybody?) As if they were on purely my own.
The role doesn't change though. It has been like that forever.
This is another part of Management (whether you like it or not). Management should be seen as a cohesive "Leadership" unit because if the leaders aren't on the same page, what good are them?
The other thing about Management/Leadership is that they should be able to relay the message in the right format and at the right level for their direct reports. C-level typically have OKR/Objective in 3-5 bullet points (the bigger the company, the more bullet points) and it's the VP and Dir jobs to break these individual points to high-level goals for their Organizations. It is the Manager's job to distill it even further to their level + their direct reports.
It's one way to keep ICs on the same frequency with leadership and to execute for a common goal.
Most ICs don't want to attend meetings, don't want to hear "high-level goals", and more importantly, don't have the skill to consume those high-level goals at their level. They need help from various layers of leaderships. Sure, there are those exceptional ICs that wouldn't mind to be involved at that level and understood the social/human aspect part of the work but let's be frank here: majority of ICs just want to bang keyboard, produce clean code, and marvel at the end results (ignoring everything in between).
Imagine this from a military perspective. The general/field marshal etc makes the call that you're going over the top and as a smart Major or whatever you know this means most of your men are going to die. Are you going to say to your men:
"Hello gents, we have our new orders, we're going to go over the top tomorrow at 8am and try and take the village one mile down the road, however, I think this is a horrible idea and you're all probably going to die."
Even if you really believe this is the case, it's a bad idea to tell your men as it means the plan (which is going to happen anyway) is even LESS likely to succeed. That is, if you can make your men believe the plan is genius and they're going to destroy the enemy easily, it may give them more confidence and leave more of them alive at the end of it.
By explaining your reasoning in every situation you can will build trust, so that on the rare occasion that you need them to act without sharing, they will trust you enough to do so. For example, when in an execution environment where response time matters.
And in practice, this is how good commanders I've worked with have operated. And this is explicitly a principle of the US Army, by understanding the objective and it's purpose units are able to continue acting to fulfill their objectives even if they are cut off.
The upside of explaining whenever you can let them build a mental model to know how you would likely handle an unexpected situation, allowing them to act in your absence.
It is unusual to have a team emotionally mature enough to handle actual transparency. You only have to read HN to know people live with extreme cognitive dissonance between wanting their high salaries and hating the business practices that enable them.
My experience has always been that certain employees get marked as "adults in the room" and are given real transparency in 1:1s.
This is true. Especially extending it to opinions and emotions.
But understanding the purpose and why of a decision/plan is only a small piece of full transparency. And is always achievable. This is the minimal amount I consider functional. Less than this is dysfunctional.
The reset is extremely rare for teams (I’ve only had this on a team once and it was magical), but happens regularly individually 1-1.
In general, if you want your reports to accept company decisions, it is in your interest as a manager to align your stated opinions with company policy. Openly disagreeing, or just trying to take a neutral position will only reduce faith in the company and sow unrest for which you will be held accountable.
Isn’t that the entire purpose of being a manager? If I were just going to repeat the company line and not advocate for my team then I might as well be a rock.
"I don't like it either. Here's what I'm doing to try to get them to change course. In the meantime, we need to do xyz, and I need you to do abc as part of that"
I have absolubtely had managers that did an excellent job of making us feel like we were in it together. In fact I'd say its one of the key skills of being a manager at all?
> Is this actually the expectation at the places you work?
Can you imagine a manager saying, "I don't agree with these decisions, but you need to do A, B, C." This might be being frank and open with your reports, but at the same time you reduce their motivation. And if top management learns about this, they won't be happy.
So yes, there is such unspoken pressure to at least not to distance oneself from the things you ask others to do, whether they come from you or from your boss.
I’ve been a manager for decades and this is the way to handle it sometimes. Life is full of things that suck but you have to do them anyway, like paying taxes or cleaning your bathroom. Why should we try to pretend that work, of all places, is exempt from that?
Wrapping it in pink wrapping paper fools no one but kills personal credibility, which is the most important asset a manager has.
Top management often does not give a shit if people are happy about the thing (who is happy about layoffs?), just that it gets done satisfactorily. So yeah, sometimes I tell my team “this sucks but just get it done and then we can get back to the interesting work.”
> Can you imagine a manager saying, "I don't agree with these decisions, but you need to do A, B, C."
Some of my best managers, on well-regarded teams, have done exactly that. Those managers are doing me a favour by flagging that it's a waste of my time, emotional energy, and political capital to argue with decisions that neither they nor I can affect, and that it will be better if we just get on with it.
This is how I operate when I have a close trust with my team and boss. But I have also been in very transactional environments where I was "ratted out" for my frankness!
Yes, it happens all the time. Each time we get a new form we have to fill out to do something or some extra hoop to jump through. If the manager I worked for didn’t act like a normal person that thought that shit was stupid I would absolutely hate working with/for that liar/crazy person.
I'm not a manager, but at the very least it seems like an implicit expectation associated with the role. I wouldn't be surprised if it was explicit at some companies.
Depending on the company saying I don't believe X gets relayed back up your chain with eventual unpleasant consequences (hey so and so doesn't agree with this management decision so they must be a misfit and can't be trusted to put the company first)
Absolutely. There is no disrespect anywhere here. I don't need to agree to do my job well. Just that I don't feel safe enough to be vocal about sharing my thoughts -)
I think this is a great move. My understanding is that some reporting chains in facebook have 12 links between IC and Zuckerberg, which is crazy inefficient. Enormous organizations are able to run effectively with 5-6 links from IC to CEO. Managers managing managers managing turtles all the way down is a horrible form of "administrative bloat". You see bloat like this in enormous organizations like colleges, governments, and now monopolistic tech companies. This is besides the point that I don't think that big tech has successfully groomed many managers into people are capable of actually managing businesses; they don't drive value, they preside over decisions and make a case for higher headcount in the next planning cycle.
Wow. I'll say that even in the Army, famous for its bloat, there are arguably fewer than 12 links (following the legal chain of command) between the lowest ranking private and the President of the United States...
Of course we also pad that with a lot of senior enlisted advisors, executive officers, chiefs-of-staff, deputy commanders, etc. who can effectively be additional buffers between each echelon.
If you want a flatter org structure, it seems like it would be easier to achieve this if manager/IC roles were distinct. If a manager is also writing code, then they won't have the time to manage as many other employees, and the total number of managers/layers would need to increase.
They might be pushing hybrid manager/coders to move back to full IC / tech lead type roles, while keeping the dedicated managers with bigger spans of control. That would have the effect they want, anyway.
yea, I don't think the manager/IC thing is a point of leverage TBH. I think the real issue here is that you have senior managers that manage 4 ICS and 1 manager of a 6 person team, and that manager should just report to a director and the senior manager should be retitled "manager" and manage 8 ICs instead of 4.
IC reports to tech lead manager (link 1). TLM reports to senior manager (link 2) senior manager reports to other senior manager (yes, this happens, link 3), senior manager reports to director (link 4) director reports to senior director (link 5), senior director reports to VP (link 6) VP reports to SVP (link 7), SVP reports to C level (link 8) C level reports to CEO (link 9). I saw these reporting chains when I worked at FAANG, and I can imagine its pretty easy to stuff 3 more links in here to hit 12.
I have seen such chains at Amazon. IC -> Manager -> Sr Manager -> Director -> VP -> SVP -> CEO of AWS -> CEO of Amazon.
That's only 7, but some links repeat. For example, I have seen Sr Manager report to another Sr Manager. Likewise, a VP report to another VP, and a Director report to another one.
At Meta many engineers tried management and then went back to being an individual contributor. I'm not sure of the exact numbers but it was a very common career path. It did build up empathy for management on the senior IC side and meant that teams didn't get stuck with managers that didn't actually want to be a manager. If the company is not growing headcount this move makes perfect sense.
That's a pretty common thing once ICs reach a certain age. I've seen it everywhere I've worked. Sometimes it's because they fear age discrimination but more commonly I've found it caused by the organization not providing a great career path beyond a certain level. With wisdom comes the ability to accept that it's OK to stick at an engineering career level for years at a time.
Chamath talked about manager bloat on a recent All-in podcast in a way that seemed to make sense. Basically there is pressure to grow your career by moving from being an IC to a manager and once a manager there are incentives to grow your number of reports. The organizational efficiency suffers when you have top tier ICs start managing teams of average people. You might get a team of 6 engineers that’s only doing 2x as much work as the former IC that’s managing them used to do, which means the cost per unit of work has increased tremendously.
If the reward for competence is promotion, in the steady-state equilibrium everybody's incompetent at their current job: If they were competent, they would have been promoted into a different job.
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.
The premise of this always puzzled me. I’ve seen many people “promoted” to a “higher” level because they displayed characteristics that they would be more successful at that role than anyone else despite lacking competence in their current role.
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.
It is called 'Up or Out' culture. It is practiced everywhere, even in the military. You don't see 50+ year soldiers, do you? Except may be in 'Top Gun' sort of movies, which just only proves the point.
You are supposed to retire or give way to top performers to take the top places.
Some organizations have tried to limit manager-bloat by offering an alternative track for ICs (senior-> staff -> principle -> whatever). But the expectations at those levels have been hard to define and individual output seems to plateau or even degrade back to 'senior' level or even less when these high ranking ICs are asked to join a plethora of meetings on behalf of the team.
He hired the painters to complement him, he never stopped painting altogether. I’ve seen the same pattern work. Make star IC a TL, pair them with good product and manager, add many engineers who can take care of all the simpler work and let the star do the main work. For orgs which can’t or won’t hire “A people”, this is the only workable solution I think.
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.
By that structure, the maximum number of people that such a company should have is 7×7×7×7×7 = 16807 Given the best practices of number of direct reports [1].
How would you deal with the rest 30,000+ Full time employees that Facebook has?
> By that structure, the maximum number of people that such a company should have is 7×7×7×7×7 = 16807
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.
I would say it's about as popular among the gamers at Meta as it is among gamers outside the company. I play it myself periodically, but I wasn't even aware that Mark was a fan of the game, and I've been here a long time.
The vast majority of the managers I've worked with wouldn't be particularly good ICs, not so sure of the wisdom of this move. Maybe it's a way to slow roll a bunch of layoffs.
Depends on the company, of course (and I've no idea how it works at Facebook), but some companies make their EMs out of ICs (much like Pokemon, I assume touching a special rock is required to effect the evolution) and it's somewhat common for EMs to re-IC-ify on their own anyway.
When the EM becomes an IC, how does this help the team grow their own skills and not get distracted by problems the EM should be moving out of their way?
When the EM is an IC, what stops them from either interfering with small stuff (I had an EM -- back then we called them "managers" -- stop us for a week trying to determine whether we should use List or Vector in Scala. Nobody was happy) or taking the big interesting problems for themselves?
> When the EM becomes an IC, how does this help the team grow their own skills and not get distracted by problems the EM should be moving out of their way?
Well, generally the team would still have an EM, just not that EM.
> When the EM is an IC, what stops them from either interfering with small stuff
> Well, generally the team would still have an EM, just not that EM
If there is an EM role, I don't see the problem. I took TFA to mean "become an EM who also codes".
> What stops any IC doing that?
Nothing, but an IC has by definition time to tackle big problems. Also, other ICs are their peers. An EM+IC has no time to tackle big problems -- or if they do, then they are neglecting their management role -- and so by default will tend to focus on nitpicking or small tasks. Tasks that are best done by junior level ICs.
I don’t really understand the first question, but do you mean that the capacity of an EM to spend time on growing team skills is reduced? There is a limited amount of time a manager can spend on that. If it’s a small team, then they could do a good job at it whilst doing small bits on the side.
For the 2nd, I imagine that if you are a manager and an IC on the side, then you don’t have the time to spend on big projects. It’s more likely you’ll be filling in gaps or doing the uninteresting but necessary work. There’s nothing stopping you from attempting to hoard the interesting projects, but then your performance on either role or both will likely suffer. That’s not really a new failure mode - any manager can be bad.
As a manager + IC, you shouldn’t be leading projects, since that’s a useful skill for your reports to develop. I guess there may be exceptions if your team is particularly junior. Ideally, if you are not micromanaging, you only participate on a big project if required or asked, not because you want to. Your main role is the people management side and to help with planning, prioritisation and communication.
> do you mean that the capacity of an EM to spend time on growing team skills is reduced? There is a limited amount of time a manager can spend on that. If it’s a small team, then they could do a good job at it whilst doing small bits on the side.
Yes, that's part of what I mean (but also: dealing with red tape, bureaucracy, and removing impediments) and no, the amount of time that can be used for this is basically unlimited: it's a full time job. "Small bits on the side" is not a good use of a senior IC, that's for the more junior members of the team.
I don’t think you treat the team manager as a senior IC. You treat them as a mid-level IC with a part-time job. If you are a manager you can’t also be considered a full-time senior IC (except in very specific cases, which should be transitionary) for the purposes of work allocation, because you can’t dedicate your full time to the job.
I don’t think management is unlimited work, at least not always. There are a fixed set of people on the team doing a fixed number of things who can only grow at a fixed rate. I agree that it could be a full time job or more, but I think that depends on the specifics. Obviously managers shouldn’t be forced to be ICs in all situations. If management is taking up all your time, you can retract from the IC pool. However, I think it’s valuable to consider and push for organisational changes to allow yourself to enter the IC pool again (maybe handing off some responsibilities to a new team etc.).
> failure mode driven by two conflicting goals
Again, I think this strongly depends on how you allocate yourself. There is room for a pre-emptible IC, that is not always available. However, it’s situation dependent whether this is useful or not. The conflicting goals theory only applies if you try and optimise for both. Your IC performance can suffer, whilst still being a net positive, again depending on the specific situation. That’s kinda upto you as a manager to quantify though. The article is more good advice on how not to approach this dual situation. If you know how to prioritise being a manager though, the points don’t apply.
On the flip side, sometimes your management performance HAS to suffer to meet critical deadlines because the entirety of the normal IC pool has other critical deadlines. It’s also upto you to avoid these situations, and if they happen then strongly push back on your leadership to prevent them happening again.
Your primary goal as a manager is to ensure team productivity and deadlines. If you can’t recognise that you are a detriment and step back (or at the very least step back when you get feedback from others who do), then that suggests that other aspects of your management are lacking as well, so it seems like the same failure mode.
The benefit to keeping yourself in the IC pool is that you can keep your skills at least slightly fresh. Even if you are no longer a full senior IC, not having any technical skills means an inability to make technical judgements if required.
All I can say is that in my experience I've only witnessed (and on occasions been, sadly) the dysfunctional kind of EM+IC. I've never witnessed it working well, which is what I'm basing my objections on.
The best managers I had were full-time managers (with an engineering background, which meant they understood the technical constraints); the worst managers I've had were either 100% non-technical, or EM+IC roles which just couldn't keep their paws away from coding.
Eh, not necessarily demoted; many companies, and I'd assume Facebook, would have IC levels parallel to their EM levels. They might be looking at... sidemotion?
> would have IC levels parallel to their EM levels. They might be looking at... sidemotion
Sure. Many companies do this too. Like Senior Engineer at the level of Engineering Manager and Staff at the level of Senior Engineer Manager.
They don't have direct report and they still write code.
Same payband and leveling but different job function.
But at the end of the day, the ICs still have to "report" to Management: Senior Engineer even if they have same payband and leveling still have to report to an actual Manager.
> When the EM becomes an IC, how does this help the team grow their own skills and not get distracted by problems the EM should be moving out of their way?
Meta EMs do people-management only, which neatly side-steps interference on tech issues.
"Here's an option you'll hate—take it, or leave" is a tried-and-true way of making people quit. "You've been re-assigned" is a common form for it to take.
No, because these positions are genuinely being offered as an alternative to being laid off. If you choose not to take the new position, then you have terminated yourself.
Well the details are important here - are they being laid off, or is Meta suggesting they quit and then forcing them into a new role? The beginning of the article just says they're "asking" them to leave the company, not firing them, and I can't read the rest so it's a bit unclear what they're doing.
If an actual layoff is the alternative, rather than being fired for-cause (after failing at being an IC, perhaps) or quitting, then yeah, it's not really constructive termination. I can't read the article to see if that's the case, though.
Individual contributors is just a fancy name for a software engineer without direct reports. Aka you'd stop being a manager and just write code (for the most part).
Anyone non-tech I know would just call it "labor", as opposed to management. The people who mostly do the things that make the stuff, rather than mostly telling others to do the things to make the stuff.
Again, people'd just say "labor" in other contexts. Or maybe "workers". I'm not sure where "IC" came from but I've never seen it outside of tech, and that, mostly online.
I think “labor” is associated with repetitive or at least well characterized jobs
In tech, any two given workers are much less likely to be doing the same thing. So they are clearly not just laboring but contributing at some creative and self-management level as well
Non-managers, they aren't responsible for anyone but themselves. I know nothing of Meta's specific titles but I'd expect that e.g. the first level of full time engineering manager would convert to a full time senior or staff engineer.
Yep. Used pretty often. Attempting to fight things like that without a union backing you is scary and risky enough (plus lots of people just have no clue what the law says—which, who can blame them when it hardly matters?) that it usually works just fine. Probably a little more dangerous with employees as well-paid as at FAANG, but then again, if they ever want to work at that level anywhere else, they're not gonna want to rock the boat that way.
It can't be that difficult to contribute to the achievement of absolutely tanking the company's value by investing in a dead-end VR-for-work platform that was always just a distraction to avoid responding in any way to Congress pressing him about election interference.
I absolutely don't know why Facebook balked at making their own phone back in the day. Facebook's entire value prop about 10-15 years ago was the fact that you could find anyone on there who you even remotely knew.
Imagine (10 years ago) being able to use an FB version of Siri/Alexa to "connect me to that girl Megan from my 5th grade classroom". Sure sounds compelling.
Instead FB released a half-assed "dailer app/widget" and forgot about it. Today that window of opportunity closed.
I think Facebook didn’t have the kind of capital to do it at the time they would have needed the captial to make a phone. Keep in mind that the Windows phone was reportedly pretty good but came out in 2010 and it turned out the smart phone space didn’t give out prizes for third place. People always underestimate the cost of developing a smartphone, even when working with modern OEMs, never mind working in the 2008-2010 time frame.
They tried to make their own phone but it just didn't work out. So they ended up releasing something just so they could show something after all that investment. Of course teh company was much smalelr then.
> I absolutely don't know why Facebook balked at making their own phone back in the day.
Because it's really hard to make good hardware cost-effectively. The only companies that have succeeded in the phone market are practiced hardware companies, except for one software company that focused on making a adaptable OS for hardware companies to use.
> Imagine (10 years ago) being able to use an FB version of Siri/Alexa to "connect me to that girl Megan from my 5th grade classroom". Sure sounds compelling.
I agree that fbs value was/is the social graph. But you’re saying that there was a lack of voice UI? Or lack of a capable mobile experience? I don’t see how any of that could have been more than marginally helpful in reducing the friction of adding a friend on a social network.
> I absolutely don't know why Facebook balked at making their own phone back in the day
Microsoft and its phone story is enough to explain why.
Facebook needs a new platform that they control themselves and Phone is D.o.A because they have to compete with other companies (Apple, Google). Nobody wants to have 2 phones and nobody wants yet-another-Android phone "just for Facebook".
No, Facebook tanked their own valuation. They monetized user data without a care for how those users might eventually feel. They became entitled about having that data and the revenue streams attached.
Apple took the opening Facebook left unguarded by realizing people actually do value privacy in their products, and made technical and marketing investments in it.
> Apple took the opening Facebook left unguarded by realizing people actually do value privacy in their products, and made technical and marketing investments in it.
Yeah, and that's why Apple's ad revenue has grown massively since ATT was introduced. Because Apple care about privacy /s.
Harsh, but potentially fair. I think that pre-2016, there was definitely more expectation that managers should be graduates from IC ranks, but that got lost around one of the (many) doublings of headcount FB experienced over the last decade.
I love management and, after over 17 years in an IC capacity, find that it fulfills me in a way that writing code stopped doing. I was also a manager at Meta in a past life, and really didn't love the experience due to the nature of the company and roles of manager. I do think I'd really like being an IC there, due to the high level of autonomy and focus on doing impactful work.
> There must be something else which you are thinking about when wording it with this positive connotation?
A surprising number of teams are NOT involved in things like news feed, story ranking, "engagement", etc. Some teams, like my own, were building foundational technology for things like AR/VR, wearable devices, mapping & navigation, etc. A concrete example of "impactful" work done by such teams was just posted on LinkedIn, which is a focus on building maps geared towards pedestrians walking around, not cars driving. This is a building block for eventual AR use cases, among other things. The team building this then enables other teams up the food chain to use this in building what eventually becomes part of an end-user product.
Thank you for taking the time to answer my question! :)
I suppose it's a matter of weighing "a set of many small utilities which make life a bit easier for N people" against "two big dangerous social networks which make life a lot harder for M people". Because the money from the former helps the latter as well.
Meta's has a corporate value for "Focus on long-term impact" which is trying to counter short-term gains that don't produce over time. They also talk about how you can make a "big impact" as an IC there, which from what I know is true since you can work on big projects, but they aren't necessarily the projects you'd want to work on if you have some form of value system that includes empathy.
Years ago, I met someone that boasted about doing auto-play for videos in your feed so that get sucked into related video after related video. He was particularly proud of implementing a feature (he worked it out with the PM) where you could only delete one video at a time from your history instead of in batch. The goal was to make it harder to purge your data and frustrate the customer so they give up. Ultimately they wanted more data on you so that they could further "optimize" the app to better suit/manipulate you. Pretty sure this is what they mean by their company core value of "focus on long-term impact."
Somebody at Meta worked really hard to make sure that when I'm using Facebook on my phone to read someone's post or comment thread, it punishes me for taking a call or answering a text message by reloading my feed with a set of completely different posts when I re-enter the app, and then making it impossible to find the previous post or thread again.
No other app has gone to such extraordinary lengths to make sure you can only view a piece of content once, and then hide it from you forever after.
I use FB via browser and have not experienced this behavior there. But I do see it in the LinkedIn app all the time. Even if you click into a posted article, when you exit from the article you won't be able to find the post so you can comment on it!
I use FB via browser and this is constant on iOS. If I am going through my feed and I click a link to another site, it opens a new tab and when I return to the FB tab I see it reload the page and I lose my spot. If I try to scroll down to find the same item I clicked on (because for example I feel like commenting), it's almost always gone. Nowadays I just take it as a reminder that FB is either deliberately manipulating me or just doesn't care about the UX, so I close the FB tab. I'm not doing extra work to make up for their user-hostile decisions.
have you met the desktop version of tiktok ? they went out of their way to make it not possible to click multiple suggested videos in new tabs and all others kind of anti desktop measures.
Okay I'll feed the troll. There are only a few places where if you implemented, for example, an effort to reduce "body dysmorphic disorder", it could instantly improve the lives of 3 billion users worldwide. Meta is one of those places.
I just genuinely don't understand why someone would consider working there as a positive thing.
So I would like to know!
But I have no way to figure it out as I know zero people who work there, and talking to a human who works at these companies is impossible because their websites are geared towards not allowing you to talk to them.
So now that I just saw someone in the wild to ask, I figured I should use the opportunity to figure something out which I absolutely do not understand.
> There are only a few places where if you implemented, for example, an effort to reduce "body dysmorphic disorder", it could instantly improve the lives of 3 billion users worldwide. Meta is one of those places.
It surely is a zero-sum to fix the problem which your company has created in the first place???
It's hard to believe you're not trolling when you present "millions of teenagers with body dysmorphic disorder thanks to Instagram" as the only kind of 'impactful' work.
What about people working on WhatsApp, or infra, or people working at FAIR or people building React, etc? The list goes on.
Meta creates a shit ton of positive impact which is not at all related to "millions of teenagers with body dysmorphic disorder thanks to Instagram".
They said that was the first thing that came to mind. The first thing that comes to my mind is fueling a genocide in Myanmar[1], but as a parent of a girl, I couldn't care less about Meta's development of React when their own research showed that they "make body-image issues worse for one in three teenage girls." Then there was the Facebook–Cambridge Analytica data scandal. It's been clear for years that to work for Zuckerberg is to do anything that he thinks will make him rich, the consequences for our children, our democracy, and the rest of the world be damned.
If you look at the actual leaked documents from FB (via the WSJ), then you can see that over 1/3rd of girls had their body dysmorphic issues improved by IG.
Oddly enough, this didn't get reported on very much by the media.
I don't see their comment as trolling. Reducing the negative impact Meta already has is a more accurate description. Given their track record so far, you'd be a tiny minority to even get to work on that instead of ad/user engagement optimization for example.
For every teen with poor body image issues there are likely 5 people served by Facebook in some way that they deeply appreciate. I talk to family members in Algeria who I'd never be able to reliably keep in touch with otherwise, and friends in Europe love FB marketplace. Yes, a service for 2-3 billion people has drawbacks. It's disingenuous to say that it doesn't improve the lives of hundreds of millions of people, though.
Facebook's algorithms fueled the genocide in Myanmar. How many muslim lives is FB marketplace worth?
Do you talk to family members in Algeria through FB or WhatsApp? WhatsApp would have been just fine if Zuckerberg didn't buy it before US regulators rolled out of bed.
I think it's hard to argue that anyone's life is improved by a company that shows such a lack of respect for its users. We could have social networks that respect us, but Zuckerberg systematically purchased them or squashed them in the cradle.
>Facebook's algorithms fueled the genocide in Myanmar. How many muslim lives is FB marketplace worth?
FB marketplace didn't cause those bad things.
FB has done bad things due to perverse incentives, but for individuals working at the company you can't deny that at least some people can have a positive experience making positive impact to the world.
The lungs plead their innocence, “We give life!" But the blood they oxygenate feeds the mitochondria that fuel the muscles that power the claws that tear into the lamb's soft belly.
To be slightly less cynical, I think they just mean that individual engineers at Meta are responsible for large chunks/vertical slices of work, so your work has a lot of individual impact on getting things out into the world.
This is the "correct" interpretation. Of course, it's sometimes a perverse incentive since getting something out and moving a needle or getting another team to use your work is also "impactful", and leads to many of the negative (intentional or not) issues caused by the apps.
Even if you don't think that some people find value in Meta apps, Meta engineers work on all types of project, lots of them are open source (see https://opensource.fb.com) and are impactful beyond just supporting Instagram.
Schools have caused many millions more teenagers to have such disorder, is there no impactful work to be done in schools?
In fact, the same research that likely was used to see such an opinion for you about Instagram in fact showed that it was more likely to improve stuck disorders than to make them worse.
I want my career path as a developer to never be anything but individual contributor. I like teaching newer Devs but I don't want to manage them. Maybe I'm being naive?
Some people spend their whole careers like this, there is nothing wrong with it. I personally avoided management for years, until I was offered a lead role over a team of roughly 4 people in Feb 2020. I had been working on the product for years and knew all the ins and outs and had a vision for its future. Cue the pandemic and everyone going remote - and the project ballooning to 25 people across three organizations. I absolutely thrived. I realized I’d done everything coding wise that I was really interested in, and that job had grown stale. I have matured, and found I have more social skills than in my 20s and early 30s. I found that not everyone could or would be interested in driving things where they needed to go to successfully ship a product. You may someday surprise yourself at how your interests and capabilities evolve.
The principal engineer role usually comes with expected impact on a big organization or even the whole company. Having that kind of impact is impossible as an “IC” in the traditional sense. Unless you are in some very cutting edge area, or get very lucky, your principal role will involve a big dose of the same leadership and management tasks that a manager or director would have.
So what is your vision of IC "in the traditional sense"?
Most senior engineers at organizations require a significant amount of coordination and people-skills. If you're not managing a team, you're definitely managing the relationship with your manager and coworkers/project teammates.
My vision for a "traditional" IC is someone who sits in front of a computer and writes computer programs. This kind of role ends at senior, or if you are lucky, staff. A principal engineer is much more likely to be in a meeting heavy environment, coordinating with many teams and driving alignment towards some vision. While this is not strictly managerial work, at least to me, it seems to fall much closer to "senior manager" than "software engineer".
Thats totally fine for folks who thrive in this kind of role. However, it does take away the ability to grow your career if you want to keep developing software. So for example, if you program for 20 years, and keep improving during this time, you would expect to be rewarded with some career progression for the progress you've made in years 10 - 20.
But as it stands, these days, if you run into someone who has been programming for 20 years, you can assume their career has mostly stagnated, and might even count them off as a low performer because they failed to grow. So it's almost a self fulfilling prophecy - staying a "true" IC has no growth, and therefore there is an incentive to just sit back and stop growing.
> The principal engineer role usually comes with expected impact on a big organization or even the whole company.
Yes, but you're not managing people. It's a lot of collaboration and leadership, certainly, but not doing any of the HR-adjacent bureaucracy that comes with being management.
I've been in a role like this for many years in a small company. I doubt it would really work in a rigid FAANG environment with formalities like levels and performance reviews and all that - it would get too political and competitive.
Other managers will always try to change your mind on this. When layoffs come around, they usually are more likely to get laid off and their tech skills are now stale and they have to rely on their 'network' to get another management job if they're lucky. Not a position I want to put myself in.
This is a pretty well-defined role in FAANG. Usually the promotion criteria to become more senior as an IC will require demonstrating mentorship.
Separately, there is also the Tech Lead track, where you don’t get reports, but rather final say over an increasingly larger area of influence and drive cross-team/org projects.
I've been working professionally for 22 years and am still an individual contributor. I've refused all attempts to move me into any kind of lead/manager position.
How far along on that career path are you? You may find that teaching newer developers is not all that different from formally managing them.
As for a technical track, read the stories on staffeng.com. And read between the lines when you’re viewing them. There are plenty of folks with technical track titles who spend most of their working hours in meetings of questionable value. And you will definitely find folks with management track titles that spend more time doing hands on work than their peers with technical track titles.
The ugly option you can try is good old-fashioned sandbagging. Knock out every technical assignment in record time, or quality, or whatever seems to be your leads KPI. Then tank any assignment which seems remotely conducive to management. Bonus points for explicitly indicating a desire to move into management. Your own leadership will think you are so miscalibrated as to believe they are doing everyone a favor by keeping you off the management track.
Edit: I realize you did not explicitly ask how to stay off the management track. Consider the last paragraph as just some idle, slightly sociopathic musing.
Staff Engineer¹ is the path for you my friend. If you don't want to manage people, focus on creating maximum impact on your project.
I think the term IC is a misnomer and is detrimental to our field. Afterall the code you write, the designs you make etc are part of the larger puzzle which completes the project. No work you do is in isolation.
my advice is to keep doors open. You will age and your needs and expectations may change. You can always start a transition to take on more managerial duties while doing individual contribution.
>I want my career path as a developer to never be anything but individual contributor. I like teaching newer Devs but I don't want to manage them. Maybe I'm being naive?
You can do this, but you will have to accept the plateau. There's really nowhere to go beyond Staff/L6, unless you're some super genius full of brilliant ideas or luck into being involved in a game changing product launch. Everything beyond that becomes politics.
The same applies to being a manager though. You're not going to get promoted forever in any role, at some point you'll hit a terminal level, whether that's in an IC track or a management track. And it's not a problem as long as you find your work fulfilling.
It depends. If you're able to side-step the middle manager doldrums to Director/VP, and you know how to play the game, the sky's the limit. But IC's are pretty hard capped at L6 short of being involved in the creation of a new business.
Well I guess the difference is that the top of the technical leadership track is ostensibly CTO, which is a “higher” role than you’d typically see on the IC side.
That said I totally agree with you overall and think the argument you are responding to is a little silly. You can have an absolutely fantastic career staying IC forever. The fact that you might cap out at “staff/principal/whatever engineer,” a hugely influential and generally very well paid role, should not be viewed as a downside to that track.
Well, in terms of the org chart, you’ll always be higher at an equivalent point in the management track compared to the IC track (starting from team lead, who will report to the team manager), but that’s not necessarily mean there’s not that as room for growth.
Even the CTO can have incredibly senior engineers reporting to them as a consultant of sorts. Sure, the probability of arriving at that role is low, but then so is the probability of becoming CTO.
I've said it before on here: being a lower-level manager in a large company is worse than an entry-level job.
No one cares about your job experience (all those painful internal tools you now have to use to manage and report on your team) so you're just expected to grit through all the broken processes and inefficiencies (kiss your evenings and Sunday afternoons goodbye), and you are mostly powerless, particularly in orgs with centrally managed budgets.
This actually sounds like a meaningful change, unlike proposals from the peanut gallery "to fire the CEO for layoffs," instead demand more output from those you keep in exchange for a job.
That is interesting. I've been working in the field professionally for 22+ years and I've never had a manager that had any technical skills. None of them could even begin to do my job.
> I've been working in the field professionally for 22+ years and I've never had a manager that had any technical skills. None of them could even begin to do my job
Technical skills may or may not be required, but understanding is...
"Each of my managers explained carefully his own theory
of what had gone wrong and all the theories were
different. At last, there breezed into my office the most
senior manager of all, a general manager of our parent
company, Andrew St. Johnston. I was surprised that he
had even heard of me. "You know what went wrong?"
he shouted--he always shouted--
"You let your programmers do things which you yourself do not understand."
I stared in astonishment. He was obviously out
of touch with present day realities. How could one person
ever understand the whole of a modem software product
like the Elliott 503 Mark II software system?
I realized later that he was absolutely right; he had
diagnosed the true cause of the problem and he had
planted the seed of its later solution. "
That must suck (unless you're really senior in which case it's normal). Hilariously enough, I learned so much more from my one non technical manager at FB but having leaders that understand what you do is incredibly helpful.
Yeah, I've never worked for a FAANG company. I do work for a Fortune 100 company, but it is not a tech company (When I was hired, I was once in a meeting where I heard the founder of the company say that we would never have an IT department because we were not a tech company. We do have an IT department now, but that happened after the founder gave up the reigns.)
Sure, neither do I (now). At that point in my career though, it was incredibly helpful and levelled me up significantly in a relatively short space of time.
But agreed that your manager should set goals rather than plans. Fun fact, at FB at the same time all ICs came up with their own goals rather than these being passed down from management.
Kind of my thoughts as well - it's "cool" there are technical managers out there and engineering managers should be technical "enough" but I'd never expect them to be competent with all the ICs' jobs
At Netflix I can't think of a single manager at any level managing engineers that didn't start as one, all the way up to the CEO. In some cases they couldn't necessarily do their employee's job, but they at least understand the technical aspects well enough to make useful contributions to technical discussions.
Pretty much all my Google managers were ex-ICs who would have been fully capable of jumping into the codebase if they had to. Some of them still did, if they could squeeze it in.
Wow, in my 15 or so years I've never _not_ had a manager who had engineering chops. Admittedly, I prefer working for smaller companies so this has often been a hands-on CTO, and I was filtering these job opportunities for technical leaders that I respected.
The managers I enjoyed working for the most came up through the ranks and were better at my job than I was. But that was only maybe 25% of the time in the 20ish years I spent as an IC. The worst for me were the ones with no understanding of how I did what I did.
That is interesting. I've been working in the field professionally 20 years (I'm not including grad school or postdocs) and every manager I've had had technical skills (deep ones) although most of them couldn't have done my job exactly the same way I did. Some would have done it better. Others, worse. Even others- would have cancelled the project, or morphed it into something else entirely.
I've been a manager once- only because of necessity while working at a rapidly growing startup- and it's not a role for me. I loved being an IC at Google and other employers, and no matter how much I tried, I couldn't convince myself that by being a manager I'd have more impact, or achieve more of my goals, or be happier.
I'd like to see more people-managers who aren't also product-managers and tech-leads: people whose job is to manage people, not work on the technical side of what the managed people work on. Some people are really good at this and should focus on it, to the exclusion of coding.
> I'd like to see more people-managers who aren't also product-managers and tech-leads: people whose job is to manage people, not work on the technical side of what the managed people work on. Some people are really good at this and should focus on it, to the exclusion of coding.
I’ve worked with managers like this but they were pretty rare ime. Most of the time it’s either a product person or someone who is subpar engineer grabbing the power seat bc that’s the only way they ever going to have any say in anything
I've never worked for a truly large company, so maybe I lack perspective. But the idea that a company could incorrectly hire THOUSANDS of people over a few years boggles my small-company mind. Hiring is so exhausting, so time intensive and so boring. And it does nothing (directly) for the bottom line - instead it costs a ton of money! Given the ultra-mega-hyper-elaborate interview process at a lot of these companies, we're talking literal fortunes on top of fortunes worth of manpower (er, personpower?).
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?
When you believe in a new technology and mission, as many at Meta do about the metaverse and VR, hiring isn't boring. It's exciting to be able to bring on more people to execute a vision you're bought in on.
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.
because the hiring process is on autopilot and the leadership of the company has already exited / checked out so they're not incentivized to care or be in the weeds enough to preemptively put a stop to it.
At a previous company, I reported to a "group leader" who had no other reports. That person reported to a director who had zero other reports. That person reported to a VP who had one other report.
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/
For this work, there should be equal rewards for ICs and managers. That is, ICs should get equal probability to get to level X in the company as managers. This actually used to be the case in old big tech, in early days. ICs can get to all the way to Director and Distinguished level with equal probability of their managers. But during last couple of decades everything changed. Big tech career ladder now states that merely making impact is not good enough but one needs to "scale" the impact. This is sheepish way of saying that one must be manager in order to claim "scaling". Consequently, there no higher level promos in big tech if you are mere IC. Unless this is solved, everything else is just talk and wishful thinking.
Good managers are few and far between and there are many ways to fail in the role. If you have low level ICs then you’ve got to be contributing as well, leading from the front. If you have high performing ICs then you need to instead be a coach, protecting and representing your talent to the next level up.
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 think my read for the reasoning is more like ‘meta made managers out of ICs in expectation of continued hiring. Hiring is not expected to continue so much so now they need fewer future managers enough to have some managers go to being ICs’
I know the general view is middle management sucks and I can see asking first level managers to become ICs may make sense in some cases, but that also means someone else is managing x times the number of employees. How is that supposed to scale?
I mean, if there are lots of managers at Meta who only have 4-5 direct reports, you could see this scaling decently well -- turn two teams into one, and that's not so bad.
But I don't think one person can constructively manage more than about 20 engineers at the absolute maximum.
My company does yearly 360s. But you only can rate peers and maybe one level up. I think they could flush out incompetent managers (there are many) quickly if people could rank managers several layers up. I can think of several directors who basically destroyed the culture of their department. They were good at talking to their uppers but made horrible decisions in hiring and management. But there was no way to raise this issue in a safe manner.
Every company should set a 6 month trial period on engineers turned managers. I only know one or two engineers who ended up enjoying it. It's far, far more likely to dip your toes into it with enthusiasm and realize you hate it. It's not about not trying hard enough, about social skills, or it being "a totally new job with a new skill set and you're not used to it yet". It's about your personality type.
Ask yourself:
Do you like being in charge of people, or do you like being in charge of the codebase?
Do you like solving your problems by asking people to do specific tasks for you, or would you rather solve a problem yourself?
Would you rather take a breadth first depth first approach to you work?
Are you good at planning, logistics, and deadlines, or are you more comfortable with going with the flow?
This is interesting. During my last job search I talked to colleagues who had positions at Oculus and Tesla. Both of them talked about things being set up for either management or IC, but not both. I prefer to do some of both. Just management would lead to my IC skills getting rusty, which would mean that some of the management that I do would become more and more disconnected from current practices. Just being a high level IC can divorce you from determining the direction of your work. High level ICs who've never dealt with the realities of managing projects or programs can be frustrating to deal with since they may not understand why things can't always be done in the perfect way.
Your preference is actually well reflected in the higher level IC roles at Meta/Google. You can get there by direct eng work with significant impact, but it’s more likely you are a person the company can trust with managing delivery of high complexity, high value projects while bringing other teams along the way.
I was an engineer, then a manager, and now I'm transitioning back to about 80% IC work. There were a couple big obstacles.
- Getting your skills back means getting hired to do engineering in the absence of sharp skills. I had to fake-it-to-make-it for a little while.
- Moving from manager to IC is a risky story on your resume, where you want to show continuous growth. You can't take just any IC role. In some way it has to show a positive career trajectory.
Now that I'm over the hump things are great. I love engineering and am glad to do it all day.
I am infinitely more happy as a PE than as a manager. I get to spend all of my time on technical strategy, have nearly authoritative control over no just my org but over sister orgs as well, and no need to write performance reviews and do the whole HR song and dance. Being a manager was absolute hell in big tech, not even sure why I pursued it in retrospect when I had the technical skills to be an IC at the same level and beyond.
I've held a number of roles in tech from IC to sales to engineering management to product management and now back to IC. The problem with engineering management is that its difficult to quantify the things that make someone a good technical manager. I'm not even sure its always the same set of things in every organization. So its very easy for there to be many really bad EMs hiding in plain sight at places like Google and Meta. Its just really difficult to tease apart what an EM's contributions to team success actually are, and whether a team's failures and successes are even properly laid at their feet when there are so many confounding factors.
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.
Can anyone explain the difference between Netflix (only a moderate layoff back in mid '22) vs. the rest of the FAANGs and tech industry? IMO its likely cultural and a demanding environment for high performing self-driven ICs with A LOT less hand holding from management on "career growth".
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.
Well said! I think my experience with this was combined with a cover-your-ass HR team that was very hesitant about putting anyone on performance review (PIP, etc) without loads of documentation and 2nd/3rd chances.
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.
Things are not as black and white as they seem. It's a spectrum - from people who detest mgmt to people who realize the value of it. You fall somewhere in the spectrum depending on your experience in the industry and depending on your experience with past/current managers. Unfortunately, at some point managers (M1, M2, VPs, etc) take undue advantage of things in an organization and dilute the true picture to an extent that all management seems worthless. Having been on both the IC and management side I can relate to and appreciate the importance of both roles. What Meta is doing is right, but be careful when speaking about management in general.
What a 'brilliant move' to purge the middle management! At many places, all but the super smart love to climb the management ladder. This strategy will force them out.
(Can't post on /. and not interested in creating an account.)
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.
I agree there are good managers, but I've only had one who I can say made my life easier and helped the team be more productive.
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.
Where I work we just had a round of layoffs and it was almost all middle level managers. I guess now it's the time where individual contributors that directly create value are more important than people who mostly organize and communicate.
Wonder what this will do to what is left of middle management.
I've avoided every attempt to make me management. I've changed roles, intentionally shutdown workstreams when they were done instead of creating a new silo. I just want to work on things. I would be happy about this, but I'm sure others aren't.
It's interesting to watch the forces that determine how deep and wide management levels can get.
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.
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 think this really shows how much Meta has changed. It's not the tech-first startup company it once was. It's become just another generic big company at this point. The only reason they would be asking managers to become ICs is if they fired too many ICs and didn't fire enough managers, and now the ratio is skewed. Why would they do that? Because they're a typical company and they see managers as "super-employees" who are smarter, faster, better than their underlings, and so can easily do their work.
I just left a (non-engineering) role where I was a people manager of 7. It was great at first but I genuinely felt my skills atrophying, so I left to join a much smaller and flatter team.
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.
FB and Zuck have always prioritized a culture of building, and created a place (at least in the early days) where builders could thrive. Over time with massive hiring this obviously changed. If they need to further 'trim the fat' Part of this move could also be as a mechanism for selecting out people who are not comfortable with IC responsibilities as a way to identify people who would not have been a fit for FB in the early days, and thus an attempt to revise at least some of the early culture.
God help them if there's a few dozen Director-turned-IC folks running around trying to "redefine industry practice" or something because they got overpromoted as a manager
This is a kind of interesting change to see FB make to me (I had heard about this a couple of weeks ago from my brother, who was one of the ICs affected by the layoffs), as recently while I've been promoted into management at a different one of the FAANGs, I'm still doing a fairly heavy amount of coding out of necessity, maybe even moreso in some ways since my team isn't able to handle the amount of projects/work given to us without covering some of the most undesirable work.
Frankly most of what managers and middle managers do can be codified to a large extent like scheduling , tasking , following up , projections and planning. Yet instead of sticking to only these things often managers end up being the most insecure person in the team .. always looking over their shoulders to who is gaining more traction than them and continuously inventing BS projects to keep the minions busy or to boost their credibility for the next position.
Maybe this works with managers overseeing 1 or 2 people. But any broader than that is likely to be counter productive.
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.
I mostly agree with you and I think it highly depends on the organizational complexity.
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
Don't managers have enough work on their plate already? Looking at my past and current worplaces (granted, none of them are Meta), I can't imagine juggling individual contributions and managerial responsibilities.
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.
This, I can agree with. I know first hand failed software engineer that turned into engineer management at FB just because they didn’t know how to do anything. So management was their escape route to success. Shuffling things around, rarely adding value.
They should either prove themselves valuable or just leave.
Hmm, it might be a good time to join Meta without the management dumpster fire going on. There are plenty of tech companies with little to no management like Valve or JetBrains doing well, so it might help Meta as well.
Should've just kept more of the ICs and asked the managers to leave. I'd take a less experienced person who has been doing something for the past two years over a more experienced person who hasn't.
As a struggling software engineering project manager, are there any reference material I could study up on to better help my team? I want to be a useful as possible to them.
Zuck has it right. All the worst managers/directors/VPs in engineering I've seen are people who don't contribute anything to the codebase. They actively discourage managers who want to write code from writing code. They instead encourage them to focus fully on process and sprint management. Lots of backwards ideologies in tech perpetuated by B-players who got a little too comfortable with "people management". I would think that the role of an "Engineering Manager" or "Tech Lead" or "Team Lead" etc. should all be pretty interchangeable, or at least have very high overlap.
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.
Writing code as a manager is my number 1 stressor.
As a manager, I have to deal with so much random bullshit. I don't mind it, but it's extremely difficult to manage that bullshit alongside code and sprint commitments. "I couldn't deliver" is remembered far more clearly than "I couldn't deliver because I was helping the team with X other thing that was far more important.".
Agreed. I'm a manager who doesn't write code anymore (at work) and, at best I'm adding log statements or updating documentation. I'm still encouraged to write code if I can, but it just doesn't make sense.
When I had a single digit number of developers on my team, writing code was still possible. When I started closing in on double digits, I realized that I had so many other things to do that, at best, I was only going to have a few scattered 30 minute or 1 hour blocks each day to write code. Also, a lot of my job is to handle the unknowns that come up, so I also couldn't really commit to any hard deadlines.
That means, best case scenario, I could only pick up work that wasn't high priority and that didn't require long periods of uninterrupted time. I still love writing code, but my philosophy has always been to focus on the things that only I can do. Low complexity projects that no one is waiting for can be done by just about anyone. My "staying in touch with the code" time is better spent doing PR reviews or reviewing design docs.
You are very fortunate to have had that experience.
Usually, when a manager/director/etc decides to write a lot of code, the result is barrages of rushed pull requests made between meetings. You will be lucky if the code in any of those PRs was actually run, and you can forget about enforcing test discipline, so you have to scrutinize them much more carefully and clean up when they get merged without incorporating your suggestions.
Others have answered what the words "IC" mean, but let me add that this is the usual name for the technical career track, i.e. the not-management track, meant for people who do not want to manage teams of people.
Strictly speaking, the roles of Engineer Manager and IC are incompatible; you cannot want to manage people and at the same time want to stay out of it. So in this particular context, "EM+IC" is a misnomer for "EMs who also need to be able handle tech/coding tasks themselves".
True! I meant the usual name now. For me it's the same as Engineer Manager: it seems to have come out of nowhere but it's the standard now. Before we called them simply "managers" (or sometimes "team leaders" of the non-technical variety).
PS: are you by any chance the same Izkata as the one in scifi.se?
I've been hearing it for about 5-7 years now, usually in the context of career paths. I think it became popular when companies realized that non all developers are made for management and you need a separate career track for people who want to advance, but don't want to be a manager.
Principal engineer, architect, etc all fall into the IC career path, while, manager, director, VP of eng, etc all fall into the management track.
It's more project management than people management. You likely have to lead projects and maybe a team, but you're usually not responsible for anyone's career growth (other than your own).
I also never saw this until pretty recently. At first I assumed people were talking about independent contractors because it was the first thing that came to mind, it possibly fit the context I saw the term used in and nobody explained the acronym they just dropped it there like I was supposed to know what it meant.
Took a bit longer to realize they meant individual contributor.
To clarify, EM stands for Engineering Manager not Engineer Manager. EMs are generally expected to be technical, but not be engineers writing code on top of being a manager.
I often make this mistake because English is not my first language, and I confuse "engineer" with "engineering": in both cases it sounds to me "a manager who manages engineers", not "a manager who is an engineer him/herself". Kind of like a "Product Manager" is a manager who manages the product, not a manager who is a product!
what does TLM mean? i wish that all you folks out there would understand that nobody outside your bubble knows what these daft abbreviations stands for, much less mean.
TLM (at Facebook) stands for Tech-Lead Manager - it’s a hybrid role, with engineering duties and people management duties.
From what I remember, it wasn’t intended as a long-term position, but was used in stop-gap circumstances (manager quits, tech lead temporarily takes on some people management duties) or for when an engineer was considering transitioning to the management track.
Yeah, it's an "M0" role. Generally folks who transition from senior engineer into management become TLMs. Staff engineers transition to "M1" or a full-fledged manager.
TLMs still have individual contributor responsibilities. M1s don't. The reason for that is generally that (especially junior) ICs aren't likely to push back against poor technical decisions knowing that the person they're pushing back against is also in charge of their rating. This feels quite fair based on my experience and as such I'm quite skeptical about TLMs in general.
Not true, TLMs can be D1+ level too at FB/Meta. Higher level TLMs more often than not tend to occur in more research-oriented organizations though (where the TLM is effectively a "principal investigator" type for some research area).
It’s honestly getting out of hand. It’s almost as if one requires a dictionary to communicate these days. Even though I know these abbreviations it’s just off putting.
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 actually like the term as it seems pretty accurate to me and I don’t know if a more accurate term.
There’s many types of “managers” who are actually individual contributors (eg, sysadmin, project admin).
When you get into principal engineer and architect titles, sometimes those positions manage people and sometimes they don’t.
I think it also highlights how one version of contributor isn’t better than the others. Some people only produce value by being part of a team, some produce value by managing, and some produce value direct from themselves.
I've always like the term soldier. It's what organized crime syndicates, armies, and ant colonies all use. The worst is when someone gets called a "resource", but I can't get too exercised about IC.
As a consultant, I've become accustomed to being referred to as "the resource" by operations people. However, the day an engagement manager refers to me directly as "resource" is the day I openly start referring to them as my secretary.
Nobody has IC as a title, it’s a whole class of job families that don’t require/revolve around managing other employees. Data Scientist, Software Engineer, Data Center Technician are all ICs. It’s just a more positive way of saying “not people manager”, especially when you are trying to build a culture that going into people management shouldn’t be the only career path.
why do you need to say "not manager"? most people are in the nature of things not managers. and if you do need, for bad, bad reasons want to differentiate them, how about NMs? oh, but that would be to obvious for the current crop.
Just in the past week "IC" has appeared in 2 front page stories on HN.
Are you US based? Beginning my career in the mid 00s I was exposed to "IC" pretty much day 1 starting at Microsoft.
Other people around me in adjacent sectors also use the phrase to refer to non-managers, it is pretty common daily parlance, I am 99% sure I can ask any of my knowledge worker friends and they'll know what I am talking about.
Google trends show "individual contributor" has been a pretty popular phrase since at least 2011.
> no, i am not us based, though i have worked there. but so what?
Every country, and even different regions of a country, has linguistic differences. This is true even if all the countries being talked about have the same national language.
For example, nobody in the US tech sector is going to know what a Boffin is unless they read The Register.
Even on the west coast of the US, vocabulary is different between California and the Pacific Northwest, although things started to merge together when the Silicon Valley based tech companies began opening offices up in Seattle.
as a matter of interest what, as vaguely as you like, do you work on? because you seem uninformed to me and it is not obvious to me that you know what you are talking about. there is one tech giant that has always been based in seattle. well, make that two.
You seem to be the one who is uninformed, considering you've never heard the term IC.
Yes, everyone knows there are two tech giants based in Seattle. What this person was saying is that other large companies have also opened/grown Seattle offices in the past decade and vice versa, which has caused usage of corporate vocabulary to merge.
Maybe you should reflect on the fact that you don't seem to understand what people in this thread are talking about and stop acting like you do.
so i guess that managers are not individuals and don't contribute? might be true. but i've been a manager and an individual and contributed code. well, who knows?
Lots of people who aren't part of the "working class" do plenty of work but that's the nomenclature society uses for some reason so if you want to communicate with everyone else, you have to go along with it.
The point is that ICs are judged based on their individual contributions, i.e. their own code, design docs, etc, whereas managers are judged based on their team's contributions
Why are you being so pedantic? At this point it seems like you're trolling.
> so i guess that managers are not individuals and don't contribute?
> i have never, ever come across a programmer working on a system of any complexity that did not depend on contributions from other programmers.
No one said non-ICs aren't individuals, and no one said they don't contribute. No one said that ICs don't work with others or depend on others.
What has been said, several times, is that their contributions (i.e. the code they produce, artifacts they create, etc) are largely individual contributions. They are the ones creating the thing, and are not responsible for others.
This gets a bit murky as you move up the IC chain, in that your contributions become less tangible and are in part measured on how you lead others and make those around you more efficient. But your performance is still largely judged on what you produced.
the nuance you are missing is that individual contributors are responsible for their own work and judged based on that. they are not responsible for the work of others. managers are of course responsible for the work of those they supervise
I am not sure. It has been around for at least 5 years I would say. I guess at some point they needed a nice sounding alternative category to people not becoming managers.
You're pretty much just repeating the constant engineer gripe of "What do managers even do". The point of management is co-ordination and direction. They're not there to contribute to the codebase, they're there to ensure people are contributing the right things to the codebase. If you really think these managers/directors/VPs are useless, describe what you think they're meant to be doing, and how it would get done without them.
This is the sort of thing that you don't recognize until you become a manager, and then you do and you watch everyone on your team run around like a bunch of kids chasing whatever caught their attention that day and it all becomes a lot clearer.
"Why are we doing this" and "how does it align with the business's goals" and more pointedly "what are we not doing so we can do this instead" and "is that the right trade-off" are all questions even very technically gifted engineers seem to have a really hard time answering.
The issue is most managers don't tend to think this specific way. They think of how to align the business goals to suit their specific needs (i.e. getting promoted).
Every single re-org I've been involved in was bureaucratic mess to give a manager a higher salary. There was no explicit reason why we needed to re-org, and no org change ever made a difference in terms of productivity. Our individual teams still operated the same.
It's not that they are useless, it's that there are often too many of them.
At a previous SV org I worked for, they had roughly 1 "dev manager" for every 4 engineers. You could have 1 for every 10 and achieve the same result.
I’m not sure if that’s true. 1 dev manager for 10 engineers might be tough. The sheer number of 1:1s would be insane, much less keeping track of the career trajectory of 10 different people at 10 different parts of their lives. I guess this would be less difficult if everyone was already at senior or staff level, but you’d still have so much of that managers time sucked into 1:1s, reviews, and team retrospectives. I’m not even a manager and I start to feel neglected as an engineer once my manager juggles more than 6 other people, because I see they start to forget what I’m working on, and those 6 start to compete for attention to get promotions…
I think it can go either way (and at Meta, I have no idea), but team size tells you nothing. You can have a team of 4 highly productive engineers working on a specific project with limited scope and 1 manager can manage that very effectively. But you can't have that manager manage two teams, you're literally just splitting their focus (and with 4 people the manager can be hands-on). On the other hand you have plenty of teams that were at one point 4 productive people, grew to a team of 10, now the manage is very productive! Managing a team of 10 people, but in reality that team of 10 is now struggling to work efficiently and are probably producing the same value as the previous team of 4. The management structure is entirely determined by the underlying scope of the work that needs to be done - and yes, very often it goes astray, but in every direction.
You are right about team size, but in many companies, the "dev manager" is certainly not hands on, even with small teams. The last team I was on, the "dev manager" never even set up his development environment. He always claimed he wanted to get more involved, but probably had too many other priorities. If you are managing a team of 4, not making any technical decisions, not writing any code either, in my opinion, it is a bad sign. You are too out of touch. Hands on is necessary with small teams.
In those environments, all the technical work and decisions are delegated to a tech lead / staff / principal eng. The "dev manager" is there for people management and high level sprint planning. Planning can be done with very little technical knowledge since the team itself does the sizing and scoping.
Obviously not every company is the same, but that was my experience at a mid-size SV tech company.
I understood the role of managers after I joined a chaotic startup which hired a bunch of people but didn't think of management. It was a complete mess. Senior engineers didn't want to manage, or didn't know how to do it. And good managers are very hard to find.
> They instead encourage them to focus fully on process and sprint management.
Thats literally the point. Its totally fucking batshit that somewhere like meta still uses spreadsheet to plan. This is why properly trained people should be doing management.
Project management at scale is not something you "dip into" its a full time job to project manage and people manage. Its not something most ICs should be doing.
A <Edit> consultant[1]</Edit> surgeon leads a team, but they don't manage the timesheets of the juniors, nurses and assistants. Meta very much expects that a consultant surgeon not only does surgery, but fills rostas, recruits nurses, does some marketing and works on the legal policy for negligence.
The issue at meta is that with the growth there is no "leadership". What is a lowly IC supposed to work on? "create consensus" and "drive from the bottoms up". That doesn't work when you have 11 layers of management, all pissing about talking about impact, but not actually driving projects.
> I would think that the role of an "Engineering Manager" or "Tech Lead" or "Team Lead" etc. should all be pretty interchangeable, or at least have very high overlap.
You should try it. Its pretty clear you've not managed people at any level of scale or formality. Not everything is code, babes.
(No. I'm not a manager at meta, thank fuck, it sounds pretty shitty.)
Chief surgeons do all those things you describe. Check out the job description [0] as they are basically department heads doing recruiting, budgeting, supervising, etc. Chief Surgeon doesn’t mean best surgeon.
But it is a bad analogy, as you've implied. What I was trying to get across is managers should be specialised, they should be someone who might or might not have been a programmer, but is now specifically managing people, or projects.
Managers who code, do exist, as to engineers who manage. But its better at large companies to have specialists to manage projects and people. With support, training and performance management, you tend to get a better outcome.
What’s interesting is that all chief surgeons were once surgeons, probably really good. So there’s idea that you have to do the thing to manage the thing.
Medicine is strange in many ways, but I think this isn’t a bad practice.
I’ve worked for non-dev managers and sometimes they are good. But I prefer to work for someone who at least once was a dev as I think they understand better what is possible and how to coordinate and lead.
When I managed teams I always tried to do something useful in the codebase. I don’t think it is possible to manage well and work deeply enough to make great software. But it’s possible to at least be able to do my own builds and at least test out different techniques.
I have worked with some fantastic "people managers" in my career who don't write code. But they usually faded into the background most of the time, except for when they needed to communicate something or I needed their help with something.
The bad managers were always working hard to schedule more meetings, force extra process into every step of our work, make decisions about how we did our work, and to change our priorities to work on their pet projects.
The bad managers occupied 10X more of my time than the good managers. It only took one or two bad managers to completely derail productivity of an entire group.
> I have worked with some fantastic "people managers" in my career who don't write code. But they usually faded into the background most of the time, except for when they needed to communicate something or I needed their help with something.
Yep, that's familiar. Good "people managers" have always been the ones that removed obstacles, and didn't become one themselves.
Anyone without intimate knowledge of the product they are working on is useless IMO. I was in the code daily when leading a team and don't respect any development team leader who isn't.
Absolutely. Of all the companies I've worked with, the one with absolutely the most effective management was the one where every manager was also a part-time IC. The head of mechanical engineering had to design a product while managing the team. The shop manager was also working as a machinist for most of their shift, or working on jig design and metrology. The head of accounting, of course, spent most of their time accounting, and only part of it managing the accountants. The head of software also wrote software, although not as much as their subordinates, and they were reviewing the codebase all the time. Of course none of the managers would chew through their IC work as quickly as people who could devote all their hours to it, so they mainly picked up tasks that weren't critical-path to avoid becoming blockers to their team.
The CEO rotated through positions, spending several months working in customer service, inventory, accounting, and even working directly on the production line. He mainly put himself on whichever team was most short-handed, although it was more to learn firsthand what their challenges were, and how the company could allocate resources to solve them. Fortunately he was a multitalented guy who could pick up those roles productively, and also humble and down-to-earth enough to not intimidate his colleagues too much when he took over the neighboring desk.
Aren't Product Managers & TPMs considered ICs? They don't have direct reports but aren't writing code either. I imagine this will be a more common option for these Engineering Managers who are managing other managers
Product Manager can refer to an individual contributor IC or someone who also manages other Product Managers (and sometimes even adjacent functions) e.g. a Group Product Manager. The titles are not very standard though. Many of these roles are hybrid as well. For example, a Product manager who will be responsible for a Product portfolio and some products in that portfolio as an IC, while managing/supporting the work of PMs working on other products in that portfolio.
Same for TPMs. They can be ICs or managing other TPMs.
My experience is the exact opposite. Managers who code are usually talking about minutia bordering on micromanagement, never put or have enough time to develop people skills, ignore career development and growth, have little to no project management skills, do a terrible job with cross team planning etc.
My experience is just the opposite. Most of the really technical people who were promoted to management that I’ve worked with don’t know how to fight the political fights for their reports or get the raises, recognition or promotions that their reports want.
>Zuck has it right. All the worst managers/directors/VPs in engineering I've seen are people who don't contribute anything to the codebase. They actively discourage managers who want to write code from writing code. They
Wow. And these "good" managers coding, how do they meaningfully pursue strategical tasks that benefit the team and organization? Do they have time for these, 1:1s, team meetings, unblocking the blocked, translating the untranslated, and generally, um, managing?
Pournell's Iron Law¹ in action. The administrators will always hoard the power and control promotions etc in an organisation.
Studies have shown time and again that small autonomous teams is the most optimal setup for software development. Having a layer of Director, SVP and VPs on top of EMs is just Pournell's Iron Law manifesting itself.
> If coding is beneath you, working in software is beyond you.
maybe the problem you are trying to solve isn't code.
> ICs do not need managers, managers need ICs.
Given the level of infantilisation at meta, and big tech in general, I think this is clearly not the case. "self management" (ie bottoms up management) stopped working at meta many many years ago.
> Some managers have negative productivity.
So do a lot of ICs "I'm rewriting x in NEW_LANGUAGE because its faster" & "just read the code, that's where all the answers are" & "no you're doing it wrong, just re-write this major system to make it do something completely different because I've not taken the time to listen to your problem" Meta is a massive pile of "not invented here" tech debt, that was half arsed for impacc and then abandoned. Most of that is IC ill disciplined "oh but I'm BORED I'm going to make a new x".
Don't get me wrong. I've had some complete bellends of managers, but that's not a function of them being a manager, that's a function of no training and ineffective performance management.
Writing code is easy,
Writing good code is not so easy
Reusing other people's code is hard
Making an entire company reuse code is fucking difficult.
Getting prima-donnas to document code so that other people can use it quickly, super fucking difficult.
Managing programmers so they don't start gnawing at the furniture, rebuild everything every six months, wank over the interns and getting them produce a viable product, one that they can't/don't/wont use is top level hard. It's something I don't want to do.
If you think developers are prima donnas wait until you hear about managers. Compared to developers, many of them fit much more into the prima donna description.
Most managers don't document anything and when they do, it is of low quality and goes unmaintained quickly.
Most managers out there are redundant and have no idea about what leadership is. They just get an orgasm each time they say no and conflate that with being a true leader.
The reason hackathons produce amazing results is because it is what happens when managers get out of the way for 1 day: improvement driven by builders that care about the product, not office politics.
You're assuming that I've never really worked anywhere with managers, good or otherwise.
> Most managers don't document anything
yup, and they are insufferable dicks for not doing it. But, in big companies you need to have presence, so managers that are successful tend to have a documented paper trail of "their" successes. Whether its useful documentation is very much another matter.
> Most managers out there are redundant and have no idea about what leadership is.
There are two issues here, lets do leadership first. Yes, leadership is not taught properly, and that annoys me greatly. Leadership can be taught, and its not to challenging to do. But on the flip side, leadership isn't just about keeping people happy, its about taking hard decisions and getting people to understand what they need to do.
Again, there are lots of bad examples out there.
Now as for redundant, if that was really the case, and that most manager are redundant, then surely they are ripe for "cost savings"? After all capitalism is mostly ruthless when it comes to staff costs.
The problem is that good managers increase productivity. However what "good" is can depend on where you sit on the hierarchy. If your CEO/CTO only talks to managers, then your manager controls the information flow. this is a company culture thing, and is closely coupled to how managers are expected react.
> The reason hackathons produce amazing results is because[..]
...of exposure bias. There are loads of ideas in hackathons, and lots of them are shite. But! the ones you remember are good, thus there appears to be a great signal to noise ratio. I've organised and participated in loads, they are good fun. But you can't run a company permanently in hackathon mode.
Potentially inflammatory story, but I think about it occasionally, and this is a good context.
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.
Building empires is quite standard in management. I work at $BIGCO as a manager and have been told that, in practice, if I want to get a promotion to the next level, I'll need to grow my team large enough to have other managers reporting to me first. So my primary target is to convince the powers that be to give me headcount, and what my team actually does is strictly secondary.
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.
I remember in my first job, one of the older guys telling me that at a certain size of company, it's all about the turf battles between the upper level managers. And as a line level employee, you just want to be on the right side of the battle.
Sounds pretty miserable to me; I suppose that's why I've stayed at smallcos/startups my entire career.
I think once a company hits around 2-5k office workers, the whole company can be occupied with internal processes, without delivering any value at all.
By definition, you want some of those companies to be old and stable. You, by definition, want life insurance companies outlive your policy. You want big car companies to build tanks in an emergency. You want big companies with lots of employees doing whatever to just exist and keep the economy stable. All the “disruption” at the edges are just for show to find the next giants
It's cost-prohibitive to start a new business in those fields due to large-scale regulatory capture and capital barriers. How many new car companies have been successful in the past decade without the personal fortune of a multi-billionaire?
The existentence of one or two enormous hidebound sequoias in a forest is not a good indication of its overall health.
I work in the insurance biz and we generally don't want to be nimble and follow best practices. That sounds crazy right? Well, best practices change over time, and fads (at least in IT if not all types of mgmt.) are far too common.
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.
I think upon examination, the folks actually shipping things at those old dinosaurs are by and large unaffected by the constantly changing upper reaches of their org chart, which just becomes a drain on profits.
The real lightbulb moment is when you realize this observation applies to almost all social structures: your school's PTA, government, militaries, large families, etc.
These bigger companies have moats e.g. life insurance is difficult business to get into and disrupt. They also have strategies to acquire smaller companies and to expand in different markets. This essentially allows them to run for a long, long time once their brand is good.
Communication overhead, like edges in a graph, scales quadratically. The computing analogy is going from 1 core to 8 core CPU gives far less than 8x performance if your task is not parallelizable. The solution is compartmentalization and clear interface boundaries, which is why microservices are so popular. Instead of 5k people working on 1 project, have 100 projects each with 50 people plus a few architects who define the interfaces.
I have been at both and frankly I think this can be even worse at a very small company because there are no guardrails to keep it from being entirely personality-driven without even a pretense of serving some larger goal.
> Building empires is quite standard in management.
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.
I once built a series of microservices doing the same thing but with different external vendors. Originally I thought it would be best to add a dispatcher/orchestration microservice that other services would have to go through, because I thought the externally connected services would all end up with differet APIs. In the end, I managed to give all those services the same API, making the dispatcher service obsolete and overengineered. Ultimately I just shipped it because changing the architecture would have meant endless discussions with that one lead architect who actually gave nor shit about anything but pointless discussion and I was out of time. So I shipped all the services.
In the last performance review, my boss complimented the amount of new services I put into production.
But if you were CEO and you wanted to, how would you engineer the incentives such that actually productive managers succeeded? Or is there something about corporate structure that makes it impossible?
A few thoughts having worked at a bunch of large companies before, with varying degrees of rewarding empire-building.
- 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.
I would think an easy way - and coincidentally, the best for business - would be to make it too dangerous to be the stereotypical office politics back-stabbing VP type. Make it known that that behavior will land you out on your ass, with no severance or parachute, and no recommendations for future employment.
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?
C-suite people from different companies end up working together on company boards later in their career. To fire with cause and no severance and no parachute some back-stabbing VPs would make it more difficult to work with said back-stabbing VP later on a company board.
There might be fundamental incompatibilities here because of orthogonal goals - if you're an ambitious person in a corporate hierarchy won't one (or maybe even primary) goal be to climb the ladder? And if you're a founder won't your goal be to 'grow the product or service'?
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.
Paying for consultants often isn’t a good use of money though, right? Like often the problem is that the right metrics are hard to know in advance and they are typically games in a way that makes it easy for the consultant to meet them without actually delivering what is desired. I think they also make it hard to take (calculated) risks which isn’t necessarily what you’d want.
First, you have to hire exceptional people, if you can.
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).
I think both you and the GP are missing the essence of what Elon is. He is neither an amazing operator and businessman, nor is he a slave driving demon. He does have a huge ego and need for attention, I'll give you that, but fundamentally he is someone who cares more about solving big problems than he does about money or people. The push to deify or villify him is all about satisfying ones own judgement, but personally I find those reductive opinions to be far less interesting than actually looking at the various things he's done and evaluating them on their own merits.
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.
No argument with what you said, but I give him credit for Tesla and SpaceX. Those are more ambitious than the vast majority of SV companies funded over the past couple decades.
Yes true, that’s what I meant by he inspired others.. to join him to solve humanity’s problems.
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.
One thing he figured out was that he could cut 75% of the dead weight employees and still have a product that 95% of the users are just as, if not more, satisfied with (despite all the predictions of imminent destruction).
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.
You act as if this behavior is unique to management. Every leveling guideline I’ve seen for any big tech company (including the one I work for) requires you to demonstrate “scope” and “impact”.
> I work at $BIGCO as a manager and have been told that, in practice, if I want to get a promotion to the next level, I'll need to grow my team large enough to have other managers reporting to me first.
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...
I imagine a lot of IT folks or those in compliance would be promoted very fast and then quickly leave the company before the hidden costs caught up with them.
That's simply counter to how $BIGCOs work. Just look at infosec for a big corporation. There's no incentive on their part to minimize cost or disruption with strict security policies and audits. The people who feel the pain are the workers, not the CISSPs pushing STIG hardening rules. And if the C-Suite starts to wonder if all the time and money is worth it? Just show them some news reports of breaches. In many industries (especially highly regulated ones), the entire audit world of Deloitte et al is designed to make things unproductive.
> 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.'
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 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.
I am in a weird spot where I am a manager and expected to be an individual contributor. I am also supposed to play several other roles as well. You are right, the skill sets are vastly different. It is incredibly difficult to have to context switch between manager mind set and developer multiple times a day. Both of my roles likely suffer due to my restrictions on being able to focus on one.
I can tell you from experience that you are going to suck at both.
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.
You are 100% correct. I manage a team now that I don't really have time to guide and am probably stricter with them than I need to be because of it. Additionally I am constantly behind on my deliverables to Sr. leadership because I don't have time to focus on the constant flow of busy work they keep giving me because they need data for some report to their leaders. I have no one that I can delegate this work too. I'm also working in an agile environment and have no scrum master. In addition I don't have time to think, I am just constantly pinged and in meetings. My blocked time on the calendar is not respected. Yesterday I had 9 meetings. Its impossible to do any type of deep work. Honestly its really not great. Salary is helpful though.
If anyone ever asks me "I want to burn out as fast as possible, what should I do?" I will send them the link to your comment.
Jokes aside, I think that I had very similar experience, and it does lead to burnout
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.
You are not wrong. I used to think I wanted to work in leadership and now that I'm there it kind of sucks. At least the middle manager level I am at. I have really started considering doing exactly as you suggest, just grinding for a year and then going for a FAANG position. I currently make more money than I ever imagined (I grew up on food stamps) and its far less than what FAANG SR's make. The thought of being able to make more than this with half of the responsibility sounds incredible and I am leaning in that direction.
Meta expects you to have managed at least 40 ppl before considering them for a M2 role. M2s made $800k+. Why wouldn’t a manager not be motivated to grow his empire? How else do you think managers will grow to VPs? We discuss ideals here but the reality on the ground is vastly different.
> Meta expects you to have managed at least 40 ppl before considering them for a M2 role
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.
Yeah. To become a D1 you need to be an M2 who successfully manages (ideally) more than one other M2, who themselves might manage M2s or M1s or a combo. So you get really large chains of people at the same level in a reporting line, all managing and trying to show that they should be D1s.
It's actually amazing to see empire builders in action. While some EMs are busy trying to keep their teams on track, others are rolling entire teams under them and growing their mandate
Depends on your definition of "direct," but it includes skip-levels. This is what some of the other comments were referring to with growing your team large enough you end up with managers reporting to you.
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.
To counter-anecdote: I've basically never had a bad manager. Several have been exceptional, 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
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've also had situations where the whims of higher-ups were misunderstood by my direct manager and direct communication unraveled the mistery
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
You are unlikely to find empire builders in that size of company because they are too easily exposed and ousted by competent leadership. The real problems start once there is way too much going on for any one person to track the major initiatives, which I'd say is more in the 500+ realm.
> To counter-anecdote: I've basically never had a bad manager.
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.
Not that everyone was perfect, but I've only once had a manager that made me go to my skip-level manager and tell him that they needed to put me somewhere/anywhere else or I was out. Didn't hurt that I had a good relationship with skip-level and and he wasn't wowed by my manager either.
Did a bunch of legacy stuff for a while but ended up fine.
Empire building was a major problem at a local company I worked for.
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.
The story of Bay Area engineering and management is so fraught that it's hard to know where to begin.
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.
Career-related. Most of it is low-level stuff, like what I'd be expected to do for my yearly reviews vs. what I wanted to do. I'll mention two stories that just sprang to mind, though there are more.
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.
Not the OP but it’s not uncommon for a manager to need one of their IC reports to replace them (and therefore go into management themselves) before the senior manager can move up.
If you think about it, middle managers are nothing more than recruiters. If the metric really is the number of heads their team grows, then the only thing they'd do is increasing their team size. In some areas, recruiters make 40-80k a referral on senior/specialties.
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.
This is pretty true for a lot of people and organizations.
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.
I like working for people like this, because often they look to increase both quantity and quality of the people they manage (if they can call you a senior engineer, then that must make them a senior manager). So they're often quite a good advocate for your career.
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.
I've worked in teams where 'seniors' were given to us by this kind of managers that were more like juniors so my personal experience has not been as good as yours.
The person you're speaking about is obviously not a good steward for the company. That said, what about "Dont hate the player, hate the game" -- that seems to apply here.
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.
I just watched a relevant interview between Dwarkesh Patel and Marc Andreessen[1] where they discussed James Burnham's ideas on how a manager class inevitably arises once a corporation reaches scale in order to maintain the machine. Unfortunately innovation and building suffers once the managerial class takes over. The culling of managers indicates Zuck maybe isn't quite ready to abdicate and there is more growth/innovation ahead?
I've seen engineers who were asked to move to EM role because they weren't strong technically to move up the ladder. They were able to move up multiple ladders in the EM track using the same technique you mentioned above (empire building).
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.
> I will call it a statistical anomaly, but the worst engineers are now in 'people management' positions.
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?
I experienced the exact same thing, and have watched the mediocre engineers that went straight for management move up the chain. IC engineering just doesnt have that good of career advancement. The cynical career advice is to just move into management as soon as possible.
Exactly. IC career is not as sexy as HN makes it to be. People pursuing IC careers are doing it for personal reasons, definitely not for growth. Compared to management it takes an order of magnitude more time, influence and energy to get promoted in the IC ladder beyond staff.
I mean, I don’t know. What people like about IC careers is that it’s even an option for an ambitious, hardworking person to not have to spend their time in management. Staff engineers have a ton more responsibility and authority than an IC could ever get in, like, insurance claims adjusting.
> I've also been in positions where my 'people managers' advised me against my interests.
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.
If you are encouraging the people you manage to make personal decisions which benefit your employer more than they benefit those individuals then it's very possible you're running afoul of this. They would likely be things similar to what's described here: https://news.ycombinator.com/item?id=34699720 (not my stories, just realized they're relevant to this question).
i have a whacky theory--based on very little--that the reason IBM turned away from APL was because fewer APL programmers did more, and that is a potentially bad thing for management, for a number of reasons, one of which your anecdote describes.
I very much doubt what you’re describing is a statistical anomaly. I think just about everyone here would agree the worst devs either become managers, or move to QA/BA.
I'm not surprised this comment is being read as "all managers were former-bad devs". Or maybe it's that some bad devs stay bad'n. Whatevs. Can't come up with empirical data for this one, have to rely on anecdotal stuff and yall dont like speculative stuff.
What exactly is an "individual contributor"? I'm confused. This term has come out of nowhere in the past 5 years, and it sounds like you're referring to someone who backed a kickstarter campaign. If this is the new term for "employee", I'm out. I can't stand that companies refer to their customers as "consumers".
> If this is the new term for "employee", I'm out.
Can you please explain what's that offensive about calling somebody an Individual Contributor?
It's a little bit of weird jargon, but it acknowledges 2 important things (they're a person, and they're actually working) which is infinitely more respectful to the people that actually do the work than "Resource" that also gets used.
To me, using the word "Resource" to refer to people is by far the most dehumanizing term I've seen seriously used in an office.
Individual Contributor is problematic in that it implies that contributions are primarily made by individuals rather than team efforts. It also implies that manager roles are not contributing which is also often not the case.
It's quite individualistic. Much like "talent" which is the latest attempt to imply people are resources without using the word resources.
Individual contributor means people who directly write code (individuals who contribute), as opposed to people who manage (managers and project managers).
It's recognition over the last few years that the standard eng -> sr eng -> manager isn't actually a path that all engineers want, does not always suit the employee, and does not always benefit the company.
AFIACT, it's intended to distinguish between employees who manage people and those who don't. I.e. "the set of employees is the set of managers plus the set of individual contributors."
It all came from the industry wide shift to make sure that software engineers were even more just cogs in a machine that could be hot swappable.
The growing concept of "IC" goes hand in hand with the increased focus on "leveling" for engineers, as well as the rise of delegating all product related decisions to the rising class of PMs. All of these create a structure in which every team, even across companies, starts to look more and more the same and any individual can be trivially swapped out for another with the same role and level.
In the early days of the startup boom, ~2008, engineers at startups had a lot more control over the product process. Typical startups where a CEO with some general vision of the product and a knowledge of fundraising and a technical cofounder who would handle the real implementation of the product. CEO would make sure the company was health, CTO/tech cofounder would make sure the product was built.
But this lead to a class of labor that was a bit too powerful. As you likely remember engineers used to contribute a lot more than purely churning through tickets.
Today you can think of IC as a prefix to a more complicated part number: IC-SRE-4, IC-DEVOPS-2, IC-DS-6. Then you just have to find someone claiming to be the part and send them through a leetcode grinder to verify the build quality, then plug them in and go!
(Not directly answering the question asked, because sibling comments already did.)
FWIW, I've heard and used it in FAANG for well over a decade.
Usually I see HN comments using "IC" followed by someone asking what "IC" stands for. Makes a change to see someone asking for an expansion of the expansion :)
Management is just a way to coast. I don't understand why we need to "manage" grown up adults. What we need are team leads who code and architect. Then give them the autonomy to run teams.
Running teams is management. Not everyone wants to be doing the roles involved in managing teams, so it's a designated job title. If you get rid of the hierarchy entirely, then what happens is that they form implicitly and everyone is completely confused as to who leads what, and that only gets worse as teams grow and the number of projects grow.
Some management is bullshit, but literally "run teams" is the important part. But if you get big enough, you do wind up with departments. It grows like a fractal.
Managers are an organisational necessity past a certain scale. If you have not felt the need for them I can only guess you've not been in a company big enough.
Think of it as trying to run a big country with direct democracy. Can it be done? Maybe. But there are good reasons why democracies become indirect after a certain scale.
"Managers are an organisational necessity past a certain scale." That sounds like a dubious claim, I'm sure there are exotic ways to run an organisation that doesn't need managers.
For example, Pirate ships ran with a Battle Commander, Accountant and Crew.
Pirate ships frequently had crews of about 50, and the biggest ones never exceed a couple of hundred. Do you have real world examples of large organisations (in the thousands of employees) being managed in a flat hierarchy? Because I don't.
Please note I'm not saying you can't be overprovisioned in managers. I'm replying to the parent comment that sees no need for managers.
Resolving interpersonal disputes and guessing how much you have to pay someone to get them to stay, and software architecture, are two (three?) totally unrelated skillsets.
You don't need to "guess" how much to pay someone. The market dictates that. HR has pay bands. Raises are always in a narrow band. I don't know what kind of disputes you're talking about.
If you ask any manager - describe your responsibilities succinctly, they will most inevitably fail to do so.
I can imagine a company that had pay bands so narrow and bonuses so small that managers had no tools to reward high performers, and although I agree that it would take away a lot of what allows managers to do their jobs, I don't think that is the usual situation.
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.