They'll probably grow back to 190k within a few months, but those 8k new hires will probably take months if not a year to fully ramp up.
They'll probably grow back to 190k within a few months, but those 8k new hires will probably take months if not a year to fully ramp up.
I feel like this is actually a good way of doing things, and wish Google did this more broadly. Just think if everyone who would have been laid off was instead transferred to a project that needs their skills, or given training to move into a role that's needed. Can you imagine what type of employee loyalty and morale that would engender?
Values shifted with the focus on earnings and growth getting less impressive.
Imagine how obnoxious code reviews would be if everyone wanted to submit as many lines as possible for their salary to go up, that is how management headcount requests works today.
Middle managers serve a role but honestly many of them can be replaced without really disrupting anything. At a certain point, you become too far removed from the actual work that is being done to really matter.
On the other hand, there are many low level managers with teams of fewer than 10 people who can be very valuable and hard to replace. People with deep expertise in the specific area they work on.
Measuring a manager by their headcount is just a lazy way to evaluate impact and calculate salary.
Because all the high value stuff(high ROI stuff) is already done or already being worked on. all that's left is low ROI projects which take up huge amounts of time but bring little value. employees and managers know they generate little value, so they end up doing more of them to compensate which makes the problem even worse as there's less and less high value stuff to do.
there's just too few opportunities, hence the need to expand into new industries.
i sometimes wonder if they would have more success with atoms based innovation rather than bits (reference to avc article on the matter). but that would necessitate hiring something other than software engineers.
Yes. However how do you find those less useful positions? And identify whether it's the developer who is less productive or the position?
For top management the easiest way is to fire people broadly and assign it all over equally by pushing the decision down the management chain. Medium managers know their teams a tiny bit (but often not much ...) than too management and identify the least troublesome positions.
And then you let them bring up cases to keep their headcount or hiring new.
Works, after a short bump in productivity, if it's just (human) resources and numbers in a sheet. (Similar to other budget cuts, where you give a Mandate to reduce cost by X% everywhere and then see who cries the loudest and who adapts) Of course has impact on trust etc. which has an invisible cost.
Not contradicting your point really, just a note
Extremely cool individual who I miss. Maybe I should say hi to him.
In fact it's even worse than that. A lot of Google's employees are dedicated to maintaining tools and infrastructure that Google built up over decades and hundreds of thousands of engineer-years because "the cloud" didn't exist when Google started. These other companies get all that "for free" (or rather, for nominal pay-as-you-go fees -- but certainly without the massive engineering investment that Google put in over the years) by building on AWS, GCP, or Azure. Without public clouds and the vast growth in open-source cloud infrastructure tooling, those other companies likely wouldn't be viable businesses.