← Return to Index Archived March 18, 2026
The Lead — Mar 18
THE PRAGMATIC ENGINEER · GERGELY OROSZ

Building WhatsApp with Jean Lee

1h 10m / March 18, 2026 /producttechnologybusiness / Transcript sourced from openai
All episodes from The Pragmatic Engineer →·Podcast website →·Listen on Apple Podcasts →

Overview

This episode explores how WhatsApp, with an astonishingly small engineering team, scaled to hundreds of millions of users while rejecting most of the management practices now considered standard in software organizations. Jean Lee, engineer number 19 at WhatsApp, shares how the company’s commitment to simplicity, reliability, and focus enabled it to outperform much larger competitors.

The conversation also broadens into leadership, hiring, performance reviews, and what modern startups—especially AI-native ones—can still learn from WhatsApp’s unusual operating model. A central theme is that many processes solve problems of scale, not necessarily problems of building great products.

Key Takeaways

One of the most striking insights is that WhatsApp built and maintained native apps across roughly eight platforms with fewer than 30 engineers. Rather than using cross-platform abstractions, the team chose native development because their goal was not engineering convenience; it was ensuring the app worked reliably on low-end devices anywhere in the world. As Jean explains, the standard was that “a grandma in a remote countryside” should be able to use it.

Another major lesson is the power of disciplined refusal. Jan Koum reportedly said no to almost every feature request for years. At first, this confused Jean, especially when competitors were shipping stickers, stories, calls, and other additions. But WhatsApp’s restraint was deliberate: fewer features meant better performance, higher reliability, and less user confusion. This was product strategy through subtraction, not accumulation.

The company’s internal operating model was equally unconventional. There were no formal code reviews after an engineer’s first commit, no stand-ups, and no sprint planning. That did not mean low standards. Instead, trust was paired with high individual responsibility, strong technical judgment from the founders, and intense dogfooding before releases. The takeaway is not that process is bad, but that small, high-talent teams can often replace bureaucracy with shared context and accountability.

A particularly counterintuitive business insight was WhatsApp’s $1 annual fee. It was not mainly about monetization; it also helped suppress growth to a rate the company could sustainably support. According to Jean, that fee roughly covered servers, salaries, and SMS registration costs, allowing WhatsApp to operate near break-even without depending on venture funding.

Finally, Jean’s reflections on Meta highlight a different truth: in large organizations, visibility matters. Promotions often went more smoothly for engineers who made their work legible to others through internal posts and discussion, not just for those doing strong work quietly.

Practical Steps

For founders, product leaders, and engineers, this episode suggests several concrete practices:

  • Define one non-negotiable user experience standard. WhatsApp’s was reliability on any device, for any user. Use that standard to reject features and technical shortcuts that compromise it.
  • Say no more aggressively. Before adding functionality, ask whether it improves the core job the product must do or merely adds surface-level appeal.
  • Match process to team size. If your team is small and highly aligned, remove unnecessary meetings and rituals. Add process only when a real coordination problem appears.
  • Build trust through responsibility. Give engineers meaningful ownership early, but make expectations explicit and maintain a high technical bar.
  • Dogfood obsessively before release. Even without sophisticated rollout infrastructure, rigorous internal use can catch quality issues quickly.
  • In larger companies, make your work visible. Share launches, document impact, and engage publicly with questions so your contributions are understood beyond your immediate team.

Notable Quotes

“I want a grandma in a remote countryside to be able to use our app.” — Jan Koum, as recalled by Jean Lee

“We didn’t have code reviews… after the first time, we didn’t really have a formal code review.” — Jean Lee

“Processes exist for audits, for accountability, and for tracking who did what. But when you have 30 people and everyone can see what everyone else is working on, you don’t really need a paper trail.” — Host’s summary

Full Transcript

Source: openai 1h 10m runtime

Jean Lee was engineer number 19 at WhatsApp. She joined when hardly anyone in the US had heard of it, saw it grow to 450 million users, and was sitting at her desk with noise-canceling headphones on when news broke that Facebook bought them for $19 billion. In today's conversation, we discuss How WhatsApp built, natively, 8 different platforms with a team of 30 engineers Why the founders said no to almost every feature request for years How WhatsApp's team operated with no code reviews, no stand-ups, no sprint planning And many more If you want to understand how a tiny team with almost no process built one of the most successful products in history, and what today's AI-native startups can still learn from them, this episode is for you. This episode was presented by StatSig, the unified platform for flags, analytics, experiments, and more. Check out the show notes to learn more about them, and our other seasonal sponsors, Sonar and WorkOS. Gene, welcome to the podcast. It is amazing to meet you. You have quite the story, early engineer at WhatsApp. But before we get into WhatsApp, how did you get into tech? I've always been a small-town girl. My dad was an OG hipster. He was really into brewing beer. So he decided to get a PhD in beer, in brewing, in brewing. So I moved to San Francisco in 1999, and that's when I got really exposed to all the different tech roles. Growing up, I didn't really even think about engineering as a job. Of course, I used computers, and I thought it was really cool to be able to use Yahoo and search things online. But beyond that, my first exposure to Silicon Valley and tech came from living here. I got to meet a lot of people who work in tech. I dabbled around with coding when I was a teenager, but not too seriously. But I did think it was really cool that you can just write a few lines, and it will just do things for you over and over and over. It was almost magical. I loved the feeling of creating something that actually runs, and debugging something, and fixing it, and it runs again. That was really joyous. And I didn't really get into, like, super into coding until I went to college. But one of the reasons why I decided I wanted to go into coding was I talked to different people. So I thought, maybe I want to be a designer. Maybe I want to be an architect. Maybe I want to be an engineer. And I talked to different adults who work in the industry. After talking to a lot of adults, I realized people who are in tech were the only ones who were really excited about their jobs. So in Silicon Valley, when you ask people, like, tell me about your work, people are often very hopeful for the future and very proud of what they're building, compared to many other adults that I spoke with. They were not so encouraged. They're like, oh, don't become an architect. Don't become a designer. So that was one of the influences for me early on. I studied computer science at USC, and one of my first internships, actual coding internships, was at a small company. It was a three-person startup, started by one of the new grads from USC. And you'll probably understand, it was a video sharing website. But it was not like YouTube, but there were so many versions of YouTube back in the days before YouTube was dominant, right? So you probably remember dozens of these video sharing platforms. They were everywhere. And one of the issues of having so many options is that you have to be visiting 12 different sites to search for anything. So we had a website where you can aggregate all the different types of videos from different sources, which is actually kind of funny because lately I've been seeing a lot of AI platforms where you can just switch between models. Very similar to that. Yeah. How did you get into IBM? I really loved working for a small three-person startup because I got to work with engineers. We had engineers overseas in China, so I got to work with them. I got to also do a little bit of coding myself. But I was coming up with the design docs, like the features list, and I was calling a lot of the shots. And I could also directly see the impact of my code immediately on the website. And I thought that type of ownership and speed and the visibility was really exciting that I get to see the impact of my work immediately. But one thing I wish I had was a little bit more mentorship because we were all new grads and in college, I felt like we were just shooting things to see which sticks. And I thought maybe for my first job out of school, I would like a little bit more mentorship and training. And I started looking at more bigger companies, more traditional companies, and that's how I ended up at, at the time, it was literally the biggest company in the U.S. What point did you decide that you wanted to leave or try out something else? Did you even decide or something just came up? One of the reasons why I wanted to go to a more traditional company with more structure was so that I could get more mentorship and training. And IBM was excellent for that. There were so many veterans, they had so much experience, and they were willing to share with me because they were 20, 30 years ahead of me, right? But one thing I really missed was the small team environment. It was just so big. There was a lot of meetings, a lot of process, and I missed seeing the impact of my work. I couldn't quite understand how my work was contributing to the overall company. So then I decided to take some time off and explore and have some fun. Yeah. And what time was this? What year was this? So I started working 2007 and I left by 2009, which was actually, in retrospect, I was really brave because it was in the midst of economic downturn. My thought process at the time was, I was only 22 or 23, and I figured even if I take a year off, I can still catch up, which I did. And what happened from there? How did you eventually get to WhatsApp? That was years later, right? Yeah, so I took some time off to try out different classes. I took a lot of classes. I did a little bit of, nowadays we call it the gig work, but I did all kinds of work. So whatever I needed to make a living while taking all these classes and exploring and really finding out what kind of environment or what kind of career do I envision for myself. And after I took those time off, I decided that I want to go back to Silicon Valley, but this time I do want to work for a startup, but maybe with people who are a little bit more experienced, maybe not new grads and maybe not a three-person startup, but a little bit more stable startup where I can possibly get both the autonomy and the impact of the work, but also a little bit more mentoring because I was still in my twenties. Okay, so how did you find this startup, which of course happened to be WhatsApp? In 2012. WhatsApp was still early. They started in 2009 and they did still have a lot of users, but they're mostly in Europe and in India. They were not very known in America. Were you a WhatsApp user back then? I was not, but my wife and her friends were, or back then my, you know, my girlfriend, but so some of my friends were using it on and off. It was kind of starting to be big in Europe. It wasn't as massive just yet. Exactly. I was lucky because I actually lived in New York for a little bit before moving here. And a lot of people in New York were using it because it's an international hub. So I had used the product in the past and I saw the job posting on LinkedIn. And then you applied? What was the interview like? I don't think we did any leet code until way, way later, until when we started hiring interns and new grads. Most of the interviews were talking about, I guess you can call it system design interviews. We would talk about how would you design this? How would you design that? Like tell me about your past experience building this product. And I recall talking to Jan about different messaging apps and being Korean, I told him a lot about KakaoTalk and how it worked. Yeah. That was my interview. Just like that. You got an offer. I guess it's startup, right? Things move fast. But I assume it must have been quick turnaround offer. And then you have to decide, right? How did you decide that you're going to join this relatively unknown startup that is building some cool messaging that you kind of thought was cool, but there wasn't much information about that. In fact, their Glassdoor rating at the time, I remember had a one star. It had one review, one star, someone saying, oh, I don't like working here or who knows if that was even a real employee, but that was their Glassdoor. Oh, that's so interesting. I don't remember looking up. I must have looked up Glassdoor, but I was really lucky because I actually had another offer from a different company, but they were a little bit sore. One company was taking weeks to get you an offer letter. Another founder closed the deal in person the very next day. Speed matters and not just in hiring. This leads us nicely to our season sponsor, WorkOS. AI startups are reaching enterprise customers faster than ever, sometimes just months after launch. And in the moment that happens, the requirements change. Customers want SSO, SCIM, audit logs, and granular permissions before they'll deploy. Building that infrastructure yourself takes months. WorkOS gives you APIs to ship it in days, authentication, SSO, SCIM, RBAC, audit logs, and more, all designed to integrate directly into your product. Skip the rebuild, keep shipping, visit WorkOS.com. And now let's get back to Jean and how that other company could not get her written offer as quickly as WhatsApp did. I was not a startup and they said, Oh, Hey, like you have my verbal offer. I am going to give you a written offer soon. But then it took them a while. And meanwhile, Jean called me a few days later after the interview, and he said, come into the office, right? Like today or tomorrow. And then he asked me, what would it take for you to take the offer right now? Love it. What did you say? I mean, I wasn't looking for that much. I mean, I was in my twenties, so I just told him, Oh, like a few things I would like to have, then sure, I'll take the offer. And I signed the offer the following day. And I did actually hear back from the other company. On the first day I started WhatsApp, they called me and I was like, Oh, I just started a new company. That's it with startups. Because if you imagine, like, WhatsApp is so international, we can't take a break, right? We have to continuously keep running, and it's always busy. Someone's, it's 8 a.m. somewhere in the world, right? And Erlang was a really robust language that was really good at concurrencies, and they stumbled upon it because they were using this other tool that happened to use Erlang and decided this is the perfect language. And I guess at the core of WhatsApp, what was the core engineering challenge? Was it, like, so many messages being kind of coming in, needing to be seated out and sent to different, you know, platforms? Yeah, that was one of the main challenges. Like, for example, for New Year's or Christmas, because everyone's saying Happy New Year at the exact same moment, that was always our big biggest challenges every year, and we would celebrate, hey, we didn't go down after New Year's. So the interesting thing about the seven different mobile platforms specifically is the conventional wisdom before and after has been like, look, if you want to support all those platforms, don't be silly. Do cross-platform. Either build your own layer that is cross-platform or use, you know, there's all sorts of frameworks. Why did WhatsApp not do this? Do you remember the discussions of, like, why hire seven, including some really hard to hire people, like for Nokia and Symbian, and you mentioned the contractors in Europe. I mean, sounds a bit of a nightmare. Why? So Jan used to always say, I want a grandma in a remote countryside to be able to use our app. So what does that mean? They may not have the newest iPhone, the shiniest phone with the biggest memory, right? In the countryside where a grandma is using it, you need the app to be lightweight. You need it to work on any kind of device. And you need the app to be simple. So those were our goals and priorities, and that's the thought process that went into our decision to build seven different platforms. And then inside WhatsApp, how did you get things done? Do you remember, like, how a project got done or what was the concept of projects and kind of what engineering processes people might have followed, especially, you know, later you worked at Meta. Compare it to, like, how, you know, like more kind of, you know, standard startups work, because I have a feeling WhatsApp was not exactly a standard startup, was it? Not really. Even Meta, compared to other big tech, especially when I was at Meta, was pretty scrappy, like not so much on writing documents, for example. So the move fast and break things model kind of allowed them to be a little bit more lean in terms of their process, at least while I was there. But WhatsApp was, like, the ultimate lean company. By the time we were acquired, we only had 20-something engineers, so under 30 people serving 450 million monthly active users. So we didn't have code reviews. The only time I got my code reviewed was the first time I made a commit. Brian asked to take a look at it before I committed it, and he asked me a bunch of questions, which I had to think through a lot, like a kind of like a coding interview. But that was it. After the first time, we didn't really have a formal code review. But, I mean, people read the Git commits because there's only 30 engineers, so you can read other people's code, and they would discuss it on the WhatsApp groups. So everyone was trusted, all engineers, that they just pushed their code to, they merged it into production, pushed it to production without a manager review, and it was trusted that, you know, they would ask if they were unsure or something like that. Exactly. Okay, and it worked. It worked. What about the release process? Like if you tell me 450 million people, the first thing I'm going to say is like, okay, did you do canarying? Did you do feature flagging? Did you do experiments? Did you do, you know, what kind of safety nets did you have, right? We didn't do much of that, but we were really big on dogfooding. So every time we were about to do a release, we would all internally use it ourselves. Jan, I think he might still say it on his LinkedIn. If you look up Jan, he said, just quality engineer. His title when he messaged me, because I didn't know he was CEO, it said chief QA officer. QA office. And I didn't know what that meant. I thought it was some sort of weird joke from the outside. So now it makes sense. So he was going around. He was making sure that it worked. He would try to break things as much as he can, and then if he finds a bug, he will, like, really try to break it, and then he'll come to it and say, hey, like, I found this bug. And you also said that Jan said no a lot. He did say no. Almost, as I recall, 99% of the time he would say no. Which I thought as a, again, as a young engineer, I was very confused because when you look at all these other apps, there were like dozen different messaging apps at the time. Like WeChat is notorious for having everything, right? They have so many features. And I was so confused, like, why don't we build all these features? These are the newest, coolest things that we should have because at the time when I joined, we didn't have groups. We launched groups shortly after I joined. We didn't have voice calls, video calls. We didn't have any, no stories, you know, all the cool features were missing in my mind. But that was by design because we really wanted to prioritize, again, the quality of a grandma in a remote town being able to use our app at any given time. What's up how they did features for years until they were absolutely sure about quality. They worked on video calling long before they shipped it. This leads us nicely to our presenting sponsor, StatSeq. Today, you don't have to choose between speed and confidence. StatSeq lets you ship features behind flags, experiment at real users, and only roll out broadly when data shows that you're ready. Here's what it looks like in practice. You ship a change behind a feature gate and you roll out gradually, say, to 1% or 10% of users at first. You watch what happens. Not just did it crash, but what did it do to the metrics you care about? Conversion, retention, error rates, latency. If something looks off, you turn it off quickly. If it's trending the right way, you keep rolling it forward. And the key is how the measurement is part of the workflow. You're not switching between three tools and trying to match up segments and dashboards after the fact. Feature flags, experiments, and analytics are in one place using the same underlying user assignments and data. This is why teams at companies like Notion, Brex, and Atlassian use StatSeq. StatSeq has a generous free tier to get started, and pro pricing for teams starts at $150 per month. To learn more and get a 30-day enterprise trial, go to statseq.com slash pragmatic. With this, let's get back to how Jean and the WhatsApp team shipped quality code with close to zero formal processes. It sounds like WhatsApp had very, very little process. This was very, very interesting because when I worked at Skype at the same time as you joined WhatsApp, and I also joined in 2013, I joined Skype and you joined WhatsApp in 2012, Skype was very proud that they sent everyone to scrum training. I was a scrum master. Other people were scrum masters. So here we were with all this scrum, all the consultants, all the everything, and WhatsApp outcompeted us with like a lot smaller team and no scrum, no TDD, no agile. How big was Skype? 1,000 engineers. Wow, that's a lot of people. Yep. I mean, when you have a thousand people, you kind of need these. Yeah, and in all fairness, like, for example, one thing that this whole scrum thing solved for a little bit is we had more than a hundred teams and everyone was working on different things. And because of all this organization, we had a prioritized list of which teams are the most important and those got all the support. So I, I guess one lesson might be that when you're just big, it's just so much harder to move fast and a small team can outcompete you. Yeah, it just takes a long time even just to communicate with everyone. Being inside of WhatsApp, how did it feel to see this massive growth, not in your team size, but in the product usage, the, you know, the people, the media, the feedback? We didn't have much media. Like nobody knew about WhatsApp. One interesting thing you told me about the office is you had countdown display. Can you tell me about them? What were these? What did it display? Yeah, so you, you asked me a lot about metrics and I think the really the only metrics we tracked, like we didn't really pay too much attention to media or Skype's usage numbers or other messaging app's usage numbers, but the one metric we counted down was number of days, like X number of days since the last outage. Wow. No pressure. Well, the numbers started to go up over time. Maybe that helped to have it visibly there. And when an outage happened, do you remember what happened after, because these days in the tech industry, it's all about blameless postmortems. If an outage happens, I guess the company kind of continues inside of Meta. Like, it seems, seems like, you know, two things at the same time, like, OK, I have this like amazing financial exit, but there's also work. How do I balance? How did you balance? How did you decide what next? That's twofold. So the, the finance side in terms of that aspect, we actually got a lot of support. Our business person organized many meetings with like the accountants or even a financial advisor. We invited a professor who was the founder of Wealthfront, and he gave us an hour of finance advice. And he recommended books. I read The Random Walk Down Wall Street, which is a great book. I recommend that people read it if you're interested in financial management. And I read several other books to really educate myself to be able to manage this new wealth that I came across as a young 29-year-old. Yeah. What changed to the day-to-day once you officially became part of Facebook? Did you have to move offices? Did, you know, did you get a new title added to like the, the meta org chart, that kind of stuff? The changes were very slow in the beginning. We didn't even move into the meta, or at the time, it was called Facebook headquarters, Menlo Park, until at least a couple years after the acquisition. So in the beginning, everything was same as usual. We still had our old office. Well, we did actually move to a little bit nicer office, a slightly bigger office. But other than that, it was business as usual. It was Jan and Brian, and we were hiring, but not, you know, at our similar, like, slow, steady pace. And I think not until when we actually moved into the Facebook office, we started seeing a little bit more cultural influence and merging. Like, we started using their like HR services or recruiting services and things like that. But it was a very gradual change over time. And then when WhatsApp became part of Facebook, as I understand it, it still is, even to the date, its own organization. Like inside of Facebook, I understand there's organizations like Messenger or like there's the Facebook group, et cetera. So like, did WhatsApp remain its own kind of organization, a little bit shielded from the rest of Facebook? We had our own area before WhatsApp. And in the beginning, we even had, like, our own chairs, our own whatever, like, walls and decorations that we were using. We brought them all over. But over time, you know, there was more and more mixing. After the acquisition, how did you start to hire more people? How did the projects change? Did things become more ambitious? Did you start to add more features? Because clearly, like, you were about 30 of you. And then in a few years, there was hundreds of people working on WhatsApp. These days, it must be thousands of people. And, like, with those people, like, what new work came up? Because, again, originally, WhatsApp was so minimalist, right, and kind of so scrappy. I guess we were choosing to be small, not that there was not enough work for us to do, right? So one of the reasons why we also tried to remain small was actually Brian and Jan did not want to raise too much money. And it actually cost a lot of money to serve so many users. You have to pay for the servers. You have to pay for the SMS registration codes. Every year, Jan and Brian would do all hands meetings. So we did have meetings. Once a year. And Brian was very transparent. He would walk through our earnings and expenses. Oh, interesting. Yeah, I had a lot of information around this. So the three main buckets of our spending was the server cost was about a third, and then about a third on salaries for the engineers, mostly. And then a third, the rest was for the SMS fee. When you try to register, you get that code. And we have to pay that 10 cents or whatever how much it costs to send the international messaging. Those numbers, I mean, they add up when you have millions of people using your app. So they actually didn't want to grow too fast because it gets very expensive. WhatsApp was free for the first year. And then after that, WhatsApp was charging $1 for every year. But they were only using it in certain countries really to suppress growth because they didn't want to grow too fast. Fascinating. Because I remember in Europe and in the US, there was this $1 cost, which I think people were like, yeah, well, whatever. I don't think we realized that this was a growth suppression tactic. Fascinating. And then when Facebook acquired, I guess they got rid of it. Yeah, Facebook said, we don't need the dollar. We can grow as much as we can because they had the funding for it. And then growth just, did it, did it speed up? Do you remember? It did, yeah. Incredible detail. Using payment to slow down growth. The lesser known detail about the $1 is that that $1 was enough to pay for all of these, the server cost, the salaries, and SMS code. Per per year. So you were roughly break even. Break even. We did have funding from Sequoia, but we never touched that money. Incredible. Yeah, Brian explained it as how his dad was a business owner. And they would wake up in the middle of the night worried, what if I cannot pay the salaries for the employees tomorrow? And he, he explained that he took the funding from Sequoia as like a backup. And I think it was $8 million of funding if I recall, if I looked at, I looked at the backup. Yeah, so we never touched that money. The $1 paid for everything. And it slowed down growth enough to be manageable. Yeah. When you joined Facebook, what, what title did you get and how did your career change? So the thing about Facebook is that everyone's actually a software engineer. I'm pretty sure they still don't have titles. They don't have titles, but they have levels. What, what level did you come in at? So being one of the five youngest people, I got, I got leveled as a junior engineer. No, you did not. L3 or L4. L3, L3, yeah. No. I had to like climb, climb all over again. Oh my gosh, that must have been a bit awkward. I was not too happy about it, but what's the alternative? Do I want to give up fasting the rest of the shares? And eventually I got promoted. But it was within WhatsApp, so you got promoted pretty quickly. How many times did you get promoted there? A few times. I mean, I eventually became an engineering manager. And then as you became an engineering manager, at some point you decided to help and start a new office in London. How did that decision come and how did you go about it? That was actually an ask from Facebook headquarters. So they said, Hey, like we're actually running out of space in Menlo Park. And also WhatsApp is so big in Europe. So why not have a presence there? It will be much easier to hire engineers because everybody actually uses WhatsApp. So let's, let's start a new office there. And we didn't have that many engineering managers, right? I was very lucky because I got asked to go along with a couple other engineering managers. And all three of us actually became managers around the same time. We actually even trained together. So we were relatively new managers when we got asked to go there, but I think we were the only ones who could go because, you know, people have children and they have to think about school and they couldn't go. I remember one, the director that I was working with, he couldn't go because his wife said she doesn't want to move with the children. It makes perfect sense. You arrive in London, you landed with these two or three other engineering managers. How did you start to grow the office from a practical perspective? What can I imagine? Like, you know, like how did you start hiring or leasing space or what are the other things that you have to do that, you know, like were maybe a little bit unexpected for you? A lot of the logistical part was taken care of for us because Facebook already had an office there. So we kind of moved in. We got our own section and it wasn't big because at the time, again, we had a lot of contractors in Europe. So we had one contractor already in England. So we turned, we converted them full-time and then we have one in Scotland. We also converted him full-time. So he would commute from Scotland every now and then. So we had two engineers plus three managers and we started hiring there. I think the hiring part was something that took longer to set up. We worked very closely with the Facebook hiring team, which was really great that we already had people who were familiar with the local recruiting logistics there. So one thing we focused on a lot was really letting engineers know, hey, WhatsApp is hiring in Europe now. Come apply because we were hiring from all over Europe and also a lot from India. Do you feel it was easier to hire for WhatsApp in Europe just because people knew about it? Did you get more excitement, more applicants? A hundred percent. You wouldn't believe, like, I used to do a lot of university recruiting. And when I used to go to Stanford, maybe 2013, like anytime before the acquisition, I would say, Hey, like, the people will come up to the booth and I would say, Hey, do you want to give me your resume? And they would be like, tell me about your company first. Different companies have different ways of self-promotion. So like, for example, I heard some companies use emails. Like, they send mass emails every time they do a new release or launch. Or, like, at WhatsApp, we used WhatsApp groups for everything, but at Facebook, they used Facebook Workplace, which is like Facebook groups where you have a group for team, your org, and your, like, everything has a different group. And I noticed as I'm representing my clients during performance reviews, the people who post the most often, who have the most visibility, usually get the easiest consensus because it's just like all very natural. Like, if I have no clue what you worked on and your manager tells me you're great, maybe, but how would I know? I don't I don't know anything about you. So it I'm less likely to be inclined to agree with your manager. Maybe your manager's right, but I don't know. Whereas if you have been actively posting and telling me indirectly or directly what type of work you have done and what type of impact that has made and what are the lessons that you learned and what type of people you work with, then I already know, okay, like when your manager tells me you're ready, then I say, yeah. and then in turn, this was actually like, it's more than just groups. It was like the Facebook feed where, you know, like it's a bit like LinkedIn, right? Just to make it so. So you see these posts come across the company and sometimes you will put hit like, and what you're saying is like, if you've seen this post from this engineer on some other team saying, oh, we've launched a feature, here's an interesting thing we've learned that we're using for Facebook and I hit like, I now remember it. And then when performance review comes like, oh, I remember that person, they wrote that. Wow. And I might even have some questions, right? Maybe like if your manager tells me, I might be like, well, what about this? What about that? But if you make a post, I can just ask you directly through the comments, right? There's a lot of engagement happening in the comments. So I might ask, have you thought about this other thing? Have you thought about this thing? And you might give me answers and I think, oh, okay. Yeah, he's thought about it. He's really good. It's amusing because it sounds like simplifying a little bit, but to be successful at Facebook, you need to also be good inside of the Facebook app and do interesting work and not hide it, actually make it visible. That's interesting. Now stepping up a step back, and you were a manager at Facebook. You saw a lot of engineers outside of the performance review and people posting about it. What traits did the best engineers that you remember share? Like what made them so good? I struggle with this question a little bit because there is a difference between like, how do you measure skill? How do you measure what a good engineer is? Is a good engineer someone who can bang out new features? Is a good engineer someone who can design a complicated system? Is a good engineer someone who can communicate all of this and explain it to non-technical people? I struggle a little bit with the definition of a good engineer because I can have a definition of a good engineer, but it may be different for every culture. A different company might have different definitions. A good one. At Facebook, what was the definition? I remember that a lot of it went down to just a very simple characteristic impact, right? Definitely. And I think the way, like there are many ways to measure impact and definitely at Facebook, their way of measuring impact was through these posts. If I know about your work and you tell me you have impact and I agree, that's impact. So going back to when you were in London office and it started to grow, at what point did the London office start to feel less of a startup, a scrappy startup and more of a big tech? I remember a time after about a year and a half or so, I realized, I don't know who that person is, or I don't know their name. That was a turning point. And at what point did you actually start to think of leaving Facebook? I think I really enjoyed the intimate environment. So I appreciate being able to, like at WhatsApp, with 30 engineers, I knew everyone's names. I knew where everybody lived. I knew their spouses and their children and their dogs' names, right? I really liked that type of intimate environment. We still hang out. We have a pretty strong bond. And I feel like when I don't even know this person's name, I just feel less connected. Yeah. So what was it? The point where you decided that maybe it's time for you to leave and do something else? Oh, so, okay. I was in London on a contract. So I had a two-year contract. They said, hey, like, go start this office. And then once the contract ended, I had the option to either stay there to continue working in the London office, or I could come back to Menlo Park. But then at that point, I had been working there for eight years. And honestly, I think I was pretty burned out. I'm the type of personality who likes to get like A plus on everything I do every single time. So it was pretty tiring after eight years. I needed a break. Yeah. And when you left WhatsApp, what did you decide to do? I say WhatsApp, but it was Facebook at that point. Yeah. I actually, because I know my personality, I don't take breaks. So I actually had a goal. It's simple, but I said I will do nothing for the next six months. I'm going to challenge myself to do nothing for six months. Did you manage? I did it. I did it. I did read a lot. I exercised. I went on long walks. I did multiple meditation retreats. But that was my challenge to myself to not work for six months. So after six months of successfully doing nothing, after setting yourself that goal, what did you do to figure out what next? So initially I thought maybe I want to go start a new company or join another startup because I like working. I love building things. So I decided, okay, I'm going to start talking to other founders or people who are hiring or people who are looking to start a new company. So I actually talked to 100 founders. I have a spreadsheet to really see like, is there any interesting opportunities that I might feel passionate about joining or building? And after talking to 100 startups, I realized I wasn't really passionate about joining any of them. And I thought, well, like, what would I feel more passionate about? And what was the thing that I liked the most about working at WhatsApp for the past eight years? And I realized I actually really liked being a manager because I felt like I was creating a culture of like support so that other people can really be learning and thriving and, you know, be able to do things freely without people breathing down your neck. Or there are many things that make for a happy career. But I found it really gratifying to be able to find that from each person and really try to help them out and create whatever that is. It might be different for different people and trying to unblock them so they can really flourish. And I thought, well, if that's what I really want to do, I don't have to start a new company. I'll just do that part. But I started exploring, like, mentoring people. I did a little bit of coaching. I don't do it anymore. And making videos on YouTube, writing, all of that to see how would I find the best way to support other people. And on YouTube and on LinkedIn, you have been sharing a lot of your learnings, your observations. What pushed you to start sharing way more than before? Like, I think you started to do this publicly after you left Facebook. I was actually writing a blog about this. So I actually just hit 100K subscribers on YouTube last week. Thank you. And I was reflecting. I almost gave up doing YouTube because I was really not comfortable being seen in public. And I've been thinking a lot about this. Like, my grandma's from North Korea. She escaped during the war. And in that culture, like, you are, you do not speak publicly. You don't want to be seen because it's dangerous. And I think there's generations of that still kind of installed in me, the fear of speaking up is real. I felt really uncomfortable, so I almost stopped doing YouTube. Once one of my videos went viral from early on and I felt really uncomfortable. But luckily I was talking to a mentor of mine and she said, Hey, it's okay to do something that you enjoy doing. Just give it a shot. So then I stuck with it. I'm so glad I did. Speaking of the thing that is happening, of course, right now, AI, you spoke about this on your YouTube channel as well. But from your vantage point, how is AI changing how engineers work, how managers work? I do find it really interesting how with AI, we're seeing smaller teams emerge. I know that a lot of teams are saying, well, we're small because of AI, but I wonder if it's independent from AI. When you're small, you're just more efficient because WhatsApp did not use AI, but we were efficient because we were small. And I almost feel that even today, I can't, cannot really point to too many teams that are as small as WhatsApp and have that kind of impact. Maybe Anthropic might come to mind, but I think even they're bigger. So I wonder if there is a, maybe just going back to basics with all of this. Maybe AI allows to do the way most The only time we did an actual code review was the first time I made my git commit. Brian reviewed my code and asked me a bunch of questions. So, Jan and Brian were both, like, so technically adept. They were really excellent at doing this. They would ask, we're trying to achieve this. Like, what is the problem here? Or what is the best way to solve this issue? What are, like, different ways we can approach this? Tell me. So do I understand correctly that, of course, the small teams help with a lot of things, but then having the founders push people they hire, especially early on, they almost, like, push them to excellence, right? Is it fair to say that by Brian doing that super detailed code review with you the first time, it just upped your game, and later he didn't even have to do anything, right? Yeah, and there's, like, multifold, right? Like, one is to really challenge me to think critically, and then I learned a lot just from that conversation. And then also, like, from then on, he never checked my code again, so I know I am responsible, right? And I do believe when you give responsibilities to people, people will step up. I mean, not everyone, but most people will. But I think this might be a bit underrated. I wonder if we've had a little bit of too over-babying of engineers. I remember for a long time there was this talk in the past 5 to 10 years, and the engineering manager is like, well, I have a new grad. It will take them months to onboard. I need to sign them a mentor for at least 6 months, maybe even a year. And were we over-babying these very capable adults? You know, they're adults, right? Even if they're 18, but they're typically 20-something because they came out of college, and they're hungry, and they're ambitious, and maybe we don't need to do as much of it always. Yeah, I think as long as you hire smart people, it's kind of like a mold, right? If you make a mold too small, that's only the limit of how far they will grow. Yeah, if the mold is too small, you have to throw away a lot of things that could have made excellent material. Finally, you're a reader. What are some books that you would recommend for software engineers or people wanting to grow professionally or in a personal sense? I love reading books. So while I challenged myself to do nothing, I actually read, I actually took a year, but I did read a hundred books during that time. That was my doing nothing. Anyways, it kind of depends on what your goals are, but you gave me some specific things. Like for your career, I think for me, what was really helpful was, What Color is Your Parachute? That helped me really understand my strengths and my goals and priorities in my career and life. I mentioned the book Surrounded by Idiots. I know the title is kind of funny, but it's an excellent book if you want to learn more about how to really communicate and work with different people. If you want to understand finance, I mentioned earlier, The Random Walk Down Wall Street is a great book for understanding how to manage your money. Yeah, I would recommend those books to start with. And any fiction books? Hunger Games was one of my favorite books. I read the whole series. I read it as well. And I almost liked it. I liked the movies as well, but I loved the books. Yeah, yeah. I love the story of, like, this woman overcoming her challenges. And everyone else and winning in the end. Several times. Yes. Jean, thank you so much. Yeah, thank you. Thank you for having me on the channel. This was a great conversation. Yeah. I hope you enjoyed this rare conversation with Jean. One thing that stuck with me was Jean's point about why WhatsApp had almost no process and why it worked. Processes exist for audits, for accountability, and for tracking who did what. But when you have 30 people and everyone can see what everyone else is working on, you don't really need a paper trail. You just walk over and talk. This is a good reminder that most processes exist to solve problems that are created by scale and not by the work itself. I also found the Skype contrast really surprising. A thousand engineers, scrum certifications, two-week sprints, and a dedicated scrum master for every team. I was one of them at Skype. And WhatsApp with 30 people and zero formal methodology was shipping faster and growing faster on every metric that mattered. This is a much-needed reminder that organizational discipline and actual shipping speed are just not the same thing. And I was in the middle of this at Skype and Jean was at the middle of it in WhatsApp. Finally, it was interesting as a former manager to hear how Jean described performance reviews as a manager herself. She described herself as a lawyer representing her clients. As in, she doesn't control the promotion, she just makes the case. And the engineers who had the easiest time getting promoted were not necessarily the best engineers. They were the ones who made their work visible. They posted about their launches in the internal Facebook workplace. They engaged in comments, answered questions publicly. And the managers in those calibration rooms are making decisions about people that they might have never worked with directly. So visibility is not just vanity, it's how the system inside larger companies actually works. This is an uncomfortable truth, but I think every engineer at a big company needs to hear it. If you enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. A special thank you if you also leave a rating on the show. Thanks, and see you in the next one.