Engineer to Manager and Back Again: Interview With Lee McKeeman

He's got three fang job positions on his resume, but that's not even the most interesting part. Hi, and welcome to the Dev Leader podcast. My name is Nick Coantino and I'm a principal software engineering manager at Microsoft. In this video interview, I got to sit down with Lee McKeman and we chat about all of his different experiences in his career, which I thought was super awesome. As I mentioned, Lee has been at three different fan companies, but the most interesting part that I found was that he went from being an individual contributor to a manager and back to an individual contributor. Now, in general, for these video interviews, I like to make sure that I'm getting the guest to cover their experience in their career to explain where they got started and how they got to where they are because I think that that's really important for all of you to hear. And I reached out to Lee not because he has different Fang experience. I reached out to him because I thought it was super interesting that he became an engineering manager and decided to go back and you'll see in this video interview that might not be the last stop for him yet. I think that you're really going to enjoy this conversation and Lee has lots of super interesting experiences to share. So sit back, enjoy and I'll see you next time. Lee, if you don't mind, would you uh give us a little bit of background for I mean, you can start as early as you'd like in in terms of like your career growth or knowing that you wanted to even get into like the software space and then kind of to where you are now. >> Yeah, sure. Um, so for a long time in school, um, talking about like preun university, like I didn't really have an idea. Um, I was like high performing quote unquote in school and in gifted programs. Um, and this is a realm where I consider like this sort of doubly exceptional or whatever. I have neuro differences and have this like giftedness label, but those um kind of, you know, I would just say it as a different a different brain, not like a better or worse brain. So, um I but I didn't know it was like, oh well, I'm good at math. What? Okay, cool. What does that mean in terms of a career? There wasn't a lot of direction there. and like took a couple of those like career surveys and it was always like coded 99 unknown or like not clear or but it was there was never like a you should do this. So I was always like okay well I don't I don't know what what do you do? Before we move on this is just a reminder that I do have courses available on dome train if you want to level up in your car programming. If you head over to do train you can see that I have a course bundle that has my getting started and deep dive courses on C. Between the two of these, that's 11 hours of programming in the C language, taking you from absolutely no programming experience to being able to build basic applications. You'll learn everything about variables, loops, a bit of async programming, and object-oriented programming as well. Make sure to check it out. >> And I had an interest in computers, but I didn't know what that looked like and honestly kind of thought it was the only thing and thought maybe that's what I would do, but didn't know what form that would take. So, you know, early on I would like build websites when that was a thing people still like did and that was like unique and interesting where now that's just like you go on Squarespace or whatever and you press some button get a very cool looking thing and um you can publish your content and whatever. So >> anyway um eventually in senior year of high school um when I was whatever you know 17 I took a like AP computer science class. Um I didn't take them earlier. They had a couple of years of it at at my school, but I didn't really know about it and wasn't thinking about it. And then it just sort of clicked. I was like, "Oh, this is a way to solve problems that's novel and interesting and like fits my brain in a very specific way." And there's, you know, the binary math and like all the way down was interesting to me. Like CPU up micro code, everything was just like, "Oh yeah, like this this fits. This makes sense to me. I could do this." and then realized like oh there is this career in software that was always very sort of magical to me like I knew that it happened. I knew that we used software but it was just like that's some sort of wizard wizardry. I don't know >> what that is or how you do that and then like peeling back the layers like this was pretty rudimentary in terms of like write some you know console applications but I think it's a great place to start but it was you know just scratching the surface and it was like the first time that I wrote code that produced more output than the length of the code it was like ah that's now something is happening because it's like you can write hello world but you've got you know depending on the language uage it could be one or two lines but I was like learning in C++ and it's like you know 15 lines and a bunch of imports and I don't like just a whole bunch of boilerplate to get this one line of output but I think it was like doing the 12 days of Christmas song or something and like that like using loops and generating things and having conditionals and then having this output come out that again is like more than your code was like ah okay like this can do something this does have some power There was also an incident with like we were doing a towers of Hanoi and you can like I don't know if everyone is very familiar with that but you're like moving discs of different sizes between pegs and you can't have a you know disc larger than another on top of one another things like that but >> it you know there's an algorithm to do this and it's very repeatable and it's very good thing to have a computer do. It's a kind of a considered a logic problem for a human to do but for a computer it's very like straightforward algorithmically. Um but it can also explode in complexity because of the number of moves and the rules. Um so I was like well I want to do I don't remember the number but 20 or 30 or 100 discs. This is billions or trillions or whatever of of operations that I was like outputting the like cuz it had to run overnight. So I couldn't just like print it to the screen. I was like outputting to my shared space on a shared drive and this was you know 2000 1999 whatever. Um and so there wasn't a lot of like policies in place and quotas and whatever. So like completely like filled the shared space for everyone at the school with that output and there was a a discussion with the the teacher. It was good to they didn't approach it as like you're wrong or bad. It was very much like an interesting conversation about shared resources that like served me well and was interesting. But um that was like one of the things that was like oh I I like I can learn something about scale and shared resources from this experience. So then going into college, university, like I I did computer science and in the meantime I was working like I worked at an early.com that was providing um free internet in malls and that was like novel at the time to have like high-speed internet. Highspeed internet was just like crusting then and becoming a thing people had at their house. Um, but that was doing a lot of it and like I got a Microsoft certified professional cert in like Windows 2000 and I thought like well that's how I'm gonna like sort of tide myself over until I'm like a real software engineer. I'm going to do it work and I never expected to like do software work right out of school. I didn't know what that was. I didn't know what careers in software actually looked like. So throughout college I was working at the IT help desk at the university. I went to the University of Texas at Austin. Um, and you know, also worked at like a real estate place just like maintaining their computers and doing some, you know, whatever whatever needed to be done. Um, and so when I did get out of school, it was like, oh no, you're supposed to quote unquote get a software job right out of school. They don't expect you to have experience or whatever. And it was like, oh well, that's interesting and novel. I just didn't have that. I didn't have anyone I could ask. I didn't know like the internet was a different place then. I'm sure one could find a Usenet group but I didn't know where to where to look. So um then it was like okay well I'm interviewing for these jobs. I don't have experience. I ultimately got a role as like a software um analyst was was the name of the role and it was working at a healthcare informatics company. So they built software for to use in uh clinical laboratories and in hospital settings for like nurses to do their charting and ordering and things like that as well as like again in the laboratory like getting results off of instruments and things like that. Um and I had no like experience in healthcare and this company was sort of interesting in that way and that they would bring us in the sort of like computer people, the tech people. Um, but then we really had to lean on our product people who were former nurses or lab techs or whatever that knew that side of the world and could explain it to us and we what regulations we needed to follow. And so it it was very interesting to like get into that domain and and actually learn that like I only thought about software as like this is technical. we just like do something and we make the computers do something and we run these algorithms. And then getting into the real world and being like, oh, humans that don't really like computers maybe or aren't very into them are going to use this software to actually perform a task and do their job. And it really matters like if the software works or not. If it's not, people are getting worse care if there's certain kinds of bugs. like people like it it sounds very dramatic but like people could die and that >> you know having been in like computer e ethics classes and the like the 25 and like someone got a you know too large of a dose of radiation and was killed that seemed >> sort of like I I knew it happened in real life but didn't think about actually working on a system that could have that impact so then you know the work that I was doing was fixing bugs it it wasn't like writing the new software as a software analyst. It was something broke in production. It was sort of frontline like you know we had a call center of of you know sort of technical support but they were they were doing mostly like script things. They were smart people. They were doing great work in working with the customers directly, but they weren't like getting into the source code. And that was where we got involved. If there was, you know, starting or stopping a database instance or trying to figure out why something was hung somewhere and lock contention or then it did get into the actual software. Is there an actual software bug here that we need to fix? Um, and I really appreciate having done that. Um, it it it was hard. It was a little bit thankless. I think I did want to be writing the software that you know Greenfield things and all of that but spending that time as a software analyst and then they sort of like created this new role cuz it was a new team and like the company was 20 years old but it was just starting to grow and get bigger and have these sort of support functions instead of engineers just taking it on directly who are building the software. So they created this like software support engineer role. Then they promoted myself and one of the other analysts into that job. But doing that job for a few years really changed the way I thought about software and thought about maintainability and sustainability. And I really appreciate that and didn't have to learn that later. like write software and then put it into production and then think about how to support it and when things broke and what kind of logging you need and what kind of you know reliability you need. So um that that was an interesting place to um to start. Um ultimately I did move into like building you know the the software but I was in the lab side which was sort of the the bread and butter of the company originally. That was how the company started. But that also meant working on a 20 or 25 year old forrans system that was running on HPUX. And like that was just a very different world. that it seemed like, you know, then what the the cool thing that we were working on was like a clinical system that was built with Pearl and like now Pearl is kind of died, but at the time that was like a cool new thing that was a you know more modern language of course than for so um but I I dug into it and like learned I like no one in school taught me for. No one in school taught me to code to be perfectly honest. It was very much like computer science wasn't about writing software very much like the program I was in was very like classical in terms of like we're we're we're scientists we you know think about things and we reason about things and how do machines work and how can we expand that >> and like software was just like oh well yeah like we write code to like demonstrate our great ideas but like that's a little like pedestrian. Um, and that that's weird. Like that that is a weird thing that you get a degree that is very kind of thinks of itself as very high-minded and very heady and academic and then like you get that degree to go into software engineering which is completely divorced from that in many cases. Like you write software, there are algorithms >> but like it is not it's generally not talking about the theory of computing like some people might be and some people might be actually writing compilers and micro code optimizations and transpilers but that's very niche in the industry. Most people are writing application software that is to be used by you know humans not just like used by other software people and you know some people do but um that is that is a lot more niche than I thought. I thought everything was, you know, what I loved was like the idea of say like software conversion from one language to another or like running a certain CPU architectures code on another and that like transpolation and like real time and like it was exciting but then also sort of disappointing when Apple like moved um from platform to platform and from Power PC to Intel was the big one. They had gone from 68K to Power PC, but like that was before my time. I didn't know about that. Um, but they just had software that just did it and I was like, "Oh, I guess we're done." Like I guess they >> problem solved, I guess. >> Yeah. Um but like they had acquired that software and it was very specific to their platform but I thought like oh that was that was my Everest and now someone like already finished it. It's it's done. So um it it had I had to sort of shift a lot when I started working into like oh like actual software development is solving a different problem like solving these very like detailed and like great in-depth problems and compilers and all of that is super important and foundational to the industry but that's not what most people are doing. That's not the software that most people are writing. Um, >> that's that's an interesting take too because I think when you're calling out that getting this experience where you're like we're we're solving problems for for people on the other side of this, not like just uh, you know, strictly focused on solving problems in a space of code. Um, yeah, I can I can definitely see that being, you know, like a a good stepping stone for many people where like I don't know if many people realize that right off the bat. Maybe maybe now it's more common that people do, but um I think it's uh interesting. >> Yeah. And I think some people are like learning to code from boot camps and I think sometimes that's done ethically and sometimes it's not. But I think that people do actually start a career that way. And I think it is more practical in a lot of ways. And you know, have I run into places in my career where I was glad that I actually had CS foundations that I learned in school? Like yeah, for sure. But that's the 1% of the time like mostly um having principles and having like you know maintainability and scalability like those things weren't really talked about. I mean it was like oh Hasll has these primitives and like all right that's cool that's amazing in fact but that isn't what scalability looks like in a lot of real applications. Um and so um you know like tail recursion amazing but like when we're talking about scalability so frequently we're talking about horizontal scaling across different machines and systems that can scale in that way and how do you you know actually use shared resources in that environment rather than a single computing like a single server environment and things like that that um really I had to like broaden my horizons pretty significantly to to understand and that and you know the school did offer like some software engineering classes where people like worked on a team on a semesterl long software project and I didn't take that that wasn't a requirement and I instead took like compilers and then a lot of German for some reason I thought that that was a a cool thing um but like I do I use that in my career no but I I learning a different human spoken language was actually very interesting and made me think a lot more about spoken language as well as like programming language ages. So, I'm glad that I did it, but it was really not like >> relevant to the work that I >> directly I guess. And I think my like even my university experience like mirrors a lot of that where like I went for computer engineering and I had a lot of math, I had I had physics, I had circuits like so there was more on the hardware side but even the hardware stuff it was more like foundational principle level things and like I think that in my head going into computer engineering I was expecting more I don't know like something that would have felt applicable. >> It felt like everything >> was like well building a NAND gate from like basic circuits is a >> a cool and interesting thing that was solved 70 years ago. So like it it having those foundations I think is super interesting and I love to know about that. Um, but in my daytoday, like I'm lucky if an optimization problem I think about the cache lines on a CPU, but that's like super rare. It is normally >> we need to get something from a data store and put it on someone's screen >> and like what is most interesting about it is >> you know we have to do that a billion times a second rather than we have to you know do something that is actually like I'm writing the microode for a CPU to you know overcome some vulnerability or whatever and people do that and that's really important um but it's not what I do um right and it's not what most of us do um So um that that was definitely an interesting excursion but um I'll sort of go back to you know working on that software and like moving essentially from um you know HPUX running on PA risk chips on very expensive servers that HP sold um to trying to move our laboratory software to run on like Linux on x86 like it actually did get into some of that like interesting low-level stuff where like the Indianness of these processors are different and so the representation of anything that's a multi data type is different in memory and if we're writing that to disk on you know flat files which is what that system was based on originally like they have to be byte swapped in memory like those were actual problems we were dealing with and it was sort of interesting to have that and I I think that that's, you know, mainly gone for a lot of people. That's not a consideration when writing applications. Um, you write code that it targets a VM or whatever and you never really, you know, get down >> taken care of for you. It's just >> that's table stakes. You don't do it like it is done. >> Yeah. Um but that that was an interesting process and then we were that company was acquired and we had been using Postgress for our you know SQL store and that company that acquired us used Microsoft SQL server and they really wanted us like you know clients had already licensed that and they you know while Postgress might have been free to license it was added technical complexity if multiple different software products were using multiple different data stores. So, can y'all run on Microsoft SQL Server? It was like, oh, we hadn't really thought about that. And it it is something now that is front of mind whenever I take something on is like, do we actually need to care about that? Are we using a key value store? Are we going to put a service in front of our data store so we can change that out without the rest of the software stack needing to know about it? Where that wasn't how the software that I was working on was designed. was very dependent on certain things like triggers in the database and stored procedures and I learned that like those are powerful things that can have tremendous cost if you ever need to make a change or support you know there is changing and then there is supporting both and those are very different. If it's like we need to rewrite our stored procedures well that that kind of is a blow and that's going to take some time but we can do it. But if it's no, we're going to continue needing to work on both. Do you want to write in, you know, PL/SQL and in, you know, Microsoft SQL dialect and like are you going to write every procedure in both of those? And it's like, well, that's >> yeah, that that's hard. Like that's not fun. So like learning about that early in my career was a real benefit that I didn't understand. I didn't know to consider that previously. So then like oh putting logic in the data store can be very costly and dangerous in some cases. So like maybe be very careful about that and like what what features do you use like there are very powerful features in these relational database systems but using them can come with a cost if you ever need to convert or change or support multiple data stores. So is that the right thing to do or should you be pulling that out into your service and only use the data store as essentially like a very rudimentary place where you put things and you know your queries are very basic and so um it was interesting and you know adding that was a a cool thing to do and figuring out certain things that seemed I didn't even know we were using database specific technology when we had an a sequence that autogenerated a key like that seems very basic but >> right >> in Microsoft SQL Server like you definitely can have an auto value key like that is coming from a sequence under the hood but you don't access that sequence you can't use it directly and we were and was that a good software design principle maybe maybe not but it was what we were doing to essentially like pre-generate keys so we could pre-generate relationships before they were persisted to the data store and like that could have been done differently but it wasn't how the software was written and rewriting it at that point would be very costly so we had to find solutions to that and like I didn't find that solution but it was very interesting to see our like database programmers and analysts like trying to figure that out and like ultimately we created separate tables with autogenerated keys just to use as a pseudo sequence for the keys in a different table that was actually going to store the data. And like maybe there was a better different way to do it, but it was like fascinating to see that that happen. Um, >> that's a a really interesting thing to like to pause on though because I think that a lot of and maybe this is more for people that are, you know, newer software developers, but I think a lot of people when they think about solving problems in software, it's like, well, we're building features or we're fixing bugs, but there's so much that's interesting around like the constraints that we have in live systems that exist. They're operating. They've been around for years or whatever. Call them legacy. Maybe they're not quite legacy yet, but what you just described is like you can't just like snap your fingers and say, "Cool, we're just going to go rewrite it over here and like it's fine." It's like, no, you have literal constraints for something that's operational. You have to work within those constraints. And you called out that it could have been done different ways of of course and that totally makes sense, but you still have constraints, right? And I think that we end up creating really interesting solutions to things when we have these challenging constraints. Otherwise, it's like cool, just pick the latest tech off the shelf and someone solved the problem, right? But that's not going to work in all of these really constrained like situations. So, just a super neat thing. >> Sure. And like in it being scrappy is something that, you know, teams talk about at at big tech companies, but what that scrainess means can be very different things. It's like, yeah, we already have a lot of decisions made for us. Um, you know, at Google, you just use Spanner. That's the data store that you use. Why would you use anything else? Like, this company is invested so heavily in this and it does all of these things and has all of this compliance and you get so much for free. It's it would be very odd to choose something different and you would need a lot of very like rigorous like justification to do that. But at a small company like this, you know, we were using Postgress because it was free. now free like it was an open source product and it was free as in beer like you could you know use it for free but it's not free to maintain or not free to scale or free to figure out no downtime upgrades or like there were a lot of things that were you know you did yourself because you were using a product that it's a great product but it it you know and there were companies that did build their businesses around adding some of that functionality and adding different clustering abilities and things like that to this product. But like it was interesting to then go to well >> no Microsoft SQL Server is a paid product and no it's not open source but it's still really viable and important for customers. So we're going to support both of these things. But you know that that was a a different consideration that I had never never thought about before. Um and so uh unfortunately like after we solved some of those hard problems and like moved this system from um HPX on PA risk um and using almost exclusively flat files for storage to a system that's running on Linux and running on x86 and using Postgress for the primary data store. Um those were hard problems and then you know on on the that was on the laboratory side on the clinical side then like this being able to run on Postgress and on SQL Server and even things like how do you connect like we're on you're using Pearl on Linux how do we connect to Microsoft SQL Server like that that wouldn't be a thing I would think about much today but like we had to find something that used like TDS as the like connection protocol to be able to connect and I'm guessing modern SQL server doesn't even like support that protocol anymore and we would not be able to do that. But um we had to find and that was like a different kind of scrappy to figure that out and find the like problems in some of these open- source things like this was a free and open- source TDS connector for Microsoft SQL Server and how do we do that with you know DSNless connections. So it's more similar to the Postgress connection string that we used and all of that but then like we're doing connection pooling but if you get to some number of transactions then it starts like reusing the prepared statements and so like we can pull connections but not for too long or it starts like going completely nuts and we don't know what the real limit is but maybe it's just going to be after 10,000 queries we're just going to close a connection and reopen one because of this issue and we never really got to the bottom of it or fixed it. We just like changed how we were using it. >> Yeah. Right. Whereas like there was something in the um open source forran compiler we were using where in the runtime when you were doing file reads there's like an end statement that then jumps to a label and sometimes it just wouldn't work and we couldn't figure out why but it was something that like plagued our reporting software like the that we had built. And so like I had to like actually look at that source code and like fix that. Like there was it was an uninitialized variable that was the problem in this case and it was being used in a conditional and it would result in an infinite loop when it was you know you reusing memory rather than being initialized to zero. And like that's again not something we think about that much anymore because we're using C# and Java and Cotlin and things where you just like you can't like you're not allowed and that not allowed can like save us a lot but it does like have a lot of cost and we sometimes find that like wow if we could just like drop down into C or use something unmanaged or whatever this could be so much faster. But that that is a real that is a real trade-off that we have to consider really closely is like we're very used to a lot of this safety and the garbage collection for our memory management and all of that stuff that was foundational in early software development. like memory management was what separated professionals from amateurs and now we our many professionals have never had to deal with that in the whole course of their career either it's you know some auto retain release in certain systems or it's you know allocation and like it's just a different world there's smart pointers and there's garbage collection and so you know dealing with that kind of thing, an uninitialized variable, like you might be able to have an uninitialized variable, but you're going to get warned or it's going to be an error or you need to annotate it to allow it. Whereas like back then it was just like a matter of course like yeah, you just you remember or you get burned 10 years later. Um, and uh, that that's just an interesting scale. And working on a 25-year-old system in the year 2000 was very unusual. Um, and I'd say it's very unusual now to work on a 25year-old system. Um, one of the last things that I was working on at Google was deprecating a like maybe 10 or 12y old notification system that came about in the early days of Android. And that seemed ancient, but it's not 30 years old. And the the time spans are just very different now. And when you mentioned legacy software, like every line of code we write is going to be legacy. Is it going to be next week or next month or next year or next decade is an open question. But we'll be dealing with it sometime. And we will think that >> we were dumb when we wrote it. And you know, ideally, that's true. Ideally, we've gotten better and smarter and learned more. But, um, you know, planning it, it's something I'm pretty passionate about. It's like planning for legacy. Like, >> what is it going to look like to turn this off or like what is it >> going to look like to add something to this, not next week, but in 10 years? Like, >> right? Should we make microservices so everything is very like pluggable? Well, sure, but that has like its own overheads and costs. So, you know, when should we have a you know more like not completely monolithic, but when should a service have 10 APIs instead of one API? And you know it is it is very you know there's not one right answer but considering that in time spans longer than a week can be very difficult and not something we think about all the time. So um >> and it's I think as you were talking a little bit earlier it's like some of the experience that you were sharing just really made it seem like from an an early point you realize like literally every decision you make has trade-offs. Every single one. So when you're even talking about this now, it's like yeah like you could ideally right you're building software and ideally it's going to be around for a very long time because it's serving the needs you know it's you know serving customers whatever the goal is and that's great but how like how much do you have to plan for that and how much is that going to like as an example how much does that slow you down now? How much is that that you're not even you know that situation might not even exist. So like you shouldn't do it now. Like the balance is crazy. >> Well, and people are really into the like Yagy, you're not gonna you ain't going to need it. Like okay, cool. But sometimes you do. So how do you balance that? How do you >> right >> choose to have safeguards in place or escape hatches in place without completely overengineering your system for things that you truly won't ever need? Then how do you, you know, guess in an educated way instead of an uneducated way? Because it's always a guess. Like you never know what the future is going to hold. And what is the horizon where you don't know is sometimes a month and sometimes 5 years, but you always are going to hit that horizon where you didn't know something was coming. And you know, rewriting a system is the last thing you ever want to do. And so like I mean some people are psyched to rewrite systems and I would say that might be a sign of immaturity sometimes. We all want to do it but I guess it's how well we control those urges and when we like actually decide it is the right thing but how are you going to you know co-create a system and maintain a system and how do you work on a moving train and how do you >> hope your customers don't need any bug fixes or new features while you're going to go rewrite everything and probably not have it meet the same you know functionality. >> Sure. And so that is where like you know things like the strangler fig pattern to replace subsystems or complete systems is very interesting to me. And like when you are starting that process hardening your interfaces at that point when they may not have been hardened in the past when the original system was created so that you can you know what level do you want to be able to replace at replacing the whole system sounds great but it's not very realistic in most cases. So what what's the level of granularity where you can make replacements? Is it at the function level? Is it at the API level? Is it at the subsystem level? Is it at the service level? Like where do you make those cut points where you can sub things out? And what is testing look like when you do that? And do you, you know, slowly evolve a system versus an outright like full-blown replacement that's a big bang change that customers will suffer through? like and they suffer like if you do a system replacement like that and you say this is what you have to migrate to you actually it's a brand new system or no it's not a brand new system but everything is going to work differently or no that feature that 10 of you love is going away and it's going to ruin your life like you're going to have to start from scratch th those are just very real considerations that um a many people may never face or they may face it well after they made a decision that is devastating. Um so um yeah so um I will um sort of adjust back because we we jumped all over and I think it's interesting and useful but I will say like that company was acquired and now we weren't doing any of those interesting things after that initial like push to you know be able to integrate and be able to use a new database system. It was then not fun. Like it I we thought we're gonna still build a new system and still do this. Nope. Turns out we're not. We're just going to turn this crank and keep integrating with the other things that they buy because we've seen what their decision is for build versus buy. They bought us. Like we know their MO, but we didn't we didn't get it at first. And once that became clear that we're not building a pharmacy system, they're going to buy one and we're just going to integrate with it. Like, oh, that's what we do now. And that that wasn't fun anymore. So, >> I don't know. Do do a lot of people even like that kind of work? I'm sure there are people that like just doing that, but I I don't know anyone that like loves >> So, I think that it can be done in a an interesting way and you could build interesting things to accommodate that and like build adaptability into your APIs and things like that. That is all possible. Um, but I don't think it is the normal way it happens. I think that the normal way it happens is that every new system that you're integrating with is just, you know, yeah, we're just doing one more and how are we going to, you know, add this one and it's just very >> so different and it's >> Yeah, >> sure. And so I I don't I haven't seen people that love it. But I now 20 years into my career, if I was to be in that position, this isn't fun anymore. I'm leaving. Might not be the like mo. It could be like maybe that's very inflexible and there's a lot of constraints put on you and you really can't think outside the box and you can't solve problems in an interesting way and >> then yeah, then maybe it is time to pack up. But I think that I have a different outlook now where it's like, well, maybe there is an exciting way to do this. Like maybe we can make these systems more adaptable and more pluggable. And how how do we make building blocks? And how would we form a like reproducible interface that when there's a new system that we integrate, we create this interface for each of them and then they plug into this overall system instead of it being a bespoke integration every time. And like I, you know, that isn't something I'm faced with right now, but I think I might approach it differently, you know, now 15 or 20 years later. Um, but I I didn't I didn't have the maturity or the experience then to be able to make that choice. Um, so I moved on to a company that did some like created software for nonprofit fundraising. I knew some people that worked there. They were very happy with it. Um, I started um on the same day as their like first um like chief um it's not chief legal officer, but something like that. Like he he was, you know, the the top lawyer and they hadn't had that in the past. And it turned out that the reason that they had hired him was to f like um to instrument an acquisition like to be acquired. Um, and I didn't know that at the time and it seemed very unlikely because this was a publicly traded company in a very niche space. >> I just thought like, well, they they've already gone public. They already, you know, have done that. They're already established and they're in this niche market. Who would possibly buy them? And it turned out there was one other big company in that space and they did buy them. And so it was sort of a a song I had heard very recently and wasn't super psyched about. Um, and you know, it it may have gone differently, but it happened that Amazon reached out at about that same time. And I was like, I'm can't work at Amazon. That's like I'm not good enough for that. Because I had no I it was very insular. Like I had worked at a couple of companies and it was sort of a big fish in a small pond thing where I was like well yeah I'm effective here but like I don't I don't think I can you know that's just a different league and you know getting an offer and all of a sudden like moving to Seattle which like ultimately the move to Seattle didn't work out but I did end up staying at Amazon for a pretty long time. I just, you know, I spent the first year in Seattle and then moved back. Um, I live in the Dallas area. >> You didn't like all the rain here? Like, >> um, it was like 300 days of sun versus 100 days of sun on paper seems like a big change, but in practice it was very, very different. I And I was like, oh, it rains. Um, I was very used to like what raining meant in Texas is a storm comes. there is a storm and it comes and there's thunder and lightning and it's loud and then it rains a lot and then it goes away. I did not know that. What it meant in Seattle was that clouds come in maybe September and they leave in maybe April and it's just sort of drizzling that whole time. It's not a storm. It is just cloud cover for a lot of the year. And then it being so far north means that the days are very short in winter. And when the quote unquote sun is out, it actually isn't out because it's behind clouds. So I would show up to work and it was nighttime. And then I would leave work and it was nighttime. And then in the middle if I went outside, it was just raining. So I that was a something I I didn't know that I couldn't handle. Um when I I made the call. It was just this is what's happening and I've got this job offer and they're going to pay me all this money and I'm really excited and then it was like oh wow Seattle's really expensive and I don't know how to function in this weather and like I also like my like candidate trip when I went up there it was like June and so it was this is paradise and it's like well that is two months so um you know It it was just they they weren't trying to trick me, but that was just the nature of >> but it kind of worked. Yeah. >> Yeah. Um but I I you know when I joined Amazon it was to work on the iOS client for um it's been called a lot of different things. I think it's called Prime Video now but their streaming video platform. Um and I worked on that for about four weeks and then they said we're sending iOS development to London. If you want to go there you can. And then it was like, well, I just moved my family across the country. I'm probably not going to move them internationally. Um, so what are we doing if iOS development is going over there? And it was like, well, we can't tell you that. You're going to need to like come in a room and a lawyer is going to scare you a lot and you're going to have to sign a lot of papers and then we're going to tell you that you're working on the Firephone. And at the time like this was years before it actually was released but it was you know Amazon's secret projects were lettered and it was project B and you know we couldn't only like four of us or five of us were actually like read into this project so we couldn't tell the rest of our team and even though we were sharing a code base because it was an AOSP project and we had a shared Android project that was used for tablets and then used for the Firephone and then used for the Fire TV and then used for vanilla Android. Like none of them could know that. And so we went over to the building where secret projects were done, which was called Fiona, right by Lake Union. And um you had to badge in at the door, and you had to badge in at the elevator, and you had to badge in at the elevator bay on the floor that you were going to. And then, you know, you could you could go and open your safe and get your prototype device out. and it was in a non-disclosure case, so you still didn't really know what it looked like and couldn't really plug in peripherals and whatever. Um, and you know, it was interesting, but it was it was very challenging and ultimately we, you know, got permission to move back to the building that our team was in, but we still needed a room that was locked down and secured and we still couldn't share our code with them. So, they still wouldn't know when they broke us. like we had this shared library and then we would have client specific top level projects and they couldn't see our top level project. So if they changed an API, they would go and fix it on the other top level clients to call it with the new parameters or whatever. But we would break and they wouldn't know and we would come in every day and just spend the first couple of hours trying to clean all of that up. And at least we could like step outside of this room and go talk to someone instead of having to, you know, go across the street and up the hill and whatever or get on. Um but it was still very tedious. So eventually they disclosed all of Amazon video because we were like key app especially on the Fire TV and so then our whole floor got locked down and everyone could know and it was a much better situation. But um I worked on different Android clients and different projects for a number of years. Um, I was doing that mostly remotely, like I said, first year in Seattle, but then I moved back here and I would travel up there every couple like once a month basically for two or three working days. Um, because this was like before remote work was a normal thing and I was always told it was an experiment and it could end at any time. Um, but worked on a lot of really interesting things. um ultimately worked on, you know, getting Amazon video or Prime Video, whatever it was called at the time, onto like vanilla thirdparty Android because we used AOSP on our tablets and our Fire TV and Firephone and all of the things, but we had never released into the Play Store and that was like a big change. And then it was like, okay, we're only releasing to the Amazon App Store and to use that, you have to go through all this rigma roll. And it it it had a lot of challenges, but getting out to those, you know, tens of millions, hundreds of millions of people that were using non-AM Amazon devices and Android was a really cool thing to work on and exciting thing to work on. And launching that was um a different level than anything that I had had worked on in the past. and being able to see like the first 100 million streams happened in the first like day or two where it had taken weeks or months on any other platform we had released on. So, um it that that was a a cool thing and a fun thing. Um ultimately we were finding that we were sort of constrained like we were I was in a client or so. So, we built the iOS client and we built the Android client and we built the features for those things. Um, but it we were still kind of niche like the web client was the main point of focus and then there were these living room clients which were smart TVs and um set top boxes and your Rokus and your gaming consoles and those things. But we were still like the mobile clients were still a little weird. These days that would be the first thing that you would think about building. I mean certainly set top is important but like not having a phone and tablet client would be unheard of and so um we were finding that we would say hey we have this we we can download to our devices that's a differentiator that's really a big deal um but we would ask for new features and like our API partner teams would be like well living room and web don't use that and we can't like spend all of this time just building these features just for mobile. Um and so right so uh so we created a like um client team that was dedicated to building mobile services. Um, and I I moved to that and that was the first time I was working on sort of a a service and we were building essentially like a build your own API thing where we would have all of these dependencies of all of the um things that we needed for getting licenses and getting details about a title and all of that stuff. Um, and then we would aggregate that into an API that could be used to like render the detail page on Android and render the detail page on iOS. And we found that like having a page at a time API was much better than having like make 10 different details calls and this thing because inside of a data center that's fine make 25 different API calls to aggregate this one thing and make this one response but for mobile when you're making all of those same calls and especially if they have to be serialized because you call and you find out oh that's actually a season or a series and now you need to go get all of its seasons and now you need to get all of its episodes and each one of those is a different call and some of them are in parallel but some of them are in serial and we're having to make round trips and the latency on a round trip is really high on mobile where it's like next to nothing inside the data center. Um so what are we going to do about that? If we can do page at a time calls, then you know we incur that latency cost only one time and then we keep all of those like dozens of API calls inside the data center and then bring back what we need to render for that page. Um, and that, you know, was was great. Like that that made a huge difference. And um, so that that was a fun change to like instead of just working on the clients, which are their own like very interesting area, being able to like work on that next layer um, where we're writing some of our own APIs for that and we're enabling things for our downloads and our download status and all of that that wasn't really possible with the previous system was really rewarding. Um and then the last thing that I did while I was in video was work on our internationalization efforts. The you know when I started we were in like US, Japan, UK um and that was kind of like it and then Germany and um Austria got like a sort of rode along with Germany eventually but it was not a lot of places like when you consider the global population. So doing a like global transition was a a big deal and it's how our first principal got to senior principal and like it was a a big project that took the whole business unit working for I think it was about a year but that was actually incredible like to have everyone work together and have this broken down and be able to do like intermediate launches in a few places and make these API changes. we needed and backward compatibility and like all of those things to be able to do that and then launch in places where Amazon didn't even exist before video launched there. It was it was really cool and I was really grateful to be a part of that and I also had been working remotely as the only engineer doing that for a number of years and it was kind of burning me out. So, I had seen, you know, while I was visiting Seattle one time, it just like in the elevator people could post all sorts of things and there was just like a, hey, we're hiring an engineering manager in the Dallas area. I was like, well, if they're hiring managers, they're going to hire engineers. So, talked to the director that was doing that and she ultimately like said, no, we're going to expand in Austin, but this partner of mine is still going to hire in Dallas. and you know talked to them and and ultimately moved into an engineering role um in the Dallas area and it was originally for this like last mile org um which was like get it from the warehouse to the person um so there was a lot of like interesting things happening there and now they're like same day or subday or there's a lot of like different ways that they get things delivered but it's all through Amazon. Um, at first it was like Prime Now was the way they presented that and you to get like 1 hour delivery was a separate app and a separate thing. Um, but I I was excited about that and then they were like, "Oh, we looked at our numbers and like we're not going to expand the way we thought. So, we're not going to grow a team in Dallas." And it was like, "Okay, well, what does that mean?" And it's like, "Well, you can find another job at the company." And it was like, "Uh, okay." like that's challenging and ultimately our senior manager here like found a place for all of us to go um all of us was only a handful of engineers a TPM and himself but um that was in our um customer trust or which was like you buy something from Amazon more than half the time you're not buying it from Amazon like they're a storefront for all of these third party sellers >> um but there's a lot of challenges with that what about counterfeits? What about them never delivering and just giving you a tracking number for something that wasn't really going to you or all of these things? What if it's uh you know used but they're selling it as new and there's just like all of these things. Um so we ended up in in that org and we ended up hiring a lot here in Dallas. So that first year was like hiring from me as the only engineer to like 12 or 13 people and then like ramping them all up and getting them involved. And we had a partner team in Seattle and how are we going to work with them and how do we evolve this team because it was founded by data engineers and a lot of what was driving our processes were very complex SQL queries and you know that worked like that was what they needed to do and they did it but it was very hard to maintain and we wanted to move it more into the software realm and a rules engine and those sorts of things but that was like a significant departure and change from what had been done um while at the same time needing to like move off of Oracle. So we had to rewrite some of these queries that were very complex and people didn't like that and software engineers didn't want their job to be converting queries and we probably lost one or two really good people because they were in the SQL minds for too long and we hadn't pulled them out and given them some software tasks to work on and but you know it was a companywide mandate and sometimes when there's a companywide mandate you like get your hands dirty and we could been smarter about rotating people through that, but it's very hard. Like a few people have gotten good at this. >> Do we want to just put new people that are bad at it on it or should those people that are >> a weird balance? Yeah. Yeah. >> Um and we didn't, you know, did I I don't think there was a right way, but we did it in a way that ended up costing some some really talented people. And that is something to reflect on, but I, you know, it had to get done and the way we picked achieved that, but it was at cost and it burned some people out and we lost some people. But, um, ultimately we moved to, you know, a streaming based system instead of a batch-based system and it was a really like good change, but it came at a a kind of high cost. Um, but through that process, um, the senior manager that was here in Dallas left. they left the company and they like, you know, we now were sort of in this weird state of like who like is our director going to manage these 25 engineers between Seattle and Dallas and like no that doesn't make sense. So like the TPM we had hired transition to an SDM role and then I also transitioned into an SDM role um at Amazon that's software development manager where engineers are software development engineers. There's not the idea, at least there wasn't when I was there and as far as I know now, there's still not a like hybrid role um like this team lead manager type role that some companies have where you can still be writing code and you have your own deliverables but you manage a handful of people. Um that just didn't exist. So I made the like full transition to a people manager, manage a team size between like four and eight engineers dependent on people coming and going and hiring and whatever. But um did that for the last 3 years I was at Amazon um in this customer trust org. Um my team owned like an internal tool that was used essentially for training our models where humans would look at low confidence things from the model where it said I don't know if this is you know someone complaining about um fraud or not. So humans look at it and they score it and you know we'd had sometimes single person sometimes best two out of three you know minority report style like who's you know what what are we going to use and then using that to retrain the models but also for enforcement decisions and enforcement decisions meant like pull down someone's you know account or pull down this one offer that they have for a product that we're finding a lot of complaints about. Um, but you know had to come up with like what is my team going to own, what is this other team going to own, who's doing what, and who's going to be moved and trying to like essentially get consent of the engineers like hey, we've been working as peers. I'm moving into this management role. We've wanted to divide the team like this. That would mean you reporting to me. That's a very, you know, different thing and a different way of working. And I tried to like get people on board. I didn't want to force that because that can be a scary change but ultimately like got some people on board and and we um so then I you know worked as a people manager. I had a lot to learn about that. Um I transitioned at a level that is kind of below what is normally the like line manager at Amazon. It's normally level six which is the same level as senior engineers. Um I was level five which was an SD2 role. Um, I had failed to get promoted to senior a number of times. It's sort of a notoriously difficult process at Amazon to make that SD2 to SD3 or senior SD like jump. Um, and I wasn't like, oh, I'll never get there, so I'm going to move to manager, but it was sort of a combination of there's a need right now. It's something I'm interested in trying, so I'm going to like give it a role. How's it how's this going to work out? and you know got um the team involved and officially made the move after maybe 6 months in the role but in those six months I couldn't access any of the like manager training because my role code wasn't right and so it was a lot of like you know kind of making it up as >> they had manager training that's uh that's incredible >> one PDF that said good luck >> courses that you could take um but uh but anyway like yeah I I did that for a number of years and ultimately going into the pandemic that was a whole different thing of managing a team. Um when everyone was remote, we would have like interns start and move here and then we'd be like, "Oh, just kidding. Like we're not going into the office. Everyone's full remote. So you can sit in your apartment here in Dallas, but you're never going to come in and meet the team and like do your whole internship." But I mean like it was a different kind of challenge to do as a people manager and kind of you know I had been doing it a couple of years at that point but um was still fairly new. I did get promoted in uh as a manager there so was promoted to L6 which was sort of the like regular like not junior kind of manager like the regular line manager level. Um and um but through that I I found some challenges with some of the things that I was seeing as leadership having some like self-inflicted wounds and having to be the messenger to engineers of some of these decisions that I might not have agreed with. And yes, you have to disagree and commit. That's one of the leadership principles at Amazon. And you have to get on board. But it it was hard to say like we're doing this thing that you know I'd never told them that I don't agree with but had to like really do some mental gymnastics to get on board with some of those decisions. And ultimately um where I I could not get on board was some of the like um essentially like instead of top leveling like bottom leveling of of people during the performance management process where you're not supposed to do stack ranking and you're not supposed to compare people to each other. It's supposed to be against the role guidelines and you're supposed to give them the rating that they deserve. But then sometimes what would sneak in is that you know at a this what was supposed to happen is for a director's org where they have 50 people or more they needed to have some percentage of people in this lowest performance bucket. But a lot of times they wouldn't take a holistic look at their whole org. They would just push that down. They'd push it down to their senior managers and they would push that down to their line managers. And then they would say, "If you have more than five people or six people, pick one for this lowest performance bucket." And it was like, "No, I'm not going to do that." Like, I don't believe that that's reasonable or fair. And that's actually not the company's philosophy. And like I pulled in the director of HR for North America and she came and like had conversations and tried to clean that up so that wouldn't happen. But then another year would come and the new performance cycle and it would happen again. And I had fought as much as I felt like I could fight on this and it just wasn't wasn't changing in that org. And so um what really happened was like I had rated someone at the like midle and for conversation like um their rating was lowered and that came up in a operational discussion with senior managers and I had recommended this person for a new team in a different senior manager org and they said like hey are you sending me like your worst performer? What's the deal? Like I can't take on >> like people that need a lot of coaching. Like I'm starting a new team. I need to see them. >> That's supposed to be your problem, not their problem. Right. But >> sure, >> but they weren't a problem. But that's how it was in in this meeting and this person reached out and was like, "Hey, you're sending me this person that's in this low performance bucket." And I was like, "No, like I didn't put them in that bucket. I don't know what's going on." on and ultimately like I couldn't I couldn't like get there in terms of you know reestablishing trust so felt like I needed to move on and that's where um you know ultimately I had a lot of decisions to make at that point do I want to stay at Amazon um if I stay at Amazon do I want to keep working as a people manager or do I want to try to work as an engineer I did some interviews essentially internally to move back to an engineering role and wasn't getting accepted because they're like well the last time you were an engineer you were an L5 and now you're an L6 and it was like well according to these like graphs we show it's like the real change is in leadership from that level it's not technical but I do have the technical chops but it was just like no like it's that wasn't going to happen so >> weird red tape like yeah kind of >> sure and I mean I I understood from some extent They're like, "Well, you've never worked as a senior engineer." And it's like, "Well, that is true, but obviously like the level of leadership I demonstrate is at L6 level, but you know, it just didn't didn't pan out." Um, and so at the time it was co a lot of companies had reached out to me over the years saying like, "Hey, you know, you're like Facebook now Meta and Google and other places, but we're like, no, you need to like come to Sunnyale or come back to Seattle or come to New York." And I was like, like, no, I have kids here. I'm not uprooting them. Like, I'm So, if you open an office in Dallas or you start supporting remote work, like, let me know. And COVID was a time when, you know, the pendulum has been swinging for different companies and how that looks now. But, um, at the time, some companies were starting to hire remotely that hadn't in the past. So, um I started looking and like when I talked to the the the first place I went was, um Facebook like and I had already had recruiting contacts and reached out to them and was like, "Hey, I read y'all are hiring remotely. Like, I've had some reachouts in the past from you like what what what can we do?" Um and they said like, "Well, you've worked for more than two years or more than three years or whatever as a people manager and that's our requirement for hiring people externally. So you can interview as a line manager, you can interview as an engineer, as an IC. Um, and I had really felt when I was a people manager, a lot of the things I really liked was like helping people advance in their careers and mentorship and connecting people to other people that could help them in their careers and all of that stuff. But none of that required you to be a manager like that. just you know you >> true >> press the button in the system to give people ratings and things and you do some of the hiring processes and like it's important and it's important role but a lot of what I was loving was not specific to being a a people manager um and so and some of the things I did love like reviewing code and designs I I still did but I wasn't supposed to and it wasn't like counting towards my performance and it was like essentially a hobby um that I was allowing to take up a ton of my time because it's what I really loved. So I decided like I actually think I want to work as an engineer again and um so interviewed and and got an offer as a staff engineer um at what was then Facebook and like the time that I was at the company it transitioned to Meta. um it didn't work like I there were a lot of challenges the you know remote work was new for them but I'm sure plenty of people on boarded successfully remotely um they were still doing like hiring people unallocated and having you do a team match process and that team match process was essentially like you come and do a boot camp to learn how to be an engineer at Facebook or Meta and then you find a team that best suits you and you like hang out with them or like ask their manager questions or whatever. And like I had worked on some Android, so I like put that in my profile. And once you as a staff engineer put that you knew Android, um it was a feeding frenzy. And like 43 teams reached out and were like, "Hey, we want you to come work for us." And I was like, "Whoa, like that's a little overwhelming. Like I'm going to have to like pair this back." So like paired back those 43 to 10 just based on like what they had said in in the profile. Um and then uh reached out to those managers, talked to them, talked to their senior most engineer, like tried to figure out what would be a good match, narrowed that down to three teams and then there there's a process where you like sit with those teams. Um but remotely like you're obviously not physically sitting with them. So, it was, you know, going to their meetings and trying to like make a couple of code changes. And, you know, I think that I'm sure some more senior people had a really good way of of figuring that out, but I didn't know what to do. And the like built-in part of the process of you like make a few code changes and hang out in a few meetings didn't feel like enough. I was like, well, what about like the road map and what about how the team is functioning and what about like the actual needs and who needs to be mentored in what way and do you have people that you want to promote and like there was just a lot of like strategy things that just weren't covered by the process and I tried to ring them out during that time but it was just like kind of a challenge for me and then two of those teams said oh we can't hire you at a staff level. I was like well what what do you mean? And everyone was like, "Well, that's impossible. They have to have an open headcount and an open wreck and they have to be able to hire people to be able to do the reachouts in the system." It's like, "Cool. You're telling me it's impossible, but two out of the three teams that I sat with have said they can't hire me now. So, like, now what?" And it's like, "Well, you have this other team." And I was like, "Well, I don't think that team is a good fit. I'm not going to pick that because it's the only one >> left." So then I was in this position of like what now? And so instead of re-engaging in that process because it was pretty exhausting, um I started like reaching out. I you know had been working now in the industry for 15 years or something 10 years 12 years I don't know but for a while and I knew a bunch of people that had come to Meta from Amazon and so I reached out to them and was like hey I just need to know it doesn't have to be your team. It can be your team. I need to know any team that's hiring a staff engineer that you know personally is like a good place to work and eventually like found a team and I was working um adjacent to a manager that I had worked with at Amazon that I really liked and trusted um and it was the like commenting surface in the mobile apps. So you know billions of people were making comments on and it was like they call it the blue app but the Facebook app. Um, so like, hey, that's that's cool. Like that's a high use surface. And then it just didn't click. Like I showed up and what I was trying to focus on was like engineer experience and people are getting burned out from the support process. And whenever there's, you know, a statistical anomaly, people will spend weeks trying to track it down. They may find the answer, they may not. experimentation was a little bit crazy and people tended to just like rerun experiments sometimes until the numbers were neutral or whatever. And it just was like, you know, that that to me was the root of a lot of the challenges the team was having. And I thought that that was my job was like help like come in and be the advocate and yes do some coding and work as an engineer but identify where these pain points are and try to remediate them and represent those to leadership and start finding those solutions. And I don't think anyone was like no we don't want to fix that. But what they did want was like you should be working your way up. Like you should start at doing L3 level tasks and then L4 tasks and then senior engineer like small projects and then work up to being in a a staff level role. And so it was like just an impedance mismatch of like well I'm not going to be the best L3 engineer. I I I can code like I want to do some of that but I'm not going to be the most productive coder right now in this codebase. Like I want to learn it and I want to ramp up to that but right now what differentiates me is the ability to like diagnose some of these challenges the team is having and look at some of the big picture things and change some of our processes and you know have a direction that we're going in to resolve some of this. And again, I don't think anyone was against that, but it wasn't what they were asking for from me at the time. And I just like dug a hole. Um, I had made an onboarding plan and people had said it looked good and I was doing it, but then they said like, "No, this should be the onboarding plan and you're behind and gave me something else." And it was like, oh, like, okay, let me like try to try to course correct. And it just like my manager left and the director left and things shifted and the person that I knew that I had a relationship left and it was just kind of like oh like this isn't going great. >> None of that sounds like a good alignment of things to be going through. >> Yeah. So, you know, I I was working on something that I think I was like progressing pretty well in, and it was like making essentially a better plug-in system for people who wanted to add functionality to the commenting surface. Cuz all the time people would be like, "Well, we want to integrate with this so people that are selling something can put their little blurb from marketplace into the commenting surface." and oh, we've got this cool avatar thing that we built for AR and VR and we want people to be able to do emotes with their avatar in the commenting surface and they would like want to come and build it or ask us to build it and it was just all like getting intertwined with our core code and so we were trying to like extricate that and put a clear boundary and have a plug-in based system and have a way for them to to do all of that. Um, and then I was like working on converting some of the existing integrations to that system while being a like advocate for new integrations to use that system. And like that I think could have been good and like could have been productive long term, but there was also some writing on the wall in terms of like performance ratings and things that it wasn't going to >> pan out. So I ultimately like started a new search and in that interim time of that next year more companies had opened up um full remote work. So um I ultimately targeted Google. I had done the like fubar challenge like you goo it this doesn't exist anymore sadly but for a time like you would be googling sufficiently nerdy things about coding then they would be like hey you want to take this programming challenge like and I was like yeah I want to take a programming challenge like this was when I actually did the challenge was when I had first moved to a management role at Amazon and I was like yeah like let me do some coding in my spare time and it'll be fun and it is challenging And so did that and like got far enough along that like got a recruiter call but that was in the before times and they were like oh yeah sorry we can't hire you remotely. So then I like again already had those contacts and I think that's been like the biggest thing in my career is maintaining like good relationships with recruiters. Like I know there are recruiters that are reaching out blind and they don't really look or understand your experience and they're mismatching you with the wrong level. Their jobs are super hard. Like they >> do the best they can. I've worked with phenomenal people that work in recruiting. Their job is really hard. The way they have to build a pipeline and the top of their funnel has to be so wide. like I just have a lot of empathy for the their plate and I think that they do a really hard job and them doing that hard job is the reason that we have career mobility as engineers and we can move around this industry and find these jobs like without them we could not do that. So I just have been really grateful for some of those relationships I've been able to maintain over time and it's a fairly tight-knit community. amongst like tech recruiters. And so if I'm looking at a target company that I might want to work for, even if I don't know a recruiter working there, I probably have a second level connection on LinkedIn to them and can get an intro through other recruiters that I do know. And so that has been one of the biggest keys for me in moving through my career is like when someone reaches out, be kind. Like stay in touch. like say I'm not looking right now but would love to stay connected and like you know when someone is saying like hey do you know anyone at this company like actually I have a tech recruiter that I've talked to and let me connect you or when I'm looking again like reach out to them. So um was able to do that after having done that fubar thing a few years before um and again like wanted to stick with the IC role. So, um interviewed for a staff role at Google and ultimately um got that job in their um chat org. So, the chat product, there's been many over the years people really like focus on the Google graveyard. And I get it. I understand people like build their life or their whatever, you know, workflow around a product and then Google's like now it's gone. But um the current chat product I you know they seem to be investing in very differently and are treating it very differently in a like pure app in the work space like suite of products and all of that stuff. So I worked um I started in the spaces or when spaces are just like the multi-person named chat rooms um in that product and they hired a bunch of staff engineers at the same time like they saw that that was really growing um but the two other staff engineers had like a like specific large project they were working on and I was a little more like floating I guess and that was okay with me like I was trying to do some engineering excellence things and trying to do some like engineering productivity and satisfaction things. So running surveys and identifying problems with like hey people really don't like how experiment cleanup is going. How can we make that better? Stuff like that. Um and then would like stumble across a project where they were like we just need some help here. Like there's no one to work on the Android side of this product that or feature that we're working on. and I would like grab that, but I didn't have this like one big area of ownership. And so after the first year, my um senior manager that I was aligned with said like, "Hey, like I don't see this changing and while the work you're doing is valuable, you know, it if you want a larger project that you can own, it might not be in this space. So, you know, we we need more help in the notifications space. Um, and so I I moved over to the notifications team. Um, that was shared between chat and Gmail. Um, a lot of some of the infrastructure that was used for sending notifications out. Um, so and some of that was because like we were in the same app like the they you know you could get a chat app but there was this like monolithic like chat and meet and Gmail um workspace app and so um you know almost immediately that was when Google's first big layoff was was when I moved to that team and someone on that team was impacted they lost their job as part of that layoff and they had been working on this like large scale deprecation of this old notification system. Um, and I won't say I regret it necessarily, but I put my hand up and said like, "Oh, I'll take that on." Like other people already have a lot of things they're committed to. We're spread thin. Like I'm new. I'm not allocated to anything right now. Let me take that on. And it was just a much bigger thing than I understood it to be. And it took a really long time. And some of that progress was very ducklike. Like I was just going pretty slow over the surface of the water from external um views where I was really like kicking very hard under the surface trying to find all of the different teams because it was owned by Gmail or this notifications team that was shared. But dozens of teams across the company like used this to send their notifications to legacy Android clients. And so like finding all of them like well plus doesn't exist. How are they still sending notifications with this or like what is books mean? Is this like the scanning of books or is this selling of books or like what who are these teams and like >> very big tech type problems where it's like yeah just there's probably a hundred teams that use this like go chase them down >> and a lot of it was archaeology like okay all I have is this like client ID or this like queue we're listening to for their signals. So like who's publishing to this queue or okay try to like find that by the like string that's the address of that queue but it was just like it was okay well cool I found that code now like who owns that okay that's a defunct team like >> yeah no one owns it now yeah >> right um but I you know I ended up that was kind of the the white whale a lot of the time I was there that team split back to Gmail and chat um because there were you know different needs and having one team wasn't wasn't working out. So I went with the Gmail side because I was working on this deprecation that was a Gmail owned product. Um and did a lot of different things on the Gmail side worked on ads some because that's what pays the bills. Um, you know, there are paid like companies that use Workspace products, but you know, billions of people have free Gmail accounts and that free means you're paying with, you know, the data that you're giving them and the ads that you're seeing and potentially clicking on. So, um, you know, we had a partnership with the ads team and they had their own servers and they had a lot of things, but then when they actually needed to integrate something into Gmail, a lot of times we would like do that work for them or alongside them or consult. And so, um, I did some of that work. We like reorged and I ended up in this org called productivity, which was like how can you get more things done when you're using this product? And one of the things that we worked on was like putting these cards at the top of your inbox to say like, "Hey, you have an appointment with your doctor or you have a reservation with your doctor or you have whatever it is like flights and deals and all sorts of different things. >> See these things? I use them." >> Good. I'm glad I Yeah, it was a really cool thing and I got to work on some of the like platform for that. like it it was established but we were still onboarding a lot of the use cases. We would call them verticals like each of those different types of cards and trying to make that more like pluggable where when someone wanted to add that they didn't need to learn the whole cards framework but that they could implement you know essentially one interface and that could plug in or you know subclass something and that that could plug into this system. um and found like, okay, how can we, you know, we have all these different verticals and we have these different views. There's the view when you're like looking at an email thread and then there's the view when you're like in your inbox and those are going to be different. Sometimes we'll put different information on those cards. So, how do we make that never an implicit choice? Like always explicit whenever there's something that pivots that where we're displaying this, you choose what's supposed to happen rather than there being a default and it almost always being wrong. And so, um, you know, worked worked on that. But, um, that that's kind of the, you know, career journey. And one of the things that that we had wanted to to focus on in that um is this like I was a people manager and now I'm an IC again. And one of the things there's there's a book called uh staff engineer that um kind of captures a lot of different archetypes of staff plus engineers across different companies. And you know it comes up in that book but it also came up in my career journey that like managing people is one of the ways you can lead. Um it isn't the only one by any means and there's a lot of overlap between line managers and senior managers and staff engineers and principal engineers where like you're responsible for product delivery. You're responsible for roadmap things. You're responsible for career growth of other engineers. But some some of the work is writing code and some of the work is actually like doing the people management and some of the hiring and performance management things that you know differentiate those roles. But there's a lot more the same than there is that's different. And I found that um working as a people manager just made me appreciate a lot of the things that I I kind of was shielded from as an engineer. Um, a lot of that was some like resource decisions and being able to set that up where I look at the team and like, well, we're getting randomized a lot. Okay, like how should we handle that? We're going to have to be responsive to those things, but it's really important to me to never pull someone off of something that isn't complete to take on this short-term task. So, how do we handle that? Is the on call going to do it? Is the secondary on call going to do it? Or how can we manage that? Can we say we do our iterations every two weeks unless it's like a sev one issue that should be handled by the on call we can pull it into the next iteration but we're not going to disrupt the current one and trying to like figure out how that would work wasn't something I had to deal with as an engineer really like it was just like oh I don't like being randomized and maybe I I had some input and I would like help rearrange on call setups and stuff like that as an engineer but some of the like nitty-gritty of like managing up as the manager and managing out. Like I would certainly help partner teams, but actually like figuring out what that relationship looked like and how much time we could spend helping other teams with onboarding to something or whatever and what would make that more turnkey. Should we make an engineering investment to make it easier for teams to onboard so that we don't have to hold their hand through that and be really involved in that process? Well, that's a big trade-off. How are we going to make that decision? It's really important, but it's not obvious. Like, are we going to do this once a year or 10 times a year, >> right? >> What if it's four? Four is a hard one to deal with because it's like once a quarter and it's taking two weeks. That's actually kind of a lot, but we're going to have to spend 15 weeks building something and and then we have to still maintain it. And it doesn't bring our integration cost to zero, but it brings it down to two or three days. But can a TPM do that instead of an engineer? And there's just like a lot of moving parts there that um I knew as an engineer like, okay, well, it would cost this much to build it or it costs this much each time we do it, but I didn't think about as much like, you know, which one should we do and and why? Um, >> and so, you know, a lot of that helped me when moving back into an IC role of thinking about more of those things and not just saying, hey, we're having this problem. We're really spending a lot of engineering time on these integrations. Um, but instead say, you know, how long do we think we're going to be doing this? Is there a maximum number of these we're going to have or is there an infinite number of new use cases or new teams that we'll on board? And if so, how often? Like is it once a year or is it twice or 10 or 100? and then try to figure out like can we just simplify it where we don't build a whole software solution for this but we've simplified the process where they can do a lot of the leg work in advance and do their own security review and do all of this stuff and then bring us something that's more pluggable and whatever where we don't have to change our architecture but we can change the process so that it's less painful. Um, and th those are the sorts of things that like being on both sides like being a manager, I've met great managers that were never engineers that were like TPMs or came from the PM role but then got really technically involved. So, I don't think that you have to be an engineer to move to a software development management kind of role. Um, I feel that sadly some engineers are really like disrespectful when people haven't worked as an engineer or haven't in a long time. Like maybe they started their career as an engineer but then spent a long time as a TPM. But like I think that diverse experiences can make for like really effective leaders. And I think that there are bad managers and there are bad managers that didn't work as engineers. >> That does not mean all of them. And it doesn't mean the majority of them be kind like give them a shot like partner with them. Maybe this is an opportunity for you as an engineer to step up and take on some of the more technical planning aspects for this manager who is very technical but hasn't been in this code base or whatever. Like don't dismiss that people's experience is different from yours so they can't be a manager of your role or whatever. like there are competencies that they need and they need to be able to reason about some of these trade-offs or some decisions that are being made, but that doesn't mean that they have to write code. Um, and I think that there are times in certain places that can be useful, but a lot of the times when you have a dedicated engineering manager role, them being a good manager has very little to do with them being a great coder in your codebase. Maybe they were at some point in their career, maybe they weren't. But either way, like if they can insulate you from bad asks from leadership and if they can help grow your career and find the right projects for you and they know what PM is going to need in the next three quarters and can align on that, if they could fix a bug or write a feature themselves, I don't care. Like and I think that you know you need to consider that a lot when like if you're essentially interviewing a manager to see if you want to join a team just being dismissive because of one particular data point can be really dangerous and um kind of like exclusive and try to I don't know. So, um, that's something that I've seen as well is like, yes, me working as an engineer helped me to be a manager in some ways, but hindered me in others because I had a lot of trouble letting go of certain things. People would like bring a problem and I would be like, >> "Okay, I'm starting on the whiteboard and I'm drawing this." And they're like, >> "No, like you have to go solve that." Yeah. >> Yeah. Like that's not my job anymore. But it was super hard for me to just be like, "Yes, I trust that y'all are going to make the right decision on that and I'm happy to give you feedback and input when and if you want it, but if you prefer to go seek the input from a senior principal engineer from somewhere else, like that's do that like do what what you need to do to solve this problem. I will help make sure you have the time you need. I will help make sure you have like the connections you need or the permission you need or whatever the the sign off for the lack of interruptions, but I don't have to say that we need to put an expiration on this record in the data store to handle this cleanup case. You'll figure that out. Like, y'all know how this system works. Like, and even if you make a decision different than mine, it's probably not wrong. And it is probably better that you do what you think is best than I dictate it and you disagree with it and have to implement something you don't believe in. So I have to like step back and if you are a TPM you're probably not going to be like hey this is the way you should code this like there's just different background. Now you may say the way we should integrate with these other teams should be like this and you may need to step back in that area and like let other people work that out but um I do think that there's different strengths and I think that having a diversity of those strengths is really important and for me like that's part of building an effective team whether I'm a senior IC on that team or I'm a manager of that team. um finding out where those strengths are and who's best at what and how the roles are defined and who actually takes ownership of certain things and when it can be anyone like it well I don't have to submit the three-year technical plan because I'm the manager of this team like a senior engineer can do that if they want to but if they don't want to I shouldn't make them like it is my responsibility that this team produces that document and I may need them to give me some inputs, but if they don't want to write it, if I make them and it's not actually like furthering skills that they actually really need to develop, then that's wasteful. And if I can't do it myself, I need to be honest about that and say there's not an engineer on my team ready to do this and I'm not able to take it on right now. So, I need to go to my leadership and say, I need help with this or I need some things taken off my plate or I need someone to consult with me on this and help me shape this document because I'm not able to do it. But I need to like really be aware of what what is flexible and what isn't in terms of responsibilities and make sure that that alignment leads to like not only the best result but the best experience for the people on the team or adjacent teams or whatever so that we're like producing our best work. >> Yeah. that um that idea of and it's come up a couple of times as you've as we've talked together here but the that idea of it's not just a matter of like you know optimizing for throughput like as much as possible all the time it's actually there is a huge aspect of this in terms of and I don't just want to say managing people leading people in general giving people opportunities that may not be the most effective from a throughput perspective but keep them engaged are part of their career growth. It might even be that uh just as an example, you have a single point of failure on the team and you're like, I need to start giving this type of work to someone else so that we don't have a single point of failure. These types of things come up. Uh I mean, it ends up being a responsibility of managers, but that's not the only way that it can get addressed. If you have people that are thinking about these things and trying to help be leaders within the team, that kind of stuff can surface and then people can start taking action on it. So, I I've really loved that you've throughout this have said like it's not like it's not just a manager that can do this. There are things that managers have to focus on where this does come up all the time. But all of these different perspectives that you could take away from your management experience, you can go relev. >> Sure. Yeah. And I I think that being, you know, knowing what you don't know or what you're not good at is as important as knowing what you do know and what you are good at. And >> yeah, >> trying to essentially like force a triangle through a square shaped hole because you think that's, you know, what has to happen and failing to be creative about finding solutions can be super costly. So, if you know you're bad at something, but it's a way that you can learn and you can take a little extra time or get a little extra input or coaching, like that might be the right way to do it. But it also might be that you need to actually seed control of that because you can't do it effectively and let someone else handle it. Um, and maybe you have to shadow them because you still need to learn, but you need to not get in their way. and finding out how to adjust to those things. And even as an engineer, like taking that away from my management experience now as an engineer, when I'm taking on a task, I may really want to learn a lot and want to take a lot of time on this to really absorb and understand every part of it. And maybe this isn't the right time. maybe this task just to get done and I can't get the depth of understanding of that subsystem that I really want and I need to let someone else fill in those gaps and just go ask somebody, hey, like I need to change the way that this is rendered and I when I look at this rendering subsystem, I don't get it yet. And you probably weren't expecting me to interrupt right now, but unfortunately the video footage from the interview ended up getting corrupt right at the end there as Lee and I were wrapping things up. So, I do apologize for that. But I do hope that you got to enjoy the conversation that we were able to capture. I think that Lee has tons of really awesome experiences to share with everyone and I really enjoyed the conversation myself. So, thanks so much for watching and I will see you in the next episode. Take care.