Ask HN: 20% of LinkedIn's recent layoffs were managers
1 in 5 of those laid off were managers. Someone correct me if I’m wrong, but that’s higher than the typical ratio, correct?
A year ago it was mgr > sr mgr > director > sr Director> vp> svp > ceo.
No one in my management chain was impacted but the flattening has been happening organically as folks leave. LI has a distinctive lack of chill right now contrary to the company image, but generally things are just moving faster.
I don't get it. Did linkedin have an image of being a chill place to work?
Ok, so, I have a friend who works big tech and he has no chill for Indians (SWEs, PMs, etc). Is there a grain of truth to the “lazy Indian” trope? I always assumed, especially first generation immigrants, would be working balls-to-the-wall. Am I wrong? Is there some sort of incentive misalignment in the H1B program? Is it cultural (e.g. like “island time”, which I’ve learned is at least partially attributable to the futility of working harder under the tyranny of distance)?
I’m not saying Indians are Lazy. I’m asking is there a perceptual issue due to some factor that’s obvious to the typical Nth-generation American?
If you underpay talent anywhere they'll do their bare minimum.
I've hired and (product) managed Indian employees and they're equally as capable as our Israeli, Eastern European, and SV employees - we just pay them market rate in Bangalore/Gurgaon/Hyderabad.
Depending on the age of your friend, they might just not be as used to dealing/communicating with non-American background people? I remember some assholes like that when I was a kid and my dad was working in the industry in the 90s and 2000s.
It's gotten better but you still see some dicks here on HN.
An American isn't gunna jive with the work culture in those regions - it's more cutthroat and productive IME - but luckily there are plenty of diaspora Israelis, Indians, and Eastern Europeans who are fine returning to the old country to act as a GM or Director while earning a $100-200k salary in countries where the median income is $40k, $20k (Czechia), and $2k respectively.
> Is there a grain of truth to the “lazy Indian” trope?
I wonder if it has to do with out-sourcing farms. I have been lucky enough to work with Indians who were all full-time employees and generally my equals. The typical Indian who works at an outsourcing farm makes so little, that they don't exactly care to work hard.
> no chill for Indians (SWEs, PMs, etc).
I'll be honest. I occasionally run into people with very strong and vapid opinions about entire countries based on 1-2 anecdotal experiences. I haven't seen this issue with other fields. It is oddly CS specific. In no other field have I met people who are so obsessed with the productivity of their peers, when the entire organization works on making ads software 5% faster.
My experience echoes this. I worked with a guy who basically built every important thing the company depended on and he seemed to be available 24/7. I’d get on calls with him at 12am and then hear he’d been on with someone the following morning at 7am. He was also notoriously prickly (possible bc he was working so damn much!). I distinctly remember him screaming at me, in his broken English, “WHO HERE IS THE ENGINEER!?”* when I had the temerity to question a minor technical decision of his. Nevertheless, I walked away respecting the hell out that guy and still get a chuckle out of the memories.
*I was a mere data analyst at the time and thus a barely functioning human in his eyes.
Indian here. First generation, naturalized American, et cetera. I'll be honest and say that my initial response was, “Ugh! Your friend is a big old racist”.
Moving on from that reflexive thought, I'll attempt to answer your question of:
> I’m asking is there a perceptual issue due to some factor that’s obvious to the typical Nth-generation American?
Well, perhaps. There are a bunch of factors:
- The H1B program is terrible in that it ties your immigration status to your current employer. Couple this with the “you can be legally fired because your boss doesn't like the color of your shoes” climate in the US and you have a pretty stressed-out bunch of people. - A lot of consulting companies seem to pay just enough wages that attract Indian H1B employees of a average to low caliber of talent, and hire them out for random software projects. The Americans on the other side of those contractors get mad at the contractors, who happen to be all Indian. - There is a genuine cultural gap where Indians are more deferential to someone they perceive as having higher authority. It is sometimes possible that a young Indian employee might call you “Sir”, because that was how they addressed superiors.
So...all these are perceptual issues of the sort you are looking at. But honestly, these sorts of cultural misunderstandings are not exactly uncommon among Europeans and Americans as well. Big Tech tends to have far fewer of the issues above. Salaries are high (I don't even work in Big Tech and my salary as an H1B was verifiably higher than some of my American coworkers), and IMO there isn't a huge difference between Indians and the N other cultures that make up the boiling pot of tech.
But then that brings me to the part about “friend who works big tech and he has no chill for Indians”. Like, Indians period? What does he think about Sanjay Ghemawat? What about Vinod Khosla? How about Amit Patel, who came up with Google's “Don't Be Evil”? What about the engineers/PMs/etc. in big tech to whom those issues don't apply?
All of this leads me to conclude (this time after some reflection) that your friend is actually just a...big old racist if he has a problem with all Indians in general, especially those working in Big Tech.
Take from that what you will. Hope you find better friends :)
----------------------------------------
[1] https://www.vox.com/recode/2021/2/16/22280502/google-dont-be...
There's nothing wrong with that - it's awkward the first 3 times, a non-issue ever after.
My problem is with the use of flowery, deferential language to mask misunderstandings. My sample count is 3, so I'm not going to say anything about a 1bln+ nation (I somehow don't want to self-identify as the GP's friend) - I'm just noting it happened more often with those 3 guys. I have no idea, even, in what part, if any, it was intentional, so - again - just noting it happened.
What's interesting is that it somehow went away after ~1/2 to 1 years. My guess is that it takes people a while to internalize drastic changes in assumptions they make. I know it takes me around 2 weeks to start pronouncing people's names correctly (sorry!), which requires an effort looking like a rounding error compared to moving countries and cultures.
I very much like a lot about Indian culture and people, and I've met a couple of very sharp Indian programmers who I'd gladly work with again, but I think it's understandable that some tech workers in countries like the US have a reflexively negative impression of working with them even before considering some of the cultural differences in the workplace.
* I feel very bad in these interactions, but it is an immense struggle to understand some very thick accents that some Indians have. To be frank, remote work has made this communication even tougher, as any imperfection in the audio makes already difficult communication very awkward. There's only so many times you can say "I didn't quite catch that" or "Can you please repeat that, the audio glitched out" before it becomes obvious that you just can't have a normal discussion with them.
* Many peoples' experience with Indians is through very low-quality recruitment sweat shops. Traits these recruiters exhibit include being bad communicators, pushy, disrespectful of social norms, have questionable motives, barely understand anything about the tech they're recruiting for to the point of even getting the names of technologies they're looking for wrong, and are rarely worth dealing with.
* I don't blame Indians for doing this out of their own self-interest, but nepotism seems to be rampant. Any company that gets a few Indians in positions to hire eventually seems to focus on hiring their own people first. Not good for your future in a company if you're not in that group.
* I don't blame anybody for trying to seek the best deal they can in life, but the H1B program has shitty properties for both immigrants as well as the existing workers in countries who get displaced. The main beneficiary of the H1B program is companies that use it to drive wages down. Hard to have reflexively pleasant feelings about this circumstance, despite it not being their fault.
I thought it was a temporary working visa more than a route to immigration? I understand the temptation to go for it (I did something not entirely dissimilar working in another country for a few years under temporary visas) but not the mindset that doesn't take into account the reality of the arrangement, which is well known up front.
There was a bit of a communication barrier with some of the Indian colleagues, depending on their skill level, but as a rule they worked hard and were approachable.
Then my own employer did exactly that after a rough few years and layoff rounds. Some of my Indian coworkers are my best ever, but dealing with sensitive personnel issues (HR & IT type work) while facing time zone and cultural barriers is still prickly.
Remote offices in other countries don't always feel "same team".
If someone speaks perfect English, gets all the in-jokes and is in general great to work with, you'll think of them as a "team member", even if they happen to be from India. But if someone has problems with the language, doesn't get the jokes, and/or has a vastly different timezone, you'll remember them as distinctly "Indian".
That means if someone asks you to remember experiences with Indian coworkers, you might be more likely to recall the people that didn't work out well, because they stood out more strongly.
There is none. I worked at a big tech company where a big chunk of positions were moved to India, and the teams in India were constantly overworked and under pressure.
There is no way this is actually a trope.
a very slimy and backwards model
perhaps it is, but that's the business a lot of big tech is in. ads drive everything. google is an advertising company with a lot of data mining on the front-end.
if your ad game and monitization isn't tight then you don't have a company, you have a public service, and one that will gas out pretty quickly.
Yeah I think Elon is almost picking up that slack. But I doubt anyone could find him at an yoga class
Keep in mind a lot of the slacker are really good at pretending to do real work and they've had a long time to hone their skills.
The gp I think is talking about rage bait videos on social media where people used to post how work was so easy at xyz company. We should know better than rely on rage bait for information. Ask your friends who worked there if they knew anyone slacking off.
Watch shows that are popular in my age demographic (eg. Succession) and the flashiness is the takeaway for most people about high paying "elite" jobs (and ignoring the toxicity and horrible WLB these jobs often have).
I've met many younger friends and mentees who have this idealized image of IB/PE/PM/VC/BigTech SWE/Consulting because the perks seem dope and it sounds "sexy".
No one wants to message that in reality, high paying jobs have high responsibility, ownership, and politics - it's my head on the chopping board if my product/divison's P&L sucks.
Also, a lot of these TikToks and Reels have some backing from HR/Recruiting. My sibling has done something similar on their own IG after getting the go-ahead from HR and Recruiting.
You don't need a giant amount of amenities and every company I've worked at hasn't had enough meeting rooms.
If I'm adding to my wish list it's a shower so you can bike to work and rinse off. It's the daily conveniences rather than the crazy atypically perks I never use that I value.
I don't work for Google or anyone else on Stierlin Ct.
That being said, the amount of things happening is crazy compared to two years ago and generally pretty happy day-to-day and genuinely excited to go to work in the morning
I can't imagine a company image being less "chill" than LinkedIn. Perhaps the reputation as an employer is that, but as a Company (and product) it's basically Facebook, for people who are not "chill"...
I've seen a trend where a company is trying to do WAY too much outside of their core competencies or too many things at the same time.
A strong temptation is to to just say "well, we will just hire a bunch of managers to oversee each project we are working on b/c having 17 direct reports who are front line employees is too many people."
Then, times get tough and you think: "Well we can't fire X b/c they are the front line employee actually doing the work for Project Make Money so we'll just fire their manager. The manager manager will just have to deal with having 19 direct reports again"
When a team grows much beyond that, the manager is no longer removing all the roadblocks. They're doing all that other stuff that _can't_ be delegated, and the team under them is now spending time doing stuff that _technically can be delegated_ but would be much more efficient for the manager to do.
Typically what happens then, is one of the underlings becomes the de-facto also-manager, relieving the burden from the rest of the team and increasing overall productivity by re-centralizing certain duties. However, this hurts their individual productivity metrics, so in bean-counter companies this is a hazardous move. It's safer to not help the team and just let the sick structure shamble on.
Their goal is to keep their report's time fully utilized, so it is logical for a manager to take on a task if it saves their report 2N as much time in IC work. For example, a manager with 4 reports can devote up to 10 hours/week fairly to each one; taking the second approximation, that's 5 hours of overhead and 5 hours of project work. The report has 40 hours/week of time. Therefore, it makes sense for the manager to do a one-hour task (say, design work) if it saves the report at least 8 hours of work. A manager with 10 reports can devote only 4 hours/week to each, so with 2 hours of overhead and 2 hours of project work, it makes sense to take on a one-hour task only if it saves the report 20 hours of work. Taking the third approximation and assuming overhead is a constant 2 hours/week/report, the first case becomes 8 hours of project work, and so a task makes sense if it saves the report 5 hours of work.
You can see how a manager very rapidly approaches the "Do nothing other than bare minimum performance reviews, 1:1s, and save the report from blatant stupidity" line as their reporting load increases. This is why so much moderate stupidity and waste persists in big companies: the manager is not incentivized to remove it (and doesn't have time to anyway), but the report does not have the organizational power to change it. And ironically flatter hierarchies tend to be worse at this, unless they have ICs step up and do the "improve efficiency for everyone" role, but then they're usually either promoted into management or they leave.
This is also why managers look chronically dumb and entitled to ICs. The IC can see plenty of opportunities where "If you just did X, which takes 15 minutes of your time, it would save me 2 hours of my time." They don't realize that their manager has 10 other reports, so a.) their manager does not have 15 minutes of time to spare and b.) their manager is only going to spend it if saves at least a day. Otherwise it makes more sense for the employee to do it themselves, simply from a scalability perspective.
What are some examples of things that a manager can do which will save time for an IC?
A mature team will hopefully have implemented efficient workflows.
Some of the levers a manager can pull to make the IC's job easier are: 1) negotiating with PM/UX to accept a solution that might have 80% of the user benefit but is 10x easier to implement 2) lining up commitments from partner teams before committing their own resources 3) lining up schedules so that all the people on a project are working on it at the same time, regardless of which team they're from 4) arranging to colocate people from different teams who will be working on the same project, to cut communication overhead 5) doing #1 to change the architecture and eliminate the need for partner teams altogether, avoiding #2-4 and cutting communication overhead 6) pointing the report at a potential solution early so they waste less time hunting around 7) answering simple questions from other teams so that it doesn't take your own engineers out of flow 8) buying off-the-shelf solutions when appropriate to scale down the project 9) killing infeasible projects before they get to the engineers.
All of these require time and technical knowledge, though. An engineering manager with 16 directs is unlikely to have time to do anything other than performance reviews, meetings, and reassigning work that comes down from product/UX/sales. A tech-lead manager with 4 directs can devote some of their time to architecture & design, which then feeds back into resourcing and project assignments.
Often some slack in a team results in the team as a whole being more effective.
10 direct reports is about half a week's work at a bare minimum without development, process improvement, etc. 20 is insane and would lead to skill atrophy and team dissatisfaction in short order.
In light of this I budget the following time for each of them:
1 hour a fortnight for general chat (what I refer to as temperature taking) to see where each of them are at in terms of morale, etc.
1/2 hour a fortnight for 1:1 catch-up covering administrative requirements (leave, review of metrics, etc, etc).
1 hour a fortnight (1/2 per week) for metric collection and review; are they having trouble with specific elements of their domain, are certain managers, stakeholders, customers, etc, holding things up. Their work tickets vary wildly in complexity and scope so this is the absolute minimum I can spend to know where each person is up to professionally speaking.
1 hour a fortnight for mentoring, training, etc. Generally speaking the more skilled staff will contact me more often to "pick my brain" regarding how to approach certain technical/personnal challenges, how to link data across our datasets, who to contact for advice on this or that regulatory or statutory requirement.
And about half an hour per person, per fortnight reviewing their changes or service requests as I am primary CAB representative for my products - and these items are key outputs of the work they deliver.
So, in essence, four hours per team member per fortnight. Very little hand-holding for such a widely dispersed team, and they remain engaged and focused on their tasks with minimum disruption.
I think they're super useful, especially in a mostly-remote context.
I'd agree with you that weekly can sometimes be the wrong cadence; some individuals will find that an encroachment. I set the goal with my reports that they own the 1:1 meeting invite and can set the cadence as they see fit, within some prescribed limits. That has tended to have good results.
For example, a 30 min 1:1 with the report looking at their wellbeing, motivation, challenges, career goals should be a weekly task. The 30 mins is really 45 mins because notes need to be made following so that there is audit trail, and clarity of expectations for both parties. QoS is important so they can't be shoved back to back, otherwise one will find actively concentrating difficult after a while, so that's really 1hr per team member per week. That adds up pretty quickly.
Add in coaching sessions (min 1hr) on specific problems, analysis of team performance, handling of fires, meeting facilitation... This is all before you get to your own work.
Doing engineering management well is a tough job. People are complex and their needs likewise. Sometimes, it pretty much is holding someones hand. I've coached juniors to seniors and it's a lot of work, feedback, questioning, teaching.
Isnt all of that your own work, as a manager?
That’s mgmt for you
My manager filters my email. And tells me what the new priority is.
Two levels up is a director. Above that is a department head. Out of 100 people there are about six that truly build, ship, accelerate the goal arrival.
The rest of us make waves allowing the divers to have a soft landing.
My manager filters my email. And tells me what the new priority is.
Two levels up is a director. Above that is a department head. Out of 100 people there are about six that truly build, ship, accelerate the goal arrival.
The rest of us make waves allowing the divers to have a soft landing.
2.) Be even better at leetcode.
3.) Interview during a downturn, when everybody's stock is in the toilet and all the companies that are about to go bankrupt aren't hiring.
4.) Get multiple competing offers.
5.) Play them off against each other. Turn them down if you have to.
6.) Get as much stock as you can in the counteroffer.
7.) Wait for the upturn, where the company's stock goes parabolic.
8.) Profit.
#3 and #7 are the most important. Timing and luck are better than skill. But you usually need #1 and #2 to accomplish #4 during #3, and you need #4/5 to get #6, which is what really makes you the big bucks in #7.
A good engineering manager shouldn't be there to herd engineers. A good engineering manager is there to protect their engineers from the organization, ensure they have the resources required to do the work, and to make sure their organizational goals, development, and wellbeing are being advocated and cared for. Scrum masters shouldn't care about that. Managers should.
In work, always selectively take time off when it's somewhat important. So your skills aren't taken as the norm.
I don't think feedback in a corporate setting from someone you have power over can be relied on.
As the money got bigger we got more grifters / professional manager types. First thing they do is rebrand middle management as “leaders” and the other thing they do is make management non technical.
This has even bled into making higher level IC engineering roles being “above” coding. “Staff engineers don’t code, they set high level architecture “.
This is toxic to an engineering org in many ways. Firstly you now have a bunch of highly paid technical employees completely removed from how things actually work. But what’s worse is you created a culture where you’re incentived to follow - a senior engineer who wants to get promoted should write less code because coding is associated with being a low level employee.
The fundamental root cause is a misunderstanding of code as low level factory work and not intrinsically tied to the design and architecture. But it’s one of many ways in which traditional business structures and software engineering do not mesh and you need an extremely strong engineering leader to keep software culture on track, which very few organizations have.
That. Same for all the decorative functions with low value added.
> make management non technical
This is a big flag to me. I know this is a devisive opinion, but I don't think you can do a good job at managing people without knowing their core business.
> making higher level IC engineering roles being “above” coding.
There is little that revolts me more than people working in technical companies, and seeing themselves as above the technical layer. I don't mind people not being software engineers, a lot of them are great, willing to learn a bit of context in order to do their job efficiently and facilitate mine. The same way I learn about the other functions. But I've worked with quite a number of managers, PMs and TPMs who talk down to me the moment I tell something even remotely technical, like I'm some sort of amateurish geek only tolerated at the adult's table. I do my best to stay away from these folks.
You're working with the wrong people.
They’re very effective at solving first order optimization problems. Increasing revenue and reducing costs can all be done in a spreadsheet. This is the value they contribute.
If you’re dealing with problems that are closely coupled, are non-linear, or have emergent phenomena, their contributions are not just ineffective, they’re counterproductive and destructive. You need creative, skeptical, and technical people for these problems. Closing feedback loops and building fault trees help you more than a Gantt chart and flashy buzzwords.
> This is a big flag to me. I know this is a devisive opinion, but I don't think you can do a good job at managing people without knowing their core business.
I have mixed feelings about this.
I used to have a manager (who later became vp) that was technical, and it’s been the worst. Of my professional life so far. He would dictate the technical solution and shut down every initiative, making people below him mere executioners. No room for dissent, he had the last word on everything.
The problem being, this person worked for like ~5 years as a developer, then became a manager, then got in charge of infrastructure.
And oh boy, infrastructure was not his core competency.
So prod infrastructure was essentially at a hobbyist level (everything in the same subnet, some dev stuff along with prod stuff, no network segmentation, a number of things implicitly relied on virtual machines not being rebooted or getting the same ipv4 if rebooted, dns was a patchwork etc). In all this he avoided solutions that he wouldn’t understand (no matter if people below him would understand them). Oh and he would have the console access to cloud services and the authority to do all the testing he wanted, we did not (hence perpetuating some thoroughly artificial knowledge gap).
So yeah… having a technical manager can be awful.
You: "And oh boy, infrastructure was not his core competency."
To the extent that people started removing hard numbers from their presentations and replacing them with smiley faces.
Needless to say, I left and that company TANKED.
I think Steve Jobs said something about A people versus C people... well he was right (even though he was bullshitting, b/c as we all know, Wozniak had the A team at Apple, and Jobs at the C team)
I still think it is kind of full of bunk, although it has some truth. A players do typically want to work with A players, but a lot of "B" players just want to have a mildly interesting job where they don't kill themselves and are happy to hire and be around other B players with the same attitude.
In my previous life, there were plenty of people who could water your eyes in the jet, but who couldn't mentor or bring along new folks to save their lives. Which made them useless in the long term because they couldn't train their replacement.
The real gold are the "A" players who can mentor "B" players into becoming "A" players. Because in any field, there are three kinds of people. The natural freaks of nature who need no help, the vast middle, and the incompetent who shouldn't be there. Organizations who crush it understand that they need the best team players out of Group 1 to mentor the crap out of as much of Group 2 as they can, and they only need to fire Group 3. But the prima donnas of Group 1 make it sound like they can carry an organization . . . and they largely can't.
I am also not a particular fan of excessive management structure, but as an architect I have to completely reject your proposition that non-coding roles are toxic or excess. I work with highly brilliant minds, with coding and non coding architects and one thing is very clear: the non coding architects are contribute more value to the end product than the coding principle engineers. And why not: they are a specialization which focus on one part of the engineering while a traditional coder focuses on another part.
I reject your rejection. In my experience any architect/staff/whatever high level ivory tower guy worth anything will look for every technical opportunity they can and will often bemoan the fact that at their level most of their day involves meetings and powerpoint when they'd really like to be digging into the code.
If a sr. technical leadership position seems happy to have their day full of PowerPoints and committee meetings the most they are ever going to contribute to their field is an amusing/horrifying story on TheDailyWTF.
God I hate this, having to attend all of these "brown bag" meetings where we get talked down to by these grifter types about "devops mentality" or whatever or BS they've latched onto
Who gave these people the right to wave their hands in the air and talk about bullshit all day? Where do these people come from? Is it nepotism or something?
To be frank, I'd rather trade some money to never have to interact with these fuckers ever again. They're literally a disease. Or at least, unionize, but don't demand money, demand that these people shut the fuck up, permanently, or gtfo
I doubt the process is even specific to tech companies. Code is work, and the one thing that signals moving up the social ladder is not having to work. That has been true for a large part of history.
Programming is often a bit of a special case when in the context of work because we it so completely isolated from the physical process of work. Programming fundamentally is describing processes at multiple abstraction levels all at once, and therefore inseparable from software architecture. This is also why it can be hard to humans to learn.
(This, incidentally, is also why I despise each and every one using the term automation in a programming context. Running a command and clicking a web interface is conceptually identical, one is not more automated than the other.)
Honestly, most of the dysfunction I see in orgs is as a result of "senior" (read: tenured, not skilled) engineers being put in charge of teams/work without having the competencies needed to be successful.
Just like home inspectors...failed contractors
-Complete technical tasks at the minimum of a senior engineer level if not staff/principal
-Train the <senior engineers on a weekly basis
-Project Management
-System Design, to the point that I am willing to put my name on each and every design as the architect
-Understand all the projects my team owns to the level that I can answer extremely explicit technical questions from other teams line engineers immediately in that meeting and not need to refer to my team's expertise
-Be on call 24/7. This isn't asked explicitly, but I am told that I need to be available to support my team for every on call event, which funnily enough means I cover 100% of the on 24/7 call schedule my team has
-People Management
-Employee growth
-Vendor Management
-more I am probably forgetting
I am not super incensed about this because the total comp has kept increasing as the expectations grow, but I am now 3 jobs in a row with companies expecting this combination of perfect high level engineer and perfect MBA accredited business leader in one role. If you have engineering managers that legitimately seem like overpaid scrum masters you should probably look to join a more mature software company.
Also if you're at a FAANG or close to FAANG startup and still feel this way, odds are that you have no idea what goes into 90% of running a team in an well running business and think that the company is making bad decisions because they don't dump 90% of their revenue into feature development instead of stupid choices like fulfilling government mandated regulation.
Edit: Also I've worked on teams with Scrum Masters. Its been more than 7 years since I last came across someone with that title. My Scrum Master equivalent planned tasks equate to less than 6 man hours total a week and 5 of that is the standup set for 15 minutes for 4 engineers a day that we normally end 5 minutes in
IMO, my modus operandi as an engineering manager is to body all the work that I can handle for a team that lets the team stay focused on the engineering work and be more productive.
With tens of billions in the bank, who will be dancing on the graves of highly effective startups
Which is why people still work for "bad" companies
Most come from non technical backgrounds, or we're in a technical role for a short time.
I have worked at orgs that have chains of middle managers. Each one of them asking for updates on the same shit.
For some reason I can only find the heavy workload manager jobs. It’s different work than being an IC (I’ve gone back and forth) but I wouldn’t call being a manager easier.
What are the JDs of "Engineer Managers" ? And what are their REAL responsibilities.
Their responsibilities are basically improve and maintain the performance of whoever they "manage" . But for some reason we decided that shitty engineers that decided they dont want do do development are the ones looking for management positions. And they get good at playing the politics game.
My wife works in a non tech position and had a manager, who studied for people management and understand in the long term what makes people perform (hint, it's not keeping them sad, overworked and getting all the shit politics).
Good managers filter the shit from you. Push back on stupid deadlines and double drippings, and act on your needs as a person.
And they may not know shit about the technical side of things, but they trust you do your job.
I think Industrial Engineers with some specialization in people management make the best managers for Software Dev.
in theory i can see the board salivating to pretend they are elon but in practice it’s a dysfunctional nightmare.
plus it’s bad for ic morale because there is now no path forward for advancing our careers to the managerial level.
For me, I was a "first line" manager of a small, rather high-functioning team, for 25 years.
I was quite capable of going up the food chain, but didn't want to. I liked getting my hands dirty, and being directly connected to the product.
I was a really good manager. I took the job seriously, and did well for the company (see "25 years," above). It was a Japanese company, and it's pretty tough to keep Japanese managers happy.
I also hated being a manager. When I left the company, and got to do my own gig, I ran back to IC status, as fast as my little legs could go.
We did good work. It didn’t really have a high profile, but it was really engaging.
Basically, I couldn’t trust anyone else to do the job, and the Japanese had a lot of trust for me.
It is a bit sad, to hear the name-calling and insults, when I talk about it, but I’m not an idiot, and I’m not a chump.
We usually get to love our job. We get paid quite well, and work on things that energize and motivate us.
The vast majority of the working population work at jobs that don’t really motivate them. Sometimes, they make a lot of money, but the work is a grind.
Many times, folks work at jobs for the social responsibility of doing stuff. They don’t like what they do, may not get paid that well, but feel like they are stepping up to the plate, and doing their civic duty.
This is a real rabbithole, and there’s a ton of opinions. Also, many managers are, shall we say, less than effective, so if we get a good manager, we should treasure them. A good manager can make difficult jobs bearable, and sometimes even highly motivating.
Why would one want to advance to a level that gets very rapidly shafted as soon as the s*it hits the fan? Just increase the programmers' comps to the same level of the managers' comps, if that low morale is actually about the money, and you've already solved half of the problem.
It fucking sucks.
And before this becomes controversial, I don’t mean every manager has 4 reports, but because organization is a tree, for every 4 ICs, there’s one manager.
For example, you could have 3PMs, 3 designers and 10 engineers, but the org could have 4 managers: 1 PM manager, 1 Design manager, 1 eng manager with 7 reportees and a sr manager with 3 engineers & the 3 managers reporting to him/her.
"Yasser Arafat had 17 lieutenants (aka direct reports). Why? So he could pit them all against each other: if they were fighting each other and jockeying for position then they were too busy to go after him."
my suspicion is lower numbers are more a function of worker power (demand for 1:1s, career growth conversation, offloading more tasks to your manager, etc)
You’re effectively either a recruiter or procurement.
A promotion to "manager" is expected to come with a pay raise. Acting as a "mentor", less so.
They assured me that they did. So I grilled them on the mechanics of it.
If you had biweekly 1x1s with all of your DRs, you would have to do 100 per week. If 1-on-1s were your fulltime job you could at most do 80 per week (2 per hour x 40 hrs). Thats just rotating through 1x1s. That's not doing anything else.
He claimed "team leads" did 1x1s, which is fine, but its hard to call them a direct report if you're not even aware of their daily work. Theres just no way you can adequately manage 200 people. As mentioned above, you are just a glorified HR person, you're no longer in engineering.
I would never hire a manager below Director level that isn't themselves an individual contributor. I know its possible to have that but I wouldnt hire it, because we expect IC on our teams.
The manager can manage that many people because he's not involved with our day-to-day work. We have a Scrum Master and Product Owner who handle their "management" parts. If there's some problem which needs manager's attention it's typically SM who communicates that.
The manager takes part in some meetings (like planning), but mostly just listening.
I was once put in charge of over 20 direct reports against my wishes.
At that ratio, you’re not really managing the team in a traditional sense. You’re providing high level direction and dealing with the individual issues that are most pressing.
It invariably becomes a situation where there are team leads acting as pseudo-managers for groups of the people you’re managing.
On the other hand, it did make me more efficient as a manager. Whenever I encounter teams with 3-4 people and a full-time manager who only manages them, it feels inefficient. Either the manager is stretching managerial duties within the team too far to fill their time, or the company has an unreasonable amount of process and cruft that takes up managers’ time.
> On the other hand, it did make me more efficient as a manager. Whenever I encounter teams with 3-4 people and a full-time manager who only manages them, it feels inefficient.
Because it is?
Over the last 10 years, we have improved productivity tools, and for every other role the expectations are higher.
I find it funny that the ratio of ICs:Managers has not gone up and the industry doesn't discuss that it should go up or what tools we need to help make it grow.
Isn't increasing productivity by solving hard problems why we get paid? My biggest question is, why isn't it even talked about and/or have aspirational goals set up?
Personally I wish we needed fewer managers but I often see their necessity.
Tech companies are full of managers and very few people actually doing engineering. The incentive structures are mismatched since most management practices come from manufacturing or service industries.
In a boom cycle, it's not a great use of resources to try to really tighten up the manger/report ratios because the size of the org because the slack lets you grow faster. The higher the growth, the more managers at a more inefficient manager/report ratio generally.
Certain orgs in LinkedIn were growing really fast. Now they're not and they know the headcount for the next year, time to ratchet down the number of managers to get a more steady, cost-efficient ratio.
Larger amounts of managers means more levels of indirection and more opportunity for miscommunication, conflicts of interest, and other negative patterns. The way to fix a broken software organization is similar to how you would refactor a faulty code base. You start by looking at the most complicated bits and refactor those to be simpler and easier to understand. You might also profile things a bit: where are things getting stuck in the organization. And so on.
Either way, the fixes tend to be similar as well: remove unnecessary levels of indirection (layers of management). Look for places with lots of dependencies. Look for ways to increase cohesiveness and reduce coupling. Etc. How do you improve cohesiveness and reduce coupling? Break teams up. Have less managers. Reduce their interfaces to each other. Shorten the lines of communication. If you know your SOLID principles, that should sound familiar.
Large organizations do the same as bloated code bases: when in doubt, they add people (more code) to fix issues. So, you get a lot of functional duplication because this part of the organization is just in the wrong part of the org tree to be off use to that part. So, they hire their own people to do the same. And some more managers to manage those, which then fractally make things worse. And you get this culture of fracturing responsibilities across large amounts of teams and those teams having to work around each other.
That's how Google ended up with a few dozen different chat clients. Instead of just one good one. They are still figuring that one out.
I was lucky for most of the time I had a great TL and a great manager so I had immediate and mid level buffers to shield me from most of office politics.
When that went away, I went soon after. Who willingly would deal with nutters. Not for that pay.
It gets worse if you need something from elsewhere in such organizations. Because now you are communicating up the tree to some busy executive with no attention span who then barks down another path in the tree down to (hopefully) the right person you should be talking to directly. Of course doing the sensible thing here (talk directly) pisses off everybody along that path who justify their existence by gatekeeping their precious resources (i.e. people) and jealously control flows of information.
I've been there and done that and have had to deal with such executives. Not fun to have your boss tell you that his boss got yelled at by their bosses because you had the nerve to send an email to a report of their report's report. This is a thing that happened to me. I was actually encouraged to continue to engage with "the other side" (as it was obviously the right thing to do) but please keep them (all of them) in the loop because it made them look like the bunch of useless muppets they were. In their defense, this was a tense time for them because there was this thing called the iphone that was an existential threat to the entire organization and people were very busy identifying the most dysfunctional bits in the org tree for firing as things were going rather poorly. I got caught up in one of the larger rounds eventually.
There seems to be a lot of negative view about managers here.
If I had to judge managers by my experience at my first job, I would be first in the line decrying them. But, now I see that is the result of faulty processes, promoting too early and for all the wrong reasons.
In my second job, my manager was my strength. We didn't have much meetings, rather lots of one-on-ones or 3-4 people discussing. Most of us were just out of college. So, when we had strong opinions on the product features, they not only heard us, but helped formulate a proper argument that we could present. He was also a good mentor, helping me reframe my viewpoint, when I didn't agree with one of my very senior colleagues (Later turned out the senior colleague was right. In retrospect, I really pity that colleague for he had to work with a big bunch of naive college graduates with no coding discipline :) )
It helps that the whole environment in the company was one of openness, camaraderie and a real desire to make a difference. But a good manager can always make a great difference in your work and happiness.
Unfortunately a lot of folks get promoted into management w/out skills/training, so engineers think all managers are bad. Which is understandable.
But a great manager is a huge value add who will give you what you need to succeed, help you grow, and keep politics from throwing things off track. Once you have a great manager, it's easy to see how valuable they an be.
I don't think you know what people managers do.
* 2.5h for 30 minute 1:1s for people that want them once a week
* 1.25h for 30 minutes 1:1s for people that want them every other week
* 2.5h for team standup (15 mins/day * 2 teams)
* 4h for project meetings (status or technical discussions) (4 projects at 1h a day, but might be two 30m)
* 2h ceremonies a week (could be refinement/planning/retro)
* 1h compliance meeting (internal or external as my department is heavily regulated)
* 1h manager sync with my peer managers + director
* 30m 1:1 with my boss (director)
* 30m 1:1 with product
* 30m 1:1 with project manager
* 2h "what's next" meetings with product + staff engineers + mgmt for our rough sizing and product pipeline (not every week, but if we're in the midst of a BIG project, swap this with syncs with other parts of the org working on the same thing)
That's 18h of meetings a week. Add on some recruiting/hiring meetings, ad hoc "let's get in a room and talk about it" risk discussions, random all hands, and some bursty higher level stuff (OKRs/goal setting/etc).
That's >20h a week, and I do feel like people need all of those to be productive. If I cut the 1:1s, attrition rises. If I cut the status meetings, stuff gets off track and fingers start being pointed. I'm pretty aggressive when it comes to cancelling 1:1 or status meetings. We'll do a lot of "we don't need this cross team sync meeting unless someone has something they want to talk about or ask questions on". Any time I spend on people or making sure we know what we're trying to accomplish has huge ROI, IMO.
FWIW: Was a former lead developer with decade plus experience hands on coding, so I believe I can bring at least some developer perspective. I have a CS degree, not a management one.
Complain to your company for poor recruiting.
If you deal with “bad” managers, that’s a function of working at a “bad” company and you only have yourself to blame for that.