Joining Meta: 8 Months Later – Part II
This is the second post in my “Meta: 8 Months Later” series. The first one is here. In these posts, I reflect on the onboarding plan I made when joining Meta — and how it actually played out.
As a reminder, this was the high-level outline of the plan:
- Technical Mastery — Gain a comprehensive understanding of the systems, their architecture, and the underlying technologies critical to my area of work. I should be able to effectively contribute and lead in technical discussions and decisions.
- Strategic Influence — Grok the business context and strategic goals tied to my technical work. Dive into the product and regulatory landscape to make sure my technical choices align with Meta’s bigger picture. Sync technical decisions with business objectives and product strategies to make a real impact.
- Leadership and Collaboration — Build my internal network, establish thought leadership, and create informal ties within the broader organization and with key partner teams.
Like I said in Part I, this was a good plan — but with caveats. The technical part was clear: learn as much as you can while you still have time, because once you’re deep in project work, no one’s going to give you another minute for learning.
The second part — strategic influence — was a lot more subtle.
At Google, we treated user security as a fundamental value — it was inherently justified. No further business case was needed. But at Meta, things were a bit different.
When I raised the idea of following Google and Apple’s lead by making 2FA mandatory at the sign-in stage, I was met with some uncomfortable looks and a very practical question: what would that do to our MAU numbers?
That was when I started to understand that saying “it’s the right thing to do” wasn’t going to cut it here — so I backed off and started digging.
The way Meta operates is both similar to and different from Google. In some ways, Meta is more honest internally about the fact that it’s a commercial company that has to make money. User security or integrity doesn’t matter if the company isn’t viable — if we can’t keep the lights on, nothing else really matters. Everything has to serve a goal — including driving user signups. Unlike Google, which can show ads to anyone, Meta monetizes only through registered users. Let this idea sit with you for a little while: user who is not logged in, is of zero value to Meta, which is why registration should be as seamless as humanly possible.
Whether it’s the right approach is up for debate — but there’s a brutal honesty to it that I respect. And I can’t help but think that being honest with ourselves is essential if we want to do the right job, right.
This model forced me to think more deeply about what we’re actually trying to achieve.
The typical approach to Security UX is to ask: how much friction can we add before it drives users away?
At Meta, I learned to ask a different question: how much security is just enough?
That is — for any given category of users, what are the most likely attack vectors, and what level of security would make those attacks not worth the effort?
One phrase I used a lot with the team was:
“You don’t have to run faster than the bear to get away. You just have to run faster than the guy next to you.”
My interpretation: we don’t need to build the best possible security for every user.
We need to build security that’s just enough to make attackers go after someone else.
This was the second of many learnings I’ve had since joining Meta.
In the next post, I’ll talk a little bit about my challenges understanding who’s responsible for what and why Growth has its fingers in so many pies.
Till next time!