Is it safe to join cost centre teams like infra or platform?

I also want to push back against the idea that infra and platform teams are cost center teams. It really varies based on the company. In fact, it can even be the reverse where infra teams have clearer business impact compared to product teams - This was the case for me back at Instagram Ads, and it will happen a lot in Big Tech:

• Product team: Try out 10 A/B tests to improve ad layout, but they all fail as it's already been super optimized across 100+ brilliant engineers through 5+ years. 0 impact.
• Infra team: Make video ads load 0.25 seconds faster with complex performance optimizations, which easily adds millions of $$$ in revenue per year. 50 lines of code.

This phenomenon happens because product changes are generally low-hanging fruit: When there is no product or a very primitive product, it's easy to rearrange pixels to improve the user experience. The technical complexity is also lower, so you can accomplish this with more junior engineers. I talk about this more here: "How do you choose an opportunity for technical depth?"

After the low-hanging product improvements get picked (and they'll get picked fast for the reasons I mentioned before), you have a ton of code and features that is not very optimized as everyone was just bum-rushing feature development. This makes the space really ripe for infra and performance optimizations.

This leads to a pattern where product development is the money maker initially, but infra becomes way more important later on when the organization is more mature. This is why infra teams are generally regarded as having better scope, especially at Staff+ levels and Big Tech companies.

It's overall less safe to be on a cost center team in this economy, but I wouldn't hyper-optimize against that:

• I still believe that the quality of the team and your personal fit (i.e. "Is this team working on something that excites me?") are more important.
• It's not worth it working on a "safer" team for potentially years out of layoff paranoia. I wouldn't trade my happiness for a 10% better chance of not getting laid off.
• However, financial security is more important to some than it is to others - If you really, really, really can't be unemployed, then by all means, find the most optimal team, even if you won't be happy there.

We talk more about this in our video here: Who Gets Cut In A Mass Tech Company Layoff?

In general, you want to make sure that for whatever team you're on, you have clear ways to measure success and prove your value to the company.

You should be doing this anyways, regardless of how good or bad the economy is and how many layoffs are happening:

• When a team has concrete goals, a strong business + product justification behind those goals, and straightforward ways to measure progress towards that goal, everything becomes easier.
• In particular, making a case for senior and staff promotions has far less ambiguity and reduces down as close you can get to it being math.

Every engineer eventually needs to level up from "I shipped XYZ" to "I achieved ABC impact" - This usually starts happening at senior levels and is really solidified at staff levels. At the end of the day, you don't get paid as a software engineer to write code or even ship projects - You get paid to solve problems and add value to the company.

So if you don't know why your team exists, figure it out:

• Envision a scenario where your team disappeared the very next day. How would the company fall into chaos? Or would it not?
• How do you affect revenue? If you don't improve revenue directly, how do you improve the lives of users?
• If you don't improve the lives of end-users, whose lives are you improving? Is it other employees in your company? Maybe it's other engineers specifically - This is often the case for infra and platform teams.
• After you figure all this out, how do you measure your progress towards your team's North Star? How to tell between the team failing to achieve its mission and the team totally crushing it?
• If you don't know the answer to the prior question, make that answer. Work backwards from all the steps necessary to prove your impact and then add the proper logs. At the end of the day, everything a human does can be logged. You just need to figure out what to log and how to log it.

Here's some good discussions digging into the mechanics of data analysis and user understanding more in-depth:

• "I want to become the "data guy" in my company - How can I do that?"
• "What high-impact achievements should a full-stack engineering intern target for a stronger resume?"