The Peterman Pod - Intern to Microsoft Distinguished Engineer in 11 Promotions (Career Story)

Episode Date: September 5, 2025

David Fowler went from an intern to a Distinguished Engineer at Microsoft. That’s 11 different promotions all at the same company. I asked him about everything he learned by going through that process.𝗘𝗽𝗶𝘀𝗼𝗱𝗲 𝗟𝗶𝗻𝗸𝘀:• Transcript: https://www.developing.dev/p/intern-to-microsoft-distinguished• YouTube: https://youtu.be/d8tRM8RJ52M• Apple: https://podcasts.apple.com/au/podcast/the-peterman-pod/id1777363835𝗧𝗶𝗺𝗲𝘀𝘁𝗮𝗺𝗽𝘀:(00:00) Intro(00:53) Microsofts leveling system(03:17) Joining Microsoft(10:18) First successful project(16:22) Bootstrapping his own project(25:44) His principal promotion(37:10) His distinguished promotion(49:51) Engineers he looks up to(53:40) Expanding on his top tweets(1:05:20) Big company tip on reorgs(1:08:25) What keeps him at Microsoft(1:17:22) Microsoft culture after Satya(1:23:04) Career regrets and work life balance(1:29:51) Advice for his younger self𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗗𝗮𝘃𝗶𝗱:• LinkedIn: https://www.linkedin.com/in/davidfowl/• X/Twitter: https://x.com/davidfowl𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗥𝘆𝗮𝗻:• Newsletter: https://www.developing.dev/• 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• TikTok: https://www.tiktok.com/@ryanlpeterman

It was probably the craziest promotion I've ever experienced. This is David Fowler. He got promoted 11 times from an intern to a distinguished engineer all at Microsoft, and I asked them about everything he learned along the way. A lot of the things that get you to senior and maybe principal hurt you bring even further. What are the hidden unexpected perks of getting promoted to a distinguished engineer? Okay, the coolest part. Also, since he's been at Microsoft for over 17 years, I asked him for his unique

perspectives about the company. Did you notice anything internally when Sotia became CEO? The culture just changed completely right. Before you change roles, ask when the last reorg was. What's the thinking behind that advice? I'm curious what has kept you at Microsoft as long as you've been. Here's the full episode. First thing I wanted to go over is I think Microsoft's leveling system is a little bit unique compared to the other big tech companies. I see on levels FYI that the leveling system goes from 59 to 70. And there's almost two levels per title. You know, two levels per SD1, two levels for SD2, two and senior.

And it keeps going on all the way down to distinguished. Can you explain the Microsoft leveling system a little bit? Yeah. So I can't tell you why it starts at 59. I'm sure someone who's been there longer than me can tell you why it starts at 59. I believe there are levels below that that aren't engineering roles, and that's probably why it has that system. So when you join from college, you typically start at 59 or 60, depending on like, how many times you intern, how long you did. There's different things that go into it.

But entry is 59. So that's like sweet one at other companies. And then you progress in level. In Microsoft, there are things called level bands. So when you say there's like two levels per title, the title tends to be the band. So you can say, like, I am a junior engineer. You could be 59 or 60. So you can't tell from someone's title which notch they're at.

So there's, you know, 59, 60 is 31, 601, 602 is 2, and then 624 is senior. And then principal is actually three levels. I never really sat on and thought about the way. It's done that way. I'm sure people that are really smart came up with those levels and why that way. But the principal level, the band is so broad. The depth of experience of the people in that band is immense. So you can be talking to someone who is like the last level of principal band that's been there forever.

Or someone who just entered the principal band just came from senior. And you wouldn't know from looking at your title. And then beyond that is like, no one knows, right? It's like levels partner. That has three bands. And then there's beyond partners like technical fellow and extension dinner. Yep. So yeah, it's a broad system.

Yeah. Yeah, thanks for laying that out. So yeah, that's the thing I want to dig into is, I mean, you went through this entire thing. You started all the way as an intern. And you've been there for your entire career and you grew all. the way to distinguished. So I kind of want to go for that story. Could you tell me the story behind you joining Microsoft? Yeah. So I went to college at Florida Tech. And I'm from Barbados. I left Barbados at like 18, like everyone else that goes to college, went to college. Funny enough,

I was looking for colleges that had career affairs. I chose one that was closest to like Barbados. It was one flight home for the Caribbean from Florida. So that was a really convenient place. And funny enough, my first major was computer engineering because I thought I wanted to do software and hardware. But in the first class, I was like, no thought for me. I want to code. I have been coding since I was like 10 years old. So I was like that's what I wanted to do. Change majors to computer science did my first year of programming.

I thought, funny enough, I thought people that chose computer science have been doing programming, like, their whole life. And they knew what they wanted to do. But in the first Java class, like, no one knew to code. And I was like, this is kind of crazy. I thought this was like a thing to everyone that chose computer science but do before you come here.

And that was kind of like being tossed into the pit of computer science, like learning about algorithms. And then after that, I kind of met one of my best friends, to this day still, we still like best friends. And we started to make games.

And we have been working on like next weekdays, making games for fun at school. And we, by the time the first career fair came around, there were a bunch of companies that came in to see different students. And we thought to ourselves, how do we differentiate from other students? So we came in with a laptop showing our game demo and we showed us to all the recruiters. And that first year we got like, I think like four offers for internships. I got Microsoft, the GE, a bunch of other small companies in Florida. But my friend went to EA.

So he had, we built a game, he went to EA, you know, interviewed there, got interned there. I went to Microsoft. And that's how I got the internship. I showed them in the game. We did interviews on campus throughout, did full-time interviews. You know, before COVID where it was all in-person, whiteboarding, got my internship. And that was kind of like history. I interned twice, 2006 and seven.

It was an eye-opening. It's coming from a small country, going to a big company, experiencing, like, big campus, big technology, talking to people who were, like, really, really, really smart. Absorbing information. It was kind of, it was great. And I was part of the last set of interns that got to go to Bill Gates' health. That was kind of, that was kind of fun. What was that like going to Bill Gates' house? So historically, every intern group at the end of the summer got to go to Bill and gets health. That was the main event, right? In my time, at least. And you would get picked up in a bus and they would take all your technology.

They would take away your phones, take all your stuff, give you instructions. You actually park out, I think, at a church, and they would take your stuff so you could take pictures. You get, you know, they would tell you like what you can and can't do at the. house and then all the interns were just going to his big really huge mansion. Funny story is I recall just standing around talking interns not paying attention to what was happening. And I remember seeing a rush of interns like run towards me and I kind of figure what was going on. I turned around and he was like he was behind me. I shook his hand. So let me see I spoke to him once.

when you interviewed for Microsoft at the time in 2006, was there a leak code or what did the process look like at the time? What kind of things did they ask? There's a book called How Would You Move Mount Fuji? And it's this classic book doing tech interviews. Microsoft created these like lead code style puzzles that everyone love to hate. The puzzles are like, why is a man who'll cover around is one of the most famous ones that people would ask you a question. When I was on campus doing the interview, I'll not forget, they were asking me questions. And I had been prepped for coding interviews.

I had been thinking about like coding stuff. But I hadn't taken all the classes yet because I was in my first year of university. So I hadn't done like all the courses required to learn about all the things. Right. So it was me on my own, my friend trying to figure out how to like what, how to prep for interviews. And they asked me, it's so visceral. they asked me a pal and jump question super easy not not hard i did on paper like with a pencil writing on paper and then they asked me did you ever watch die hard three no there's a scene

where bruce willis and sam jackson has to stop a bomb from from going off and there's like water in a fountain and they have a five-gallon jug and a three-gallon jug and they have to make exactly four gallons to avoid the the disaster Oh, okay, okay. And I had seen the movie, right? But I couldn't remember the sequence of steps required to get that to work. And in an interview, my, after the coding question, they asked me this puzzle. So you have infinite water and you want to make four gallons and you have a three and a five junk.

And you have to make exactly four gallons. It's like, how do you do it? And I sat there and I was like, oh, my God, this is they heard. And I figured it out. But it was funny because to me, it was like, this is like pre-leak code, not even thinking about solving some sorting question or something. This is just like puzzles. Like, can you think through puzzles?

And the last question was, how do you count the number of gas stations in Florida? And I sat there and I was like, is this a trick question? And the guy listened to me, he says, no, and I'm like, I don't get the point.

I don't get the point of this stuff. And I thought I had, I thought I had like done really poorly. But they had, they called me. So I was, okay, I couldn't have filled it miserably.

That's so funny. because people hate on leak code all the time, but these puzzles, it sounds like league code's better than these puzzles actually. 100% related to the job. I didn't even know if you can prepare for some of these things. Like my last interview, my second last interview when I was when I flew out and was on campus, I got asked, how do I add two numbers in base negative two? That was my final question.

It was just like, what? It's come a long way since this changed a lot. I mean, like, some for the better, some for the worse. So going back to the story, then, so after you had the internships, say you committed for full time. And then you had a pretty quick career growth on the outset. And I see that there are a few pivotal projects that led to the upward trajectory past senior. Kind of want to talk about the story behind those projects. So for instance, maybe we can start with Nuget, which is the package manager.

What's the story behind that project? That was interesting because Newget, I think really 10 plus years and now is like the package manager for dot net. It was when I think about the impact now compared to what it was when it started. It's kind of jarring because we started off. We were building a brand new web stack and we were trying to compete with like the LAMP. So LAMP was like Linux Apache, MySQL, PHP. and we were competing with that from a dot net

Windows server standpoint. Whether or not that made sense or not that time, I didn't think about that stuff. The bosses above me told me we're doing that, like, let's do it. So we built this whole new web stack and Ruby on Rails

had come out like concurrently at the same time and gems was like this huge deal. Ruby gems, get gems, get packages, you know, run commands and rails. And we had seen that, but there's also a cohort in the company looking at things like WordPress and Drupal and those have packages too. And I think the consensus was we need to have a package

manager to like pull in packages so you can extend the platform. And the very first version of Nuget was this in browser package manager that was like a WordPress thing. And I remember we had this meeting with, who is now an EVP, Scott Guthrie. And it was all about like Rails and gems and we have to compete with the package manager. And there was a product manager who had mopped up in screenshots and PowerPoint and experience. And it was me working with an architect saying, like, we had built something. Like, can we just start from here? And that meeting formed the Nuget team. It was me, I was the first engineer. There was an architect, David Evo and Phil Hatt. And we were the phoning team of Nuget. There were other open.

source nascent package managers in the ecosystem, open wrap and new. And we had a conversation with some of those people. And we started off this mission to build a package manager for this for dot net. And so when you were building this, it sounds like it got pretty critical adoption within the dot net platform. Yeah. What did your performance review look like when you were, you finished building this thing? Was that like a really incredible success? for someone who wasn't even a senior engineer yet? Yeah, I got, my first promotion came like eight months in when I joined. Even before Newgate, I think my first year was me.

I had intern twice, so I had a lot of experience, like just Microsoft's in general. And I would work on the things I was assigned. And then I'd work on more stuff. One of the things that I did was I would troll forums looking for feedback for our products and I would just build features to solve them. And I just did that over and over and over. And they kind of showed product managers on the team and architects and who turns out were my sponsors. I guess in the looking back on how it, how I went.

And I think that helped me be in a place where I could be the one to build new get. I would I would basically just look for problems to solve and I would attempt to code them first. I was very, I mean, maybe I'm still the same way. I'm a code first asked questions. kind of person. So my whole thing is code is currency. I can show you a working sample. It's not PowerPoint. It's not a document.

Here's a working example of something. Oh, we should start there and then move on to something else. So my review for Newgate was like I was getting really good reviews early in my career because I would just grab things. Funnily enough, one of my directors at the time told me like maybe five years ago that he would just tell people that David has. energy. Go talk in. Maybe that's my stuff. Stuff came my way. You mentioned that New Get grew way past your what you imagined. And I know at some companies, there's this idea of

deferred impact where sometimes people continue to get credit for something that they built and is continuing to pay out for the company. Did you see anything like that in your subsequent performance reviews? Yeah. I want to say maybe the bigger ones. The bigger ones felt to me like a conglomeration of history, like past success, adding up, plus success. I think on Microsoft in general, impact is supposed to be for the year. But I think when you're doing these, I think there are some things we call them ban changes. Right. So when you jump across bands, it's a bigger promotion.

Within Byn is a smaller promotion. So if I go from, you know, 61 to 62, I'm still an SD2. But, you know, it's still worth a promotion. But when you jump and you cross the boundary of going from to senior or senior principal, you require more, more things to, more impact to make that leap. And I think, I'm not sure if there's an official deferred, in fact, thing in Microsoft. But I remember that did come into play when I went to, you know,

higher levels of principal and stuff, because it was definitely not. a one-off like, oh, you did this one thing this year, like, you're promoted? It's like, have you been showing repeated impact over the last end years? And do we want to, you know, keep you going forward, et cetera, et cetera. So I think it did, it did matter. You mentioned some other larger projects. So maybe we can talk about some of those. So there was a signal, signal error or is signal? Signal R. Yeah. So that was, that came from that. The naming, the name is the timeframe came from the time of Flickr, Web 2.0, remove E's from the end of things.

That's, I don't know why we call it Cigmore, I mean, we know why, but that was a fun project. I had been working on nights and weekends on this project, and it was, funnily enough, like, Google Docs came out, and I have been, like, enthralled with the thought that you could co-edit in a document. That was like, this is just nuts,

and it works super well concurrently, and I was like, can we do this for code? So I had to start, I went off trying to build Google Dots for code. Could have been rich, but I didn't do that anyway. And while doing it, I learned about WebSockets, which actually hadn't come out yet. I learned about basically how to build those kinds of apps. And that led to the creation of SignalR.

In the meantime, there was a product manager on the team, Damien Edwards, who was also building a talk to describe how to build long-winning streaming apps in Dotnet. So I had seen his talk and I was like, hey, I'm living this thing. We should collaborate on this new library, right? So that kind of spawned the nightside weekends. What we call out on Microsoft, you can moonlight and work on things that are not tied to your work separately, officially. So we have been doing that like overnight. We just work on this thing up until like midnight every night.

We made it open source. And then people start to use it. And we were like, okay, this is interesting. catching, catching on, becoming a thing now. It was still just two of us working on this every now and then. Didn't know what we were doing really, kind of like just building this thing to make it work. And then at some point, a product manager at Microsoft on the team said, hey, we should make this official.

And that's when, I think that was the first thing I experienced, like, building a project from scratch. Previously, I had been working on other people's ideas. You know, someone had a great idea. I was a decent dad. I would come in and be like, found the engineer. This one was like my brainchild.

So it was very much, I, we built the prototype, built the entire thing from scratch, and now I was being given the chance to have a team to work on it. I was never a manager, but I was the pseudo tech leave.

So we hired like kids from college. I ended up working on Signalore. We had a team of like eight, I think, one point. And it was surreal because it was like, okay, there is this random thing that I built like on a weekend and then it kind of turning into this project. That's real. What was the motivation for Signal R? What made you pull the weekends and the late nights to build this thing that seems like it was outside of Microsoft? I hadn't seen anything like it. Like when Google Docs

came out. It was first of its kind to work that well. And it just felt super new and no one, I hadn't seen apps do that. And it was like, how do we enable more apps to do the same kind of thing? NoJX, like socket IO and Node were super new. And socket IO had just come out. And it was like, oh, that's a really cool way of building these apps that are chat and can send stuff from server the client. And we just, I think that just draw. me because it was like, okay, I hadn't seen people attempt to do this before. That's this. Let's push. It's funny, we push the boundaries of like the technology a bit. We hit limits like all over the place in the tech stack that became problems to solve deep in the deep in the core platform.

So that was a really good way to learn, learn more about the overall networking stack. And I think the amount of problems we got to tackle maybe made it enthralling for like a dev that like, I got Nurse Knight. It was like catnip. This is so interesting because you grew through this project and it was permissionless, which is that no one handed it to you. There wasn't some manager or some PM that came to you and said, hey, your staff's on this project.

You just went and you built something and it was so impactful that it actually led to a ton of career growth. I'm kind of curious, maybe we can, is there some way for us to reverse engineer that? for others like how how do you go about starting projects where the motivation comes completely from you within a large company so really the question um if i had to to boil it down to one sentence you can just do things and i think the the way people talk about it now is you have agency and it often seems like you don't like it's really hard to find time and i am not not recommending people spend nights and so we can working on all the projects. But early in my

career, my main goal was to get better at like software engineering. And the way of doing that was to learn everything. Like build anything you can build games, websites, like just build a ton of different things. And you get some gain experience from learning how to build those types of software. Right. So I think that was ingrained in me from really, really early on. And then And the other thing I did early on in my career was I found someone that I wanted to, I found someone on the team that I wanted their career. So on my team, there was an architect, David Evo, and his job seemed really cool. He got to think about the future.

He kind of spanned multiple areas of the product. He got to build the next wave of what was coming next. So I basically attached myself to him and I mimic his behaviors. I said to myself, okay, I want that role. Let me make sure I'm seeing what he does that seems to work. And I don't want to keep doing that. And I would be the coder of his ideas, right, for a while. And that turned into learning how to do it on my own.

So I kind of did this gradual thing where I was like attached myself to people who were like that. And then I found myself in that same position. Okay, here's a new thing. I have some insights. Let me try spiking a thing that will work. And then I communicate ideas with code. So I would always build a prototype first and then show someone, show an advocate on the team, show the architect, show the PM and say, like, is this useful? Is it cool?

I saw this issue that a customer was having. I think this solved a problem. Do you think we can turn into something? And I think that pattern of doing that helped me gain insights into what people, what helps people get over? the hump of like should we build to me or not. I would build a thousand things and maybe one would hit. It's interesting that you say agency. I think a lot of people who work at big companies or talk about big companies, they feel like it's difficult to have agency. They have all these projects that are assigned to them depending on the team culture. And it sounds like you

had that agency through energy. So you are moonlighting. You were going above and beyond. You did your normal stuff, but then on top of that, you had all this extra agency. In my understanding, that's how you unlocked agency at a big company. And I think it afforded me, I think once you build a reputation for being able to kind of perform build and build things, I think more things come your way. I don't want to say it is easy or it will happen. But I think in my case, 100%, like, when I, the more things I built, The more things I showed people on the team, people would just say things like, hey, David,

we're both these new thing. Like, we want to get your take. We want to get your opinions. You work on it. Can you help a build this thing? A lot of opportunity comes your way when I think you have a good rep for building stuff. I think further in my career, that showed very true for what happened after Signalor pretty much. You get a lot more of those permissioned opportunities when you have credibility.

and permissionless agency is, it's almost this hack to kind of bypass credibility. Yeah. And the funny story, I think the funny thing is like, you get a chance to be more permissionless, the better your track record is. So the more you have,

the more success you have, the more liba you get to fail, which gives you space to try more things. Yeah. Yeah, no, that makes sense. I've seen that a lot. the very high, fast-growing software engineers, they're almost this weapon that management and people around them say,

we trust you, go do that thing that you do. And they can go and try all these risky projects. I bet if you were someone who was struggling to meet expectations, a lot more directed opportunities are being handed to you and you're being monitored. So I can totally, yeah. Totally see that. So true. Going to your late stage promos,

you got the promotion to, principal, you got the promotion to distinguish at Microsoft. I'm curious, what is the thing that led to the promotion to principal? Principal was interesting. So I had a one boss, I won't say his name, I had a one boss who told me when I got a senior that my promos was slow down. I remember that meeting where I sat down and I got the promotion. I was really happy and he kind of gave me this down early. Don't expect more promotions from here because, you know, I was like, what does that me. And I really took it to heart, but the jump to principle is a big jump. I have been working on SignalR at the time. I built this. If you ever use Heroku, Heroku, like, pioneered,

get pushing and deploying your app like instantly, right? We had built, there was a, there's a tech call app harbor for dot net. This company was doing the same thing for dot net. And we built a similar thing for Azure. This is like super early in Azure timeframe, really. We had built this like brand new. It's actually still there. It's called Kudu. And I had, I had been working with this same architect and I had built it with him. And then at some point in that timeframe, I got pulled off of that. And I think this is one of the places where like your track record helps just get set up for the future opportunities. So I had. And my director tell me, hey, we have this new thing spinning up and we need you to go work on it. And obviously, you know, you're working on something else. You're like, man, I'm, I want to finish what I'm working on. But then this thing happens. I'll help people this thing.

And that ended up being the beginning of the new dotnet core. They rewrite. It was cross-platform and modern and new. And it was a big opportunity. Like, so big, it was scary at first. Like, oh, my gosh. like, what do you mean you're the architect? And I was senior.

I was, it was me and another principal engineer that got chosen to be the architects of this project. And I hadn't had an experience working at that scale before because I think you had like 30 engineers that were working on this project. We had free reign to kind of build whatever we thought was right. And that was like both amazing and terrifying.

And I think through that project, I learned a ton of things, Like, knowing how to, I don't want to say we weren't managers, but learning how to manage a project and architecture and scale. And like, initially, I was trying to co-review every single change. You can imagine that Bermil. Within a year, it was like, okay, I can't, I can't, we can't do this anymore. We have to figure out how to trust people and scale and figure out what's important, what was not urgent versus urgent, et cetera. That year, I got promoted.

actually had my first kid and I got promoted that to principal that same year. I did this. The first year of Donate core design and building it. You mentioned that the team grew so much that you had to scale yourself out of necessity. What are the things that you did that allowed you to be an architect for so many engineers without burning yourself out? So I learned some of this during Ciglar. the smaller version was similar when they had

seven or eight people overall or eight engineers, text or product managers and we had two new hires and I had never had the experience of delegating in a way where I thought it was like

if I gave you this work is to grow you, right? I never thought that way before. I was always like, I'm a senior engineer. I can get this done. I can do it faster than you. Like, why would I give you this thing

when I can do it faster? We had a really smart engineers that we hired from college. And it took me a while to kind of get past. It's going to take them longer at first. But once they understand all the stuff, then we can amplify the impact. And I think once I saw that, it flipped my brain. So I had something from the signal frame that was like, okay, if you can invest in people and kind of get them on the same pitch as you, if you are on the same wavelength, if you can

delegate more, then you can kind of get more done as a team, right? You begin to be, you begin to think about outcomes and less about like the work you're doing individually. I think the leap from senior principle feels like being able to do more through others than yourself. And it's, it's right thing a lot of people end up plateauing because software engineers are very like, you know, we want to, we like coding. we want to be alone.

We want to build the things ourselves. Software engineering is a collaborative event. It's like we want to figure out how to get the customer feedback, figure out what to build, figure out how to build it the best way. And I think that change in my brain prepared me for like dotnet core because it was such such a bigger scale. Like how do you even begin to manage that many people, that many facets? We rebuilt everything from trashed.

Like we literally rebuilt the package manager, the runs. time, the libraries, like everything from the get-go. And it was overwhelming at first. What I think helped a lot was not treating everything as equally urgent. Like, that was a big deal with like, if this change over here went in and it wasn't perfect, I wouldn't be like, we can't merge this. It needs to have this interface, these tests. Learning how to set foundations for others and to trust others and like letting people fail

was a really hard thing for me at first. too. I could avoid the failure. And it turns out the team, like, I think a lot of the things that get you to senior and maybe principal hurt you great even further. Being a control freak, being someone who like is amazing at their job, getting stuff done it in a very specific way, doesn't really help you when you want to feel it's 1,000 engineers. You have to kind of figure out how to inspire others to do the same as you. three different means like one-on-ones or or you being an example or like more more different techniques but it's difficult to just be to type you're not going to type harder and make a bigger impact so it's like I shifted my brand to be outcome focused was a big big change you mentioned

the architect title or I guess role what does that mean at Microsoft that's a fun one um when I joined I saw someone who was a principal software architect. Let me just say to myself, that's the role I want. I don't know what it is. That's what I want, though. It's kind of a semi-official role at Microsoft in a certain levels. The middle principal balance, you can be one of these architects. And to me, it really means you're more breadth rather than depth.

You're more overseeing the design of the overall system. We have different engineering archetypes, I would say. Even at the highest level, you have someone who's a, super coder who is like I am just going to build so much stuff I can impact so many things there are people who work on really deep technical details that have a huge impact we have one of the foremost GC experts like in the entire world like working on the dot net garbage collector so you can have that kind of impact you could be someone overseeing a hugely impactful area of the product.

So there's a lot of space to kind of like figure out what archetype you want to be. And I think the architect rule for me felt like breadth. So I am architect for ESPNet core back in those days. I am like overseeing the design of the whole stack, the web framework, web server, how we how we ship package like the entire engineering idea. And I'm not the engineering lead. I'm the architect. So I'm trying to vet the decisions that are going to like,

last really 20 years. If we do this change, no, we can't do this thing like five or 10 years. And I hadn't had experience doing that before, but I had a really good mentors who had done that. I had been watching and shadowing and trying to understand for experience. Like, how do you build systems that last 20 years? Like, fully crap, right? So as you've grown to Distinguished Engineer at Microsoft, how has the percent of your time that you spend writing code changed? It's funny. I think there is what your job is.

Like, do I have to code every day to do my job? I don't know if I get rewards anymore for coding. I get rewards for outcomes. But for myself, selfishly, I code every day. So my team knows right now that I send lots of poor requests every day to the code because I'm currently working on. I have a new project I'm working on, this shirt, aspire. and I code a lot.

So I personally make sure that when I'm working on a project, I am somewhat involved coding still. I don't want to be the architect who doesn't know the code and is giving people instructions. Like, you should do this, and I'm going to go away now and disappear somewhere else. And anyone will see me again. I want to be the person who is like, I'm a pair on the team.

I want to be everyone's peers, and I want to be facing the builds and facing the tests and not there isn't any work as beneath me. It's kind of what I'm thinking. So when I'm on team, I typically work as I'm as an engineer on the team. If you stopped coding right now and you just kept leading the team, would your performance review look fine? Yeah, I think so.

But the Stoge engineer is definitely about company-wide, org-organizational-wide impact or company-wide impact. So I think even though my day job is definitely making sure the architecture of Dotten as a whole is sound and good and moving forward and we're doing the right things and pushing, is a part of my job that is, like, looking forward and, you know, talking publicly and, like, inspiring people internally. and mentoring people. So there's a lot of things I do that aren't like why you used to do way before

that I think help with impact. As an example, I gave four talks internally about how to use AI to do software engineering. And that happened just because I had been using it myself for a lot of different things and someone said, hey, you should give a thought to the team. You think about the impact of those things. They help when you see engineers who aren't. just your boss telling you to go do something seemingly for bad reasons. Engineers who are credible telling you how they do their jobs.

So I do a lot of that stuff too. A lot of things are not software engineering to be frank. When you got the promotion to the distinguished engineer, what's the story behind that? Absolutely insane. First of all, the Stinguished Engineer is the final level of like partner. If you go on to the levels of FYI, you see level 59 to 80. I think the last is 80, the final level. Distinguished engineer, I think is 70 on there.

Right. And there's actually, there's actually an official process to become, to get that title. You don't just, it's not a promotion that you just get. And because you did a great job that year, it is a set of, of technical leaders have to peer review and decide that, decide if you are, if they're worthy or not, they said if you're worthy or not of that title. It was probably the craziest promotion I've ever experienced, mostly because of the people that are there at Microsoft.

Just as an example, Guido Van Rossen, who created Python, is the same level of me. Wow. like imposter syndrome right imposter Angelo's great he's great he's really fun cool guy maximum imposter syndrome

I'm I'm young I think I'm young for for that role too so like when I was going for that role I felt I thought that would affect me as well it did it but I felt

it would affect me so I had all these hold ups about like am I really at this level can I perform there can I do well there and then with all of my, I think this is probably where all the work I've done in the past helped

because you do need a body of work and you do need a good track record to qualify for these kinds of roles. You can't just become a DE because you had one fun, one fun year. I think some of the criteria ends up being like, what have you contributed? like that impacts company-wide things what have you contributed that so a lot of it is like deferred impact I guess I think makes sense because dot net remember when I went to from principal to partner in the email it had dot net course impact and that was a by then it had been about seven years it wasn't like I did it last year or before it was like this is built up impact and then like

I had been the architect to help people adopt the new dot net internally. And I had done that for a bunch of different teams. So there was all this kind of build up to like, I guess deferred impacts that they're really good way of saying it. And I think all those things helped. Newgate, Signler, like, how did it, how did the thing that you help build and mold and raise, like, grow? How did it impact the industry, the company?

And those all come into a company when, um, the, I think they're fellows who decide who becomes a VE. Were you involved in that process at all, or was it a surprise when you got the distinguished promo? I was involved from the point of view of helping my leadership with like content. So I gave them all of my contributions to things, things I've written, like papers are written, code contributions to various, various projects. I kind of gave them the raw material.

I didn't do anything else. But what made it impactful for me was seeing the other fellows at knowledge and say, like, well, deserved, and this is about time. And, like, okay, that's this. Maybe I should, maybe it shouldn't. Maybe it shouldn't be here.

This is good. You mentioned the lofty expectations of this distinguished engineer level. Yeah, is that something that you worry about now that you've been acting in the role for a while? At first, I would tell people, I am a baby D. I've only been here a couple of months or it's been one year now and I'm not sure yet.

I think no, it's been two and a half, two and a half, three years now. I feel pretty confident. I can perform at this level. And I think I understand what is, what is required. I would say initially, very much yes, my first review cycle, I felt pressure to like document everything and just write down what I thought was all the impacts, right? It wasn't, it felt very much like, oh, my gosh,

I need to make sure I'm, we're going to bring all stuff down, telling me boss what I'm doing, like, making sure he knows. Because I think you're almost an executive at the company. You're at the level below being an executive. And, like, it's super scary to think about having to have that impact every year

repeatedly over and over. So I think I found a, pattern for kind of like making sure I had the right level of impact. Talking to my bosses, making sure I was visible, make sure I'm doing all the right things. So yeah, I don't feel the pressure as much now. But who knows? I mean, things can change.

Things can change. So you went through, it looks like 11 promotions, which is kind of ridiculous. You went all the way from the beginning, all the way to that. And the crazy thing, you're saying Guido, the founder, the creator of Python is that level as well. I can't even fathom, because apparently there's one last one, the technical fellow. What does that final boss level even look like? So the people who are fellows, tech fellows, I guess the one that, you know, in my division

that everyone analyzes, Anders Healsberg, made Turbo Pascal, Delphi, C-sharp, and Tetris. so like no one's competing with that dude because like no you can't repeat building for successful languages but i think if you were thinking about the the archetype of like someone who is a fellow it's that level of impact right or the people who built the windows kernel actually there's one guy Dave cutler who came from deck back in like the 80s or whatever and he helped build he built Windows ntie he build Azure, the OS, he built the hypervisor for Xbox. He is the only senior Kenneth O'Fellow. Wow.

That isn't even a real title. That's just his title. Wow. So it's kind of like, I think at those levels, everyone's a unicorn and everyone has their own path. So you aren't trying to follow people's path one to one. You're looking for proxies for impact. To be a fellow, you need. industry-wide impact, not just impact in your division in your company.

It's like you need to do something that impacts the industry. I think we hired someone recently who is a fellow who like invented RSS. It's like that, it's like that level of like thing, right? It's like you built something that became the industry standard for, you know, the internet. Like there was a guy on my team who was the intern for Tim Berners-Lee. and he is on the HTTP spec. Like, is that? And right.

Yeah, so those are the kind of people that end up being fellows, I think. Were there any unexpected perks of getting promoted to distinguish engineer? A size more money. Let me think. Well, for instance, I guess the thing that I'm curious about is at a lot of companies, when you get promoted to a certain level, you get added to special forums that only distinguished engineers have access.

Okay, the coolest part. Here's the coolest part. There's an email alias called engineer. That is all the DEs on Microsoft. It is just the coolest alias of the engineer on Microsoft. That's awesome.

That's one of the perks. Yeah, but there is, there's an internal, there's a forum where we all meet, I think every couple of months. The way this typically works is you have a sponsor. Right. So when I'm when I was going to be I told my mentor I want to be at the E. I had I had mentors who were fellows. Okay. So one one tip when I became a partner, I told my men I told my management that I want a mentor. I want help find a mentor who is a fellow because I want to be one. So I figured if I want to be one, I should have people who are mentors that can help me get there. And my one of my one of my menors. One of my menors, mentors was very impactful on my career. He invented PowerShell Jeffrey Snowver. And he was one of the best mentors that I've had. He actually left Microsoft. I went to Google recently. But he was like

really, really impactful for me in my career. He was one of my main sponsors. And I ended up getting to go to one of these tech leaders forums. I got to mingle and talk to all the people who were like there. It was really, really interesting, really cool. You mentioned that that mentor was incredibly impactful. What was the things that he was telling you that made a difference? A lot of people I want to say sugarcoat, like how to get places, how to get promoted, and they'll give you very generic feedback. You have to do a part of that's super impactful. He was very, very much directly. We should go talk to the people who decide and ask them, like, where you are. And it was jarred to me because I never thought about asking the teacher for why it, like, no one ever tells you, you have to do X to get promoted, exactly.

And it never exactly works one to wise. It's like, you have to have more impact. So make sure you're working on something that's like, you know, super impactful. And maybe you aren't now on change. He was like, let's go to the source. Go to the host. Let's go talk to the CTOS. Let's go figure out like what it means for you and your role.

And I was like, that is super. helpful. Because it helped me understand what I should and shouldn't be doing in a very, like, real way. It wasn't just arbitrary advice that just happens to you. It was like very explicit. I had a second mentor. I had done some, there's this thing where you can get feedback from different people in the company, your manager, your peer, et cetera. And it gets turned into a package and they give you feedback. And it tells you your strengths. and what you're good at, what you're really bad at, what you're, how you're under stress, all these things.

And my first reaction is, oh, my gosh, I'm going to have to fix all the things I'm bad at. I got to figure out how to, you know, get leveled. And my mentor was like, no, no. Take your strengths and amplify them even more. You could work on the things you're not good at and be average at those or you can work on things that you're really good at I'm a superhuman at those things.

And it, it broke my brain because up until, and that was like, I want to say five years ago, up until then, I had been thinking about, man, how do I make sure I am better at everything so I can be a well-rounded individual? I think it was like, no one gets promoted to these roles for being average. You need to, you get to be superhuman in something

that you're really good at that people aren't, right? So that helped me refocus to thinking about finding ways to make up for things that I'm not good at. So as an example, if I form a team, I am not the one that's going to schedule meetings or I am not going to go through every detail of how we ship and all the all the checklist. I am super bad at that stuff. And I will make sure I have someone who is really, really good at that stuff. So I can focus on what I'm going at. So, Bacet helped me reframe how to think about amplifying why I do well to kind of get more impact. Makes sense.

I mean, it's kind of like power law type of thing. At the top is where there's the most insane returns. Just take those things and go further on that exponential. Exactly. It's exactly that. You mentioned a lot of these impressive engineers. And I think as a distinguished engineer, you have a unique perspective because you can see what is impressive with a critical eye of a great engineer. What are some examples of

other engineers that you look up to and what makes them impressive to you? I can talk about some of the well-known ones and then talk about like just people that I work with in general that are impressive for different reasons. My current team, they're like five other partner level engineers that have been here 20 plus years that are just really good for different reasons. like experts in the GC one person is like a super coder like just he just codes 10x

people complain about and there aren't 10X he's 10X he just produces way more cool than everyone else combined right there's one guy who like literally seem to know everything about obscure things you would never understand and you're like without having to have seen it yourself

there's all kind of stuff stuff about C stuff about compilers, stuff, both the OS and you're like, how does he seem to know everything about everything, right? And then there are engineers who just seem to know what to build and have a good eye judgment. So I'm on the C-sharp review, design review team. So we meet every couple of months and we review C-sharp features, right?

New features come into language. And I'm on there with Anders Heelsberg, who made C-sharp, right? So like, what I say doesn't matter. Well, he says matters. I mean, it does. It counts. but the way he communicates like the way he gives feedback

for what feels good and what does not feel good he always does it in a way that is very much like he is not talking down to you I mean this dude invented four languages are just like what everyone uses and yet he can still talk about it in a way where it's like you know some people are really smart and they talk down to you and you feel dumb

because he's like oh he's super smart and I'm dumb he does it in a very pragmatic, practical way. Then you see the code he commits, and you're like, dude is inventing types of him theory that we haven't even seen before technically. Insane. So I admire a lot of, like, watching people like that spread their impact.

Mark Rosanovich, who's CEO of Azure, famous for his Windows tools. He still codes, and it blows me away sometimes. Like, he actually is working on something right now. And he sent an email two days ago. And it was like, holy crap. And it was very dev, a dev-centric email. It wasn't a high-level we should do X.

It's like, no, I wrote some code. I improved the performance. And like, here's a result. And I was just like, how does you have time to do this? So I think whenever I see high-level engineers or I see still coding like that, I get really inspired. It's really easy to fall into the meeting trap. Actually, when I went partner, I fell super steeply into the meeting trap of like I was in meetings all day, every day.

And I got really sad. And my mentor said, as an I-C, your job is to have like, you need to think and to build stuff. So minimally on your calendar, block eight hours a week minimum to do that stuff. And it took me a while to change my brain to say, I can just say no to meetings. Declient, decline, decline, decline, decline. Mark, Eric Codd. So I think the next set of questions want to ask you, because you have a public presence on Twitter,

there's all these top tweets that you have that I think are really interesting short thoughts that I'd be curious to have you expand on. Yeah. So I think the first one is, talking about university courses. And you said that there should be a university course that explains how to refactor code, how to make changes to it without breaking an existing code base. My question to you is if you were to design that course,

what would some of the key concepts be? Having been working for this long, though, in industry, computer science is not software engineering. It's not even, it's not even close, right? computer science is learning how to learning the science of computers and bits and bytes and the math and algorithms and you do a little bit of things that are software engineering like but it's nothing like software engineers so when you get your first job you spend a lot of time just trying to understand what's there so you can surgically make your first change and not destroy everything really don't break

the bill don't break everything else so I think if I were to have a course you would be thrown into an artificially big code base. We would have maybe it would have to change every year because students will just copy from the previous year. So it would change every year, different code base. And your job is to make a bug fix. You got to fix a bug in this code base and write a test for it. And just the skills you learn being a code archaeologist

is so different from just writing by an L.E.C.C. question or doing a homework assignment that is just like this one thing in a textbook, you learn a lot of adjacent skills from just trying to figure where to put the code in the first list. I think it's funny. I think thinking, I think it would be super useful. Like every, every assignment is making one, one fix. And maybe you can set up the code base such that it's not super hard to figure out what it is,

anyone with enough time, like, you know, we can figure out and made it this one triple change. and add one text. But I think a lot of people's jobs are tweaking software that is there already. Not everyone gets to create new software. If you work on Windows, sure, you'll build new components, but you aren't going to change the kernel unless you're going to do a new OS. So yeah, super useful skill. Yeah, I think there was another set of tweets that I saw that was kind of around this idea

of that tech interviews are focused so much on writing new code. but actually the real high leverage skill is debugging it. Yeah, what gives you that thought? Maybe you can expand on that. So early in my career, I worked with a ton of engineers who were, and on the Donnet team, we had a lot of engineers who just worked at the platform level. So I got to see firsthand people diagnosed crazy crashes, risk conditions, spreading issues.

I got first hand, a firsthand steeped even watching, people's mindset when they go to diagnose issues. I thought to myself, like, there's kind of two skillsites that are, maybe you learn some coding, but they're just not the same skill set. And if you think about building an application, deploying it, shipping it, and then getting craft reports trying to resolve issues, like trying to figure what's going on in production, there's this second skill set that is just not writing, like not authoring code that is how do you even think

through debugging issues. How do you know which thread caused the exception? What tools do you use? How do you think about how I got there? And I talk to myself, it would be fun to have an interview where you give someone a crash dump or something. Like, hey, this app just crashed,

like figure out what the problem is. And you aren't trying to see if they can solve it. You want to see what they even start doing. Like, do you start adding logs? Do you rerun the program? How do you think about risk conditions? Do you, like, print thread IDs and try to figure out interleaving? Like, all these interesting things come out of watching someone try to diagnose problems.

I, it's funny, I have the highest respect for engineers who can be thrown into, like, a problem situation where they don't know the code base super well. And they can kind of solve the issue. Super fun story. I remember being, this is early days in Azure. there was this very, I can't remember what the site was, but there was a very popular site that was going down and was running on Adjord. And I'm in like all, so I was up late.

It was 1am. And my CBP sends me a message, like a DM. It's like, hey, you free? I'm asleep. What? Yeah, I'm free. I get added to a call that has like 100 engineers trying to debug why the site is crashing.

And, you know, we call the team who was working on it. It was some other company, but we were helping them as an engineer's platformer self, trying to debug the issue. And you could just see the different people's skill sets, trying to figure out what the issue was. And we solved it eventually. It was a concurrency issue somewhere in some dictionary that caused a risk condition. And I thought to myself, like, this is one of the skills that you need to have.

as an engineer. Like writing code is just it's a small piece of your overall skill set. Learning how to debug and think through issues is like another big big chunk. Yeah and as evidence of that being very impactful, I know some companies, you know, every company has their different archetypes and you mentioned like super coder, also known as code machine in some places. There's also I've heard the archetype fixer too and that's that's a really cool one because it's been described as, someone drops in somewhere, they make a one-line change after tons of investigation, and it gets two times better, three times better or something like that.

Oh, my gosh. We have some engineer on the team who there'll be a thread that I got started off. All per issue somewhere in GRPC call. And I'll add the engineer the thread and say, hey, can you look at this? Boom, boom, boom. Here's a trace. And I'm just like, oh, my gosh. It's solved.

It's solved. So impressive. Another tweet that you had I thought was really interesting is it says, lukewarm take, the lower on the technology stack you sit, the less mistakes you're allowed to make. What made you think of that? Did something break super low level in the stack somewhere? I have to be working on something.

So I work on platform. So the way we think about software is way different from, you know, higher level services or even web, web front lines or whatever. I think maybe I have been working on something that broke. I mean, a lot of things break that are just kind of insane. The things that we change, that break services are absolutely unheard of. We will change the order of how things come back in a method and it just snaps some some company's website goes down. So I think when you work at that that you gain an appreciation for the kind of changes you can and can't make.

I think that tweet maybe was inspired by one of these bugs. Because I work on, I think at that time I had been working on first party adoption of dot net. And we had seen a couple of people upgrade and hit issues that made us just completely shocked. it was like, how did you find that bug? Like, no one has that. What do you mean you have 400, 400 arguments to method? Like, that's not. There's some limits somewhere that, like, that can be a real problem, right?

There's another tweet here. And that was really interesting. It's about promotions. You said that when you got promoted to a senior software engineer at Microsoft, you remember thinking that other people were smarter than you and should have been promoted first. And you would have thought they would be angry. but the opposite happened.

That actually having good coworkers matters a lot and people weren't, you know. So yeah, what's your thought there? This is, you are bringing about some good memories. So I remember when I was going to senior, I actually, I was actually a little worried about getting what it before, because I had it on a really fast path. And I thought, I mean, maybe it would make people jealous. It was like, why not me?

And when I joined my team, I think there were four people from MIT and two from CMU. And I had gone to Florida Tech. And I was like, okay, these people are way smart than me. So, like, my way of working through imposter syndrome was just to, like, work really hard and, like, be a busy bee doing stuff. I think I understood that when I got promoted a senior, that the impact was not about being intelligent. It was not just about like getting the highest grade or being smart. It was like, are the things that you're working on being impalpable with the business? And that was the shift where I began to understand like, okay, it's not just about what I know.

It's not just about that this person on the team is really smart in area X. It's like, can I take all that and produce something that is impactful? And that promotion helped me see, okay, that was the Nuget thing, the Ciglar thing. that's how you get promoted. That's how you add impact for the team. It's not just about knowing this thing about this feature, about this area, about this OS. Because I always felt like, man,

I don't know enough about technology X or about area X. I got to go deeper and learn more. And the question was always, is that for you? Or is that for your career? What's it for? You don't have to know how, I don't know, maybe maybe you should, but you don't have to know how TCAPE works. to get promoted to the senior.

I'm sure people don't know the details of how it works, right? I think that promotion for me helped me separate, like, being smart from making an impact. It's like, okay, promotions, impact these promotions, being smart is something else. It's just like knowing, knowing more stuff and being helpful for solving problems.

And the second part was, my coworkers were happy for, me, at least outwardly. It was, but I was, I was really worried at the time because it was like new person, joint team gets promoted really fast. Like, do people see that as why not me or do they see it as yeah, that makes sense? Right. When I asked questions about other people who kind of went up really fast to my period at

the time, they would say things like everyone knew it was going to happen. Like, there's certain people where people kind of know where it happens and you never know if that's the case for you or not. Or if people are this like, man, I don't think that person deserves it. So you've been working at Microsoft for over 17 years now and one of this tweets that you have is talking about big company tips that you have. And it says, before you change roles, ask when the last reorg was. What's the thinking behind that advice? The big companies are a machine. And I remember someone telling me really early on that, like, and maybe it was tongue-in-cheek.

It was like, when you're, when you are an executive vice president at these companies or a CVP or whatever you are, you show that you're doing something. It's like motion. Like, reorgas are motion. And motion means that you're changing stuff. And the only thing constant is change. these big companies. Like, there's always a reorg plan. There's always a reorg coming.

There's always a reorg that just happened. And you're trying to figure out in between the reorg moments, what were, like, who were the leaders, what was the impetus, what caused it to happen. I mean, you can never know when that's what's coming. But learning about the previous one is super, I think it's super important just to understand like where we are, where you would be heading, right, in that dimension. My org had a big reorg recently. Previous meta person now runs Jay now runs my org.

And I think it's super important to know that because it helps you figure out what the purpose is now. Right. If it just happened, it tells you a lot about where the org is heading, where the team is heading, where things are going. I think it's easy to kind of change teams or move around and not think about the overall. players with that org is going. But then Microsoft is big enough that is like every new org is a whole new company.

So it's definitely worthwhile trying to figure out where what the goals are of that org, where it stands, no, what happened last time, kind of thing. I bet I tweeted that after

either talking to a mentee who had been Rejorg and I think there had been like four in a row or something. That's crazy. Or it happened to me. But yeah. I see.

you're saying you should read the behind the scenes of the reorg and what that means for your career in the future yeah oh yeah i heard someone say something to me recently that was really good advice it was when you're looking to change jobs don't think about the things you love because they'll be easy to do think of what the things you hate like what can you not stand about like working in the area or an environment or whatever it is and go look for that if you see that that'll be that that'll be the thing that will be hard to get around our work through. Let's say you hated open space and you wanted a closed office. If the company was open, like, don't go to the company that is open because then you'll

be unhappy, right? There are better examples that are probably more toxic about people, but that's a simpler way of describing it. You've been at Microsoft for a long time with your entire career, even including your internships. I'm curious what has kept you at Microsoft as long as you've been? Yeah, every time, yeah, I think about this myself a lot, like what keeps me here. And I think I am part of the generation of millennials who brought the curse of like our boomer parents, like trying to stay in the same place forever. I have a lot of friends that jumped around and they got paid for it and it was really good for them in their careers.

I want to say I maybe didn't take the same pack and it kind of worked out. I had a couple of times where probably the most impactful time where I maybe almost left was when I was senior my boss left and went to Twitter pre-IPA Twitter and a year in she tells she pings me and tells me to come like go interview at Twitter and I actually interviewed

at Twitter and at GitHub it's funny, GitHub on Twitter at the same time and I got to I got both offered and the offers were pretty good. And it was probably the first time in my career where I was like at a crossroads because my career had been going fine I was working on a signal owner.

I was like on the up and up. But then here's this offer that seemed a lot better and they're pre-IPO companies like, should I should go? And there was a lot of deliberation as to like if I should go or should stay or not or whatever. I ended up staying and it worked out, but I will say the morning, like Twitter went public. Instant depression.

I was depressed for like a week. Oh, my God. Oh, my God. What kept you at Mark? Because it sounds like those offers were better than what you were making at the time. Yes, they were. So when I got, they countered. And the counter was fine.

It wasn't like, I mean, I guess looking bad, no, it was pretty good, but it was fine. But they had me talk to like our executive vice president. And he was like, you're going to be like a state engineer in like five years. I mean, he definitely oversawed. But I was, I think maybe for me, it wasn't just the money that made me stay. It was like I had been working on something that had built an impactful. that was, like, built permissionless.

I had, I think at the time, I had been getting a lot of autonomy at Microsoft and leaving would have been like starting over. Probably one of the things that people don't talk about when changing roles or leaving or getting a better offer somewhere else is you build up a network, a network of people, a network of, you know, a track record. I can kind of work on what I want to work on at the moment. At that time, maybe not so much, but I think I had been given more autonomy. And when you're weighing the like, should I stay or should I go is like money is one thing.

The other is like, are the people good? Not just good engineers, but like good people that you want to work with. There is the people aspect, the money aspect, the network aspect. aspect, all these things kind of matter in the soup. And I think I stayed because at Microsoft, I had been getting my fix of working on a new thing every couple of years. On my LinkedIn, there's like a new project every two years. And now it's like by design.

I think it helped me not get bored or not like kind of like be. I didn't feel the need to go somewhere else to do what I want to do because I thought like I could do it on Microsoft. so that that kept me here for this long. I mean, I won't say that I hadn't thought about leaving every now and then. It does come with my brain every now and then, but I think so far, the people, the pay for me is fine. The people to pay the project, the impact I get to have, working on what I work on, is a big, big thing for me as well. Do you think that if you had a mentee today facing the same decision, so they're,

they're at Microsoft and they're doing well. And then they have a pre-IPO, opening eye offer or something better than what they have now. Well, would you tell them you should stay at Microsoft or would you say, you know, maybe go with the risky thing? I would tell them to go. So, fun story, Ashley had a mentee who got an offer from a separate, a different company. but they weren't in a place where they could do their best work. So the combination of the offer plus that, I was like, you have to go. I said they're going to counter, but you have to go.

You can't stay here. You should go. If I had that for myself, maybe I would have been gone. I would have been gone. You had this interesting tweet on job hopping that I thought was maybe relevant now, is that you said once in your career, you should work on a project long enough to see the long-term impact of your decisions. It's a humbling experience.

That's a good one. So it could be better for long-term growth in some cases. Yeah. So what I would say is so that one, that tweet was inspired by my career has always been this like work on a thing and move on. I would still have ties to the thing I worked on, help people that are working right now whenever things go wrong or whatever. But the thing that I have worked on for 10 years, Dotnet Core,

was the longest of ever, worth my career, ever, ever. And I think it was a good change because it really helped me appreciate it, like deciding to do something in the first two years. And then, holy crap, seeing the impact of that decision, whether it be bad or good, right? it gives you a whole new skill set perspective on how to make decisions. And for some things, it's obvious. And you can say, okay, well, we didn't understand at the time, the scope or the scenario

or whatever else. But things that didn't seem important became important. One of the jokes that I make about, you know, when you work on something for 10 years, all the small issues you thought were small that were just like, we can do it later, will become big issues at some point. Like somebody will hit everything that you punted. And it happened. All of it happened.

And I thought, like, I think maybe if you think about 10-year projects, 20-year projects, who knows if it's good for career growth? Maybe not. Like, maybe if you work on the same for 20 years, like, oh, my gosh, not great. But it'll teach you a different skill set. That is, like, you get to understand the implications. you get to understand, you know, if you were going to the next version, you would have much more insight into like what you messed up.

It's really hard to appreciate what you messed up. When you like do a thing and you leave, you ship V1, all good, new project. But I don't, I don't fault anyone for like doing both things because I've done both too. Yeah, I could see it better for, I guess, developing judgment. But I, and I could also see it being, you know, imagine a career that's a leg of jumps. that could and if assuming every jump is higher than the other that person's probably going to have a lot of career growth but if all the projects they start just kind of go downhill once they leave I wonder what it does for their pattern recognition judgment yeah yeah exactly it's funny

I told someone I don't know exactly how to describe the ingredients that make up a successful project but I can tell you when I'm working on one versus when I'm not. And that is built up over time and experience in like seeing which things work out, which things don't work out. It's kind of fine-tuning, I guess, an internal model in my head. Okay, this, this has the smell of something that can be successful versus not. And there are some things here that I've seen that work out well in some things that are not really good and super well.

And yeah. Coming to the end of this, I kind of want to. ask you some just high level reflections and things. One thing I'm curious because you're so high up at Microsoft at this point and you've been there for so long too. I know the common perception is pre-Satia Microsoft was very different from post-Satia Microsoft, at least in terms of stock performance. Did you notice anything internally, like the culture shifting when Satya became CEO?

Huge. I mean, I always tell you. hires that it's really hard to think about the culture ship between Satya and Balmer because you, I lived it, right? You, like, I was in it. And it's really hard to see the big jumps where we are now to where we used to be. Because it literally happened gradually. It was like things were rolled out and there's a lot more.

The culture just changed completely, right? probably one of the biggest ones that I noticed because I experienced this when I joined there was teams competing on the same angle like two different teams that I think historically there's been a Microsoft used to do this thing where two

end teams could work on the same end state and then one would win and who knows what happened Bistanda and Riore or something else there was a big focus on collaboration over like just like being the first to do something. I never experienced it myself on my team, but I definitely worked with teams who you can tell

we're kind of building the solution before knowing what the problem was. There's a lot of that I saw when I was, and I was an observer. I was like very early in career, like observing how people interacted and culture-wise and just the way people interacted changed. like meeting culture

like how meetings would appear emails things that seem so obvious in hindsight like if I look at how people would communicate in meetings now versus emails

versus how used to work like remote friendliness versus like how people work in teams like I remember being in a meeting and someone raising their hand on teams I always like raise your hand for talk

like this is not like because I had I had grown up in a culture where you would just talk, right? You just talk. You don't, you wait for a pause and you talk. You don't, you don't raise your hand to talk or you don't. Maybe it sounds crazy. There's a lot more consideration for everyone else.

It wasn't just, what's it called? Highest paid person's opinion. I think that's kind of how Microsoft, when I joined, like, if you were in a meeting with people that are very senior, it's hard to get awarded sometimes. And if the most senior person was, load and aggressive, like, people that

didn't think that way in the moment would not get a safe. I think one of the big changes was in, like, how we communicated as a company, as a team, collaboration became a thing that was part of your review. So, like, if you were not using,

if you were not trying to use things that other teams built, like you were dink for it. If you were going to copy and create a clone of someone, one else's thing because you're special, no, the incentives push you in the opposite direction. I think that's probably the most impactful change. That and that and the style of comms was like a big change that I observed just like existing in those times, those times. I see.

Okay. So the culture shifted through performance incentives and maybe just some of the stuff that was messaged, top down. Yeah. Yeah. And the behaviors that were being modeled by, like, the leaders. Like, literally in meetings, people raising their hands, people calling people who haven't spoken. Like, imagine you're in a meeting and there's someone really quiet that has really good thoughts, but maybe they don't like to speak up in meetings, pulling it of that person in the meeting.

Like, I remember when I first happened, I had never seen it before. I had never seen someone say, hey, Ryan. You're quiet. You've been quiet the whole time. What's your opinion on this matter? Like, there was just people talking and then you would leave. Now there's a lot more. It's much better, much more consideration for others.

A lot less people screamy, shalty. I was in a mean, like, really early in my career, people were like shouting. I remember thinking to myself, like, there's no. I'm going to have to show us at some point. There's a famous XKCD comic about the culture at different companies. And if I recall correctly, the Microsoft one is a drawing of people with guns. The guns. The guns. Yeah. It's so funny. I think that picture is funny. And it's definitely not guns at all. It went from guns to ambivalence. Like, don't bother me to collaboration.

So I think that progression is probably the biggest change in between Bomber and Safia, the joke about the guns to, I don't have a gun at you, but, you know, as long as you aren't going to, like, disturb my situation, like, we're good to go. You're over there. I'm over here. It's all good. Two collaborations where, like, we incentivize collaboration. You get rewarded for collaboration, though.

So I think that was the biggest, the biggest shift and change I saw in the culture. When you look back on your, your career so far, do you have any major regrets that people can learn from? That's a good question. Major regrets. Major, maybe not. I would say early in my career, I was super arrogant. I was very arrogant.

You could probably find my GitHub. If you look at some of the GitHub comments and the tone, I would say I was lacking some empathy in a bunch of different places. One of the big shifts that I think my brain made over time, learning how to build teams and kind of impact through others, was like patience, patience, empathy. Those two traits help help a lot with, like, growing teams and growing, like, influence and people, right? It's not just because you're right.

Being right means nothing. This is not important, right? Being right is, like, one of many things. And I used to want, I used to, like, I'm right, therefore everything else is, like, we'll follow on from there. I think learning over time that that doesn't really matter as much because there's a lot of shit's agree. when you're in top-range areas. This is not the most important thing. So I think early in my career, I was very much like,

yeah, I'm right. I don't really understand where we're having this goal. Why are we still talking about this thing? I'm right. And every non-net, it'll creep out. But, like, I think I have a lot more self-awareness now whenever that's not the most important thing for the moment, even though it's like a thing still.

I learned over time how to dial it. but in general yeah maybe the fact that I didn't leave and go to Twitter because they would have gotten like a ton of money as a senior engineer or go to or go to Facebook I had a bunch of opportunities

I just didn't I didn't take it super early on okay one regret that I do have that is not directly career related but like maybe in the same ballpark I had a friend in 2008 who sent me a message he was going to do a Bitcoin company. I was like, I don't know about this crypto thing.

Dude has so much Bitcoin, though. What, what? Oh my God. That's so funny. Yeah, that one. When you look back on your career, what was your work-life balance like throughout? I used to ask this by saying there was no balance. There was just work hard, play hard kind of thing.

I would say no. So someone told me recently that I worked by bus isn't about 9 to 5 and stopping. It's about what things give you energy and what things drain energy from you. So early on in my career, I was working all hours. I still do because I enjoyed what I was doing. I may be a little too much. So I would just like have to dab back every now and then. But I enjoyed what I was doing.

I said I worked a lot. Like at work, afterward, like on different things. Um, because programming for me was not just my job. It was like my passion. So I never forget one, one summer I came back from vacation. I started making games just like for fun. Um, I learned a lot of making games. I took that into things that worked I was doing and more stuff.

And for me, it was always, I just love building stuff. So I want to build more stuff. Um, what I would say is draining now is like, meetings that just don't feel like that they have a purpose. If I were in meetings all day and I felt drained after work and I kept doing more work,

that to me would feel like no balance because I want to do stuff that isn't meetings, but I'm not doing that journey day and then I'm going home after hours doing more work. That is like burnout quality. So I would say like balance was always, I work a lot.

I'm absolutely over-calling. for me, I love this career. It's kind of insane that I get to code for a living. So I see that as like a privilege that I'm going to keep doing until I can't do it anymore. Yeah, I think when I look at a lot of people's careers who have been, you know, as successful as you, that's one of the unfair advantages I see almost everyone has is they have this innate intrinsic motivation. So they work a ton of hours just nonstop. And a lot of like you, a lot of people love it.

And that is such an unfair advantage. It is. I saw when Andrew Carpathie's taught, and he said 10,000 hours to get good at anything. And maybe it's not true. But I, early in my career, and maybe even though I wanted to become a very good software engineer. right and people always ask me hey what book did you read what did you what did you do to become a good software engineer and I'm like I wrote and read a lot of code like just anything you can get your

hands on and there's so much more code no there you can read consume and write and I'm not sure if it's good advice but why I know is that I did not get good at software engineering or building building a programming, whatever you want to call it, from like seeing something online or reading a blog post or it's like, just do it. Like build everything. Databases, distributed systems, games, like, everything you build will teach you a new skill that you don't even know you have until later on.

My GitHub is a graveyard of project. I just build stuff and put it on there. I want to learn how to do multi-wit. I don't forget, I tried to build a fighting game when I was 16. I wanted to build Street Fighter. So I got all the art from somewhere online. I started to build a Street Fighter clone. And it wasn't for any real purpose.

It was just to learn how to build a fighting game, right? How do you make key combos work? And how do you make that stuff work? And that pattern of like, I need to know how this thing works has served me like to this day. I need to understand how the thing I'm doing works. How do I get this thing to be on that thing? Yeah. So I love what I do.

And I think that has helped me do it more and get better at it. And then last question, if you could go back to yourself when you were just graduating college and entering the industry and give yourself some advice, what would you say? Oh my God, Nigelich, you're freaking salary. When I got my job, I did not know that I could even negotiate. I would have gotten more offers.

I mean, looking back, it doesn't matter right now. But if I was going to talk to a new college hire getting a job, like get multiple offers. I like bump up that money. Bump it up. I watched my friends do it. I was just like in shock. Like I'm from Barbados. I go to the States.

I get an internship. I get a job. they gave me the most money I've ever seen in my life and I'm like, thank you. Thank you. Thank you for the money. I have no job.

To hear kids talk about, yeah, I said no or I said I'm going to go check out Google first or Facebook and get offers. Now it's just like, what? And that just became normal. That became the norm and it just blew my mind. I couldn't rationalize what was happening.

I do think it's definitely worthwhile doing that. I've seen kids do it so long. This is so impressive. This is like, this kid is telling us no. And I've been, I've been like on enough hiring committees now to the hire interns.

And I'm watching the back and forth between this kid and the recruiter. And I'm just like, this kid's a genius. It's buffing up. It's amazing. Mass respect. Awesome.

All right. Well, thank you so much for your time, David. Really appreciate it. Is there anything that you want to say now or maybe where can people find you? I am available on X, Discord, Blue Sky. Are those the main socials not?

Are there more? I mean, there's LinkedIn. I don't know if you use it. LinkedIn. LinkedIn. It's funny, LinkedIn has become a social network. It's the most bizarre thing ever. I am on all these things.

Tweeting about dot net and AI and all kinds of programming stuff. Awesome. I'll put it in the links in the show notes. Thanks so much, dude. Awesome. Thanks for listening to the podcast. I don't sell anything or do sponsorships, but if you want to help out with the podcast,

you can support by engaging with the content on YouTube or on Spotify if you want to drop a review. That'll be super helpful. And if there's any guests that you want to bring on to, please let me know. I feel like sourcing very senior ICs. There's no well-studied list out there on Google that I can just search this up.

So if there's someone in your org or at your company who you really look up to and you want to hear their career story, let me know and I'll reach out to them.