Ask HN: Why hasn't x86 caught up with Apple M series?
421 points by stephenheron 2d ago 607 comments
Ask HN: Best codebases to study to learn software design?
100 points by pixelworm 4d ago 89 comments
Google has eliminated 35% of managers overseeing small teams in past year
373 frays 165 8/27/2025, 9:16:56 PM cnbc.com ↗
It’s part of an effort to have dedicated managers and dedicated engineers instead of hybrid roles.
This is being sold as an efficiency win for the sake of the stock price but it’s really just moved a few people around with the TLMs now 100% focused on programming.
In those last 3 years I've only seen TLMs used to assist an overloaded EM.
The pattern I've seen is something like:
Maybe project C was just reorged under the Principal EM or maybe it's a speculative side project. But those last three are clearly clustered, there's no good line manager fit and the principal EM feels disconnected from the 2 mid level ICs. Project C is a bit of an island and projects A and B are taking up most of the EM's time.So the Principal EM deputizes Senior IC on project C as a TLM until things have changed enough that there can be a dedicated EM. Eventually the TLM converts to EM, a new EM is brought in, or there's a reorg, etc.
Of the two times I saw saw it happen locally, both converted back to ICs after a year or two and noted that the role felt like being 70% IC and 70% EM.
Nowadays the TLM role doesn't exist so the principal would delegate most of the technical responsibilities of the M role, giving them nearly full control of project C, but would not give them a formal role. (I've been that senior IC for project C.)
(Edit for formatting.)
I am obviously not disputing your experience, but wanted to mention that this was not the standard pattern. The standard pattern for forced conversion at L6 (Staff) was either 6 or 7 reports (I don't remember exactly).
> Principal EM
I don't want to be overly pedantic, but there's no Principal EM on Google eng ladders and so it's not entirely clear which level you're referring to.
The IC ladder runs Staff SWE (L6) - Senior Staff SWE (L7) - Principal SWE (L8) - Distinguished SWE (L9)
The Eng Manager ladder runs EM II (L6) - EM III (L7) - Director (L8) - Senior Director (L9)
P.S. I hope I got the EM II/III designations right. I think EM I is L5, though almost never seen in practice.
P.P.S. Confusingly, the IC ladder allows a limited number of reports (the limit increases with level).
Principal EM - USD$1.3m/yr per https://www.levels.fyi/companies/google/salaries/software-en...
Staff EM - USD$664k/yr per https://www.levels.fyi/companies/google/salaries/software-en...
Staff IC - USD$557k/yr per https://www.levels.fyi/companies/google/salaries/software-en...
Senior IC - USD$410k/yr per https://www.levels.fyi/companies/google/salaries/software-en...
Mid IC - USD$290k/yr per https://www.levels.fyi/companies/google/salaries/software-en...
levels.fyi doesn't appear to use the term "Technical Lead". There is "Technical Program Manager" and "Technical Account Manager" that sound like they'd be similar (someone technical transitioning into a full-time non-technical role). And then roles such as "Product Manager" and "Program Manager" seemingly for those who are currently 100% non-technical in their work.
Does the change mean the most competent solution architect who has successfully designed and implemented many complex systems from scratch is capped in salary package because they're not doing the important job of demanding those around them fill out TPS reports all day?
[1] https://www.levels.fyi/companies/google/salaries/software-en...
"Technical lead" is not a role profile or ladder, it's what you're doing. You could be a TL at L4 on a small project, and you could not be TL at L7 if it's a big enough project. All very subjective.
The point of this thread is that there are teams with a manager who is the defacto TL for the projects the team is doing, so they have IC responsibilities, and then there are teams where the manager does manager things and there's one or more separate TLs.
I've worked on teams in both structures, both in and out of Google, and whether TLMs vs EMs work well depends on so many factors: who the manager is, their management style, the org's priorities, the projects, etc.
In house solutions architects are not really a thing at FAANG. Designing and implementing systems is what mid+ level SWEs are expected to do. The solutions architects I have seen were all in the sales org helping external customers better use the cloud. My experience isn't exhaustive of course.
It also sounds like the 10x developers are underpaid by a factor of 100!
The prior poster is missing the L7 tier, which is Senior Staff Engineering Manager for the Engineering Manager Ladder.
L8 is a Director on the Engineering Manager Ladder L8 is a Principal on the Software Engineer (SWE) Ladder.
Tech-Lead Managers (TL/M or TLMs) were on the SWE Ladder.
For reference:
Software Engineer Ladder
L8 - Principal Software Engineer
L7 - Senior Staff Software Engineer
L6 - Staff Software Engineer
L5 - Senior Software Engineer
L4 - Software Engineer II
L3 - Software Engineer (new graduates would start here)
----------------------
L2 and below exists in rare occasions.
Engineering Manager Ladder
L8 - Director
L7 - Staff Engineering Manager
L6 - Engineering Manager (M1)
L5 - Engineering Manager (M0 - normally this level does not exist for external hires and is for the rare situation when a SWE is converting to the Engineering Manager ladder)
> Does the change mean the most competent solution architect who has successfully designed and implemented many complex systems from scratch is capped in salary package because they're not doing the important job of demanding those around them fill out TPS reports all day?
No.
It's just a way to ease unsuspecting engineers into management. If you don't suck at management, your team inevitably grows (or you're handed over other teams), and before long, you're managing full-time.
Which means that there are three type of people who remain TLMs in the long haul: those who suck at management; those managing dead-end projects on dead-end teams; or those who desperately cling on to the engineering past and actively refuse to take on more people. From a corporate point of view, none of these situations are great, hence the recent pushback against TLM roles in the industry.
Inevitably because why?
> those who suck at management
If higher management can figure out not to put more people under them, why can't it figure out to remove the existing people under them?
> those managing dead-end projects on dead-end teams
If "dead-end" just means "not growing" then that sounds fine. When a company does thousands of things only a small fraction of them need to be growing.
> those who desperately cling on to the engineering past and actively refuse to take on more people
"Desperately cling" is a wild way to refer to someone sticking with a job they like. And if they're a TLM it's not the past, it's the present. Wanting to keep your present job is very normal.
And is the end goal to have zero TLMs in this expanded team? If you're going to pick new TLMs to go under the one you push into higher management, what's bad about leaving them in place and putting someone else above them?
as in "and the strawboss said well a-bless my soul, you load 16 tons.."
Impact and outcomes are far more important than outputs, so it makes sense to for you to spend a lot of time on that. But, when performing review time comes around, you’re still bounded by hard metrics around outputs.
(1) As an engineer, I prefer to be managed and guided by someone who actually knows what I work on, preferably better than I know it.
(2) A manager who actually understands the tech is often better at unblocking the team.
(3) Since senior IC openings tend to grow very thin as you become older, TLM path might be a viable career path for at least some.
Can this role work if we don't expect IC output from the TLM beyond what they themselves take on for their own satisfaction and growth?
As a manager of people who know far more about the things they do than I do, my goal is to assist and ensure in the right place (for them and the org). It’d be foolish for me to hire peons who know less than me.
Much of the reason the TPM job exists is simply so your manager can be an advocate rather than a nag. The nag job is offloaded to the TPM, but the TPM has no decision-making power, so you don't get perverse incentives where the manager burns all their relationship capital making you do your work, or sandbags the deadlines so they don't have to.
In many orgs TPMs are also in charge of goodies like fun events or device/swag distribution, as a way to offset the negative emotions that come from them basically being nags.
The problem I foresee here is, there would be escalation meetings and all the non-technical managers would sit back and point fingers at the TLMs until they leave.
TLM is an odd role. I understand big tech companies have their own culture but it does seem like a poor management strategy regardless of efficiency.
Of course, this can backfire in many ways. You end up wasting engineering talent, and as the organization grows, managers spend more time on paper-pushing than on creative work. And there's no shortage of engineers who are just bad at reading, talking to, and managing people.
But the huge perk of management is leverage. If you're technically competent and credible, and want something to happen, your team will see it your way. If you're a random "ideas guy" in an IC role, that's not a given.
There are three levers of power in an organization - relationship, expertise and role. Role power is by far the least effective. If you can’t get team buy in for your ideas or they believe you’re an idiot, you won’t get anything done.
A high level trusted IC who builds relationships inside and outside of the team and who is strong technically can work miracles.
At my current 700 person company, I’m pushing through a major initiative that management up to the CTO was at first skeptical about because I convinced them of my vision and I built relationships to get buy in.
I’m a staff engineer.
Even at BigTech I saw L6s and L7s ICs push through major initiatives the same way.
To be frank: it sounds nice, but I don't think that's really true. It's the power of "who's going to decide my promotions", "who is going to advocate for my team and get us more resources", "who approves my expenses", "who is going to protect me if something goes wrong", etc.
This doesn't give the manager a pass if their ideas are objectionable, but if they're credible, it's a huge advantage. Small disagreements disappear and people fall in line behind your vision, get excited about it, and make things happen.
In contrast, in an IC role, you can successfully push for initiatives, but you're always working against that dynamic. The merit of your idea aside, folks might simply feel that you're pushing them in a direction that's less likely to get them rewarded or recognized within their reporting chain. That takes extra effort to overcome.
Being very visibly anointed by some VP helps, but that's tapping into the exec's leverage, not yours. And that approach has downsides; I worked with more than one architect / uber-TL person who were universally disliked and feared. The perception was that they showed up to make your life worse by putting extra work on your plate, without having much skin in the game.
Of course that’s the play. Even a lind manager can’t get major initiatives through without getting the buy in from their manager. When I was working for startups, the director (1st company I had influence at) and the CTO at the second had been convinced of my idea and gave me the authority to pull who I needed to get it done.
Fast forward past BigTech to where I work now - a third party AWS consulting company, after convincing the powers that be of the market, I had it escalated to be one of the companies initiatives for the year.
But more so in BigTech, promotions aren’t completely on your manager. At least at AWS you had to have recommendations by I believe two or three people one level ahead of you and it had to go through a committee.
From talking to a couple of L4s that I mentored when they were interns and when they came back, they were both complaining about the promotion process even though their manager supported them.
Eh, maybe at faangs or at the executive level but at non faangs you might not notice a role having power because most roles with the Manager title are no longer actual managers but supervisors.
I had more agency over where capital was deployed as a teenager deciding how many people were going to be on the shift for closing, then I have making over 200k/yr as a Senior Manager.
Any role that has decision making power over where money goes automatically has a massive amount more power than a role that does not
When I was being hired as a strategic hire for startups - and was being interviewed by the director or CTO - I specifically asked would I be reporting directly to them or another manager. I actually refused one job because I saw that the expectations they had from me and how far I was down in reporting structure was incongruous.
If you were in a growing domain, and the TLM stayed engaged with the code it worked really well, but as soon as one of those failed it was a bad roi for the company and a pretty terrible experience for everyone. the juniors were never getting promoted since there was only room for 1 expert on the small domain. The TLM was just chilling getting 5-10% raises a year without going outside of their little kingdom, but making sure their domain worked well.
As their junior got better they coded less but their juniors couldn't grow as long as they were there because the niche didn't need that many people.
I don't think its a coincidence that all these companies eliminated these rolls after 2022. When you have unlimited money and massive headcount growth these roles can exist and give your good but not exceptional people room for career growth. At static headcount, you basically need to do what banks do -- yearly cuts or no one can be promoted or hired.
IMHO, the conditions where a TLM role is appropriate are:
1.) You need to be in the company growth phase where you are still trying to capture share of a competitive market, i.e. it matters that you can execute quickly and correctly.
2.) There needs to be significant ambiguity in the technical projects you take on. TLMs should be determining software architecture, not fitting their teams' work into an existing architecture.
3.) No more than 3 levels of management between engineer and person who has ultimate responsibility for business goals, and no more than 6 reports per manager. The mathematically inclined will note that this caps org size at 6^3 = 216, which perhaps not coincidentally, is not much larger than Dunbar's number.
4.) TLMs need to be carefully chosen for teamwork. They need to think of themselves as servant-leaders that clarify engineering goals for the teammates who work with themselves, not as ladder-climbers who tell others what to do.
Without these, there is a.) not enough scope for the feedback advantages of the TLM structure to matter and b.) too much interference from managers outside the team for the TLM to keep up with their managerial duties. But if these conditions are met, IMHO teams of TLMs are the only way to effectively develop software quickly.
Perhaps not coincidentally, these conditions usually coincide with the growth phase of most startups where much of the value is actually created.
I'd love to say that the answer is "because I'm a good manager", but I think that the real answer is "because there was money=headcount available, the layers of management above me successfully presented our value and inflated our needs enough to convince a VP to give it to us, and my own manager physically did not have enough hours in the day to have 1:1s with all the new incoming headcount without introducing some layers of management under us". If it weren't me, it would've been some other manager. For that matter, I wasn't a manager when I joined the team, but I was interested in managing and of sufficient level that I could pass department policies, so I ended up more than doubling my team size within 6 months of becoming a manager. The team was pretty busy for the first year or two after that - we'd gotten all that headcount by arguing that we were critical to some big strategic initiative, after all - but there were long periods after where we were oversized by a factor of about 2, so I just let everyone work 20 hour weeks and phone it in until the next big project came.
The more time I spend in the corporate world, the more I become convinced that success is a matter of meeting the minimum qualifications, bullshitting, saying yes to opportunities created by people who are themselves bullshitting, and doing the minimum amount of work needed to avoid being called on your bullshit. Businesses don't hire because they actually have work to do. They hire because they have money and money=headcount and headcount is the only way for a manager to get promoted or pad their resume.
Given a fixed headcount, you can't have frequent promotions without either personnel turnover or allowing for employees to be routinely demoted.
I mean there is the obvious part of the answer in that managers are the ones that are given the power to define that growth ladder, but I'm not sure this fully explains things. If people are transferring from technical positions to managerial positions then should they also not be aware that there is a lot of advantages to allowing people to keep climbing the ladder through technical positions? That institutional knowledge can be incredibly valuable. It's often what leads to those people being such wizards. They've been with the code for so long that they know where things will fail and what are the best parts to jump in to make modifications (and where not to!). But every time you transfer one of these people to a non-technical role that knowledge "rots". More in that code just keeps evolving while their knowledge of it remains mostly frozen.
Which what you say sounds like maybe the worse end of that. Taking that person with institutionalized knowledge and hyper focusing their capabilities on one aspect. That doesn't sound like an efficient use of that person. Though the knowledge transfer part sounds important for a company's long term success, but also not helpful if it's narrowly applied.
do they report to the same level? every place I've seen a "technical track" and "management track" it seems the higher level technical people report to someone on the same or even lower level in management. I.E. a manager can have technical reports that are equal level or higher. that obviously doesn't happen in the management track.
not that these are first level managers but if a principal engineer not reporting to a VP, the it doesnt seem like the tracks are equal.
The hybrid role idea has always been ridiculous. It's two different jobs, like being a mechanic and an accountant. Do you need a mechanic? Cool, hire a mechanic. Do you only need a mechanic part-time? Cool, hire a part-time mechanic. But I don't want my mechanic stopping and starting the work on my engine 3 times a day because somebody has tax questions.
The whole point behind the division of labor is to specialize, and get really good at your specialization. Picking up multiple very different jobs and trying to do both is the opposite of efficiency. People knew this 250 years ago.
Overall: this is a good thing. By taking up less room on the technical side, I've replaced one of me with four strong engineers. Previously, I was split between TL work and EM work and as a result, did a half job of each, leaving too much un-done.
The other thing I'll note is that engineers are basically the only role with this distinction. Product Managers, Program Managers, Sales, Marketing, all those roles seem to combine management with seniority. Only on the engineering side do we have both a TL and Manager hierarchy (while typically the TLs for a team report to the same manager that the line manager for the team does, they exert authority differently). This works out okay on the eng side when there is a strong alliance between the TLs and the EMs, but that doesn't always happen.
No comments yet
[1] https://paulgraham.com/makersschedule.html
As far as I can tell, the main function of an EM is to enforce the company policy. I'm not sure there really is a need at a smaller place.
In a small company (let's say anything under Dunbar's Number), you have a very dense network organically, and EM's aren't necessary. As the company grows larger, the matrix becomes sparser and sparser- until you get to something like Google (180k employees plus maybe that many again contractors) and you have almost all 0's. So an EM's job is to solve the communication problem, because information still needs to flow around the company, in and out, whether it's "do this project" or "another team already solved this problem" or "this project is a never-ending world of pain and should be ended" to "employee 24601 is awesome and should be given more responsibility."
Probably the best description I've heard of the EM role is that "It's a large collection of part-time roles, all with disparate skillsets, that together are responsible for ensuring the success of the project."
Communication is a huge part of that - downwards (telling reports the information they need to be successful), sideway (getting information from cross-functional partners and managerial peers so you align your projects with theirs), and upwards (managing expectations and asking for direction at the appropriate point so upper management doesn't freak out).
But other skillsets involved are: playing therapist (managing anxiety, morale issues, resentment, and misconduct); coaching (both technical and interpersonal); splitting up vague exec mandates into subgoals; prioritizing; hiring; managing performance; serving as a point of contact for whatever random problems your reports bring you; negotiating; setting team structure; developing expertise among your reports; managing their careers so they get promoted; ensuring that they're recognized for their accomplishments; helping people have fun in the office; modeling a culture of respect; selling new product initiatives; and yes, enforcing company policy.
I find that it works well, the TLM keep a foot in the action, so to speak and has a better idea of what's happening with the product being developed, what issues we're facing (also in terms of tools, environments...) and it keeps their knowledge of the product more up to date. Of course with their background, I wouldn't say they are all the greatest at managing, but I don't think they've ever done big mistake on that side of their role. So in short in our case it works, but it could just be a consequence of the local organisation and people working there.
I have a lot of thoughts on this. IMHO, it's appropriate for the state that Google is in now, where it is a large mature conglomerate, basically finance & managerially driven, built around optimizing 10-K reports and exec headcount & control. It's not a particularly good move from the perspective of shipping great software, but Google doesn't really do that anymore.
The reason is because software construction and management is unintuitive, and concrete details of implementation very often bubble up into the architecture, team structure, and project assignments required to build the software. TLM-led teams have a very tight feedback loop between engineering realities and managerial decisions. Your manager is sitting beside you in the trenches, they are writing code, and when something goes wrong, they know exactly what and why and can adopt the plan appropriately. Most importantly, they can feed that knowledge of the codebase into the new plan. So you end up with a team structure that actually reflects how the codebase works, engineers with deep expertise in their area that can quickly make changes, and management that is nimble enough to adopt the organization to engineering realities rather than trying to shoehorn engineering realities into the existing org structure.
Now, as an EM with 10+ reports, I'm too far removed from the technical details to do anything other than rely on what my reports tell me. My job is to take a slide deck from a PM with 10 gripes about our current product, parcel it out into 10 projects for 10 engineers, and then keep them happy and productive while they go implement the mock. It will take them forever because our codebase is complex, and they will heroically reproduce the mock (but only the mock, because there is little room for judgment calls in say resize behavior or interactivity or interactions with other features and nobody's holding them accountable for things that management didn't have time or bandwidth to ask for) with some hideously contorted code that make the codebase even more complex but is the best they can do because the person who actually needed to rewrite their code to make it simple reports up through a different VP. But that's okay, because the level of management above me doesn't have time to check the technical details either, and likewise for the level of management above them, and if it takes forever we can just request more headcount to deal with the lack of velocity. Not our money, and it's really our only means of professional advancement now that product quality is impossible and doesn't matter anyway.
Ultimately the value of the TLM role was in that tight bidirectional feedback between code, engineers, and management. As a TLM, you can make org-structure decisions based on what the code tells you. As an EM, you make org-structure decisions based on what your manager tells you. But at some point in a company's lifetime, the code becomes irrelevant - nobody reads it all anyway - and the only thing that matters is your manager's opinion, and by transitivity, your VP's opinion. A flattened org structure with as many reports per manager as possible is a way for the VP to exert maximal control over the largest possible organization, mathematically, and so once that is all that matters, that is the structure you get.
I thought it was a nice stepping stone for people to learn management without having 10 people dumped on them. But it looked bad on paper.
Once you're late stage though, that's done. TLMs are probably being held to 100% of IC standards and manager standards, people under them are jockeying for "impact" and don't want to compete with their manager, etc.
I totally see why it wouldn't work at today's Google. Honestly maybe it's a positive sign they recognized that.
There’s always a downside to anything, and the merits/demerits are all about the politics of the org.
I really never intended to have a management position, but this has been an incredible opportunity to experience a portion of it without fully committing. Other replies have described this as a transitional role, and I don't think they're wrong. In the long term, especially if the company grows, I can probably be more valuable by committing to one path or the other. However, for the right person and situation, I could see us minting a TLM again, regardless of size.
Simple as that. It’s fine during times of growth but that’s not happening right now.
Without it, nobody on the management side of things actually writes any code, or has first-hand experience with working on the product. The line managers just end up as a go-between between the workers and their directors, because they only know what their reports tell them. They don't know much for themselves.
You can't quantify this sort of loss on an earnings report, but among many other things, it does a great job of diluting ownership of the product away from the teams working on it.
Best in that the TLM generally has complete control over the product execution (and can commonly bulldoze the PM). It's amazing if you have a solid vision of what you want and you want to get it done.
Worst in that the workload can be intense as the team grows.
Ohhhh this explains so much. My career is pretty much entirely at b tier companies who try to implement what faangs/mag7 type companies do but always fuck it up because they don’t understand the fundamentals or are unwilling to part with any of amount of power or money even if they got more after all was said and done.
Anyways post covid all of a sudden every company was expecting me as part of the Software Engineering Manager roles I was getting, to have 7-10 direct reports, do 30 hours of project management per week, _and_ simultaneously be better versed in every single project my direct reports were working on or at least be the initial architect for the project.
I just ignored it and kept my people productive since that was an impossible ask of me, and for 5ish years that was good enough for companies but I guess if the faangs are wiping that role clean I better switch career niche again
Being 50/50 makes it hard to advance/develop in either one of them significantly.
The biggest issue is that management requires a lot of "wasted time" paying attention to whats going on around you and IC skills require a lot of "heads down time". It's a big fight between those two modes.
I've done it at a startup but it required doing most of my IC work after hours. Which isn't that sustainable.
If you oversee 0-2 people, in most cases that’s probably not an efficient ratio. How did Google get so many folks in that position in the first place? And I assume the other 65% take up the slack to fluff their teams? Or what? Leave the other 65% managing 0-2 people?
Having tried that arrangement a few times, I think it's better to have small pods where everyone is an engineer and then all the pods report up to a dedicated people manager.
I would have so many questions if I got an offer for a position where I had to oversee less than 0 people
Being the team lead in this sort of structure is grand fun, of course, but being a team member is brutal on the ego, and requires enormous skill to be a boost to velocity instead of a drag. Thus, it requires ridiculous compensation, even if you’re mostly sitting idle when the project is in a serial phase. it’s the sort of play that I could believe 2012 google could profitably execute and 2025 Google can’t.
Also 35% is way too low if it’s really less than three. Should be more like eliminating 95% of those scenarios.
Think of a delivery company, for example, where drivers make deliveries, which is what the company gets paid for. Too many managers - AKA too few employees per manager - will sink the company, because managers draw a salary but don't make deliveries.
Of course, this analysis might not work as well for a company like Google. I'm pretty sure I can publish an ad without any human intervention on Google's end, so maybe they have no equivalent to the drivers, making the ratio incalculable.
For bigger teams (10+) you either need individuals who are very independent and driven, or have dependable line managers.
I've actually had better experiences with higher employee:manager ratios for this reason.
When the manager can't possibly be involved in everything they're forced to let go, delegate, and skip the management busywork.
My worst experiences have been at companies with one manager per 2-3 employees and skip-level managers who were expected to be involved as well. It was a never-ending stream of meetings, weekly hour-long 1:1s with multiple people, goal setting, personal development exercises, and a growing list of scheduled distractions.
The managers felt like they needed to make work to justify their managerial roles, so our time got filled with meetings and activities that didn't contribute to anything other than making the manager feel good about doing things they heard about in podcasts and books.
that described internal Apple hardware teams i was on for years, as having as flat as possible an org was a priority to prevent bureaucracy and fiefdom forming middle manager nonsense
I wonder why these people are made managers in the first place. That too this kind of title seems quite prevalent in the company given they found 35% of all managers are like this. Either the statistic is just plain false or google is really dysfunctional
Reminds me of severance and the polite little drones reciting their eigan lore.
Google is a blight on our society.
That's not to say it's easy - its absolutely not. But Apple is living off of Steve Job's visionary prowess and continues to do so.
As someone who used to be an engineering manager, I was always surprised at how inefficient the division of responsibilities seemed to me. I mean, when I was an eng. manager, a substantial portion of my time was just taken up by logistics - like when we did a move to a new office building, a huge time sink was stuff like seating charts. Perhaps a company as big as Google has more folks taking care of stuff like this, but I still think the following breakdown makes sense:
1. A "technical mentorship" role: someone who codes, but is also explicitly responsible for skills growth and technical feedback of ~5 junior engineers. This person would not be responsible for stuff like salary/raise negotiations, promotion decisions (but would obviously feed into that, more on that below), logistics questions, etc.
2. A "directing manager" (obviously that name kind of sucks, but I didn't want to confuse this with other "director" or "manager" terms). This person explicitly does not need any technical skills. They are responsible for all logistics/salary negotiations, etc. They would be responsible for around ~5 technical mentors, so then up to 25 people under that. Promotion decisions, for example, would be made amongst the 5 technical mentors, deciding who on the team is most deserving to move up. But then the actual salary decision would be made by this "directing manager".
I'm sure this could be tweaked, but the overall idea is to separate technical vs. non-technical skill sets more efficiently.
No manager with more then 7 reports No IC with more then 7 managers between them and CEO
But often such teams in faang come up as a by product of someone’s empire building and that is unfortunate for others involved in it.
I could even see there being a 1-person team, but their slow tooling and red tape creates the need for extra headcount.
You experience some the benefits of being a manager but bear all the responsibilities of managing others. It becomes challenging to make sound judgments when you must consider two different perspectives of a problem. Essentially, you’re taking on the duties of two jobs. I’ve found it incredibly difficult to step back and allow the team to make decisions without my input. My technical bias compels me to intervene when I perceive a decision as clearly incorrect. However, this approach hinders growth and may be perceived as micromanagement. While it’s a challenging position, it’s an excellent opportunity to explore management and determine if it’s a long-term career path you’re interested in.
We walk into the meeting room, past the employee desks, over 50% of it was empty. I asked one of the colleagues showing us around where they all were - "they just work when they like!". Wow, what a dream! Google has/had? this rule where you can take some 20% of your time in a given day for yourself. But, mostly people used something like 40% of it in reality. I thought this was the perfect working culture with great work-life balance. I had very high expectations for the employee quality until I met the TLM and his team we were supposed to meet.
What a bunch of clowns. They suggested we use Cloud Spanner - one of the most expensive offerings at the time and our bottleneck (and bleeding) came from legacy MySql. He didn't even know that Spanner was more expensive than their Cloud SQL offerings, not to mention completely different offerings (it's No-SQL). None of them even knew when to use Spanner for and when to stick with SQL for. It was their own product line-up and we had more knowledge than them! I didn't pass any GCP exams even, at the time. That was the funniest part. We just needed help with some re-architecting of the client's application on a legacy PHP-MySQL combo. They didn't even have suggestions on what stack to migrate to! No idea whatsoever and they tried to talk their way out of it. In the middle of the meeting, my boss leaned over to me and told me "Neya, I think you probably know more than these guys, let's leave" and we wasted no time. To Google's credit, they did offer us some credits to use, but it was far too less than what were bleeding.
I went back to office and out of curiosity searched for how much these guys make - It was easily 120k - 250k (back then) depending on their experience. That's when I literally stopped trusting Google with anything at all. I could never be that laxed when I take that much money from anyone. Later, I learned a lot of these people were just there because depending on the country, you had to maintain a quota (ratio) of certain demographics within Google, most of the TLMs and their teams just conveniently fit into that. Why fix something that's not broke, right?
The Google we knew with the original startup culture was long dead and this story is atleast 7 years old now. For over 5 years since then, they did nothing but make money by simply increasing prices for GCP offerings. I remember our costs rising up suddenly after they just pulled the rug on us with Cloud storage price increase at random. No innovation, nothing. The AI mode they launched now after ChatGPT took the market by storm was what should've been 5 years ago. They are following the pattern exactly as described in the book we learned in our Masters' - "How the mighty fall" (really good book) and well deserved. You reap what you sow.
/endrant (thanks for reading!)
I have advocated many times and been told no for a situation like, "hey I know a major core problem we need to solve, give me one extra engineer in addition to myself and maybe a part time tech artist and we can deliver this to you."
It is repulsive how many large corporations follow such outdated and rigid processes, and follow the logic of "more engineerer betterer"
> The 35% reduction refers to the number of managers who oversee fewer than three people, according to a person familiar with the matter.
Not that I'm trying to gain favor or hoping my future AI managers will remember my kind words and promote me when they take over my company.
It’s nearly 20 years since Google had a category defining product - they haven’t built or acquired a single thing that dominates in the same way that android, maps, search, docs, etc. has since about 2006. It figures.
Product wise, Perplexity has them beat by a mile - that said PPLX doesn't quite have the same ads buy-in (or all the Chrome-tricks Google plays to keep tracking alive).