Author rachel nabors 1608310508588

Rachel Lee Nabors

Principal TPM leading Developer Education and Programs on sabbatical from Big Tech

Rachel Nabors lives to teach the world to code so others may create a future we can all believe in. They spearheaded the new React and React Native docs at react.dev and reactnative.dev and are consulting in this space after leading developer education at AWS Amplify.

Description

Saron sits down with Rachel Nabors again. They talk about what Rachel has been up to since they were last on the show in 2017, the inside scoop of Big Tech, and Rachel’s experience working for organizations such as Meta, Amazon, and Microsoft. You’ll also hear why Rachel has decided their next chapter will be at a startup and what they are hoping for in their future.

Show Notes

Transcript

Printer Friendly Version

[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host, Saron, and today we’re talking about the difference between performance-based firing and layoffs with Rachel Nabors.

 [00:00:18] RN: React was where the money was, so all these people were investing their valuable lifespans learning technologies that wouldn’t get them those intergenerational wealth accumulating fancy corp jobs. I saw that and I was like, “Well, that is a bad pattern. And if you can disrupt that pattern, you can have an outsized impact.” So how might you do that?

 [00:00:42] SY: Rachel and I explore what they’ve been up to since we last spoke and the learnings they gain from their time with organizations like Microsoft, Meta, and Amazon after this.

 [MUSIC BREAK]

 [00:00:57] SY: First of all, welcome back, Rachel. It’s been a while since we’ve talked. It’s been a while since we’ve connected. Welcome back on the show. We’ve had you on, on 2014 and in 2017, and now we’re back in 2023.

 [00:01:09] RN: It’s so good to be back. However, I’m wondering if we want to introduce with performance-based firings. It sounds so negative. I’d love to know more about just big tech careers, period, just sort of covering big tech careers, what people think they mean and what they actually mean.

 [00:01:25] SY: Yeah, sure. Absolutely. We can totally dig into that. So what have you been up to since we last spoke? Last, we were talking about you being a cartoonist, transitioning into coding. That was kind of the big theme of our last conversation. What have you been up to since then?

 [00:01:39] RN: Well, I released a book with A Book Apart about UI animation. And since then, I actually began my big tech career journey. That book, by the way, is Animation at Work. You can get it at abookapart.com. I have to give a plug for all of my historical work. It may be six years old, but it’s timeless classic animation principles. Surprisingly though, I’m not doing animation anymore. In the past six years, I started working as a program manager at Microsoft on the Edge browser. Then I pivoted to go abroad, working in Amsterdam at Booking for a year. And then I wanted to work with engineers, really amazing engineers and open source again. And I joined the React core team at Meta London and worked with Dan Abramov to launch React.Dev. And I was also responsible for ReactNative.Dev as well.

 [00:02:32] SY: Wow!

 [00:02:32] RN: So dove deep with the frameworks community. And then I swung back to the US to do a stint at AWS. And now I’m heading back to London to begin my startup journey!

 [00:02:43] SY: Oh my goodness! Wow! Okay. There’s a lot to unpack there. So I guess my first question is it feels like in the last six years, you’ve done a lot of different technologies. You’ve worked in a lot of different technologies. I mean, when I think of the Edge browser, that’s browser land, right? And you mentioned React Native, that’s front end or Reactland. And I’m wondering, how did you do that? How did you learn about all these technologies and work in all these different spaces? Was it learning on the job? Or are you a secret browser expert that I just didn’t know about?

 [00:03:19] RN: Well, I actually knew a lot about browsers from my work on web animation APIs with the W3C.

 [00:03:25] SY: That makes sense. Yeah.

 [00:03:27] RN: And I also documented the web animation API on MDN as a bit of a thing that I was doing with Mozilla. I contributed to their dev tools, et cetera. So it was really exciting to get the opportunity to work on Edge as part of their community team. However, browsers, they move at a different pace and working on a browser is a lot different from working with front-end developers. You’re building things for front-end developers, and that is a very different sort of work that you do. Rather than building apps and making delightful experiences, you’re wrangling different engineering teams and product managers inside a gigantic super structure of people with competing goals and needs. And for instance, you might be asking, “Gosh, why haven’t we added many new HTML elements since HTML5?” The reason is it is actually super complex to add a new element to a browser.

 [00:04:23] SY: Is it?

 [00:04:24] RN: Oh, yeah. So there’s a lot of pushback when you want to arbitrarily add new super divs, et cetera, which is why you see new elements advancing in browsers very slowly. And in that regard, working on browsers is a little unique because every browser has to build to a unified specification so that everyone has the same experience. This is one of the few roles where you’re going to work at one company, but work with many people at other companies. And that’s kind of what’s magical about standards work.

 [00:04:57] SY: So this was at Microsoft. Is that your first kind of big mega company to work at in your tech career?

 [00:05:05] RN: It sure was.

 [00:05:06] SY: Yeah, how was that?

 [00:05:09] RN: Well, I definitely learned a lot about big companies. It’s not like working for a smaller company or being a front-end developer, where you wake up, you write some code, and the client is appeased, and thumbs up it or thumbs down it, and then you get to go to bed. That’s too easy. The challenge with working in a big company like Microsoft is that a lot of it is networking, the same way you might network with people on dev.to or you might go to conferences, you’re doing that inside a large company. And you’re also, of course, doing it with people at other companies that have a vested interest in what your company is developing. But you have to understand them as well as you might understand, for instance, your developer community. And you also have to understand the users just as well and you have to understand all the conflicting priorities for what’s going to ship this year. So it’s a little bit like being a flight traffic controller, a little challenging in that regard. And I learned that I had to be okay with stepping away from the engineering and teaching side of things to do that work, which was a little bit more hands off than I wanted to be, which is why I struck out on a different adventure.

 [00:06:18] SY: So before we get to that adventure, your title at Microsoft was Program Manager. And my understanding of a PM at Microsoft is very different from what most people might think of as a program manager in other jobs and other industries. What were some of the responsibilities that defined your role there?

 [00:06:37] RN: That’s an incredibly good question. And I got to tell you, this particular team I was on, I think defining the responsibilities and roles was one of our jobs. It was sort of like get in there, find something you were passionate about, and then make that your job. That was one of the challenges with Microsoft is that there’s a bit of a joke in the industry, which is, “I worked at Microsoft as a PM and I’m still not sure what we do.” Microsoft has officially changed the title to product manager now, but I got to tell you, program management at Microsoft is unlike product management at other companies. I like to say that the challenges with these “P” titles, program, product, and project, is that often they do a little bit of all, and depending which company you’re at, it’s going to have a different definition.

 [00:07:24] SY: So after you were at Microsoft for a bit, what was your reaction to working at a big company? Were you like, “Give me more,” or were you like, “Okay, I got to size it down a little bit”?

 [00:07:36] RN: Microsoft, I realized, took me a little bit away from my craft. I wanted to go back to my craft. And so I had this lovely opportunity to move to Amsterdam and be the resident UI animation expert at Booking.com. And they were building a design system. And I thought this would be a great opportunity to kind of reboot, try a slightly different size of company, more of the medium to large. It’s a little bit less strategic and working on standards and a little bit more hands on doing a lot of the things I’ve been doing in my web animation days, consulting on design systems, et cetera. And actually, it was a lovely time. I really love the people at Booking. I love Amsterdam to this day. I think it’s where I want to work forever. I’d love to grow old in Amsterdam.

 [00:08:29] SY: Aww. It’s a great place. Yeah.

 [00:08:31] RN: I like it a lot. I can say it was one of the best years of my life was working there. But the problem was I had tasted the fruit of having massive impact in the industry at Microsoft, and as much as I loved Amsterdam, I felt like I couldn’t go back to individual contributor work.

 [00:08:53] SY: Ah, I see.

 [00:08:55] RN: Yes.

 [00:08:55] SY: That’s interesting because I’ve heard people say, as an IC, it’s interesting because you are working on your own to-do-list, your own kind of task list, and you’re making your own contributions, but it feels like there’s the potential of depth for those contributions where you’re might be contributing narrowly, but you’re going deep because you’re really fixated on a problem and you’re trying to solve it all the way through. Whereas when you are taking a step up and going a little bit broadly, your touch points are a little bit more shallow, is kind of how I’ve understood it, but you have broader impact because there’s more people that you’re managing and you have a bigger project, but you’re not the one kind of hands on and kind of in the weeds of things. So it sounds like you’d prefer the broader approach versus kind of the deeper, more narrow approach. Am I understanding that correctly?

 [00:09:46] RN: So here’s the fun thing, and you’re not wrong. The fun thing is I am a person who has special interests, and they take about five years to work their way out of my system.

 [00:09:56] SY: Okay.

 [00:09:57] RN: When I was a teenager, I became fixated upon Sailor Moon, and I spent five years learning Japanese so I could translate the comic books, because the translations of the anime’s episodes were cut short on a cliffhanger, and I wanted to know what happened next. And I still learn Japanese as a pastime. I like to say it’s my hobby, but I’m not nearly as in with it. It turns out UI animation was something I dove deep on for five years. The start of my big tech career coincided with me starting to lift out of it, where it’s like, “That was cool. I have done many of these things. I have dove deep. I have contributed to APIs and standards,” but there’s no job to continue diving that deep. UX designer role is going to require you to go broad. Anyway, you’re not going to get to null out on animation forever. And I was already starting to cast my net wider to figure out what is the thing that I want to fall in love with next. And UX design was not it, not at Booking, at least. UX design there is it’s its own special kind of beast. A lot of it circles around A/B testing, for instance. Perhaps to the detriment of the interface, I have heard all the complaints about Booking’s interface, but that is what happens when you do A/B testing-led user experience design. You end up with an interface that optimizes for clicking the button, not necessarily an interface that optimizes for delight. And that is one thing you might run into in a formal design role at larger companies is that you might find that there’s less room for thought leadership and principled design. You might find that, for instance, KPIs end up leading and influencing design more than the best practices that you might be used to practicing on smaller projects or bespoke startups.

 [00:11:53] SY: Was it a big organization or did it operate more of like a startup?

 [00:11:56] RN: So here’s the fun thing. Every big company likes to believe it’s still a startup, short of IBM and Microsoft. Amazon says, “We’re still a startup. We move fast.” Meta says, “We move fast and don’t break too much.” Everyone still likes to think that they’re a baby shark and Booking was no different. They had their principles that serve them well. I would actually argue one of the challenges with these companies is that they’re a little dog that hasn’t realized that they’ve grown up to be a big dog. They still think that little dog practices are going to serve them. But the problem is if a little dog doesn’t realize they’re a big dog, sometimes their behaviors can be harmful.

 [00:12:41] SY: Yeah, well put, well put. So after you realized that you wanted to have a bigger impact, and you were kind of done with booking, you wanted to move away from it, what did you run towards?

 [00:12:52] RN: My life got dicey in here. You might wonder why I kept jumping from different roles. But after Microsoft, my marriage actually fell apart. My father died, and I was in the middle of an international move. And so that exciting journey to Amsterdam, I was supposed to be doing with my husband, turned out to be a long distance divorce and me grieving my dad. And after that, well, I really missed working with engineers, and I wanted a fresh start. As much as I loved Amsterdam, it felt like it was being fixed in a place and time, and I wanted to try something different. Again, I wanted to move towards having that broad impact, but I wanted to do it in the front-end development community. I didn’t want to be so far away that I was working on a browser on specs that may or may not ever be released, nor did I want to be an individual contributor whose work wasn’t really going to ship because of the focus on A/B testing. I wanted something that was somewhere in between, where I could have impact, return to my favorite community, which made me feel warm and loved and supported and still feel good about the work I was doing. And I wanted to do it with some of the amazing engineers because I got to work with amazing engineers at Microsoft. They had the coolest, like graphics and rendering engineers working on the Edge team. And some of them had gone to Meta to work on Oculus. And I was like, “Well, I like where these guys are going because they’re smart. Maybe I should check out what’s going on at Meta.” [MUSIC BREAK]

 [00:14:42] SY: So Meta was kind of where you had your eyes.

 [00:14:44] RN: Well, I didn’t want to leave Europe because I was enjoying it. I have a lot of friends in Europe because I used to travel and speak a lot in Europe, and I was just having a great time. It was not the same as being in the US. We had proper vacations, almost an entire month of vacation days everywhere. And I wanted to stay near that, at least for the time being. So I was like, “Well, where are the nearest smart people working in this space?” And there was the React team in London where Dan Abramov was. And I was like, “All right, let’s take a look at the React problem space. What’s going on here?” And one thing I’d noticed was that React community wasn’t exactly the most welcoming community and learning React was really hard. I tried many times and I’d failed. I’d get stuck in Kent C. Dodds’ course where it’s like, “Now we set up the environment,” and dealing with all the dependencies and just trying to get from zero to a working environment. I’d usually get frustrated and wander off. And I wasn’t the only person. And additionally, when I talked to the women I knew in my community and I’d say, “What are you learning?” They’d be like few because I feel like there are more people like me there. Or people of color, they’d say, “I like Ember, the team is really welcoming.” And so everybody that I knew in my circles was interested in non-React frameworks. Even I was previously doing animation talks in the Vue ecosystem before I left the US, which I really loved. I absolutely adored the Vue conferences, and Sarah Drasner encouraged me, and that felt so healthy and helpful. And I realized when I was looking at jobs, that all the six figure jobs in big tech, they all needed React. None of them were hiring for Vue or Ember. I mean, maybe at Google you’d get Angular, but for the most part, React was where the money was. So all these people in these groups that are already earning 80%, 75% of what the industry standard is, were investing their valuable lifespans learning technologies that wouldn’t get them those big, beautiful, influential, intergenerational wealth accumulating fancy corp jobs. I saw that and I was like, “Well, that is a bad pattern.” And if you can disrupt that pattern, you can have an outsized impact across many people’s lives and their children’s lives. So how might you do that? And that’s when I DMed Dan Abramov.

 [00:17:23] SY: And what did you say?

 [00:17:24] RN: I was like, Oh my God, I used Twitter. I got to tell you, every job I’ve gotten in big tech happened because of Twitter DMs.

 [00:17:30] SY: Wow! Okay.

 [00:17:32] RN: I really miss old school Twitter. It’s not what it used to be. We’re going to have to find a different way to network. So I DMed Dan and I was like, “Okay, Dan, I’m in Amsterdam. I want to work with great engineers. I want to go back to the front-end community. And also, I want to make React a place where people feel like they belong. And I want to make it so anyone, anywhere can get an amazing straight from the React core team education in React, no matter what their income level is.” Like 600 bucks for a course is just not attainable for people. And it’s like, “We got to democratize React if we’re going to make this truly the library of the people. We got to do something differently.” And Dan was like, “Hold my beer,” and talked to Tom Occhino, who is the director of the React org at that time. And they brought me in as a hybrid docs and developer advocacy person. Word to the wise, if you’re joining a big company, don’t join in a hybrid role. This is a lesson I learned the hard way. Eventually, you’re going to be asked to pick one. And I had the choice between picking documentation or developer advocacy. And the two orgs that I would have rolled up to would not have been the React org at that time. It would have been a docs org or it would have been an advocacy org. And at the time, the documentation org aligned more with my vision for having that scaling impact. React has many advocates in the community. It does not need an advocate from Meta, in my opinion. Actually, there’s a really great guy, Matt Carroll is actually really knocking it out of the park as the official developer advocate for Meta’s open source org. But at the time, the advocacy org was not the right place for pushing for the overhaul of the React Dev and ReactNative.Dev portals. I felt like having that outsized impact and community leadership was going to happen pushing those projects. So I made a career decision to have an impact. You’ll find that when you work in big tech, you might have a goal when you come in, a very set goal, kind of like that, and you have to choose whether you want to navigate around a career or navigate around having the impacts you came there to have. Like if you want to have a career at Meta, being a documentation engineer might not be the place where you’re going to have the most impact at Meta. Being a software engineer, I would actually say, is the way to have impact at Meta. If you want to have an outstanding career, engineering is like the best role to get not developer advocacy, not technical writing, engineering. Or if you don’t feel passion for engineering, but you’re very knowledgeable about the space, but you have more passion around, for instance, meeting user needs, product management. Even if you’re a designer, product management is still a very good role to strike into because you’re focused on the user, watching and observing the user, and it has elements of data analysis, et cetera. These are things you might be familiar with from user experience and design roles. So anyway, I was setting myself up to have community impact, not necessarily have a long and storied career at Meta. And that had been what I was intending to do all along, because Meta, it was a controversial company then. It’s a controversial company now. A lot of people were like, “Why are you joining that company? I thought you loved the open web, man. You’re bad.” [00:21:06] SY: Right. Yeah. It had a lot of problems in it. Still working.

 [00:21:10] RN: Still does.

 [00:21:11] SY: Yeah. Okay. So you ended up at Meta, you ended up on the docs team is what you ended up picking. And what was the impact that you were hoping to make? You mentioned kind of this safe space, helping increase generational wealth, especially amongst people who traditionally, historically don’t experience it. What were some of your big missions? What was the impact that you were hoping to leave Meta with?

 [00:21:35] RN: Well, I had two impacts I wanted to have. One, to bring more women into the React community and set them up for being thought leaders, for getting the spotlight. And I also wanted to democratize a React education, to take the knowledge that was locked inside the brilliant minds of Sebastian Markbage, Andrew Clark, and Dan Abramov, and get them out there for everyone. I worked on the React Native Team as well. And I got to tell you, I love the React Native Team. I think that was the best time I ever had working in big tech was working with the React Native Team. I bet hard on React Native. This was the first time I got exposed to mobile development communities, Android, iOS. And I learned that front-end development is not just about the web. It extends all the way out to pretty much any interface that needs to be implemented in code. And so this was just an exciting, like expansive journey for me. I got to go to React Native EU in Poland. It was wonderful. So anyway, the pandemic happened. It went big on React.Dev. Let’s talk impact. When I joined the React Team, I did this women of React scene where I went and interviewed all the women who were doing community management in the React community and women who were committing to core and working on the React teams. It’s a cute little zine. I still have a bunch of them, but I leave them in the bathrooms at React conferences when I go to them. And then when the pandemic hit, I organized Women of React Conf, and it was one of the very first online first conferences that came out after the pandemic, and it really spotlighted a lot of women in the community. I didn’t organize it myself. Nobody builds something like this in a vacuum. I went out and I grabbed Jenn Creighton, Sarah Vieira, Kevin Lewis, and we had so many cool people speak. There was like Shruti Kapoor, Pariss Athena, Sophie Alpert, Luna, Shubhie, Nicole Sullivan. There was a panel of The Future of React. Neha was there, and Talia, and Adrianna Valdivi. Oh my God, it was so good! Anyway, that project didn’t have the impact I wanted it to, even though I was including people like Sylwia Vargas in the Dev Portal project as well. One thing I think that happened over the pandemic we don’t talk about is that women’s leadership just disappeared off the board. I feel like there are even fewer women in React now than at the start of the pandemic that I can point to and say, “This is a thought leader.” And maybe that’s because the social networks might’ve changed. Maybe they’re all on YouTube or Twitch right now. But I do think that we saw a pattern during the pandemic of, at least when I was organizing that conference, I noticed originally the set of people who’d confirmed they would speak. Half of them bowed out because they had to pick up the slack at home and it was too much.

 [00:24:34] SY: Yeah.

 [00:24:36] RN: But on the documentation side, I have more of a success story. I think I learned from Women of React, like, one person cannot change a community. You cannot change who is a core contributor just by sheer force of will. You can set up the events, but you cannot change the impact that a pandemic is going to have on the roles that women serve in their households. You can try. And I’m sure that the work that I did did help raise awareness, and I know it for a fact that it helped some people get very good jobs, but I think that the work on the documentation probably had the impact I was looking to have.

 [00:25:16] SY: And what was that?

 [00:25:17] RN: Well, on both sites, React Native and React.Dev, I installed metrics to see how successful people were and how much they were getting out of the documentation. And if I recall correctly, lifted the positive sentiment score of both of them by about 70%. So, of course, docs are an investment you have to make over and over again. I’m not sure if those numbers, at least for React Native, are still there. It’s hard for open source products that don’t have an active and dedicated writing team, like Astro does, shout out to the Astro team and the work that Sarah Rainsberger is doing to organize the community to write those docs. Amazing. But with React.Dev, we pushed to beta. I remember really pushing hard before I left for us to release the content because people needed it so much and I knew it would take another year before it was completely ready to take over from the original reactjs.org, but the beta site did launch and it was in beta for about a year and impacted about eight million developers around the world. It got people from zero to hello world in less than 10 minutes because we got interactive sandboxes on the site. So people weren’t thinking about setting up their environment. I mean, how many of us are going to start a job and be working on setting up a React project from scratch? No. You’re going to be working in someone else’s code base. You really need to understand React more than how to set up the code base. So we focused on that. I worked on adding illustrations, basically like building out this long curriculum with Dan Abramov. It was really great and had collaboration from people like Sylwia Vargas to make sure that all the examples, you might not notice this, but all the examples are completely culturally neutral. Usually you’ll run into like cats and Star Wars, and these things are very Western. Cats are cool animals in all cultures. It’s kind of an American/Western thing to be obsessed with them.

 [00:27:21] SY: I know that.

 [00:27:22] RN: Yeah. I knew that from Booking, like you can’t use animals and advertising consistently with every culture in the world because there’s no animal that has the same message in every culture. And so you’ll find that they focus on kind of the joys of humanity, culture, cooking, monuments, cities. So I did everything to make the documentation as engaging and accessible as possible, writing an international tone, for instance, that it would be more easily translated by machine until the translators could get there. I have so many learnings from this. I could keep going, but the feedback we got from the community is that the docs are a major improvement and that they are doing their job and helping people get that free, excellent education in React.

 [00:28:11] SY: That’s beautiful. That’s such a great mission to have. And I think that there’s lots of causes that we all care about just as individual people, but it’s not necessarily easy to find an opportunity to pursue those causes and to try and make a change. And it’s really great that you had the ability to get paid to see the impact that you want to see in the world.

 [00:28:33] RN: That is, I think, the ideal, is when you’re going into these big companies, if you can get paid to have that impact and put on the corporate mecca suit, it’s amazing. It’s an amazing opportunity. But you don’t always have those opportunities. Most big tech jobs implement this feature on a team, herd this cross organizational conflict toward a conclusion. They tend to be very implementation based. You might call them political, but I would say understanding humans and making trade-offs and convincing them to do things that are in the best interests of all parties. And that is a skill that you can learn. Some people are better at it than others. So big tech jobs aren’t always what they look like. They are fetishized, but they come in many different varieties, and they have many different challenges.

 [00:29:25] SY: So tell me what it was like to work at Meta, just as an employee, as another big tech company. Did they move fast and break things like they claim? Or what was it like?

 [00:29:36] RN: So one thing you have to remember about big companies is that they contain multitudes. So they always say whenever you’re talking to somebody about like, “Yeah, I joined this company and I had a great experience or a bad experience,” and you’re talking with somebody else who’s also been at that company. Invariably, what you both end up saying is, “Yeah, well, it really depends on where you land.” [00:29:58] SY: True.

 [00:29:59] RN: And that’s a way of saying some orgs have leadership that’s going to jive with you better than other orgs. Maybe you’re a person who likes to make numbers go up and to the right. You’re going to do well in an org that really cares about the bottom line and has leadership that cares about the bottom line. Or maybe you care about doing right by the community. Well, you got to look for those charismatic leaders who are doing right inside these large companies and really guiding it towards doing the community thing that’s good for everyone. That takes a very persuasive and powerful leader to do that amidst KPIs and bottom lines. Negotiating resources is something that leaders have to do, and that’s what you want to look for in a leader.

 [00:30:41] SY: Absolutely.

 [00:30:42] RN: But you really don’t know until you get there, what kind of an org or team you’re going to land in. I have tried many times to sort of figure out, set myself up for coming in on the right project with the right people. And in the end, you just got to jump and find out.

 [00:30:59] SY: And hope you made the right decision. Hope it works out in your favor.

 [00:31:03] RN: At Meta, I was very fortunate because leadership made a beautiful umbrella for open source to operate under and allowed the React team to do what was right by the community. I think this is still evidenced in the way they engage with the community and have invested in, for instance, Matt Carroll, the developer advocate, and continue to invest in, for instance, the React Native communities as well.

 [00:31:28] SY: That’s really beautiful. That’s really great. Coming up next, Rachel talks about their final big tech role and why they’ve decided to take a step away from it and turn back towards the world of startups after this.

 [MUSIC BREAK]

 [00:31:54] SY: So after Meta, what happened next?

 [00:31:57] RN: Well, after Meta, the pandemic was coming to an end. And once again I felt like I’d done what I could for the docs. The project was on Rails and it was time to go see where I could have more impact. And I had an opportunity to join AWS as a technical program manager and build a documentation team or a developer education program for AWS Amplify. And I did that for a year. I was a principal technical program manager there, which was really exciting. Technical program management is sort of managing without having direct reports type role. You can have technical program managers reporting to you. This is kind of how big tech works. You don’t get to manage teams of people who have different job titles. For instance, you’re not going to manage a designer and an engineer. They’re each going to have their own design manager and engineering manager. A technical program manager is somebody who puts together the strategy and the programs that these people come together on. For instance, creating a plan about how to organize amplifies, microsites, and 916 pages of core documentation into one developer hub. That’s something that a technical program manager could do, as it doesn’t really fall under the ownership of the design team or the technical writing team or the product team. So that was the sort of role that I took on there. And I think that marks the end of my journey with big tech.

 [00:33:28] SY: Wow!

 [00:33:29] RN: I am now going back into startups.

 [00:33:31] SY: So how many years was that in big tech?

 [00:33:34] RN: I think it was about six years.

 [00:33:36] SY: Six years. And now that you’re going to startups, are you relieved to be done with that adventure? I know you said you kind of spent five years immersed in a new thing that you’re really into. Was that kind of that immersion and now you’re ready to move on or how do you feel about your time there?

 [00:33:56] RN: I learned a lot. I learned a lot about what it takes to succeed inside these large companies, but I also know that I like to move very fast and I’m very community oriented and those particular skills that I excel at. They say instead of trying to make yourself better at the things you’re not great at, you should go all in on the things you are great at and excel at them. I excel at things that involve growing communities, teaching people, et cetera. And I was the happiest in the three years I spent at Meta because I got to play to those strengths. And it’s easier for me to play to those strengths at small companies that are growing their communities, that are teaching the world about their product that want to have an opinion at the table at standards bodies about whatever it is that they’re diving deep on. And in that regard, I’m probably going to be more satisfied over the next couple of years, working for smaller companies that are actively pursuing those things while bigger companies are sort of pulling back from those as nice to haves. We’re in an interesting situation with the tech scene right now. And so I’m not saying I’d never come back to big tech. I might. I certainly learned how to make sausage, but I think right now my skills are best served in smaller startup situations. But if I saw the right opportunity, sort of like another opportunity to do what I was doing at Meta, I would take it. Probably. The best thing about working at big tech, that sounds so mercenary when I say this, is going to be the money. If you get in there and find out you love it, the money is life changing. It will take you anywhere you want to go. It’ll let you do anything you want to do and take care of the people that you love. And it’s completely reasonable to aim for a big tech job in that regard.

 [00:35:52] SY: Was it what you expected when you thought about the idea of working at a big tech company? What was in your mind? What did you think it was going to be like and how did it compare?

 [00:36:04] RN: You know, my experience with big tech was I’d only ever really met and talked with their developer advocates, the Chrome Dev Advocate team, and some of the PMs on Chrome. Here and there I’d meet someone on Safari who was working on specs. And I thought it was going to be, like you come in and you drive specifications and you do what’s right for the community and the customer. And I came in and found out that it’s a lot more do what is right for the company. And I don’t think it was that way at Meta, to be honest. Meta, I didn’t get that vibe at all. But at other companies, it really is a business. It really is a company doing things. A lot of people think, “Ah, the Chrome Developer Advocate Team, Chrome does so much because it loves the users.” It’s not true entirely. Yes, the developer advocate team loves the community that builds for the web. But you have to remember that somewhere there’s a VP that’s strategically investing in Chrome, not out of the goodness of their hearts, but because there’s a reason to invest in Chrome. There’s a reason to drive the specs and be the dominant power getting APIs pushed into production. And you have to remember that whenever you’re thinking about joining a big company is that you might just be the cool person working on the floor at conferences and telling people how great X, Y, Z is and how much the company’s mission is altruistic, but eventually you’re going to find out why the company wants to do that. Now the interesting thing about the React core team was there was no ulterior motives up the chain. React was an outgrowth of an infra project. And that was amazing because it was the most academic project I’ve ever been at, at a big company. And you can find projects like that in R&D orgs, for instance. But always keep an eye when you’re joining. What is the ultimate goal here? What is leadership hoping to get by investing in this? And then you have to ask yourself if you’re okay with that.

 [00:38:13] SY: Any downsides to working at big tech that you’re comfortable sharing?

 [00:38:19] RN: Well, I mean, it depends on which big tech company you’re looking at. Amazon is known for you have to set boundaries with Amazon or else it will take whatever you give. It will never ask less of you, for instance.

 [00:38:31] SY: Right.

 [00:38:31] RN: Microsoft, I learned there, for instance, there’s a strong tendency for product people to pass on lists of requirements to engineers. So as an engineer, you might like that. You’re kind of getting requirements given to you rather than creating the requirements yourself, which is more of a Meta thing. You really have to ask about the culture and figure out what you want, because they’re a little different in each of them. And if you go to a company like Microsoft and you expect to be able to do whatever you were doing at Meta, having that kind of engineering-led approach, you might find yourself frustrated. So you really have to pay attention to how are these companies set up. Is it engineering led? Or is it product led? Or is it marketing/profit led? If you don’t do that bit of research, you might find yourself frustrated where you land. The downsides also are that it’s a little bit more groupthink, which can be a pro or a con. If you have a great idea for a splash page, you’re going to have to get that passed through marketing, you’re going to have to get design sign off, et cetera. And also things move slower just by the nature of the beast, which is why slogans like move fast are kind of, well, they feel a little disingenuous at this size because you can’t move fast when you have five different orgs that have to sign off on something and all these different moving parts. So if you are a Speedy Mcspeederton, you might find the slower pace to be frustrating, or you might want to look for like a role in one of the more R&D type places or a small startup-type program inside the company where people are allowed to iterate a little faster.

 [00:40:20] SY: Absolutely. I’m curious how you felt about working at two companies specifically, Meta and Amazon, that are a little controversial to work at that have not great histories with the public and have done some shady, some questionable things in their past, and frankly, in their present. How did you deal with that? How did you feel? Did you experience any cognitive dissonance or any reluctance? How’d you think about that?

 [00:40:48] RN: Well, I know I lost some friends when I joined Meta, but there I really did feel that the greater good was the thing to focus on. Meta gains nothing from React being popular. In fact, it’s more of a sink for them than anything else. Community management is not something that it wants to spend money on. So it doesn’t. And so the React community manages itself, which is problematic. But then again, it could be problematic if Meta was managing the community. Some companies do manage their own community and they don’t do it well. So maybe it’s just as well that the React community remains self-determining. But for me, I always felt the greater good overruled any misgivings I might have about joining Meta. And I did get to go in and see inside the company, which was actually pretty enlightening. Of all of the FAANG companies, I feel like Meta is the most unintentionally harmful.

 [00:41:46] SY: Oh, interesting. What do you mean by that?

 [00:41:48] RN: Well, engineers don’t always think about the consequences of their actions. If you have a strong engineering-led company, you’re going to see a lot of engineers walking into things that maybe a product management company or company with strong lawyers overlooking every different project would say no to. And they will get there as they get older. Microsoft already learned all of those lessons in the ’80s. Every big company goes through that. But for me, I think Amazon was the bigger challenge. But you have to remember Amazon also helped me get here as a kid because I didn’t have access to programming books growing up in the middle of nowhere. My library didn’t have them, the bookstores didn’t have them, and Amazon delivered them. They sent them to me and that’s how I got here. And so I wanted to understand more about how Amazon came to be. I wanted to get what they call the two-year MBA from the dog years you get working at Amazon. I knew very like most people leave Amazon within 24 months. I think there’s some metric that’s publicly available about that. It’s common knowledge, not most people. I don’t know exactly how many, but the point was you have to go in knowing this might not be for me. The stories that I’ve heard might be true for people working on the infrastructure just as much as the people working in the warehouses. And you have to go in with your eyes open, and I did, because at that point I’d seen Microsoft, I’d seen Meta. I was kind of like, “All right, so what’s this one about?” I was going to try to do Netflix and Google too, so that I could sort of speak to the differences between all of them. But honestly, I think I’ve run out of steam.

 [00:43:33] SY: So for folks listening who would love to work at a big tech company one day, would love to work at a Google or a Meta at some point in their future, what advice do you have for them on how they might have the kind of career that you’ve had?

 [00:43:46] RN: Gosh, I wouldn’t know if I’d recommend anyone have the career that I have. I don’t think you could reproduce it either. Sliding into DMs and being like, “I want to join this specific team. Would you let me do that? Would you let me?” I would say a good thing to do is to think about, like, do you want to be, and first off, if you’re thinking about being a developer advocate, that is the one thing I recommend you not come to these companies as being a developer advocate means in some ways having less of an opinion than you can have as an individual contributor. Because you’re public facing, you can’t really speak your truth. Whereas as an individual contributor or a manager or a director, you can have more opinions and influence company culture more where you’re not going to be able to talk trash about, “I don’t agree with this hiring policy,” in public as a developer advocate. I mean, these companies, developer advocates tend to take on more of a salesperson role, and that can mean sacrificing more of your individual personality, ethos, and opinions to give the spiel and the banter on the conference floor, or to give the talk on the spotlight at the big Microsoft conference every year, which are the goals that these folks are living for a lot of the time. So I actually recommend going in as either an engineer or product manager. And for engineers, there are many reasons, great benefits, great pay, ostensibly even better work-life balance than you’re going to get at a startup, especially if you can put up boundaries at some companies, but the thing you will have to know is that the bar is pretty high. You do have to practice to get in. You’re going to expect to practice for at least six months of interviewing. You’re going to want to LeetCode if you’re an engineer. I recommend you should always be LeetCoding if you’re an engineer with your eyes set on FAANG. You should try to like do one problem a day with friends for a substantial lead period instead of cramming. Don’t put yourself under pressure to like, “Oh, I’m going to cram and LeetCode for a month.” You’re setting yourself up for a lot of heartache. You want to make it a slow burn. You make LeetCoding and pair programming and peer reviews a daily part of your intake. Think about your stars. When you’re finishing projects and you’re working on projects, keep a little file where you think about how you want to frame this to tell your story when you’re interviewing. All big companies use the STARS framework. Go Google it. It’s really easy. Also, the Cracking the Coding Interview book and the Cracking the PM Interview books, they will tell you all about the differences in the different hiring processes, the interview rounds, et cetera, at these big companies. Practice at some medium to large companies that you’re not set on. Just like when you’re applying for colleges, you got to have your backups. You want to start with them.

 [00:46:41] SY: Your safety schools. Yup.

 [00:46:42] RN: Yup. You start with them and then you work your way up to the big guys. Tell yourself, “I’m going to be interviewing this month at these companies. I’m not serious about them. I’m not going to accept any offers.” You practice negotiating on those offers and you’ll never know. You might actually find out you prefer the mission and the people at one of those, and they’ll make you a really sweet offer because you’ve been negotiating on it like your life doesn’t depend on it. And you might surprise yourself.

 [00:47:10] SY: Yeah. Absolutely. Well, thank you again so much, Rachel, for joining us. This was really enlightening hearing your stories about big tech. Thank you so much for sharing your experiences with us.

 [00:47:19] RN: Oh, thank you so much for having me back, Saron. And I hope the next time we talk, I get to tell you all about startup life in Europe.

 [00:47:25] SY: Absolutely. Sounds good. You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.

 [END]

Thank you to these sponsors for supporting the show!

Thank you to these sponsors for supporting the show!