I'm at LI and my reporting chain is Sr mgr > Sr Director > VP > Sr vp > CEO.
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 used to work for Large Tech Company and I would pretty frequently fly out to San Francisco Suburb for work. One of the more interesting time periods of that phase was when the office building I worked at for Large Tech Company was across the parking lot from LinkedIn in San Francisco Suburb. We frequently played a largesse game of hangman with the LinkedIn employees drawn on the windows across our parking lot. LinkedIn employees then were fun and living the Hooli roof meme for sure from our perspective.
In the 90's, the shadows of the P-3 Orions regularly flying out of Moffett Field to hunt for submarines would pass over my house and briefly darken my living room many times a day in Mountain View.
I don't think linedin has those office buildings anymore. They did a land swap with Large Tech Company for some buildings Large Tech Company owned elsewhere.
Yes, for sure. Don't know if being acquired by MS resulted in this reputation (MS has had the same reputation for decades) but they are well known as a chill workplace.
To be clear, we still get an awesome amount of time off but deadlines pushed are comical to the point of, "well that's not Happening" except not everyone realizes this and is driving towards unrealistic deadlines they will miss.
It's funny, I knew a fairly junior guy 4 years ago there on the east coast and he was portraying an image of being constantly under the gun and overworked.
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?
Huh, my experience is the opposite. Indians work themselves to death, while Americans have very clear boundaries on when they stop working. Chinese Americans & Indian Americans work about the same as Americans, but 1st generation Chinese immigrants easily take #1 for the most hours put in.
> 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.
For context: your average outsourcing companies like Infosys pay their new hires ~$4500/year. And before you say thats a lot for India: it's not. That's paycheck to paycheck life in cities where these outsourcing companies have offices.
> 1st generation Chinese immigrants easily take #1 for the most hours put in.
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.
> 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?
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 :)
> But then that brings me to the part about “friend who works big tech and he has no chill for Indians”. Like, Indians period?
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.
> It is sometimes possible that a young Indian employee might call you “Sir”
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.
Yep, being a first generation person who moved cultures from India to the US, I am pretty sure I was a lot more deferential, if not flowery when I began working here. It took me a while to internalize the “No, I think you're wrong” or the “No, there's no way I can do that by Tuesday, sorry” confidence that seems to come naturally to even new grads at their first job in the US. I also suspect that this held me back a bit early in my career.
> The H1B program is terrible in that it ties your immigration status to your current employer
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.
Officially it is, and if you present to USCIS that you have plans to go beyond the limits of H1B, technically they could take action. In practice however,
What company were you at and what were you paying? Did you directly hire or use 3rd party contractors/bodyshops?
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.
For those located abroad, a mix of referrals and also basing hiring criteria on a mix of where you worked previously, where you studied, a very rigorous panel interview, and having EMs and PMs who have cultural competencies in regions like Israel, Eastern Europe, and India.
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.
Anecdotally, the Indian people I've worked with have been incredible. One of them (my manager) annoyed me to death and I eventually quit because of him, but I never doubted his work ethic. If anything it was my American coworkers who would frequently take off early, goof off at work, etc.
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.
Yes, I believe perception is skewed due to how people categorize their experiences:
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.
I used to loudly proclaim, given previous work experience, that companies that offshore basic internal services like HR and Desktop Support across the world are companies in their bad times & willing to abuse their own employees.
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".
I have no issue with my Indian coworkers but my company has all but said they are trying to replace me with off shore workers. I do a lot of quotes for services and while the off shore guys are much cheaper they pad the crap out of their bids, where they will take 250 hours, we'll do it in under 100h, that difference makes us almost the same price. So then it's up to the to decide do they want it cheap or fast. But I can see the clock on the wall ticking.
Every Indian colleague I had here (Berlin) was a ruthlessly ambitious workaholic (sometimes a reform workaholic that realised they shouldn’t work that hard or they’d burn out), quite often very competent and always very driven. Just as another piece of anecdata.
> Is there a grain of truth to the “lazy Indian” trope?
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.
This person is incentivized to show off how glamourous and laid back it is rather than the actual work they are doing in the 8 hours around this 2 minute video, so I'm not sure why you'd be reminded of it.
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.
Free/cheap food, enough meeting rooms, and a place to walk.
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've seen other similar videos made in identical style. I think it was a viral trend. The objective being to enrage people with smug workplace laziness culture, and get plenty of views as a result.
no idea why you need a dedicated person for dealing with the advertisers. it seemed to be just pressure from adl to scare the advertisers away, or otherwise adl will generate controversy
Without internal Twitter context, but having seen companies with marketing teams... there's a lot of people involved in doing close work with partners, whether advertisement ones or others. On the tech side it's kind of like AWS support - sure, everyone had access to the support portal, but once you start spending $$$, you'll get dedicated people sitting in your company's slack channel, providing support, advice and planning if you need it. (Sure, it doesn't always work great, but the idea holds) I'm sure that whoever was the big ad spender with Twitter has a dedicated contact reachable more directly. (And possibly negotiating better deals than advertised to everyone)
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.
because advertising and marketing are still very much industries where your "face card" matters and where companies will spend millions of dollars elsewhere if Chet from Advertising gets laid off.
"the missing 80%" you mean the ones that would go from the salad bar to the yoga class and then go into a DEI meeting and talking about how we must change "the color of our vibes"?
Yeah I think Elon is almost picking up that slack. But I doubt anyone could find him at an yoga class
There was probably a lot of slack at twitter, but as an outsider it's incredibly hard to correctly identify who is the slack and who is doing real work (and a lot of people are somewhat in-between) in such a short amount of time. Musk took a massive risk and I'm sure a lot of the collateral damage were people doing genuine work.
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.
I mean, they're making a lot less money, so I dunno. It's easy to run a company with a skeleton crew if you run it at a loss. it's the cost efficiency that makes it harder.
The chill is gone, there is pip quota, aggressive deadlines, layoffs, and reorgs.
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
> a distinctive lack of chill right now contrary to the company image
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"...
Speaking as someone who has been a "middle manager":
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"
Having 17 direct reports is too much. Managers are not just a link in the chain of command. They also do stuff that needs to be taken care of. All kinds of unusal things happen and not all are suitable for delegation. 17 direct reports is not only a measure of how many colleagues they need to manage. It is also a measure of the large the weird-things-that-needs-taking-of-scope is.
Seriously. The most effective teams I've ever worked in, had 3-5 people under a manager. The manager occasionally got their hands dirty when they could spare the time, but in general, "getting every roadblock out of 5 people's way" is a lot of work, and combined with all the non-delegatable stuff, would keep them pretty busy.
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.
Was thinking about this in mathematical terms recently, in terms of what's efficient vs. what can scale. In general, managers can't do things for reports that don't scale fairly across their whole team, because otherwise it'll give the appearance of favoritism for those reports who get favors and demotivate the rest. So to a first approximation, a manager with N reports can devote at most 1/N of their time to making a report's job easier. (To a second approximation, it's more like 1/2N because the manager also has overhead tasks like 1:1s and performance reviews that scale with the number of reports. To a third approximation the denominator scales supra-linearly after about 10 reports because you start taking up all your time with management tasks and have literally zero time for project work.)
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.
The biggest one I've encountered is just scouting out problems before handing them off to an IC, to ensure they're framed correctly and the IC will be able to make rapid progress on them.
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.
The goal of a manager ought to be to maximize the effectiveness of a team, which does not directly mean fully utilizing time, especially in a software development context.
Often some slack in a team results in the team as a whole being more effective.
Your final paragraph is why it's so important for companies to grant formal titles to their ass. managers. You can effective manage a large number of direct reports, if you have an assistant to handle the other half of your job.
I have 10 direct reports across 2 teams, with responsibility for a number of actual deliverable work pieces external to these staff.
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.
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.
One could say that, sure. I'm yet to see an alternative that offers better outcomes... In fact, the alternatives I've seen/lived through have only offered significantly worse outcomes (both personally and for the organisations).
That point is quite variable. In some cases, yes, that's the whole job. In others, that can be a split e.g. some EM roles are 20/80 heads down to heads up.
My team have a very wide and complex domain of work; essentially we cover all of the domain of public health administration - patient management through to billing through to regulatory reporting, etc, etc. My team can be presenting formal advice for changes to statutory inpatient reporting one day, then troubleshooting a billing algorithm the next day, and then writing a FHIR parser the day after.
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 have a team of 13. It's a lot of work. One-on-ones, setting direction, making plans for the coming period, talking and negotiating with stakeholders, scrum ceremonies, quality control, helping people grow, resolving conflicts - it never ends. I enjoy it though.
Like all things, if it's done as a cargo-cult activity, then yes it can sap a lot of time for little reward. However, when done well, a 1:1 can be a high-value activity.
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.
I do them bi-weekly, but it still takes up a lot of time. However, if you don't do them, people will feel like they're not being heard and they have no scheduled semi-informal way to communicate with me. So I will never hear their worries or concerns, I don't know what they're struggling with, I won't hear their ideas for improvements, etc.
I think they're super useful, especially in a mostly-remote context.
It depends on the nature of the work but technical work (which -like most people here- is I assume what we're talking about) requires a lot of time investment to truly understand and give meaningful feedback.
I have a long held belief that engineering managers are mostly a scam, and are actually just overpaid scrum masters. This is from working at some top companies
Silicon Valley used to have engineering managers who managed engineering.
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.
> As the money got bigger we got more grifters / professional manager types.
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.
MBAs succeeded in making management a distinct discipline that has been divorced from the work, only connected through metrics and KPIs. If you cannot talk to them on their terms, they are happy to impose sanctions on you.
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).
GP: "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."
You: "And oh boy, infrastructure was not his core competency."
> 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.
Wow. You've also just described oil and gas Operator engineering departments perfectly. It's got to the point in oil and gas operating companies, where even the simplest piece of technical work is outsourced, and even if you wanted to produce quality engineering deliverables yourself, it's hard to hunt down someone who is willing to review and sign them off because so few have that competency themselves. Of course nobody admits to that, so they're just slippery and try to reassign or deprioritise any work that involves actually doing a calculation.
I moved over to Silicon Valley fairly late (in 2018), and I was immediately shocked at how frowned upon... even disincentivized technical knowledge was at the management level.
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)
The A/B/C quote isn't about lone wolf devs, but is "A players hire A players, B players hire C players". Meaning really good devs want to work with other really good devs, but mediocre devs want to work with crappy devs to make themselves look better.
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.
I've worked in software and I've flown jets off an aircraft carrier. Egos are not an unfamiliar concept. And while there are "A" players, there are also arrogant prima donnas who think they're "A" players, which is why I'm skeptical of sentences like this.
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.
This is how you get the Office Space "I have eight different bosses" environment. And they all play "hide the problem, fluff the status" games so the leaders above++ have no idea how big of a shit show the ground level is.
> 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.
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
This is true for every tech company outside of Silicon Valley as well.
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.)
Fantastic comment. Btw the same dynamic also exists in other areas such as other engineering disciplines, finance, etc, as Im told. Software was probably an outlier until people realized you could make a good career out of it
Well with size comes management. Management of money and architecture.
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 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.
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.
I think you're right on the money, with a single exception: there is a value to engineering managers being trained in professional management skills.
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.
On the other hand, manager writing production code is a terrible footgun for the team. Time/resource conflict between helping a team and shipping code has no good outcome, either I let team down by decrease their productivity, or I let team down by slacking behind.
What I saw is that role isn't working either way. TLM don't have manager's power (can't reward and cannot punish) and at the same time expected to churn out production code, carving continuous focus hours out of manager's schedule.
You might be right, but that might be because they're just really bad managers.
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.
I've had managers that were good at "protect their engineers from the organization, ensure they have the resources required to do the work" and in general doing a good job at deflecting bullshit. But I have never had one "make sure their organizational goals, development, and wellbeing are being advocated and cared for." In fact I'm struggling to recall any conversation I've ever had with any manager about my goals or development that was not a perfunctory one in an annual review.
As an engineering manager, my team doesn’t know half the crap I keep off their shoulders. But that’s the part I play these days if we want to get things done.
Yeah, but... isn't that kind of strange? Most managers who didn't know half the things their reports were doing, would conclude that their reports were useless. So is it surprising that developers who lack visibility into the things going on above their paygrade, tend to conclude that their managers are useless?
Yeah, I'm a little baffled by HN's contempt for engineering management. IME, whether the manager is any good is one of the most important factors in whether the team is any good; it's one of the things I'd be most concerned about if I was moving role.
Yes it depends on those things, nobody is denying it. But most managers are still useless, that's statistically observable, just chat with any random programmer outside of SV.
A good engineering manager should be like a warrior in a garden; mentoring and fostering the engineers, and ready to go to "battle" for them at a moment's notice.
Bruh, I don't know where you've been but "Engineering Manager" positions are the new "Devops" from 10 years ago in terms of needing to do multiple jobs. Every position I've both applied for and gotten has required that I can
-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
If that is legimately the case then you are probably working fore a bad company. I would caution you to confirm that your engineering manager isn't working in the background on a bunch of non engineering tasks that kept the engineers more productive.
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.
At my FAANG, the chain up until the SVP has an engineering background. I previously worked for a startup that put a non engineer in charge which was super weird. Before that, my engineering manager was highly technical.
My manager does little else besides asking what everyone is working on every day. We could automate her position with a slack bot and get the same results.
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.
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.
Work for a company whose policies allow this. (Some companies essentially require that the people manager an IC reports to must be of higher notional level than the IC, some do not).
The problem with "Engineering Managers " in our software verticals is that we mostly get people who are shitty engineers and shitty people managers.
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.
I'm not a scam, I like to believe, because I've always gotten good feedback from my teams. But definitely the job description is quite light and a bit handwavy, so all companies could use fewer engineering managers, not more. I myself would volunteer to go back to IC right now.
You think someone is leaving honest feedback on those forms? It's trivial for any manager who is not a complete moron to figure out who left a bad review and retaliate as I've seen happen multiple times in my career (mostly to other ICs but sometimes entire teams)
Not only that, but even if I don't think my manager is the best guy ever, there's usually no point in giving them bad marks on those forms. It doesn't cost me anything to give good marks, and helps them play their own game.
This. It would be suicidal to leave a manager a bad review. The only thing that works is anonymous feedback which is how Meta/Facebook is so effective at getting rid of bad managers.
Scrum masters don't really need to be super technical right? They just need to make sure the rituals work and eventually make themselves redundant. I'm an IC and thinking of following some courses so I can fill that role in my team but only because it may give some credence to the rituals, not because my technical insights make it better. I think the rituals can add value but only if they're taken seriously - otherwise they're a waste of time.
I prefer those because at least a product manager is busy. Scrum Masters are so often bored to tears and end up generating all sorts of meetings as a result.
We try, but Compensation Committees tie our hands (99% of the time it's for good reasons, but it's not fluid enough to help that 1% outlier you REALLY NEED).
Where are all of these scam manager jobs where I don’t have to do anything other than a little bit of scrum mastering? Sign me up!
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.
AFAIK This isn’t true at any FANG-like companies. Engineering managers I’ve seen either code or at least do technical reviews. This is true for senior managers and often still true regarding technical direction at the director level.
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.
firing entire levels of middle management seems to be a fashion these days, but from experience in my org it has been counterproductive. my current manager now has >60 direct reports so can’t even find the time to handle each of our basic hr tasks, let alone provide any leadership.
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.
Nothing new. Middle managers are the traditional food for layoffs. Have been, for decades.
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.
if you hated it, how and why did you stay for 25 years? i’m at 7 years as an ic at a fortune 500 co and want out. ideally i’d start my own co without taking vc money, but so far i’ve been too afraid of the risk.
i don’t think you’re an idiot, nor a chump. just was wondering how you summoned the strength to persevere even though you didn’t like managing. maybe it’s a generational thing, my parents stayed at the same place for their whole career, but these days we’re expected to jump ship every few years if we want a raise that matches inflation.
Software/tech folks have it better than almost anyone else.
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.
yeah i loved my first few years at big co which in hindsight was because of my manager. he hired me out of college and somehow brought the best out of me, resulting in many patents, publications, and a huge budget that rewarded our success. then the csuite turned over and my great manager was let go. now i’ve had 3 since and they’ve been progressively worse if measured by team output. so it goes
> plus it’s bad for ic morale because there is now no path forward for advancing our careers to the managerial level.
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's a big mess, for sure. I'm currently trying to interview as many of those managers with>10+ direct reports as possible to see what their biggest pain point is with staying on top of it. If you're one of them, ping me (https://www.linkedin.com/in/sascha-manuel-reuter-3177752b), and let's see how we can ease the pain for you and your directs.
I am dying to leave the management track and go back to SDE. Pretty much every company out there bloated their ranks to include more middle managers and it became an unbearable mess. After 12 years in management, though, I can't get interviews for SDE, so I am kind of stuck. Imagine writing code for a living? DREAM.
The worst thing is that I never wanted to be a manager but somehow always got pushed that way by the higher ups. I blame my background as evangelist being able to explain technical things to management. Ugh.
Funny. I always want to put my head down and write code, but because I actually know how systems work and help everyone else out to accomplish the basics, every job ever pushes me into infrastructure roles and I end up being the organization's Brent all the time.
Not the parent but,
the reference to "Brent" in this context likely comes from the book "The Phoenix Project: A Novel About IT. In the book, Brent is a key IT employee who is knowledgeable and skilled, but he becomes a bottleneck because everyone relies on him to fix problems. Due to his deep knowledge and expertise, many tasks and critical issues can only be resolved by him. This reliance on Brent causes delays and inefficiencies in the organization's IT operations. The term "Brent" in the tech and DevOps community has come to symbolize a single point of failure within a team or organization.
Typical ratio of people to managers in a company is about 1:4, so that tracks.
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.
Every time I see more than 10 direct reports, I think of this quote:
"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."
Interesting. Parent comment is about 4:1 even.
In my career I saw from 5:1 to 20:1 IC to managers on a direct level.
However the higher one go the better the ratio, like VP to SVP ratio rarely reaches 10:1 even. Now I'm curious what are the industry 'standard' numbers.
20:1 is terrible. You may not have managers but other ICs then need to burden themselves with management duties. Even if you have 1:1 for half an hour every week, that’s 10 hours of just 1:1s. There is no reasonable way to keep track of it. It’s bad for the manager, it’s bad for the IC. Anything more than 10 is bad, ideal would be 7-8 reportees.
My manager has a bit more than 20 direct reports, and it works well in my experience. We have 1:1 every two weeks, but often there's not much to say.
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.
The difference is that they are not managing me, they "manage" their area of expertise. Better than an "all-rounder" who is doing PO, SM, HR, approving vacations and doing 1 on 1s ...
> In my career I saw from 5:1 to 20:1 IC to managers on a direct level.
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.
What you described in first half is how things should (and used) to work imo.
> 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.
bytedance has 50-200 reports per manager in some teams and are wildly successful
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)
I remember interviewing someone once that claimed to have 200 direct reports. I was really blunt and said "nobody has 200 direct reports".
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.
I’ve heard of companies where hundreds of people officially report to person X but there are “mentors” with 3-5 mentees that seem an awful lot like other company’s mangers. Not sure what the point is exactly.
I mean manager has at least some power, 'mentors' or 'leads' - don't. At current org. we have ~20 ICs in the department and one manager, there are clearly 3, maybe 4 folks who are more senior in experience and more influential, but no, no one perceive them as managers.
Given the grandparent was talking about Bytedance, perhaps you're the floor supervisor for dozens of disposable people watching reported or flagged content to identify porn, violence, etc. on TikTok - disposable because depending on what sort of banned content actually gets posted, you might have a lot of mental trauma and burnout that the company would really rather just replace people than deal with.
When I started my career it was pretty common to have a team of ~12 under one manager with a couple of TLs. Nowadays it's more like 1:4 or even 1:3 - that's 3x management bloat for mostly bureaucratic reasons and with no obvious improvement in productivity or retention. Then there's the thing you said - people with "manager/lead" in title but no obvious managerial responsibilities.
In many shops managers are now doing TLs work like designs and technical vision except they dont actually write any code. This goes about as well as one would expect…
> Typical ratio of people to managers in a company is about 1:4, so that tracks.
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.
Productivity tools don't help you when dealing with people problems. You can't throw a TODO app or some other bullshit on someone who is underperforming or to coach someone for a promotion.
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?
I do think all of these various kinds of managers - none with any actual clout, is part of the problem. It is although the structure is designed by employees for employees, not stakeholders.
I bet most of the rest are also managers in practice, although they might have had different titles.
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.
I see this discussion has gone deep into so called technical managers and their effectiveness, even their necessity.
I feel there is no clear answer possible. We are trying to objectively analyse what is not objective in the first place.
Before we discuss necessity of some role we need to define it.
Who is a good technical manager? What do they bring to the table?
Definitions anyone? I can try but it will be subjective. I am sure there are different sets of opinions around what %mentoring and IC they should do.
In fact, can we even define software engineering role and standards? Someone who writes code to solve a problem? To me a good one will write concise code thats easy to change making good use of available tools and paradigms. I have already used several vague terms.
My point being, we are in a profession where entry barriers are low. Role responsibilities and standard of good work are contextual and opinionated.
That has a direct impact on your experience with peers and managers.
You are not always going to approve of the number of managers, their level of tech involvement etc. Have clarity on what you can tolerate and what you cannot compromise on.
You can actually use the SOLID heuristics that people use to evaluate code quality to also look at organizational quality and the quality of decision making in organizations.
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.
When I was working in local government my team, that I was 1 of, had two permanent staff with 7* managers above us.
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.
I see all the comments about how managers are necessary. Let’s assume we can automate more and more HR tasks, what are managers required for besides that?
Conflict resolution, planning, escalations, engineering work, performance evaluations, morale, career growth. I'd say most of the work I deal with is managing escalations from senior ICs of varying technical and organisational natures.
I once counted the number of people between me and the CEO while in Nokia and I got to about 8 levels.
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.
Got somehow similar experience, except software folks tended to mingle quite a lot and cooperate. But pushing through anything new or getting help... The hierarchies were brutal, the management were yuppies busy with business travel and "conferences". Things were somehow working or were absolutely impossible.
I am really sorry for all those who have lost their job today.
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.
Also ensures communication vertically and horizontally across the org, works with partner teams, provides guidance and mentorship, and who’s efficacy is the number 1 cause of attrition.
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.
The amount of communication and reporting required increases with an increase in number of managers. By reducing number of levels and number of managers, you are reducing the amount of communication required in the first place.
I haven't had a manager before who didn't complain about how many meetings they have, but I think they are a necessary evil for the position. My short stint in management sure saw meeting numbers balloon.
I'm a manager for two dev teams (~10 people) my breakdown per week is:
* 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.
That's pretty standard. And where I work we have each manager also drive at least one major initiative that spans multiple teams. So that ensures that you're the domain expert in at least one thing above and beyond what your team is working on.
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.