MLE/Backend/Frontend vs Product/Infra
shift in mentality that paid off for me personally
The change
A few months ago I changed teams.
I shifted from a backend / modelling / ML infra heavy team to a more full stack engineering role. (That’s a story for another time).
I now even touch some frontend code! Crazy right!?
So… does that make me a frontend engineer all of the sudden? No more backend? Full stack?
I don’t like those definitions.
What I like to say is that I shifted from a "70% infra, 30% product” to a “90% product, 10% infra” engineer.
What do I mean by that? Let’s explore!
New axis: a shift in mentality that paid off
I will cite verbatim [1]:
Product-first engineers map to “Product engineering”—building, launching and maintaining features that solve user problems. They often love being in the same room as designers and product managers to learn about users, and they love finding technical opportunities that can improve the product.
Code-first engineers map to “Infrastructure engineering”—building infrastructure platforms that support applications, be it via building CI/CD pipelines, implementing logging, or supporting high traffic etc. They’re motivated to better the craft of programming and are often obsessed with things like test coverage, using the latest technologies, code architecture, etc.
You see, quite a dramatic change that has nothing to do with the tool you use, whether your code can be seen by the end of the user or anything like that.
I personally view coding as a powerful lever for impact, regardless of the specific technologies involved.
Before making the switch, I was quite scared:
“I will be writing frontend… I have no idea and little interest in it”
“OMG, billions of users will see my new features with their own eyes”
“My code will handle QPS in the million with real money flowing”
In the end, I took the opportunity to stretch myself and acquire new skills (with great results, ask my manager):
Stronger product sense → How to decide whether to build something or not is rather challenging (being data driven is hard)
Mediating between product areas with conflicting objectives → Adding a new ad in general does not sit well with core youtube teams, as you could imagine.
Write tons of code touching systems across auction of ads and youtube app → Quite the variety!
If I had been stuck in my old way of thinking, I would not have made the switch and I’d have lost out on a great opportunity for rather silly reasoning.
I hope you can also benefit from this new way of thinking and assess which style reason more with (It should help your career!)
Talking about career: I want to discuss how the Infra/Product axis impacts seniority/career advancement.
Career growth in a product vs infra team
A closing note on what I see inside a big tech company in terms of career growth under the light of this new framework.
In general, it’s quite hard to make “L6+” impact on a product oriented team in a incumbent company. You can imagine that a product like Ads is already quite mature and there are very few low hanging fruits left. You need to be at the right place and at the right time to get the juicy projects. (I personally got lucky, I will tell you about it soon when I finally ship something really cool!)
I see that infra team are more senior heavy instead. Imagine you are in charge of logging across all youtube ads. You don’t particularly care about the monetary impact (no need to look for the juicy fruits that make revenue go brrr), but by default your work already impact a billion dollar machine.
I personally really enjoy product work, but I feel that if my career aspirations are not met I will migrate to a more infra heavy roles down the line as I become more and more senior.
What about you?
Can you share more resources about this product/infra thinking?