Seven years at Facebook

3 Oct 2026

I’ve been at Facebook for 7 years and recently got promoted to IC7 (Senior Staff SWE), so it felt like a good time to share the lessons that have helped my career the most. I meant to write 5 of these for my 5th anniversary, but it took me 2 years to find the time, so you get 2 bonus ones.

I learnt almost all of these from other people: sometimes as direct feedback, sometimes as advice, and sometimes just by feeding my curiosity (people do eventually get annoyed when you keep asking questions). So sharing them feels natural to continue the circle of tech life :)

1. One thing at a time

This is advice I got early in my career from a senior manager on our team, in response to a very basic question: “How can I be a good engineer?” The answer was simple: “Pick one small thing (a system, a framework or a service), get really good at it so that people come to you when they need help with it, and then move on to the next one.”

When I first joined Facebook, I worked very hard and fell into what I thought was the true programmer routine: at least 6 cups of coffee, and at most 6 hours of sleep. My plan was to go broad and learn everything; I thought that was THE key to success. What I didn’t realise was how large Facebook’s systems are. You can’t make meaningful progress on all of them at once.

So I followed the advice: I picked one system and learnt to use it really well. It happened to be a system used for firefighting, and we had a lot of fires. Soon enough I was on the call-in-case-of-fire list, and it turned out that’s where a lot of the interesting, fun and impactful work happened.

2. No black boxes

Next is advice from a senior engineer, in answer to another very basic question: “What makes a good engineer?” The answer: “No black boxes.”

Big companies have lots of systems, and it’s easy to get into the habit of knowing them only by their interface rather than how they actually work. Nobody has time to explain everything. Your onboarding buddies and mentors have plenty of their own work and mostly just want you to get the job done.

I applied this to the same system from lesson 1. It worked brilliantly for its intended use case, but opening the black box let me extend it to a slightly different vertical, which meant more impact (and more fuel for my curiosity).

A more recent example is streaming LLM responses. We were early to build agentic applications and hadn’t figured out the whole user experience yet, especially with third-party models, and it wasn’t delightful. Everyone treated the gateway as a black box and assumed only the platform team that owned it could make the change (this was before coding agents took off). But when I dug in, it turned out most of what we needed was already there. A few lines of code later, we had a much better streaming experience.

Coding agents now make it much easier to learn how systems actually work, if you choose to use them that way. The flip side is that with agentic coding, even the people building new systems don’t always fully understand them. Whether we’ll still need to read code is a separate debate, but knowing how things work is never a bad idea.

3. Ask for help

This one I got as constructive feedback, probably the most useful I’ve ever received:

My career grew relatively fast, and when you’re used to solving problems on your own, you wrongly start to believe that’s what you’re rewarded for. What you’re really rewarded for is getting problems solved, and asking for help is part of that. I had always read the first two lessons as things I had to do alone; this feedback helped me refocus on what matters more.

This advice is even more relevant today. Agentic coding has created a false sense that you no longer need help. Yes, we can build more things in parallel (software factories, loops, etc.), but attention to detail doesn’t scale, and sometimes the easiest way to get more of it is to get more eyes on it. A delightful product still needs an insane amount of attention to every detail.

4. Know who you are building for

This one is universal. It doesn’t matter how big your company is, whether you work on product or infra, or what you’re building: you need to know who you’re building for and what your work actually looks like in production.

No matter how much you plan, or how many edge cases you think through, you will get things wrong. A user might not understand the “obvious” button you show them, or another engineer might keep forgetting to pass a TTL to your cache service.

In big companies there are plenty of people who can watch production for you and send you a digest: data scientists, data engineers, growth folks, product managers. But as a builder, it’s your responsibility to know what’s happening in production and what people using what you’ve built need.

When we were building a support assistant, we were obsessed with optimising time to first token. Then one user gave us a fascinating piece of feedback: “When AI responds quickly I trust it less, because I don’t think it has done enough work.”

Our intuition was that faster is better, and we measured against that assumption. That assumption drove our tradeoffs, including how much compute we could spend on each response. Once we changed them, we could give higher-quality answers (and no, we didn’t add fake delays). Dashboards tell you what is happening, but to understand how people feel when using your product, you need to look at individual examples.

So I’ve built a habit: every morning, whatever I’m working on, I try to look at real examples to get a feel for what’s working and what’s not (for the support assistant, that means reading feedback from UX research). It puts the numbers on the dashboard in context.

5. Buy low, sell high

I got this advice from a senior engineer when I was struggling to get people on board with how I thought we should build a product. In big companies, getting everyone aligned can be exhausting, and this advice put things in perspective.

Say you own a stock you know is massively undervalued, but the market hasn’t caught on yet. What do you do?
a. try to convince people it’s undervalued so they buy it?
b. buy more, because you’re convinced it will go up?

The stock is your idea. If you really believe in it, stop spending energy convincing people and invest more of your own time in it. If you’re right, the price will follow.

I’ve applied this a few times since:

1. When we launched the support assistant, it ran on a new backend that our existing review tool didn’t support. It was one of those things that falls through the cracks in a big launch: everyone was focused on shipping, and it wasn’t on anyone’s list. The only way to investigate what the assistant had done was to query raw, append-only data by hand. My old self would try to make people see that we needed it and then build it. My new self just built it, and after launch it has become the most used tool for investigating agentic experiences.
2. Big apps have hundreds of settings, and finding the right one is hard; people usually end up googling the exact steps. Wouldn’t it be nice if the support assistant could just change your settings for you? Again, the idea wasn’t popular, so instead of convincing people, I just built it. 2 of the 5 features listed in the launch post are exactly that.

This might sound like it contradicts lesson 3, but the two work well together. Asking for help is about getting a problem solved. This one is about the stage before that, when people don’t yet see that the problem exists. You don’t need permission to solve a problem other people can’t see yet.

Nobody needed convincing once it worked. That’s the sell high.

6. Smart or right?

This is the lesson that took me the longest to learn. When I was more junior, I used to get really irritated in meetings when someone wouldn’t give a perfectly factual answer to a question. As I’ve become more senior, I’ve realised that people ask questions for different reasons, and your job is to figure out the intent behind them. Often, those imperfect answers were answering what was really being asked.

For instance, if a VP asks whether you’re using another team’s LLM or fine-tuning your own, what they’re really asking is whether you’re building on the shared foundations they’ve invested a lot in, or whether those foundations aren’t on par yet. If a teammate asks the same question, you can probably just send them a code pointer.

A better answer for the VP addresses the real worry: whether the foundations are paying off, or whether the duplication is justified.

A lot of this comes with experience, but last year a senior PM on my team gave me a framing I really like: “Do you want to be smart, or do you want to be right?” Being right is answering the literal question correctly. Being smart is answering the bigger question behind it. If someone wants the literal answer, they’ll usually tell you. Otherwise, work out what’s behind the question and answer that.

7. Life’s short, maximise happiness

“Life’s short, maximise happiness” is the motto of my friend and former manager. He used to tell me this almost daily. I’m still learning it, but slowly getting there :)

I had always optimised for fast career growth, and I never learnt to celebrate. In one performance review I got the best outcome possible: the highest rating and a promotion at the same time. I still wasn’t happy; I was already looking for flaws in the past six months. Looking back and learning from your mistakes is important, but only after you’ve celebrated.

Another time, my manager told me I’d been promoted again, and my immediate question was: “Okay, how do we get to the next level?” I will never forget his face. Pure shock. He suggested an alternative: take a deep breath and enjoy it.

I also kept telling myself I’d celebrate later, once I got to the next level. But later never comes; there’s always one more thing to do. So celebrate early and celebrate often. Life’s short, maximise happiness.