Between platform (serving developers) and product teams (serving end customers), what should be one's preference based on level?

At a very high-level (take this with a mountain of salt):

• Product is better for junior -> senior
• Infra/platform is better for staff+

Breaking Down Product

Product is great because it's very intuitive. You can see it. The end-users can see it. Impact is crystal clear. You are completely right here.

Things can also be Google-d and StackOverflow-ed. When people think of software engineering, they think of the shiny products. The overwhelming majority of online resources are about product problems, not how to identify a scroll perf bottleneck when your app is being run on 10-year old Android phones in developing countries.

The problem with product is that the technical complexity is inherently lower for reasons I cover here: "How do you choose an opportunity for technical depth?"

Another issue (especially at a Big Tech like Grab) is that once products get more and more mature, the bureaucracy is suffocating. You need to go through waves of PM and design approval to do anything, even if it will be A/B tested. It sucks.

Breaking Down Infra/Platform

It's a common trope that when FAANG product engineers hit a wall going from senior -> staff, they switch to infra. This is primarily because the technical complexity is far higher.

Impact is less clear, but depending on the infra, it can be very measurable. The most painful infra team is one focused on code quality, like you're making APIs for other engineers to call. This is hard to measure: How do you know how much better your platform code is relative to whatever jank the product team could have spun up itself?

However, let's take a team like mobile build speed, one of the most important teams in all of Meta, a mobile-first company. Mobile engineers across Meta do tens of thousands of builds a day with BUCK, Meta's internal build system. Apps like Facebook and Instagram literally have 100 million+ lines of code. If you can shave just 10 seconds off the average build, you are saving thousands of engineering hours per year (and Meta engineers get paid a ton of $$$). This is massive impact. But of course, you can't Google your way out of hyper-optimizing BUCK to shave a couple seconds of latency here and there on a 100M+ SLOC codebase. It is a very, very hard technical problem.

I talk more about the differences between product vs. infra here: "Is it safe to join cost centre teams like infra or platform?"

Everyone Is Different

I'm not saying you should be product until you get to senior and then immediately switch to infra: That's a recipe for disaster. People who try to game the system almost always lose. You can't hack career growth like that. Product isn't a free ticket to senior and infra isn't a free ticket to staff. Getting to senior/staff levels and beyond will always be hard.

As I have said many, many times before: Figure out your strengths and passions and play to those. Here's some things to think about with this decision:

• If you like aligning people very different from you - Consider product. Being able to really understand and convince PMs/designers will go a long way for you. And if you hate this, this is a sign you're cut out for infra where teams definitely won't have a product designer and often won't have a full-time PM either.
• If you truly love extremely hard technical problems - When I say "truly love", I mean you're the type of person who is perfectly happy finding that mega-genius 10 line optimization after 2 weeks to increase performance by 5%. If that's you, infra might be your home.
• If you enjoy understanding and talking to users - This is a point for product. The fastest growing product engineer I have ever seen would sit in on UXR meetings and coordinate very closely with the UXR lead. They had this deep sense of user empathy, which allowed them to have an insanely high batting average taking product swings. So many of their A/B tests were stat-sig positive. This person went from junior -> staff in a little under 3 years.

Alex hit on a lot of really good points, especially around building around your skillset and preferences vs. external factors.

I've always leaned very heavily towards Product and spent my first 6 months in a managerial role a Product / Strategy role. You are much closer to revenue generating activities, which make your progression, especially at very senior levels (i.e. Director+) much easier. However, don't make your decision purely on this since I've seen it backfire pretty hard for people who don't like solving problem in this space (e.g. user interaction, studying purchasing behaviors, surveying market trends, etc.).

You can always move between the two as it's not that permanent of a decision. I'd actually strongly recommend getting at least one role in each to make the most informed decision.

Personally, I moved back closer to data platform / infrastructure after my brief stint in Product since my primary goal at the time was to drill deeper from a technical POV. You can still make a huge impact from a cost-takeout and productivity standpoint, especially if the infrastructure already handles a lot of traffic.

Thanks, Alex and Casey! Those were really great points.

Oh wow, a topic I think I'm uniquely suited for considering I actually have worked product and infra on big and small projects at Apple and Uber. I am currently on an infra team. Note that my writeup with be uniquely suited for big tech and Android development.

What Alex said about leveling up at Product vs Infra is not entirely correct. I would argue its easier to get promoted in product than infra. Not to mention infra has a tendency not to let people into their teams until upper midlevel. Very few juniors are allowed to join so count your lucky stars if you get into one early in your career.

Consider that wide impact is something you need at the Staff level. If you upstream a change to a common product/infra library, you have a better chance of getting better promo rather than upstreaming changes to open source software. That's because the common product library/infra change is not in the traditional scope of most product teams as they're mostly focused on their own vertical. On the other hand, contribution to open source software and wide impact is baked into the nature of infra and so the only way you can escape that scope is by having an even wider impact: cross-company collaboration or some level of convergence between tech stacks (ie. Android should collaborate with Backend common libraries). Which is an insane amount of scope. You can roughly think of getting promoted from senior -> staff in product to midlevel -> senior; a +1 rank difficulty and scope.

As for the nature of the work, I would describe it as going from "well known and well defined" to "unknown and unknowable". This is because in mature codebases, 80% of the product's tooling, architecture, and practices are well known and well enforced. Therefore, the only thinking you need to do is the customers' expectations and flows in the system. The rest of the code is just a carbon copy of things you've probably done before.

In infra, the developers are your customers and you service them which means you will have to do things that few know the right answer for. For instance, debugging complex pieces of software you don't own but are using or investigating JVM level memory leaks (how many people do you know have debugged Java itself?). Personally, I never thought I'd be digging into the JDK 11 code itself and looking at how ClassLoaders actually work with compiler plugins when migrating from Java 8 to 11 as an Android engineer. But here I am.

This is also why I disagree with Alex's assessment that product people should enjoy interfacing with people more. Again, your developers are the customers on infra: you'll be talking to them and their managers to see their needs. If you're lucky, you'll also have metrics and dashboards built out for you like at Meta. That customer interaction aspect does not change.

This is also reflected in the feedback to your work. In product, you know if the goal is met if you have met the predefined requirements and if the user experience is solid. In infra, you may not know until it bites you or becomes successful. For instance, using Alex's example, if you want to decrease build times by 3%, you would need to study a system you are unfamiliar with and make several changes to several different spots. However, that system is not just unknown but also changing constantly so your understanding shifts from quarter to quarter. Therefore, you can never be completely certain that the fixes you roll out are ever going to get you to there. Certainly you can prove in isolation it works but in production where the variance of build times can go up and down by the week or day, depending on various outages and whatnot, its nearly impossible to tell (is it just noise or did you actually make an impact?).

I don't think most people should do infra unless:

1. You like being wrong all the time. This cannot be understated. You will always feel like you're wrong until otherwise proven. And even then, you can never be certain if its luck or skill.

2. You are self guided. Infra's problems are very rarely obvious. It is up to you to sniff those out, create your own projects and solutions, and lead them.

3. You are highly highly efficient and are extremely rational You need to have an understanding of when you're wandering too far in the wrong direction in an codebase you don't understand. This means being able to sense the unknown and unknowable and know what is a big time sink and what is the best payoff for effort.

4. You have a long attention span. You can focus on a single problem for weeks without making progress. I have a video, Debugging Under Uncertainty, that goes into the background reasoning and investigation behind why I filed this fix upstream and why I chose to write this. Its a relatively simple diff. Note the back and forth between me the maintainers.

5. You have an extremely high level of personal responsibility. Infra is always an unknown. You WILL break things and break them often and be wrong a LOT that may or may not break things for the entire company. But you must be able to own every error. You cannot claim wins and ignore the losses. Most infra leadership understand that mistakes will be made. But that is not an excuse to dodge your role in causing company-wide outages. See #1.

Don't get me wrong: the rewards and learning you will get are amazing. The smartest and most brilliant people tend to rise up to infra and developer productivity in general because it requires an amazing ocean of experience to make the right calls (or at least avoid a lot of failures). You will also get unique opportunities most engineers don't such as intercompany conference involvement.

If you want another sample of the type of work infra does, here is an issue I filed just today against Bazel 7 that was only recently released a short time ago. This investigation alone took me several days and wandering into several dead ends. In the end, we have a fix that is just a few lines long but probably not suitable for upstreaming to Bazel itself but it gets us out of the woodworks. I highly encourage you read the conversation and my comments to get a sense of the sheer amount of proofs and dead ends I went into. And that's only investigating Bazel itself.

And if everything I just said seems overwhelming, keep in mind I'm only just a senior engineer. There are several staff engineers who do this type of work in their sleep, very efficiently, and without breaking a sweat while leading a very technically complex migration. They can investigate and file 3 times the issues and come up with better fixes for them in the same time it takes me to do 1.

I'm just trying to keep up

This was an excellent advice, Edbert! It motivates me even further to go into Platform/Infra. I am trying to put myself in uncomfortable situations to maximize my learning. Hoping that this could serve as something interesting and challenging.