Pod Insights The Peterman Pod Tech Lead for Meta's Most-Used Programming Language (Promotion Story) About this episode Dwayne Reeves is a Senior Staff Engineer (IC7) at Meta who is the Tech Lead of the most used programming language (Hack) at the company. He started at the company as a new grad from MIT and shared the story of how his career grew. We discussed:
• His promotions to Senior (IC5), Staff (IC6), and Senior Staff (IC7)
• The value of type systems
• Transitioning to a TLM and why he switched back
• Working with brilliant engineers and overcoming imposter syndrome
• Advice for his younger self
Timestamps:
(00:00) Intro
(00:39) Joining Facebook
(04:52) Did MIT help with career?
(07:13) His first team
(10:37) Why static typing is superior
(13:17) The uncanny valley of type systems
(16:11) Senior Eng (IC5) promotion story
(19:24) Staff Eng (IC6) promotion story
(23:38) Manager transition story
(28:57) Managing ICs vs EMs
(32:54) Senior staff Eng (IC7) promotion story
(35:42) Impressive ICs
(40:33) Why stay at Meta
(44:28) Advice for younger self
(45:46) Outro
Where to find Dwayne:
• LinkedIn: https://www.linkedin.com/in/dwaynereeves/
Where to find Ryan:
• X/Twitter: https://x.com/ryanlpeterman
• LinkedIn: https://www.linkedin.com/in/ryanlpeterman/
• Threads: https://www.threads.com/@ryanlpeterman
• Instagram: https://www.instagram.com/ryanlpeterman
• Newsletter: https://www.developing.dev/
Transcript Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.
0:00 Speaker 00 Writing code is not what my job as a software engineer is. My job is to-
0:04 Speaker 01 This is Dwayne Reeves. He's a senior staff engineer or IC7 at Meta who joined the company as a new grad from MIT.
0:12 Speaker 00 Those promotions were kind of a surprise for me because-
0:14 Speaker 01 He shared a bunch of lessons he learned the hard way getting to that level.
0:17 Speaker 00 I was having the worst half I ever had at the company and I was really upset.
0:22 Ryan Peterman? What's the story behind you becoming a manager?
0:24 Speaker 00 You know, one of the things I had to get used to as a manager is-
0:28 Ryan Peterman? If you could go back to yourself and give yourself some advice, what would you say?
0:34 Speaker 01 Here's the full episode.
0:38 Ryan Peterman? Thank you, Dwayne, for coming on. I really appreciate your time. You know, today I kind of wanted to go over your career story. I feel like there's a lot of interesting stuff because you started at Facebook when it was Facebook and, you know, pre-IPO and all of that. So, all right, well, let's start at the beginning of your story. I see that you started at Facebook right out of college and you went to MIT. I'm kind of curious, were there other offers that you were considering? And what was the story behind you joining Facebook?
1:07 Speaker 00 It's actually an interesting story because I really wasn't interested in Facebook, to be honest. I was like really interested in Google and Twitter. Twitter because I was a big fan of Scala as a programming language and I know they use that at Twitter. And Google because I grew up on the East Coast and they had offices in Boston and New York and Facebook didn't at the time. Why I ended up interviewing for Facebook was actually as interview practice. I had a friend who was working at Facebook and he was trying to- he joined, I think, back in 2007, actually. And he was trying to convince me throughout my time to come for internships or other things. I was like, ah, I don't really know. I don't, I don't see myself going to California.
1:52 Speaker 00 And he was like, finally, hey, this will at least be good practice for your Google interview. So I was like, sure, let me do it. So I did end up interviewing and ended up making to the final rounds. And when I actually got on campus, my whole viewpoint kind of started to change and open up. Just being able to talk to actual- Engineers and the kinds of problems they were working on. I was, you know, obviously a user of Facebook, being a college student at the time. And it was hard for me as someone who is kind of interested in more core CS problems. Of like, oh, Facebook's just a website. What is there really for me to do? And when I actually got on campus, hearing like some of the problems they had to solve with Memcache and just how to scale up a system like this.
2:35 Speaker 00 Hearing things around how they optimize PHP by having their own custom runtime for it. All these things made me realize like, oh, they're actually doing some real engineering work here. That got me pretty interested.
2:48 Ryan Peterman? And I mean, I imagine at Google, they're also, you know, they were obviously doing real engineering too. So what was the thing that made Facebook really stand out?
2:58 Speaker 00 Yeah, uh, well, I understand they actually gave me an offer. But I think, I think overall, the other thing is like, it's just the level of care I felt from like they, they really wanted me. And they showed it in, uh, sometimes not so subtle ways. Two things that come to mind. One was when I got my offer, it was the best offer I had. I think I didn't, I didn't end up getting an offer from Google. I did have an offer from Amazon, you know, I didn't accept right off the bat because I needed some time. I said, hey, I need some time to mull over my offer. And a week later, I got a email out of the blue from my recruiter saying, hey, we just increased your offer. I was like, oh.
3:38 Ryan Peterman? Oh, wow.
3:39 Speaker 00 Yeah, I was like, wow, I didn't even ask for this versus like Amazon. I like talked to the recruiter and they're like, yeah, we don't negotiate with new grads. You just take what you give you. The second thing is, at the time, I remember, I think I had already decided to join Facebook at that time. But, uh, there was something where the CTO at the time, I think Brett Taylor, he actually came to MIT's campus and took all the new grads that were accepted and like took us out for, um, like lunch. Like a local cafe to like talk with us. So all these interactions, I was like, wow, I couldn't imagine any C-suite level person at Google or any of the other companies I was working at actually taking the time to talk with us personally. So that really felt, uh, special.
4:24 Ryan Peterman? Because they were smaller, they're able to do that more tailored recruiting. What was like the rough size of them? Just to give people a sense of like, is this startup? Or is it kind of like growth stage?
4:35 Speaker 00 Yeah, I think at the time, it was probably between a thousand to fifteen hundred employees. So not small, but also, well, given we're like, I think a hundred times bigger now. It's, it is small. It's all relative, right?
4:52 Ryan Peterman? Yeah, hearing that you went to MIT, it's not controversial to say that obviously is a big leg up when
4:59 Speaker 00 Definitely.
5:00 Ryan Peterman? You know, interviews and kind of, you mentioned one of your peers like had already been working at Facebook. But one thing I'm curious, now that you have all this experience in the industry, how much of a correlation is there between maybe the prestige of the college you went to and a career success?
5:19 Speaker 00 I think very little of it has to do with the actual education piece you get at different universities. Like my education at MIT was fantastic. There's a lot it taught me. I do think that's valuable and immensely valuable. But I've also met lots of engineers who I work with who, some of them didn't even go to school.
5:39 Ryan Peterman? Right?
5:40 Speaker 00 And so the thing I really know for sure was a big differentiator between me and them was, I just had more opportunities because MIT had this name recognition that, you know, for my freshman year, I was talking to recruiters from any tech company. They would always come to a career fair and be willing to talk to me just because of the school I went to. Versus others, engineers I work with, is it was almost just by chance that even got on Facebook's radar. And they were just as capable of engineers as me, but just because of, I guess, a different path they took in their career, they very easily could have not ended up at Facebook, which would have been a huge loss for the company.
6:23 Ryan Peterman? It definitely increases the opportunity and chance, like those kinds of
6:27 Speaker 00 Yeah.
6:28 Ryan Peterman? elements of it.
6:29 Speaker 00 Yeah, I mean, I remember my freshman year, I had an internship from Microsoft. And almost that alone was enough for me to get a internship offer from Apple as well. It was just kind of crazy because I remember, you know, I grew up in Bridgeport, Connecticut, growing up in the inner city, going to public school, you know, child of immigrants. Like, working at companies like Apple or Microsoft was like the dream. Like, I never thought real people actually worked there. Immediately going from that to, oh yeah, there's recruiters here and they actively want me to work with them was not anything in my head I would have even imagined being the case. But MIT was just normal for the students there.
7:13 Ryan Peterman? You joined Facebook, you got the offer, they kind of, you know, sold you in. What was the thinking behind joining a team like that when you entered Facebook?
7:22 Speaker 00 We were looking at developing kind of like a service that was meant to evaluate some pieces of code and move it outside of the main PHP code base because PHP was seen as like not a great language to develop in. So we were like, yeah, we can, if we use this new language we develop, we can do some computation closer to the data stores and all these ideas. You know, this will help efficiency and all these big dreams. Honestly, this was something like, it was not a team on my radar at all. But they reached out to me because, well, maybe my resume, they thought I would be interested. And that was like, I think, one of the great, like, first times of actually trying to do something language-related.
8:06 Speaker 00 Where, for the most part, all I was doing was trying to translate PHP code into their own custom DSL that they were developing. But by, I was on that team for maybe two years and by the end of it, I was actually trying to develop new features for this language. Ultimately, that project ended up getting canceled. Then I started working on more things related to privacy infrastructure and how do we find ways of representing privacy policies and rules in a easier to manage way than just simple if or else statements.
8:44 Speaker 00 And I did that for a couple of years. At that time, Hack was introduced to the codebase. And we were kind of the newest framework that like decided, hey, we're going to go all in on using Hack and types, which is what I loved because I grew up working in statically typed languages. I just thought they were superior. So PHP was always weird.
9:06 Speaker 00 And after that project, I was trying to figure out what I wanted to do next. And there was this opportunity of kind of different parts of the codebase. And all that was written with PHP was not typed in Hack. And I was like, I could make an attempt of trying to type this using Hack. So it was meant to be like, I think, a week or two project. It ended up taking a whole quarter. But it was very rewarding because it allowed me to interact with the Hack team a lot because they're anxious of like interested in having more people use Hack in codebase. And I was trying to do something which honestly no one else had attempted at the time of
9:47 Speaker 00 how do we take a very core piece of API that was not designed to be typed? And how do we actually go about doing that? And there's a lot of hacks, a lot of bash scripts, a lot of ingenuity, I guess I would say. So the end result was after I completed this migration, about 20% of the call sites, they're moving it to the Hack API, discovered that there is some kind of error in the code, usually around how it handled null types. This was kind of like, I view as like one of the big results of like, hey, Hack is not just this cool tool. Like it's actually finding mistakes in the codebase at scale. And I feel that is really what started to have Hack be taken a bit more seriously.
10:32 Speaker 00 It's like, hey, should we be more aggressive in terms of replacing PHP with Hack?
10:37 Ryan Peterman? You mentioned dynamically typed, statically typed. Are statically typed languages objectively better than dynamically typed ones in industry code?
10:46 Speaker 00 It's subjective, but I think a lot of evidence points to, yes, they are superior. Particularly in the ways to think about it is particularly if you think about the problems we face at a company or codebase at the scale of we develop here at Meta or any large industry. It's like, it's more of like a information communication problem where as the size of a codebase grows, the more you have to keep in your mind of the context of like, well, this code is meant to do this and this code is meant to do that. So if I change it, this is how it needs to work. It starts to break down as you have more people who are working in the codebase and the size of the codebase grows, that you just naturally need tools
11:29 Speaker 00 to help you manage that. And type systems just happen to be an effective tool for communicating intent. Maybe there's cases, if you're just a hobbyist and you're working on your own and you could just keep everything in your own head, yeah, you could probably move faster with a dynamic language. At the scale we operate with, where you, even if you get like 100 engineers, like you need something that helps you communicate ideas and keeps track of that. And that's where I feel types really help. Types also help with tooling, right? So you have all the complete, it helps you search the codebase and all these other things beyond just like given errors that it provides value in. It's not surprising,
12:10 Speaker 00 you see even for dynamic languages, most of them have some form of optional types, at least for that reason alone.
12:18 Ryan Peterman? I guess some of the obvious advantages are it brings more of the state or what we're trying to communicate explicitly written into the code via the types. And then also because of that, tooling and various static tools can traverse that and provide value to us. So that's a big value add for industry code. Is that right?
12:41 Speaker 00 Yeah. And it's actually kind of incredible to think about that you write some text in a file and because you write it in this way, that we have developed ways of proving that, hey, this, this text you've written does not exhibit these classes of errors at all. And you could just rely on it. And that's really powerful, right? And it's, you know, one of the, I think, main achievements we've had in the space of computer science.
13:10 Ryan Peterman? Definitely, like formally verifying that this bug cannot happen because of those types.
13:16 Speaker 00 Exactly.
13:17 Ryan Peterman? In my research and kind of, you know, studying some of the type migrations, I think you mentioned before, like this uncanny valley of type systems. I'm curious, can you explain what that phenomenon is and what you mean by uncanny valley?
13:32 Speaker 00 I grew up playing video games, so this was a term I learned in that space where from there it's from more like, if you have computer graphics, as you try to make something look more human-like, in general, you feel better about it, like you feel more connected to it as it starts to look more human. But then it gets to a certain point where it's almost human-like, but it's off in subtle ways. And all of a sudden, you get kind of put off from it. And maybe you're familiar with this term. I feel the same thing will happen in terms of as you move from dynamic languages to static languages. And the reason I felt this way is at the time, people only worked with dynamic languages or only fully, fully statically typed languages.
14:16 Speaker 00 And did that necessarily have the muscle, like memory or like weight trained in their brain? What does it mean if I have a type? It actually is not correct. And as you add more and more of these, the, the places where the types actually aren't doing what you would expect in a static language that exists, the more off-putted it will feel. And so that's how I came up with that concept, right? Was comparing this to how it applies to the space of graphics, human, human graphics, and trying to make a similar analogy to communicate this point. And it proved to be really effective way of contextualizing the problem we were trying to solve on the hack team at the time.
14:57 Ryan Peterman? In the process of migrating to a fully statically typed codebase, that last bit, actually things start to get worse because you're almost there. And so the, the bugs that come are much more subtle and the behaviors are much more subtle. And it's actually worse for a bit, till 100%.
15:14 Speaker 00 Yeah, and I think there's even something particular because we were, you know,
15:20 Speaker 00 The foundation of the language was PHP was that at the time, there were certain behaviors PHP had, which were incompatible with trying to make a sound type checker for. And there were some questions at the time of like, well, should we keep those behaviors? Or should we get rid of them? And I think my post was more making the statement, we should get rid of those behaviors. Because if you have a language, even if you had everything typed, the fact that the types can't be relied upon because of these subtle behavioral differences, then that will be a problem or will create a less than ideal state for development. So I think that's it's also some of it is, you know, because of PHP
16:03 Speaker 00 and some of the peculiar decisions they made of how their runtime would operate.
16:09 Ryan Peterman? I see, I see. That makes sense. And so in your time as an IC, I know you eventually transitioned to management.
16:15 Speaker 00 Yeah.
16:16 Ryan Peterman? So you must have had some promotions and things that helped your career grow. Are there any stories, like particular times where you felt like, okay, that was a really good learning experience and helped you grow as an IC?
16:28 Speaker 00 Yes, two, two of them come to mind. So one was when I got promoted, yeah, as a senior engineer. I kind of mentioned earlier about this project I worked on of trying to create a hack API for the, for the N's framework. So since that went well, I was asked to, hey, can we do this at a, at a larger scale? Like, can we move more code from PHP to hack? And so I ended up spending a, a half doing that. And at that time, up to that point, my idea of what value I gave to the company was 100% based off of what code I was able to output. And so when I started this, I was talking to so many people.
17:14 Speaker 00 I was like giving ideas to the hack team, giving ideas to other engineers with the work on. That had almost no time to actually write code myself. And because of this, I felt I was having the worst half I ever had at the company. And I remember like having a conversation with my manager about. About this and she was like, you know, it's important that, you know, you're doing the right thing in terms of talking to other people and getting them involved. But you should find some time to write some code on your, on yourself. And I don't know if she talked to her, her, her, her manager afterwards, but like, I think the next one on one, she was like, yeah, that thing I told you, that's actually wrong. Like, keep on focusing on just what the end results were.
17:53 Speaker 00 And for me, the thing that really connected is still at the end of the half, I thought that I was like, yeah, you know, we had some results. Yes, we increased the amount of hack adoption or coverage from like, I think 20 or 30% of the code base to like 60 or 70%. Now like hack felt like it was a fixture in the company. Like people weren't really looking to write PHP first. Everyone was starting to write hack first. So I felt like I had good results, but again, I wrote the least amount of code in my career so far. So I wasn't sure how that was going to play out in terms of my performance review. And the thing that really connected was like, oh, actually that was the highest review I ever got. I ended up getting redefines that half. Wow.
18:38 Speaker 00 And I got promoted to IC5, which I wasn't even in the conversation because I was like, oh, I'm not writing enough code to even justify that. And it really solidified to me that writing code is just, is not what my job as a software engineer is. My job is to identify and solve problems. Sometimes that's the best way of doing that is writing code. Sometimes it's me bringing clarity to a problem and a path forward for how to solve it. And if others end up writing the code, then that's fine. So that's something I think was a pretty big mind shift there of experiencing of like, okay, I don't have to be the most efficient, you know, coding machine out there.
19:19 Speaker 00 Right. There's other ways I could add value. So that was definitely one of the, one of the pieces. And the second one was also, I guess, what led to my promotion to IC6. So after that half, right, I just explained, I was actually joined the hack team. So I wasn't even on the hack team at the time. So this was started in, I think, 2050.
19:40 Speaker 00 Fifteen, I joined the team. They said like, hey, you would be the tech lead. I have no idea what that was. And most of the engineers who were on the team before, they ended up leaving. So it was like me, another engineer I brought on the team who I worked with before, and like a new grad hire. And we were like, this whole system we are now responsible for. I quickly struggled for a few years trying to understand what was my role as a tech lead. You know, I was comfortable that my output didn't necessarily need to be related to the code I wrote. But I still felt like I was responsible for seeing the outcomes end to end. So one of the things I worked on was trying to redesign how our
20:23 Speaker 00 collection system work, arrays and stuff within Hack. And I spent all this work on the design, spent a whole year on it, convinced our runtime team to implement it. Started with the implementation and started to roll in. We had some people join the team. And I was like, all right, here's my, you know, project to get me to IC six is trying to complete this. And I remember my manager telling me, okay, Dwayne, I actually want you to work on something else. And I was really upset because I was like, why, why are you telling me to work on something else? This is my project is up to speed. Why do you want me to do something else? And this is my path. And he was saying like, and he gave this analogy, which is really interesting. It's like, think of what you're doing. It's like you're like a rocket ship.
21:05 Speaker 00 And like there's different stages as you are firing and like, you know, you have the initial set of like engines that are meant to like leave the orbit, right? But once you escape the orbit, there's like other jets that can fire. And he was like, I only cared about you getting us out of orbit. Now that we've done that, you should pass this off to someone else. And now you can find something else to do instead. And he wouldn't let me leave the one on one until I agreed to do it. And, you know, I passed this on to another engineer and I was, I don't even remember what I was focusing on. But I remember, you know, the half ended and again, I was like, okay. Well, I did that. So let's talk about, you know, what my path for six to be is like, oh, actually I just got you promoted. So congratulations, you're now.
21:50 Speaker 00 Six. So in both cases, like those promotions were kind of a surprise for me because I had a mismatch between what my expectations in my head of what I needed to do to perform at the next level versus what in reality was important. And each time it felt like being okay with having less direct control on the outcome. And the real important thing I did was just aligning what the right strategy and what the right problems were in the first place.
22:20 Ryan Peterman? A lot of more senior ICs, the value is they come in, they figure out what's important to solve, why, you know, get all the alignment. And now there's this, it kind of like the, you've left orbit at that point.
22:32 Speaker 00 Yes.
22:32 Ryan Peterman? This is something everyone's interested in. Then you hand it to someone who's great at, you know, getting it done. And so it, and it's cool that your managers were proactive and driving your growth. It's because it sounds like you weren't really eagerly involved and figuring out, hey, what do I do to six and, you know, scale myself? Okay, I'm going to go scale myself. It's almost like you begrudgingly did the things and they were coaching you and you just got promoted as a byproduct.
23:00 Speaker 00 Yeah. Uh, you know, it was also a bit early at the company. So some of it was like, probably they are willing to move faster, like, hey, Dwayne, we, we see the potential in him. Why like hold the promotion for another half? Having a strong relationship with your manager is the thing I see most consistent in like my career. Whenever I felt disconnected with my manager is when I felt most frustrated. The times when I felt most connected is when I felt I was doing my best work.
23:28 Ryan Peterman? And I, I think I see that, that through line in a lot of people's careers, like almost everyone who has had success, they had a good relationship with their manager. And so speaking of management, I know you eventually transitioned to, you know, being a manager. Curious what made you want to try management? What's the story behind you becoming a manager?
23:48 Speaker 00 It's interesting because it's kind of, kind of similar to how I ended up at Facebook. It's like, I, I didn't want to be manager. It was not a part of my career plans. The team was at this point growing rapidly. And you know, my manager at the time, he was like, hey, we need more managers on the team just because of the growth rate. Here's an opportunity for you and we could either try and find another manager externally or you can give this a shot. And I said, no. And the next time I met him, I heard about the T L M role, like tech lead manager. And I was like, oh yeah, I could do some coding and maybe a little management. This might be a nice transition. And I mentioned it to my manager and he was like, oh, you don't want to do this. I was a T L M at another company. It's like you're doing two jobs.
24:32 Speaker 00 I I wouldn't recommend this as a manager. So I was like, okay, that's fine. I won't be a manager. And I think he probably talked to my director because he came back the next one on one. He was like, actually, yeah, we should, we should try this. You could, you know, be a T L M or whatever you want, you know, just try this management thing. And since I, you know, was starting to get more comfortable with like delegated and I was like, okay. If I'm still technically evolved, so I could try being a manager and still have some technical influence on the team. And for me, the main decision around like that point in my career was there's so many times that I've discovered if I was set in my way of
25:11 Speaker 00 was just trying what I felt comfortable with, that anytime I did the opposite and did something I felt was like I would be uncomfortable with led to better results. So I was like, okay, I don't really want to be a manager, but it will force me to learn a lot and it will force me to be uncomfortable. So I was like, okay, I'll give it a shot.
25:29 Ryan Peterman? I hear that advice often on that T L M is, you know, two jobs and it's not super sustainable. After you tried it, what was your experience with being a T L M and would you recommend it to others?
25:45 Speaker 00 The first couple of years, it was actually pretty, it went pretty well. As a new manager, I was quickly, you know, I started off with like three, three reports and then went to four and five. Then like there's this big shift where essentially I had the whole team under me. They were supposed to be a manager in Seattle for part of her team that had left. So I had maybe like 12 or 13 reports and. I started, you know, saying like, all right, can I convert this person to be a manager as well? And I started having managers report to me and I was still given technical direction. But I think the thing that became tough was as the org started, we, we were successful. So we continued to grow and it became harder and harder to think about, all right,
26:31 Speaker 00 how can I continue to contribute as a tech lead while also figuring out how to scale out this org? And there was, you know, some ideas I had around how to do it, which was basically I need fewer reports. Let me get like three managers to do all the management and I'll just manage them. Then I have time to think as a tech lead. You know, my own manager at the time, he didn't think that was the best outcome as for building a healthy org, which I think makes sense because he has a lot more experience being an org leader. Ultimately, I got scaled down to here's a few direct ICs I worked with and I continued being a tech lead overall.
27:12 Speaker 00 So it wasn't necessarily the workload that was the issue, but it became something where does the thing that helps the team the most align with the base responsibilities I need to do as a manager? So here's a way to kind of demonstrate this, right? So as a tech lead, at the time, I think there was something like thirty five to forty individuals on the larger team that we were working with on the language team. And so the best thing for that thirty five to forty group of individuals of what I should do is different versus the maybe six or seven ICs I was directly supported. And so I had a PSC where if I would be great as an IC, I was told I would get a GE.
27:55 Speaker 00 Like basically my role as a tech lead for this group of thirty five to forty individuals I was doing really great at. But as a manager, I wasn't failing. I was a good manager, but I had to do that job successfully. I, I wasn't necessarily looking to exceed as a manager or do or maximize the growth of those six to seven individuals I was supporting directly. This became something is like, is this actually what's best for the team long term? And ultimately, I had a choice of I could basically try to replace myself as a tech lead. So I could focus on being a org manager or go back to being an IC.
28:36 Speaker 00 So I could focus more freely my time on what the needs of the larger organization needed from technical leadership. And the choice became obvious for me as like, it was just easier to find a manager for six to seven people than me trying to find someone who can be effective tech lead for our group. So that's what ended, what led me back to be in the IC.
28:57 Ryan Peterman? You mentioned that in, along that journey, you managed some EMs and you managed ICs as well. I'm kind of curious, what's the difference between managing an IC and EM?
29:06 Speaker 00 It's really the difference between trying to support someone as they are working through technical problems versus people problems. You know, one of the things I had to get used to as a manager is, you know, when you're IC or you're doing something technically, the feedback loop between you doing an action versus you seeing the results of that action is shorter versus what you try to do as a manager, right? So if I'm working with a IC, I'm trying to up level them so they could take on larger bits of work or learn how to be more creative or thorough in terms of the work that they do.
29:46 Speaker 00 As a manager, the things I attempt to do in one meeting, one-on-one, I have no idea if it helps. Right? There isn't something I could tell like, oh, I hit compile and then I, it passed or I run the unit test and now it passed. But as a manager, like it might be like six months, nine months down the line where like something clicks or they come to a meeting or one-on-one and say, hey, I finally got that thing you said and I'm actually seeing results from it. Now that same thing applied to a people manager is even like a longer loop, I'll say of like the problems they have of like, and some of it was, I was a new manager, so I wasn't always necessarily.
30:30 Speaker 00 Clear around like, well, what's the best ways of getting them the things they were struggling with as a manager? What advice can I give them? How can I coach them up? It wasn't something that I actively went in. It's like, I need to do something different for these managers. Right? I was kind of a vibe manager. I was just like, this feels like the right thing. And I think for the most part, things were fine, right? From a standpoint, the team, the org was doing well, but I wasn't necessarily focused on optimizing the org. I was like, fine, if the org just ran, right? And I was able to do technical work. So, um, you know, I know you asked about what's the difference between the IC and a manager and to the management?
31:15 Speaker 00 It was more like for me, I was realizing that my brain was focused more as like still as a IC is like, the org is fine for the most part. I'm not looking for other opportunities to see this organization operate more. And those are the kinds of stuff I think you should be thinking more about as you are more of an org lead and are supporting other managers. It's helping them think about as they have their own team, like how they should coach others or how, what opportunities they should be thinking about. Or even seeing like, doesn't even make sense for them to be a manager still, or should I? Or is there some other opportunities? So these are the types of stuff I probably should have been doing more of as a, as a skip manager.
31:58 Speaker 00 You know, I thi- I think the thing I enjoyed the most around management though was around the coaching. And so that's where I leaned on a lot more with like one-on-one was like, what's your problems? How can I help?
32:08 Ryan Peterman? And it sounds like the coaching that you enjoyed most was IC coaching because you liked being an IC yourself. So, and you're saying that for EMs reporting to you, the best thing is to kind of flip that switch and start thinking about the best org design and how do we grow people? And how are they going to support their team?
32:28 Speaker 00 Yeah. And that just wasn't the natural way I was thinking, like day to day. Particularly because, yeah, I was the tech lead. So if I came in 80% of my day focused on what's the technical challenge? Challenges we have and how can we best tackle them? Trying to switch to 20% of my brain of like, well, is this even the right structure we have, the best execute on this plan? I just was not good at switching between the two.
32:54 Ryan Peterman? Yeah, at some point you're promoted to senior staff or IC seven equivalent. I'm curious, what's the story behind the promotion?
33:03 Speaker 00 So we talked earlier about this uncanny valley like post. And that was really that vision was what drove the team for a while. Like as we started to scale up the size of the team and what we were pursuing a lot. If you ask anyone in the team, what will we do? And it was like, oh, we're trying to cross the uncanny valley. And I think what led to the promo was basically enough things lined up as we were executing and we were making progress towards this that was like attributable to my vision that it made sense to be promoted, right? At that point, it was something I remember being a bit more active, talking to my manager about. And at that point in time was kind of seen as like, it's just a matter of time.
33:47 Speaker 00 We just need to see more like results because I had a clear vision I had laid out and we were starting to see results from it. So we just needed to see it a little bit further along before we got the promotion through. And yeah, I ended up getting it the half before I switched back to being an IC. So I was actually still a manager when I got promoted. I think at the time they said officially TLM didn't start until M2 equivalent. So if you're at M1 and you're a technically manager, like no, you're just a manager, right? But I think the promo to M2 was based on the technical contributions I gave as more IC as opposed to my ability as an org lead.
34:28 Ryan Peterman? If I'm understanding, the blast radius of what you'd done was basically a migration of the full to fully statically typed on one of the base, I guess, languages that almost everyone was using. I don't know the exact percentages, but you know, hundreds, at least maybe even thousands of engineers using this. Is that right?
34:47 Speaker 00 Yeah, I joined the team in 2015. We had a mix of some hack and some PHP. And we soon moved to basically everything being hack. We also had some notion of like hack strict mode versus a partial mode, where strict had requirements that you wrote all the types that were necessary versus partially you could leave things out or whatever. And by this time I got promoted, we basically got all the code base. So back in 2015, out of the hack files which were in the code base, maybe only like five or 10% were strict. So by the end of this, right, around the time where I got promoted, we more or less had all the code base now being strict hack.
35:30 Speaker 00 And so that was like a pretty remarkable difference, you know, plus a bunch of other work we did of changes to the language runtime and other things that had kind of paid off at that point.
35:42 Ryan Peterman? Coming to the end, there's, I kind of wanted to go over like some career reflections going over this story. But one thing that I was curious about is because you're early at Facebook, you've probably had a lot of chance to work with some very legendary ICs. I'm curious, is there any IC that you worked with or you thought you were really impressed by them or maybe you have a story working with someone?
36:04 Speaker 00 Oh, yeah. Oh, there's so many excellent ICs I've worked with. So I almost feel a miss if I call some out, but I'll, I'll mention one. Kendall Hopkins. I worked with him when he first joined the company and he's an excellent IC who was really good at understanding for a code base or main, you know, or main code base that was running hack. I was thinking from a language perspective. He was thinking more from the developer perspective, like what are they actually trying to do? Like what are products needs? Like what do product engineers need within this code base? And he's just was an excellent engineer and helping to think and strategize, like, how do we make these larger changes at scale across the code base?
36:48 Speaker 00 So he was very key, I think, instrumental in my success. Another one that comes to mind was Paul Bizinet. You know, I don't know if I said this. But when I joined Hack, I had no prior experience with languages or compilers or anything. Honestly, I didn't even know what a lector was, which is like a very base component of a parser. And Paul, he answered, he was my sounding board. Like, I could ask him anything and I felt comfortable, no matter how dumb it was, he would take the time to explain it. And so I don't think I would have survived, particularly when talking with the HHVM team. If I didn't have Paul there to kind of teach me different concepts.
37:29 Speaker 00 Yeah. And another one I just want to call out is, you know, he's a colleague of mine, Andrew Kennedy. This guy is incredible. He's literally written foundational papers on type theory. Like you would do some research, like, let me look up some things around type theory. And you're like, oh, Andrew Kennedy, his name is here. And he, and he kind of figured this out. And it was one of those cases, I did not, when I first met him, I did not know how amazing of his pedigree that he had. And he's one of the most humblest guys I I've met. For someone who's so accomplished already, working with him has really showed that I shouldn't be afraid of someone's prestige.
38:10 Speaker 00 Right? I have value to add, even if it seems like I'm not, you know, you know, I'm more junior or anything else, right? That there's always something, everyone has their strengths and there's something you could always add to that. And with Andrew, there are times where we talk about different language features or ways of typing. And even though I didn't have the same background he had, finding ways where we can communicate and see like, he would say, oh, Dwayne, that's actually an interesting viewpoint. I hadn't thought about that. Made me feel like, hey, I could actually, you know, punch and hold my weight. And then there's stuff he'll do. I'm like, I had no idea like how to even think about this problem. So, yeah, those are just some of the, some of the ICs I really call out.
38:52 Speaker 00 It's like me having worked a lot with and seeing just some of the amazing work they've done at the company.
38:58 Ryan Peterman? It sounds like it was humanizing working with him. I mean, I guess if you had just heard about him, you'd think this guy's untouchable. But getting to work with him, seeing him be friendly, adding value in discussions, kind of made it so that you were, I guess, not scared of his pre-degree. Is that right?
39:16 Speaker 00 Yeah. And that's something for myself, you know, having, you know, been on Hack now for 10 years and been at the company for almost 14, it's something I'm sensitive to as well. Cause I still remember that time when I was just a younger engineer. And so every once in a while I'll go, I'll meet someone and I'll introduce myself and they're like, wait, you, you're the Dwayne? Like, you're like the hack guy? And I'd be like, oh, like, don't think of me like that. You know, I, I want to be approachable. I want people's ideas to feel valued. And, you know, yeah, we're all humans. We all learn things, right?
39:58 Speaker 00 And just because of whatever I've accomplished in the past or any ideas I have, doesn't mean I'm always right. I'm always looking to learn more. And I think that's one of the things was great around the team I had, was just so many senior I C's, those with, you know, some I talked to had more experience working on programming languages than I was alive at the time. But yet.
40:23 Ryan Peterman? That's crazy.
40:23 Speaker 00 Yet how willing they were to talk to me and, and explain their, their approach. And I just think that's something all, all senior I C's should try to emulate that, like humility.
40:33 Ryan Peterman? You mentioned you've been at the company for a long time. I'm curious, like, what is the thing that you find keeps you at Meta? I think in this industry, a lot of people, you know, hop jobs.
40:43 Speaker 00 Yeah. So there are definitely some times I think of wherein I was considering jumping ship. And the thing that I always reflect on, right, is, is my motivation for moving, is it trying to solve a temporary problem? So let's say like, hey, at the time, I'm not particularly happy with the project I'm working on. Is that really a reason? For me to leave the company.
41:09 Ryan Peterman? Right.
41:10 Speaker 00 And versus like, um, and each time I, you know, I would interview and I'll have an offer and I'll think like, is me making this change or move really gonna change like the fundamental problem I feel I have at the moment? And each time I reached at that point, I would just objectively look at, well, what are the problems I have? And what are also the things I enjoyed about the work I did? And particularly growing up at this company, you know, things that I was being, I had a voice that had carried weight. I had opportunities to help bring in diverse talent into the company.
41:53 Speaker 00 And frankly, how many opportunities is there to work on a, on a programming language? I was, that was also the piece. And I had a great team. And so if there is a moment of like, yeah, there's some discomfort that was for like two months. Is that really worth changing over? Right. And for me, I always was like, yeah, I could, I could sit through it. And most of the time, things ended up improving. Uh, and so that was for me, my like perspective is that I don't want to make permanent decisions based off of temporary circumstances.
42:31 Ryan Peterman? And it sounds like, I guess in those cases, when it wasn't good, the situation was resolvable. It was not something that you couldn't change or your manager couldn't help you with.
42:40 Speaker 00 Yeah, you know, I feel some of the things in terms of what would lead, what would have led me to like leave, right? Is if I didn't feel valued. And in a lot of the cases, I, when I would look at it's like, no, there's all the signs that I am valued here at this place. And so the issues was not focused on that. It was like something else like, oh, it's the, it's the project I'm working on. Do I feel it's not getting the recognition it deserves? And some of it realistically might be like, I just have a warped view of what I think should be recognized. And if I talk and really face this, like, yeah, I'm actually wrong. Here, or maybe they are wrong and me with enough time, they've realized that.
43:24 Speaker 00 You know, if I fundamentally did not believe in the mission of the company, or like I felt my manager was creating a toxic work environment. Things like that would be more of what I would see is like, yeah, if I'm in that situation, I would have left already. But none of those were like the circumstances I had. And honestly, I feel I'm a bit privileged and fortunate of that to experience that in my career. And it's it leads to a lot of like, there's just been so many great people in my time. I've been able to work with both managers and others at the company. That it's let me really have a career so far that like goes beyond my wildest dreams.
44:03 Speaker 00 Right. When I was first learning the code as a high school student, you know, the child of Jamaican immigrants. I would have never in my wildest dreams have thought that I would have end up with the opportunities I've had. Working at this company and it's not, I want to want to say sentimental, but it's really appreciating that. Like I've actually been really blessed and really fortunate.
44:27 Ryan Peterman? And I guess the last question I want to ask you is now that you have all this experience, if you could go back to yourself right when you graduated college and give yourself some advice, what would you say?
44:40 Speaker 00 I get asked this often and the thing is, the thing I'll say is, hey, Dwayne, I know you like coding. But the thing you should realize, right, is when someone goes and tells you, hey, can you write some code to do this? You should stop and think, how do they know that's the right code to write? You should aim to be the person who's making those decisions around what's the right thing to do. There's a lot of imposter syndrome and other stuff I dealt with early in my career. That having this clarity is like, it's not about, you know, I'm more than what I can type on the keyboard. Right. My ideas and the value I derive is is greater and like focus not on just being an output machine.
45:21 Speaker 00 But really being the one and focus like, can I be in those rooms that's deciding what's the right thing to do?
45:27 Ryan Peterman? Yeah, thanks for sharing and I I feel like someone with your amount of career success, sharing that you had imposter syndrome, I think that can be helpful for a lot of people. So, um, yeah, thank you so much for your time, Dwayne. I really appreciate you coming on.
45:43 Speaker 00 Yes, it was a pleasure, Ryan. Thank you so much.
45:46 Ryan Peterman? Hey, thanks for watching the show. I don't sell anything or do sponsorships, but if you want to support, you can subscribe on YouTube or you can leave a review on Spotify. And I'm always looking for new guests to interview. So if anyone comes up who you think you really want to hear their career story, let me know and I'll try to reach out to them and get them on the show. Thanks for listening as always and I'll see you next time.
Previous GoogleX Chief Scientist On Imposter Syndrome, Career Growth, Project Taste Next Amazon VP On Promotions, Getting Fired Twice, Working With Bezos | Ethan Evans Page updated November 2, 2026 · transcript and summary are machine-generated