Should You Build Products or Infrastructure?

Ryan Peterman writes The Developing Dev. He went from L3 to L6 at Meta in four years, about twice the usual pace. In one essay he lays out what shifts when you aim for Staff+ on a product team versus an infrastructure team.

Up through senior engineer, the choice barely matters. You still work with product managers, shape scope, and deliver features. The gap shows up when you try to climb past that line.

Two Paths To Staff

Infrastructure engineers can move an entire company with one well-placed change. Speed up a core service or improve a shared platform and every team downstream feels it. Infra groups tend to stay small because the code is the lever.

Product engineers work closer to one customer problem, so the blast radius is smaller. The upside is people scale. Product orgs have more teams, more roadmaps, and more seats for managers who want to steer user-facing work. If you like owning a slice of the customer journey, product is the more direct route.

Choosing The Work You Want To Repeat

The split is old news. Vgod wrote about it years ago. The answer still depends on which puzzles give you energy. Start by noticing where you want to keep tinkering after meetings end. Then read how promotions are judged at your company. Infra ladders reward deep technical work that other teams adopt. Product ladders reward user outcomes and roadmap moves.

Shadow someone a level up on each path. Sit through their stand-ups. Skim their design docs. The hidden work shows up fast. If you can, borrow a sprint on the other side (i.e. help reliability if you are on product, or polish onboarding flows if you live in infra).

Either path gets you to Staff. Pick the kind of influence you want: building the tools everyone else uses, or building the product the customer actually touches.