Sometimes, no software engineering at all!

I’ve worked at Facebook as a software engineer for 4 years.

But I spent almost a year on my last team without shipping a single line of code. I was essentially doing the job of a product manager and a tech lead rolled into one.

I was talking to users, clarifying the problem we wanted to solve, defining success metrics, brainstorming and prioritising ideas, forming a roadmap, aligning with other teams, scoping out work, and managing projects.

I started to really miss being able to just sit down and code all day without interruption. After all, that was the reason I got into this profession.

I also got tired of working in a mature part of the company where the problems were more organisational than technical.

My work stopped being fun.

So I switched teams and now my job couldn’t be more different.

This is something I really love about working at Facebook. There’s huge variation in the work that software engineering teams actually do here.

You can spend your time coding, running experiments, analysing data, talking to users, planning and managing projects, interviewing, hiring, mentoring, and everything in between.

The exact balance just depends on your team and your role on the team. And the great thing is, you can choose both!

Product

If you’re on a product team at Facebook, you get to write and ship a lot of code. But you usually don’t need to solve hard technical problems. So the actual code may not be that interesting. You’re just trying to get a product out the door as fast as possible so you can see how people use it and then iterate.

The hard problem is not figuring out how to build the product. It’s figuring out what product to build. At Facebook scale, this means running lots of experiments to see what works and what doesn’t.

Most new products fail. For every “Facebook Marketplace” there are many other products that don’t get traction and get axed. But at senior levels, you’re rewarded for successful outcomes — not execution. So being a product engineer can be a high-risk, high-reward game.

Infrastructure

Infrastructure teams at Facebook are like product teams but instead of building for billions of consumers, you build for other engineering teams.

Since your “product” is used by other developers, building it usually involves more technical problems like figuring out the right APIs and abstractions to offer them. And rather than running experiments on the masses, you can speak directly with your colleagues to figure out what’s working and what’s not.

Compared to a product engineer, it can be easier to get successful outcomes. Usually infrastructure problems are better defined and you can derive solutions to them more rationally. And as a developer yourself, you can better empathise with your customers. Since they’re your colleagues, you can get instant verbal feedback from them. And once they build on top of your APIs, it can be hard for them to migrate off, so infrastructure tends to be stickier than consumer products. These differences also explain why many founders prefer to start B2B companies over consumer ones.

Ranking

Finally, there are ranking teams. These are usually product teams but where the core product uses machine learning. So you’re more of a data scientist here than a software engineer. You build training data pipelines, monitor data quality, train and evaluate models and run experiments.

Product and infrastructure engineers tend to improve their product by writing lots of new code. But ranking engineers improve their product by refining their model parameters, training data, and loss functions. So if you like writing lots of code, you might not enjoy ranking.

However, compared to regular product teams, it can be easier to get successful outcomes. Ranking teams usually just take an existing product or feature, that’s already successful, and improve it with machine learning. So there’s a lower risk of building something that users fundamentally don’t want. At Facebook scale, there are plenty of successful products that machine learning can improve and there’s plenty of data to train high quality models. So there’s plenty of opportunity for impact.

Here’s a full breakdown of the differences between product, infrastructure and ranking teams:

In my 4 years at Facebook, I’ve worked across all 3 types of teams. My current team is building the frontend framework for Facebook Shops. This is a blend of product and infrastructure, and I’m loving it because I get the best of both worlds.

I get to tackle interesting engineering problems, build for my colleagues, and write a lot of code. But at the same time, I’m close to the product, so I get to think about consumer problems, run large-scale experiments, and participate in a big 0-to-1 product bet.

But there’s another key ingredient that makes my current team so great — it’s in a relatively new part of the company.

Maturity

When your team is in a mature part of the company, you tend to encounter more organisational, technical and excitement friction. So building your product can become a drag.

Organisational Friction

Instead of spending most of your time coding, you can spend most of your time in meetings, “aligning” with the countless stakeholders who have an opinion on how your product should work and how it should integrate with theirs. And it’s not just engineering and design teams — it’s privacy, policy, and legal teams too.

Technical Friction

When you finally sit down to build your product, you can spend more time trying to understand the existing codebase than actually writing code. This isn’t fun when hordes of other product teams have already stampeded through it, leaving a wreckage of edge cases and ugly hacks behind.

And when you finally start writing code, you have to ensure it’s compatible with every possible state of every adjacent product. This complexity doesn’t just slow down product development. It makes products more prone to bugs once they’re launched. So you have to spend more time on maintenance too.

Excitement friction

In a mature part of the company, you can feel like you’re just optimizing something that already exists rather than creating something fundamentally new. Many ideas have been tried already, so there’s less room for your imagination to run wild. If you’re like me, this can make your work less exciting.

Tech Lead

There’s one final ingredient that makes my current role very different from my last one — I’m no longer “tech leading” a team.

As a tech lead, you generally don’t get to spend most of your time coding. Instead, you spend most of your time planning other people’s work and reviewing their code.

You’re responsible for the overall technical direction and execution of the team. This means you can’t just work on the projects that you find the most interesting or fun. In fact, the unpleasant technical work tends to fall to you.

You’re the team’s last line of defense, so when things go wrong, it’s on you to jump in and resolve the situation. When people are stuck, you need to unblock them — whether that means helping them with their task directly or connecting them with the right people. Part of your job is also blind spot detection and filling in the gaps that others have missed. You need to proactively identify risks and mitigate them.

The organisational work of aligning people within the team and across partner teams can fall to you too. This can demand a lot of your time, especially in a mature part of the company.

However, although the work can be less technical, you can have a much greater impact by acting through others. Since you’re responsible for setting direction for the whole team, your decisions are highly leveraged. Your actions could be the difference between the team’s success and failure. This can be very rewarding, especially if you genuinely care about the team’s mission.

Many engineers get drawn into more organisational work when they want to advance their careers. I know I was. But it is possible to advance while staying deeply technical.

Wrap Up

Today, my job is vastly different than it was a few months ago.

Before, I was tech leading a ranking team in a mature part of the company. There wasn’t much opportunity to write code, as the technical work was more data science than software engineering.

My role was to set direction, help plan and review others’ work, and align people within the team and across partner teams. This meant even less opportunity to write code.

And I was in Facebook Ads — a mature part of the company — where I encountered lots of organisational and technical friction. This meant even less opportunity to write code.

My job stopped being fun.

Now I work on a product infrastructure team in a new part of the company. I get to spend lots of uninterrupted time coding solutions to hard and interesting technical problems. I’m not the tech lead, so I have more freedom in what I work on. But my work is still highly leveraged, as I’m building for other engineers. I don’t have to deal with organisational or technical friction. And I’m really excited about the team’s mission as well as the product we’re supporting.

As a software engineer, there’s huge variation in the work you can choose to do — especially in a large tech company. And there’s not just one path to advancing your career. So it’s worth figuring out what you find fun, exciting, and energising, and then leaning into that. For me, that meant the difference between burnout and having a lot of fun!

Thanks for reading this far! If you have any thoughts, I’d love to hear them.