Google Layoffs (What it means for you)

How it impacts Data Scientists and Data Engineers

Everyone’s favorite fear mongering topic: Layoffs.

BowTiedCelt here to distill the recent Google layoffs into plain English for my Data Science frens. (Follow me on twitter @bowtiedcelt)

Some of you may recognize the name, and of course I’d like to thank Raptor once again for partnering with me. The collaboration between Data Scientists and Data Engineers is one of life’s great joys (just kidding, stop breaking my pipelines.)

Once again, we are reminded that you are just a row in an excel sheet. Upper management will sack you without a second thought to hit their numbers. As Silvio tells us in Sopranos, you’re only as good as your last envelope:

Google Layoffs

History Lesson

Before roughly 2023 Google was not a company that did mass layoffs. It was not something that occurred, Google’s strategy was to cultivate as much talent as possible and move people around the company or have their utilization be low. They could afford that because Search and Ads *printed* money.

With OpenAI and Microsoft challenging Google on Search, Google’s hand was forced to stop living in banana land and compete again. That meant starting with some layoffs. In late 2023 early 2024, Google had a round of targeted layoffs hitting their Open Source team, which included open source titan Chris Dibona, who was known for making key hires and key decisions on Google’s open source strategy which includes many great libraries such as TensorFlow and Kubernetes.

Fun Fact he also hired chief git maintainer: Junio Hamano:

read the full thread here: https://twitter.com/BowTiedCelt/status/1617904409236901889 (throw ya boy a follow)

Overall, notice how the layoffs were in a shared service or platform team, not in Ads, YouTube, or Search? more on this later.

Recent Layoffs

About a week ago, Google had another round of targeted layoffs to the Python and Flutter team. To understand this we need to make the distinction between shared services and business unit teams which goes into profit center vs cost center.

Profit Center vs Cost Center

One of the most important lessons in engineering. You are on a cost center team or a profit center team. Shared services and platform engineering are cost centers. Business unit teams are profit centers. Concretely, Google’s Search, Ads, and YouTube teams are all profit centers, they print money, and there is a direct line between their products and revenue generation. Shared services and cost centers, the line becomes skewed and indirect. For example, Google’s python team, they are a shared service. This team maintains a stable version of python across the company, contributes upstream to python, and enhances tooling to make Google-specific optimizations, like configuring a linter to Google’s Python Style Guide.

It gets increasingly difficult to answer, “so what exactly would you say you do here”, when youre on a platform team. Yes, they do GREAT work, and GREAT engineering, but how does having a Google-optimized code linter generate revenue? If you can explain that succinctly then your team wouldn’t have been let go.

Conversely, upper management didn’t have to ask the YouTube team, how they make money, everyone knows, YouTube directly generates revenue and new features directly contribute to the product.

This is an incredibly important distinction because layoffs will hit platform teams first and then teams with product teams that are not doing well, and lastly the real revenue generating teams. Reread if you are lost.

Data engineering is typically seen as a platform team / cost center. Data scientists can be seen as either, it really depends on your company. You *need*to depict your team as profit centers.

To recap, shared services and platform teams are cost centers and the first to be hit with layoffs because the line to revenue generation is less clear.

Python and Flutter teams

These teams are shared service teams at google, meaning they are - cost centers. These teams maintain versions and tooling around python and flutter internally, and contribute back to open source.

On HackerNews an ex-employee detailed the python team’s work:

in addition to contributing to upstream python, we

* maintained a stable version of python within google, and made sure that everything in the monorepo worked with it. in my time on the team we moved from 2.7 to 3.6, then incrementally to 3.11, each update taking months to over a year because the rule at google is if you check any code in, you are responsible for every single breakage it causes

* maintained tools to keep thousands of third party packages constantly updated from their open source versions, with patch queues for the ones that needed google-specific changes

* had highly customised versions of tools like pylint and black, targeted to google's style guide and overall codebase

* contributed to pybind11, and maintained tools for c++ integration

* developed and maintained build system rules for python, including a large effort to move python rules to pure starlark code rather than having them entangled in the blaze/bazel core engine

* developed and maintained a typechecker (pytype) that would do inference on code without type annotations, and work over very large projects with a one-file-at-a-time architecture (this was my primary job at google, ama)

* performed automated refactorings across hundreds of millions of lines of code

I can tell you from being on platform teams, that is *great* work. It saves times across google’s engineering teams and streamlines development. Notice how though the speak is only highlighting the engineering challenges? Doesn’t mention any tangible or semi-tangible business value. That is the problem with platforms, looping the engineering back to the business is a challenge. Engineering is great, but when you work in a cost center, you need to be highlighting any business value, or literally just making it up.

If you found out that upper management sees you as the L on the Profit/Loss Statement, what can you do *today*? You need to tie one of cost center engineering feats to a product team, almost like a case study. For example, for the second bullet point, you should say something like that, give a short blurb on the action, then tie it back to “The YouTube team is able to save 2 hours per release because their library versions are automatically updated as a result of the library automation,” always tie your cost center work back to a heavy-hitter product team.

They are subsidizing your work by directly generating revenue. Additionally, this is why you *always* prioritize the feature requests from the important product teams when it comes to platform engineering. This directly ties your work to a profit center.

Offshoring reports

Various outlets are reporting that Google is offshoring these positions to ‘India or Mexico.’ Generally companies are taking austerity measures and offshoring positions that do not directly generate revenue or play a key role in the *business*.

It is certainly possible that this is possible, but it doesnt seem that replacing 200 US employees to offshore is going to make a big impact on Google’s bottom line, but thats probably why Sundar is the CEO and not me.

Theme: Investing in AI

The takeaway here is that Google is freeing up resources to invest in AI. AI is the tide that will float all boats. Google is making cuts where possible to freeing up money to invest into AI, such as Bard/Gemini. No surprises here, Google fell behind on AI and needs to make up ground. They are hoping by throwing money at it, they can fix it. The time of Google needlessly hoarding software engineers that micro-optimize internal platforms is over. Lean(er) Google is being rebuilt.

Conclusion

Google's recent actions reflect a strategic move towards prioritizing investments in AI over certain operational functions. This aligns with the broader trend of tech companies doubling down on AI to maintain their competitive edge in the market.

Thanks again