The truth is that a majority of tech companies don't need 50%+ of their employees.
Google could lay off vast swathes tomorrow and be immensely more profitable without any loss in revenue.
The 2010s will be remembered as the golden era for tech employment. The second we start getting industry wide layoffs, the insanely high wage inflation we've seen will kick into reverse much faster than you probably believe possible.
Further, tech employees will be the first to suffer in a high inflation environment due to rising discount rate. Yet tech is such a small portion of the labor force that layoffs here basically mean zilch when it comes to the unemployment rate/inflation, and thus there's a long way for it to fall before the Fed adjusts policy
> The truth is that a majority of tech companies don't need 50%+ of their employees.
Totally agree. The problem is, nobody knows how to tell which ones.
On the ground it's obvious. I'm sure everyone here knows who on their team is crucial to their current production stack, and also knows others who would have no impact (or even positive impact!) if they left.
One level up - the direct EM - has most of that context too, but some is already lost. At the next level (Sr. EM or Director usually), almost all of it is gone. At that point, cutting 50% is just guessing. Keep going up and eventually the risk becomes too high that you'll sacrifice your key players along with the rest. Bath water, baby.
No heuristic is perfect, but it's fairly easy to quantify empirically from activity/records. Developers who are productive (actually write and ship large amounts of quality code) tend to be valuable and those that don't, aren't.
That being said there are some intangibles, like morale etc. It's possible there are people that benefit the team while having low personal productivity.
But anyway, no need to approach in that way. There are probably entire branches of google that could be laid off without any material impact to revenues/profitability, thus all layoffs concentrated in single arm.
Crypto divisions could be cut at many companies without affecting their core businesses. Did Square need to rename itself to Block and add all kinds of crypto functions? How many hundreds of developers are working on that.
I don't think X% headcount cuts horizontally across the org are ever a good idea. Cut non-essential functions. And cut in core branches opportunistically based on low performance.
> No heuristic is perfect, but it's fairly easy to quantify empirically from activity/records. Developers who are productive (actually write and ship large amounts of quality code) tend to be valuable and those that don't, aren't.
If you are factory line worker, yes.
If you are a developer or a manager (a "knowledge worker") -- what you could be observed to be doing has usually little correlation with result for the company.
I know people who are busy producing total crap, managers completing tons of projects achieving bad results, very energetically with huge fanfare. And I know admins that have everything so well automated and working reliably that they are watching youtube whole day, their managers none the wiser about what could have been. Or people who do nothing and have one brilliant idea a year that saves the company tons of expenses. And every other type inbetween.
In a lot of teams it is usual for senior developers to produce relatively little code compared to juniors, when looking at the value they are creating. Maybe because they spent most of their time doing other things like helping juniors, doing code reviews, designing new solutions, talking to clients. Or maybe because they are getting the most complex problems.
If you can measure this you would deserve Nobel Prize. A more likely explanation, though, is that you have no idea how complex the problem is.
In my experience working many decades, in most teams there are few individuals who are making things go and frequently not even their direct managers understand how people are exactly contributing to productivity.
I don't like to respond to my own posts but I forgot to include something which I think is important.
Unfair "heuristics" create unhealthy incentives that are typically way more damaging than having little clarity.
1. People feel treated unfairly and their engagement drops off a cliff at that point in time. People can be happy even accepting a punishment AS LONG as they FEEL they are being treated fairly.
2. People feel pressed to do things for show, just to appease measurements even if they don't believe it is right. Soon they are fine doing substandard or even completely shoddy work even in areas that are not measured, because that's what people do. People do not just selectively resign from doing good work -- if they feel they are asked to do bad work somewhere they will also do it in other areas and find a rationale for it.
3. People who will not accept bullshit and would want to do right regardless of unfair measurements, will evaporate from your company. They usually leave on their own. This will leave your company worse overall -- with no people who will tell managers the truth when it is needed the most.
4. The corporate, thinking they have measurements, stop looking to actually do better. The measurements become everything.
It is frequently better to not pretend you solved the problem and accept the problem is hard and try to do best anyway.
I've been around for long enough to see how all obvious solutions are flawed, but I don't see any good way out. I have a feeling that the coming decade whoever finds a practical solution to this problem will win the next round of tech wars...
One of the big value-adds for a senior engineer is being able to recognize tasks that just don't need to be done, ever, because they just won't contribute much value relative to other things.
Remember, it's not how much you get done. It's how much of the right stuff you get done.
Yeah, exactly. Now explain to somebody they need to come up with a measurements for all the things I have very efficiently declined to do... saving everybody time, effort and helping the really important task get the bandwidth it needed.
I keep hearing this argument about "knowledge workers" yet writers produce books, designers produce design documents, developers ship code.
sometimes you slow down because you're starting something new or you're blocked by other people, but in general productivity measured in code changes frequency / volume and the impact of the feature being worked on is rather straightforward (how many users use the feature, how much revenue it makes).
anyone who argues against this is ether on the poor side of this measurement or work in a cash flush environment where no one cared about this.
Developers do not just ship code. If you think developers only code you are naive and unfamiliar with developers' work.
Developers solve problems and then ship implementations of those solutions.
You can ship completely technically correct implementation to a wrong problem or wrong solution of a problem and it will look perfectly fine for an untrained eye.
My O(n^3) solution that has 1000 lines of code would be 5 times more valuable than 200 lines of code of O(log(n)) solution that I was able to write because I just fucking know what I am doing. The algorithm using lines of code as proxy for productivity will say the junior jackass did 5 times more work than me in the same amount of time.
And then you get the graybeard who changes a tiny bit in the data structure and makes entire problem go away. Find heuristics for that!
Only a person that delves in and spends a moment figures out that that half million lines of code is completely unnecessary because of Y.
The problem with measuring value of a knowledge worker is that you can't enumerate all possible outcomes to be able to tell with certainty that there is a better outcome, because you don't have the knowledge -- they have it. A person with knowledge has better library of possible solutions and better chance of finding it.
The value of knowledge worker in this case is being able to find better solution (because they have the knowledge you do not). The implementation, at least in case of developers, is usually the simple part of the problem.
Imagine you are in an unfamiliar city. You order a taxi and then spend 1h driving from A to B. The taxi is comfortable and the driver is perfect gentleman. You pay your fare and hop off at B.
Only after the fact you will or will not realise that actually, B was just one block from A and the driver essentially screwed you.
In this situation a map or instructions from somebody could tell you this, but with no map or instructions you are at the mercy of the driver who may or may not be doing good job and you will be unable to tell until after some time you got some more knowledge (got familiar with the city and got the Aha! moment).
You just refactored a piece of company software, severely reducing tech debt. Or made an in-house framework that made the others' work easier. Or mentored another engineer. By that formula you should be fired immediately.
Developers ship solutions to problems, which often involves some code. A developer who solves the problem in a fast, cheap, maintainable way with an off-the-shelf package is superior to a developer who solves the same problem in a slow, expensive way with many thousands of lines of unmaintainable code.
> but in general productivity measured in code changes frequency / volume
Oh my. I don't even know what to say to this other than:
> anyone who argues against this is ether on the poor side of this measurement or work in a cash flush environment where no one cared about this
If you can't point to the person on your team who's churning out mountains of crap because they think productivity is measured in lines of code, then...
is a full enough overview of an engineer's output in a crude manner.
if you implement a feature that makes 10$s per user for 100M users in 2 lines of code you're the best developer out there..... if you write 10000 lines of code to ship something that makes 0.005ct for 100 users ... you should not be employed.
As an engineering manager I advice every developer to find a way to learn to measure their output because that is a good way for them to know their value (ask for a raise, move to a different company ...)
If one line of code produces $1M of impact, should it be considered inferior or superior to a developer who produced a 100k line codebase with a couple thousand commits?
But measuring direct impact to the bottom line for a developer is just confusing the roles of the business development team / sales team and the devs. As a manager, do you choose who works on which feature? If so, doesn't that make your subjective choice (on who gets to make the $$$ feature) the only metric that matters?
The level of self importance expressed in all of these responses is quite amazing.
Being a developer/engineer is not a particularly unique or hard to acquire skill, it's highly prized only because it's a new domain and there's an imbalance of supply and demand of workers. In the longer run, wages will certainly regress far closer to the median.
What defines productivity will of course be context dependent, but the majority of companies are building products, and it's quite obvious which developers are contributing vs which aren't.
If you're building a novel system that requires a strong theoretical basis for decision making, then you can argue that low output people are potentially valuable. But 99.9% in industry aren't doing this.
And seems many are lacking situational awareness. I could easily rank all the developers in my org with a very high level of accuracy. If you can't you're a poor manager (or branch/subdivision for larger companies).
Seems the vast quantities of butts in seats, do little paid a lot, kind of workers are particularly triggered here. And boy, there are a lot of them.
Way off course. Replace developer with manager and you still get the same problem.
It is all about knowledge and making decisions. Nothing to do with the fact that software development is a new area.
Architecture (buildings) is a very old trade. And yet you would not dare to measure architect's performance by the number of sheets of drawings they produced.
Some architects are sought even if they produce little drawings.
Most architects produce a large number of fairly similar, mundane designs.
Some architects produce small number of well researched an thought through designs that make them sought after in the market and allow them to charge exorbitant prices for their services. They are name that is attached to the design and the owner of the building will tell their guests this and this architect designed my house.
See, it is not all about the quanitity.
Same goes with fashion design, writing books, and so on.
It is called knowledge work.
It is called this because the person uses their individual knowledge to perform the work rather than some kind of reproducible recipe.
A car mechanic that only looks up procedures in the book is one thing.
A car mechanic that has intimate understanding of the car and experience solving various types of problem is a knowledge worker. He might listen to your car's engine sound and go directly to solving the problem and his performance compared to the other guy will be in no way correlated with the amount of time he spent on the problem or number of times he hit his hammer.
Lines or amount of code written is a terrible, and easily gamed metric.
Some of the very best engineers write the fewest lines of code, often making fewer yet better abstractions that fulfill more business use cases more simply. They might also help others write less code.
Some of the most prolific coders are great. And some are terrible. The challenge is discerning the two. Coaching a prolific yet bad coder to slow down can be as challenging as coaching up a slower / not yet confident coder. And the slower coder will do vastly less damage in the interim.
I understand this as theoretical possibility, and it could lead you astray if you're trying to tell a 40% developer from a 60% developer... but in practice I have never met a superstar IC who doesn't also ship a ton of code (even while they help out others). If you fire the 10% of ICs who push the least code, to within a rounding error you're extremely unlikely to regret it.
It's strange to see this confusion when it comes to software. Any other discipline and you wouldn't say engineers that don't do any engineering are the best engineers.
I’m going to respond to the second half of your comment because the first part is trivially false and the others have already spoken to that: do you think Google should cut all teams but those involved in advertising? Because the rest aren’t making money. Why keep them around?
Ironically that might not be such a bad idea. If the assumption is that Google is unlikely to make further gains beyond online advertising, shareholders would gain more profit in the long run by cutting the teams, and talented people might move to companies that are better at making money in the other areas.
The problem is that upper management don't want to be the one declaring that they're giving up on growing the company. Especially that they have billions of dollars to spend/waste every year.
> No heuristic is perfect, but it's fairly easy to quantify empirically from activity/records. Developers who are productive (actually write and ship large amounts of quality code) tend to be valuable and those that don't, aren't.
The most prolific people at my startup were doing 20k/month. The worst performers were doing 500/month. No, the people doing 500/month didn't compensate for it in other ways.
Of course this was a company that needed to build a product and enhance it to survive, not a pseudo-monopoly daycare.
Even up to a few hundred developers, its quite obvious who's a strong contributor and who isn't. The people who produce the most code are almost uniformly also the most theoretically strong/capable. Though there was a case where somebody was quite prolific but produced pretty poor/buggy code. It's obvious from how smooth the features they developed go when shipped to production.
In most workplaces you'll find that 80% of the results are produced by the top 20% of contributors
I am in that condition, so personal experience here:
- i do most meetings with internal stakeholders to understand needs and changes, and document them
- i do most "architecting", as i have most context on the systems my team is responsible for (also I am the oncall escalation point all the time as I am the senior person)
- i write about 10% of the code, usually what other colleagues aren't comfortable with (legacy systems mainly these days)
"Development" is not only writing code, and senior roles tend to code far less because we get wrapped up with the rest of the company so other folks can code and deliver.
My team, manager and customers seem very happy about the whole thing (but hey, maybe everyone hates me!). I do want to code more, maybe with a good PM i would be able to, but I have no illusions about that.
They've coded for 10 or 20 years, and now just sit back and design interfaces, write specs, evaluate technologies, mentor juniors, do code review, and of course the ultimate mind blow when you're trying to figure out who to fire: they remove code instead of add it. Unfortunately for the company, these "imposters" do indeed get weeded out in preference to the recent college grad copy/pasting thousands of lines of StackOverflow answers. I usually escape before all that drama though!
I think for me it was more a journey of understanding the necessity of the function and not the person. As in, I would question the need for management or marketing.
As I matured and, in some cases, tried to perform those tasks myself, I had a respect for the function. The people may still suck but at least now I understand how good execution of that function is necessary for the organization as a whole.
I definitely see the value of management, marketing, and especially product management. Having worked at places with and without that function, I'm more convinced than ever that software architects are a net negative.
I worked somewhere that did this. They restructured the same teams with new managers, mandatory tests to get into your same “new” team. Strangler Fig Pattern style.
You say that, but companies that cut tech too deep will probably get crushed under a mountain of technical debt or gradually lose goodwill due to buggy or stale products.
Point is, it's possible to ship crap with a small crew. But the cuts won't come uniformly from scoping back or removing low productivity engineers. You'll also see corners cut, upgrades delayed, security flaws ignored, and so on.
Obviously there's bias involved, but I really don't see a reality where this isn't the case. I've literally never worked at a company where half the team could be laid off and the product would still function at its current level of functionality for 12 months; let alone adding functionality. If you've worked at a company like this; I imagine there are some; then sure; the lights could be kept on. Hey there Oracle & IBM 2.0.
Then again, you (the company) just laid off hundreds of extremely talented engineers with few other marketable skills except "the industry you trained them in", you've been paying them insane salaries, they're just going to turn around and compete with you, except now they've got a clean slate and have learned from all the mistakes that caused them to be necessary in the first place.
The well paying, large companies are literally 7 of the 10 largest companies on the S&P. Oh, and by the way, one of those other 3, UHG, they have... 850 job openings with the word "software engineer" in the title; about 15% of all their openings. Johnson & Johnson, they're on there, 300 software engineering openings, out of 3000 total. Berkshire is also on the list, harder to get their count, but you get the point; software is EVERYWHERE.
I just... don't get it. I don't get how someone can believe what the grandparent believes. I mean, you can argue a more measured stance, that the outlier 99.9th percentile salaries we've seen in the past four years are probably going to stagnate. Maybe; I'm not convinced of this, but its a reasonable stance. You can argue it'll be harder to get into the industry, as companies want experience and not coding bootcamps; I'd bet on it. But to argue that tech companies don't need 50% of their employees, when they're the plurality of the wealth of the United States' public markets; its comical. Where else did that wealth come from, if not their (tech) employees? If the argument is they're overvalued, maybe, but that's speculation; buy Puts if you believe it, but I'd buy Calls on "you won't".
Then again, maybe the grandparent is talking about non-tech roles in tech companies? I can't tell; and moreover, I don't think even they know what they're arguing for.
> But to argue that tech companies don't need 50% of their employees, when they're the plurality of the wealth of the United States' public markets; its comical.
If they were claiming this was something unique about tech I'd be sceptical. But if they're claiming it's just regular corporate dysfunction I'm not so sure. I've watched whole teams of extremely talented engineers put multiple years into building something that never saw the light of day, not because of any technical flaw but because of shifting organisational politics. The idea that less than 50% of employees contribute to the bottom line doesn't seem so implausible.
I think I agree with you, but I'd take it a step further. The plan from management may in fact be various projects in development, few of which will see the light of day. Those few pay for all of the spent effort on the others.
This is no different from VC behavior. It's unfair to label the shuttered projects as not contributing to the bottom line, if they were part of a pool of investments.
I don’t know if I’d agree with the claim that 50% can be cut… but there is certainly bloat and it could be time to trim the fat. This would be very good news for the industry since all those engineers will start new things and build new companies.
That said, I think the salaries might stagnate. End of 2021 had everyone starting a new job and competing offers. It may not last so the negotiations won’t be as lucrative. Beyond that, tech salaries are high because the profit per person is high and that won’t change much, especially if companies trim excess employees.
I read somewhere a while ago (can’t find it) that Uber once discovered they had multiple teams all making an internal map gui, just siloed into different orgs so there was no visibility. While it’s a crazy example and probably fake, it’s not hard to imagine an org like google or Amazon where there are 100k employees having some level of duplicated efforts.
With office politics, some architectural decisions get made because everyone wants their team to touch important things. I was part of a team that owned a critical request flow and when they were adding new features it was decided that this API should be the entry point for those new features (10% increase in traffic estimated). So it went from a crud app (stateless app with database) to an API ingress with a (custom written) event queue linked to a queue processor (by AWS sqs) linked to a service that was responsible for handing the request off to one of several crud apps (except no new ones were written). Now 4 teams had a portion of the flow under their control. Was there a reason for this architecture? Yes. Would it have happened if the org didnt balloon from 7 engineers to 50? Probably not. Would customers have noticed? Yes, the API would have been faster and more reliable.
Beyond that, it’s well documented that tech people like shiny new toys. I interviewed at DoorDash for a pretty visible product team. They said they were hiring to do a complete rewrite of their product switching to <buzzword> and that it was their main deliverable for 2022. The team I was leaving during said interview was allocating 50% of headcount to rewrite the tech stack from binary on VMs to “AWS native” technology. No new features. If the team was told to cut some headcount or was denied headcount to grow, that’s be the first project axed because it doesn’t save money or help the customer. Meanwhile, my new team has 1/3 the people for a literal 10-100x traffic product with way more customer visibly. If you spent the last few years on this team, you’d think software engineering was lean and efficient. On my last one you’d say it’s bloated and full of busywork.
Adding people fast is very bad for an organization's efficiency, for a variety of reasons, including the one you mention.
However, subtracting a lot of people fast is just as bad for an organization's efficiency, for a whole host of other reasons. Not that I expect Robinhood had much choice in the matter at this point.
That remote work stuff will go away. People are kidding if they think large organizations can innovate and remain competitive when everybody on a team isn’t in the same room.
Individually people might think they are more productive (at least coders do) but the communication issues that arise from remote work are gonna really become an issue soon enough.
Nah, remote work isn't going anywhere—it's here to stay. I know management doesn't want to believe that because they want to count asses in seats, but the collaboration issue has been solved by Zoom/GitHub/Trello/Slack &c.
So I agree people are less efficient, but I think it’s here to stay.
I started a new job during covid and it took me a lot longer to few productive than I was comfortable with, and it’s because I couldn’t just grab someone and ask them to explain something quickly. Knowledge was way more siloed.
But the convenience of working from home and not commuting and not dealing with the office is hard to shake.
They easily can. When you’re in a large, multinational organization with multiple offices and teams everywhere, you are essentially working remotely as is.
Large companies aren’t particularly innovative, so this whole argument is pretty moot to begin with.
Well then - found a company that employs half the people and become the next Google. Should be easy if your magic insights can make you twice as profitable. Maybe this is not how innovation works though.
Google could fire their entire org outside of ads, search, and android and still roughly maintain the same revenue/growth.
It's quite obvious. They are dominant via first mover advantage and monopoly esque positioning in search.
And they could likely even not change search at all and stay on top for 10+ years.
What is the marginal value today of a given Google employee to the company's bottom line? Super low.
The tailwinds driving strong growth for these companies came primarily from macro/digitalization, not because they invented feature X which enhanced revenue
Not a good argument from you. As if the sheer number of employees is what made Google successful in the first place. And as if efficiency alone makes a successful company. Why would you think these things?
GP was stating that 50% of tech workers at big companies are redundant. Armed with that knowledge he should be in a stellar position to found a company that is very profitable compared to its competitors who incur double the labor costs. This incredible competitive advantage will enable him to become the next Google eventually.
Sounds plausible? No? I wonder where the error is.
Having a better understanding of who the essential employees are is necessary, but not sufficient, to run a more profitable company than the current market leaders.
I get your point, but don’t you think that if it was really so easy, somebody would have done this already? There are other factors like key people leaving if half their colleagues get laid off.
The claim itself is so extraordinary because it defies all economics.
> Yet tech is such a small portion of the labor force that layoffs here basically mean zilch when it comes to the unemployment rate/inflation, and thus there's a long way for it to fall before the Fed adjusts policy
The really scary thing for me is the possible macro environment for tech.
Indians will soon overtake any of the Western countries as the largest English-speaking population on the internet. As I'm sure many of you know, Indians are hugely talented and most of us who had to deal with CS or Maths have probably resorted to some of the extremely generous Indian experts who teach these subjects on Youtube. There are some very good institutes and universities with solid reputations, many expanding to boot camps and such - so there is a very good volume of tech talent coming online fast.
So you have a tsunami of highly educated, English-speaking tech workers coming online AND a sudden surplus of laid off tech workers in the West. It could potentially get really ugly for the Western tech workers used to six figures for working 30 hours per day and then spending the rest of the day on activism or "day in the life of a X" Tiktoks. After all, we just tested remote work and you can live like a king in India for much less than even the cheapest Western town.
> tech workers used to six figures for working 30 hours per day and then spending the rest of the day on activism or "day in the life of a X" Tiktoks
> You've never worked a job that isn't 30 minutes of work and then the rest of the day is posting "day in the life of a FAANG employee" Tiktoks or being a paid activist.
That is incredibly not what it's like to work in tech in the US. I doubt you've been anywhere near a big tech programming job.
In my experience, it varies highly between teams. I've personally worked at 3 FAANG companies and the culture was meaningfully different between them. There were times we were doing 12+ hour days, and times where you could get by working an hour or less. They all pay competitively, so it's really up to the individual to decide how hard they want to work and whether to focus on something of interest.
This gets said in every conversation about remote work but this has been the case for a few decades now. If the software business was just about chucking commodity CS grads at problems and YouTube videos and the man month theory was true then everyone would be running their companies on batteries of commodity Devs already.
>It could potentially get really ugly for the Western tech workers used to six figures for working 30 hours per day and then spending the rest of the day on activism or "day in the life of a X" Tiktoks
I don't know where you work but the people actually doing the core work that drives multi billion companies don't work like this.
Multi billion Companies aren't stupid they aren't paying these salaries because of cost of living they're paying them because the economics mean get more value from the work done than they're paying out. The best developers in India already get hired by FAANG and they're working in SV.
Have you ever worked with an Indian company?
I am just laughing each time I hear huge talent pool. So maybe your top 1% is incredible but they already left the country.
You’re not wrong but there has been a big shift in the Indian tech education scene the last couple of years. All these startups raised an insane amount of money and are suddenly hungry for product-focused talent.
The average Indian engineer used to aspire for consulting jobs (think TCS, Infosys) since product-focused jobs were so few. Now their goal is to get a job at a startup.
Consequently, the tech stack and skills they’re learning is entirely different. Not .NET and Java but React and Rust and UX design.
I really think the quality and type of Indian engineering talent you will see in the next 5 years will be radically different. The market has shifted drastically.
This is my experience too. Worked with an Indian start-up and most of them were utterly useless. They also never managed to make any of their deadlines because they'd always say yes to whatever you asked. Thank god for the one guy who always fixed everything we needed.
Of course, this is a broad generalization, but so is the idea that Indian talent will take over the world.
Seems like a culture problem and not a talent problem. Us developing world folks do not easily say "no" because we grew up in a top-down, authority-driven place.
Americans are pretty uppity when it comes to taking orders if you compare to others.
There is also a difference in interviewing. Only in America do you have to proactively market and sell yourself. Most other cultures are more timid and humble.
It's not about the yes or no culture difference, it's just the lack of autonomy to solve a known problem, root cause analysis, debugging skills, proposing a solution, empathy towards customers etc.
And don't get me started with the caste system making a bunch of clueless people arrogant to no end.
I spend these days 4h+ a day in calls to explain basic stuffs and basically debug a multi-awards SaaS application as nobody has a clue in that company.
You say that like these well established tech companies (like Google) haven't already optimized the employee counts and employee salaries needed to produce the (current) best ROI and also figuring for future company growth.
A bare-bones, scrappy team makes sense in the startup world but not the publicly traded enterprise engineering world. Move Google back into this world and it'll quickly crumble in a few quarters.
Has any tech company that laid off 50% of it’s employees survived? Maybe one or two. That would seem to indicate that the 50% number is too high.
Perhaps you see it as 50% as like when people say they only need 10% of the functionality of MS Word so they could drop 90%. Except that 10% is different for everyone.
The bureaucracy expands until external factors force it to stop or contract. Google Search and Ads are a small percent of the company but nearly all the revenue. It’s not hard to see how that can lead to runaway bureaucracy.
The key is competitiveness. If all your competitors are improving their offerings year over year, you must do the same. If they all cut staff and stall on development, you can too
So nothing will change then? Instead of 135k people not answering the phone and telling you to go F… yourself you’ll only have 120k people not answering the phone and telling you to go F… yourself. Or maybe Google has amassed so much AI knowledge that all of its employees can be replaced by a single Raspberry Pi that doesn’t answer the phone and responds to all inputs with go F… yourself! A hundred years ago you would have had to pay a million people a penny a week to sit around not answering the phone and telling you to go F… yourself to achieve the same effect. Hard to believe the human race has come so far so little time.
But what’s more amazing is AWS support, because they answer the phone, and they solve your issue, and that’s the trick nobody else seems to be able to master.
Google could lay off vast swathes tomorrow and be immensely more profitable without any loss in revenue.
The 2010s will be remembered as the golden era for tech employment. The second we start getting industry wide layoffs, the insanely high wage inflation we've seen will kick into reverse much faster than you probably believe possible.
Further, tech employees will be the first to suffer in a high inflation environment due to rising discount rate. Yet tech is such a small portion of the labor force that layoffs here basically mean zilch when it comes to the unemployment rate/inflation, and thus there's a long way for it to fall before the Fed adjusts policy