Leading Engineering Teams Without Burning Out - Interview with Ray Nicholus

My guest in today's podcast episode is Ray Nicholas. And aside from sharing a last name that almost is the same as my first name, we actually share a lot of similar philosophies when it comes to managing and leading engineering teams. We got to hear about taking opportunities in terms of saying yes and no to certain things and when that makes sense and when it doesn't. And of course, leading engineering teams as an introvert. And for those of you that don't know, I am very introverted. I might not seem like it when I'm talking on video, but you'll get to see in this episode how we talk about being introverted and what that really means as an engineering leader and trying to turn on the right sort of social cues when you need to in the right settings. So, I think that you're really going to enjoy this one. I personally had a lot of takeaways where I was like, "Yes, that seems like it's very similar to how I like to look at stuff." So, a lot of maybe confirmation bias for me, but overall a really awesome conversation. So, sit back, enjoy, and I'll see you next time. Well, Ray, if you don't mind kicking us off, would you like to give us a little bit of background for uh your career journey? And like I said before we started recording, you can start as early as you want. >> Yep. So, I kind of feel like I've been l one of the lucky ones where I always knew I wanted to work with computers. I mean, since as long as I can remember, you know, learned basic when I was 10, C when I was like 12 or 13, working with Slackware at 14. Um, you know, my first job was fixing computers for a school district before I could even drive. I've always kind of wanted to work with computers. Um, and then, you know, I studied computer science and right out of college, I started with a software engineering job and I was the first software engineer at a startup in Madison, Wisconsin, which was, you know, daunting for me because it was kind of an odd way to start a career. Um, normally when you're jumping into a career, any career, especially out of college, um, because, you know, as you probably know, college doesn't really it it potentially helps you think, but it doesn't really prepare you for the realities of work. So, I didn't really have anyone to learn from there. I was sort of on my own and just had to make things happen. Um, so it was kind of trial by fire and I feel like that made me a stronger engineer right from the beginning because I had to develop stronger problem solving skills because it was kind of fight or flight. Is that right? Flight or fight or right? >> Yeah. And for I'm assuming no internships or anything. So it was kind of probably like mostly theoretical stuff from college and then like by the way like now this is the real world software's got to happen and >> Yeah. Yeah. And I was I was doing like as a as a night job or day job and I had night classes. I was doing uh I was doing IT work for various companies just to supplement my you know what meager income I had at the time. My first real job writing software was you know the day after graduation more or less. >> Awesome. Okay. And so uh how long did you stay at the startup? Like what was what was that like? >> Yeah. So I stayed there a year and a half and and it was a long year and a half. Not to disparage a startup. I mean I my boss was great. It was great people but it was really tough. Like I was the only I was the first software engineer there and they hired a few others and I was pseudo managing them but I had no business being a manager at that point. Um and I was getting you know I was always on call. I was Yahoo was one of our customers. So I was getting paged at 3 in the morning. And at some point I said I I got to do something else. I got to go somewhere else. This is this is too much for me. So, I went to a much much much bigger company where I could learn from people. And I did that for I don't know was it four or six years? I can't remember. Um it was uh Avid, which is a giant, you know, video company, you know, video software company. Um, so that was a little bit of a relief because I was it was sort of a reset where I had an opportunity to to learn from much more experienced engineers and that's when I was first introduced to the web like web development at that point. I I just been doing server side Java based development C++ and at the tail end of that job is when I kind of got into web development, web-based development and that's kind of where I've been at ever since more or less. >> Interesting. And if you don't mind me asking, like going from cuz you called out having more like experienced people to learn from, which makes sense, right? Some places like sometimes at startups you might have some really awesome senior engineers right there from the start and then it's a close working relationship and that's great. Bigger companies statistically there's probably just going to be more experienced people around you. But what what else like did you notice going from like a kind of like very early startup where you're like one of the first engineers to like now you're dropped into a big company and like the structure like what else is was kind of going on for you? >> Yeah, there was a lot of structure. So I learned a lot of things being going from a small company to a big company. Obviously there were a lot of things to learn at the small company but I had nothing to compare it to. Um at the big company there were some obvious differences. Um there was a lot more structure like you mentioned quite a bit more structure which I think was probably good at that point in my career to experience some structure instead of constant chaos. Um the other thing was I sort of realized at that point it was something I needed right I needed more structure I needed more senior people to learn from but the the major difference that I noticed and that's something I took to heart for the rest of my career is and this is you know obviously this is all subjective this is the way I see things this not everybody sees it this way of course but at a larger company I felt my contributions were like throwing a pebble into the ocean right um you're you're you can create some value, but how many people are going to notice that value? What really how how valuable are your contributions really? There's thousands of other people at the company versus a smaller company where I'm one of five engineers and one of 10 people. Everything you do um not for better or for worse has a major dramatic effect on the company. And I think um after I became a little bit more confident in my abilities working for the larger company, I realized, hey, I I do want to be able to to have a more of an effect on the company. I want what I'm doing to be realized. I want I want to make a difference. I don't just want to be a cog, right? >> Yeah, that's a really interesting like uh reflection of that. And I I found like so I I also worked at a startup like at a school uh did that for 8 years and then work at Microsoft now. So very much like small company to big company and um whenever I talk about impact uh and reflect on it it's I always feel like it's a weird thing to kind of like to quantify. So when I worked at a startup, it was for digital forensics and the impact I was like well it's not like millions of users across the planet but like we help you know we help police officers, law enforcement, investigators like a lot of the time it was help like helping rescue kids uh from like uh from sexual abuse and things like that. So like from a from an impact and like how rewarding that feels like that was pretty incredible and I don't know if like I'll ever kind of top that feeling of impact. And then going to Microsoft, it's I like how you said that though. It's like like I the space I work in, there's impact potentially to millions of users, but in terms of like how I feel my um impact is to the company, like it feels like a pebble even though it's potentially millions of end users. So um it's an interesting thing. Um, and so you you started to have this realization and then you wanted to go to smaller companies again to to kind of get that feeling back. >> Yeah. And that's what I've done ever since. Um, that was the only big company at really big company I've worked for. Every company after that has been a pretty small company. I would say um probably the largest was few jobs ago, but even that wasn't very big. They've all been um very small to relatively small companies and and that's been deliberate, but you know, as I mentioned that the the whole big company isn't for me kind of thing is subjective, but I can see reframing that where you work for a large company like Microsoft, but you see sort of your team, your organization is more or less the company that you're affecting is like a small company, right? Does I wonder does it does it feel like that at Microsoft for you? Yeah, it's so it's very funny you mentioned that because um I would say so I've been at Microsoft just over five years now like five years in two weeks kind of thing and um I I I didn't feel that way for for a while and then very recently I was having this reflection and um I was thinking like the sort of the org that I'm in right now and I don't mean the the greater org that's like thousands of people I mean sort of like up to my skip level manager and then even my manager I was like, hey, we're we're a team, but we're kind of broken into these smaller teams. And when I was thinking about the size of that and kind of at the the pace we're going and stuff, I was like, that's actually quite comparable to like some of the early days in the startup. So, if you kind of draw this boundary around that, I'm like, it it actually does kind of feel like that. The big difference is that you have like insulation or or other things around you whereas like at a startup it was like you know we we didn't even know how to have like we had engineer we had senior engineer we're like we don't know what else to do for like career structure like you're you're kind of coming up with all these things. So that that's probably the other big thing is around us we have this insulation of like a enormous company but the feeling of like the team and the structure and the growth of that is it kind of feels like a like a mini company. >> Yeah, that that's sort of what I I did get that feeling at my the company I was at, but I I probably just didn't wasn't mature enough to assume that sort of mindset, but I'm seeing it now. >> Yeah. And like like I was just kind of admitting to I I did not really see that before and honestly probably over the last week I was having this reflection. Uh so that's why it's yeah very very funny timing but yeah it it does kind of feel like that. So um yeah that's cool. So what about like so if you're going to smaller companies you did mention web development. Uh, has the domain like aside from just being web, has the domain been very different across the different companies or like did you stick to particular like industries within like web development? >> The domain the the type of customer we're serving has certainly been different. Um, but it's all more or less been B2B. I'm trying to think of a scenario where it really wasn't B2B and I'm not coming up with one. Um, so yeah, the industries have been it's all been SAS stuff. Um, you know, mostly selling SASbased products to larger companies with a with a web presence and in some cases a mobile presence. >> Interesting. Okay. And for you and in that development experience, I'm going to be guessing if if it were smaller companies, did you find yourself doing sort of like full stack? like you kind of mentioned the beginning there was more like some sounded like backend work but I'm guessing maybe it's been more full stack since then. >> Yeah. So I like I said started out with backend and then it it was full stack for a while and you know to some degree it's kind of always been full stack as you mentioned but uh I think when I when I sort of was introduced to my first introduction to web development was was through like jQuery. So that was the that was sort of how I saw web development initially and that was back in I don't know was that 2011 and that's when browsers were quite a bit different than they are now and something like jQuery was very very important and I was just sort of fell in love with that that that the web development it was just so different from what I was used to before I could see how I I could create something that users could you know it was it was visual it's something that I could create that users could see and use right away versus this thing running on a on Slackware somewhere in a rack of servers in a data center. Um, not to, you know, not to say anything bad about backend engineering because I I I still enjoy doing that to some degree, but there was something a lot different about front-end web development and I kind of focused more on that as a full stack developer for a while and I kind of became more or less an expert in that area and I I carried that on throughout my career but I found that I you know my first pivot was from backend to front end and with sort of a full stack thing going on there but I I I wanted to sort of branch out more. I didn't feel like being pigeon holed into front-end development. So, I started doing a lot of DevOps stuff. I started picking up QA work and then later down the road management came in and that was yet another pivot. But I just sort of felt like and this is another thing that I wouldn't say that you can do it at smaller companies, it's that you have to do it at smaller companies is wearing all those hats, right? You have to wear a lot of hats. there isn't there isn't as many levels of hierarchy and it a company of 10 people if a customer support request comes in and the customer support person is at lunch well one of the engineers is probably going to need to pick that up and that's fine it sort of made me a more well-rounded person and I kind of enjoyed being able to do that sort of thing having a wide variety of roles that I could fill at any given time >> yeah when you had mentioned like you soon as you mentioned like doing DevOps work and then said keyway right after I was like oh yes Given that you worked at smaller places, it's very much like I would say like if if I went to a smaller company after Microsoft at some point, I would very much imagine myself I have to remind myself, you know, you got to wear all the hats. And for anyone that's listening, like I would say, especially if you have not yet worked in a smaller company, uh whether that's because you started at a bigger one or you're not yet, you know, at your first place, smaller places, I would say that's it's an expectation. It might be uh unwritten, but it's it's kind of out of necessity, right? It's not um you you might be like, "Hey, cool. Can I have that opportunity?" And it's like, "Sure." Because it's basically going to be handed to you right away. It needs to get done. >> It's like all hands on deck all the time. And and I like I said, I like that, right? I Yeah. >> I I don't want to be, you know, Ry the front-end manager, Ray the front-end developer, or Ray the backend developer, Ray the DevOps guy, Ray the QA guy. I just want to be, you know, Ray the engineer, right? And I do the things that need to be done to get that to to get the product across the finish line or to get the feature done. And that could be writing the front end and writing the back end and doing QA automation and setting up the infrastructure or being involved in all that to some degree. >> Yeah. Yeah. And it's interesting, right, because as you were talking through some of that career journey, like it sounds like in the beginning when you were very fresh to it, like that was probably a little bit too chaotic, right? Like some structure was needed, but now that you have a lot of that experience, you can kind of lean into like it feels good to be able to go do the things that like need to get done. >> Yeah. I think it's I think it's just sort of a confidence that you build up over the course of your career. And maybe when you get to a certain point, you know, this is n equals 1, but maybe when you get to a certain point, um that confidence allows you to makes it easier for you to do all those different things and wear all those different hats and not sort of wonder, well, can I really do this? Should I really be doing this? You just sort of do it. >> Yeah. Yeah. And I I don't know. I can I can remember stuff in early startup days where it was like it's got to get the fact that I'm in management now is literally because of that. They said the team's growing. You can talk to the engineers like we're going to be hiring more. Like do you want to try leading the team? And it was like I don't know what I'm doing. I'm like I'm fresh out of school. Like and I guess that's actually pretty typical uh management on boarding is no one knows what's going on. So here you go. Um but that's something I stuck to. Um, but there was lots of things you mentioned like with uh with customer support and stuff. I can remember like yeah, like we got to go triage things and like that's not what I worked on, but we have to go look into it. Like there's no choice. >> Yeah. I I the thing that kind of annoys me the most is when I hear the that's not my job kind of I you don't really hear that from from good employees, from good engineers. The it's not my job. I mean it's especially at a smaller company that that's sort of a taboo thing to say but sort of off topic a little bit before you were before you're an engineering manager right you were an IC or an individual contributor right this is and I I this is something that I think about a lot and I'm kind of wondering what your thoughts on it are and maybe how you approach this are you more of a hands-on manager like do you do you like to to sort of dig into the code or do you like to focus more on your people or a little bit of both or or how has that work worked out for for you so far in your career like what have you what have you like to do? >> Yeah. Yeah. And this has changed a lot in my career and I think it um part of it because being at a startup where like every hat had to be worn, part of it now is like not at a startup. And the other thing that I would layer on to that is like sort of experience in my career. So for for context at this point um I I code every single day but not at work. Um because I like like I just enjoy it. It's a hobby of mine. So I like building software but at work now I don't because uh number one uh I have a team of very smart engineers that is capable of doing that. I review code with them like I participate at that level but I don't write the code. Um if I I'm going to kind of rewind a little bit though for when I was working at a startup um for eight years I was a like IC and manager like at the same time. And so I wrote code, I built a lot of the products with my teams and and managed them as well. But um there was I remember talking with my HR leader like throughout those all of those years and she she would ask me this not in a way that was like trying to force me to make a decision, but she would say like hey like have you considered like which path do you kind of want to go down here? And I kept saying like I don't know because like part of me felt that I could still contribute a lot of value by writing code, working with my team that way. And the other part of me was like yeah but I I really do enjoy managing the team, helping people out. Like there's something really fulfilling for me about kind of helping people grow and sol like I'm not solving their problems but I'm helping them kind of navigate them so that they can basically they end up solving their own problems. >> You're a facilitator. >> Yeah. So like I I look at my like in my role it's a very much a support role and what happened towards the end of those eight years was that towards the the end I was managing two teams my time actually contributing to the code base was less and less and given the the company growth I spent a lot of time kind of like like helping other teams and navigating things like at a at a higher level. Um, and like I had history at the company, so I could kind of do that in these different areas where people are like, "Hey, wait, how does this work again?" Or, you know, we're about to go dig up this feature, but I remember you talked about something like this in the past and we had explored this before. So, kind of like consulting for other teams at the company. And so even at that, that's like 5 years ago now. So at that point till now I have found that in order for or it's not in order for me to grow but I have found that I reached a point where I can have greater impact by typing less code and if I think about my career progression so I've been an engineering manager for 13 years but I'm still not a I am not a manager of managers and if I want to be a manager of managers technically I would have had a director position if I like stayed a little bit longer where I was before 5 years ago but But if I would have sorry if I if I want to be a manager of managers, I would have even less time to be writing code. It would be a lot more strategy, be a lot more working with managers to help them navigate different things. And so I feel like if I want my career to move in that direction, it's not that I am not allowed to put my hands on the code or that I shouldn't, but if I'm doing that, I'm probably not, what's a good way to say this? It should be a almost like an emergency or a reaction to a scenario, not a commonplace thing. I should go, hey, look, if I need to be doing this, there's probably a skill gap or re like a I don't like calling people resources, like a headcount gap, like skill gap, whatever. Um, and I should have more like something on someone on the team to be able to help with this. So, that's I think my long-winded answer, but >> yeah. And so you you had that opportunity initially to sort of explore both worlds at the same time, IC and manager, and then you were able to sort of make that choice. And I I totally identify what you say about, you know, the moving up to the point where you're a manager of managers, right? Now you're now sort of touching the code almost looks like you're being negligent in your duties as as at that position to some degree. And that I think that's probably tough for people like you and me where we really enjoy coding. And I mean me speaking personally, I I coding is also kind of in my blood and I don't think that I could just totally sever myself from that entirely. And I I can even now as a manager um that's the thing I struggle with the most honestly right now is um I know what I'm supposed to do as a manager. I know what my responsibilities are and and I'm expected to be hands-on to some degree, right? Especially at a smaller company because again wearing lots of hats. Um but it's important and this is something I'm still working on myself to understand when you should just back away and trust your engineers to make a to make a decision to make an architectural decision and when you should jump in to help. And I think that the the thing that's the most difficult to realize until you're told it is as a manager when you're stepping in there um let's say you here's let me give like a contrived example here. >> Sure. Yeah. um you are uh there's a you're putting there's a proposal there to go a technical direction for like a feature and uh the team makes a decision right they they've decided they're going to go this particular way and you see an opportunity where some you feel like it isn't going quite right so you interject and say hey everyone I feel like maybe we should maybe we should make these do these very specific things in the code instead >> and everybody does it So you think, "Oh, well, my idea must have been the right one, so great. I'm glad I stepped in." But it turns out that isn't necessarily the case. What probably happened is everyone agreed because they're like, "Yep, my manager said this is the right way to do it, so that's the way I'm going to do it." Um, not because it's the better way, but you it it's and if you don't realize that's what's going on, then you sort of see that as an opportunity. Well, I should be jumping in more. I should be contributing more to code. And then it's sort of a vicious cycle and it sort of spirals and now your now your engineers don't feel like they're trusted at all. And I I'm not saying it's ever gotten to that point in my career, but I I I often try to take the opportunity to jump in in the code and have to sort of restrain myself. Sometimes I'm not able to. That's the toughest part for me is be um you know being a manager from my perspective is knowing when to jump in which is very rarely and being able to you know just trust in your team to do the right thing. I mean be informed but let them make those decisions. You're the manager, they're the developers. >> Yeah, it that's like such an interesting like set of challenges to balance, right? because and I I think especially so in smaller companies like you said where there is still this expect like if you're managing a smaller team or there's you know like there's a lot going on being able to jump in and help where help is needed makes a lot of sense but how you were describing that it's kind of interesting right it's like what when do you need to do that versus like when do you want to you when when is it make sense to give other individuals on the team a chance where like you might be like, "Hey, look, like I could probably figure this out." Like I, you know, some background in this space, like I know I could go figure this problem out. And you might have someone on the team where you're like, h, like, okay, this might make me feel a little bit uncomfortable for them to do it. But like sometimes you just let them do it, right? like if they're not going to if it's not going to paint you into a corner or cause like a really big risk or like a big uh surface area damage like sometimes giving people that opportunity like you have the guard rails you can put in place. You want to make sure it's a safe place for people to fail. Like sometimes they need that and it's it's hard because you like you said you kind of have to restrain yourself sometimes. um and knowing when to step in to to kind of help mitigate or course correct versus like, you know, are are you just doing that because you you wanted to or I don't know. It's uh it's a really difficult challenge. I I feel like that what I'm what I'm coming around to the realization is that um maybe it's only okay to step in you know and and for architectural decisions if I'm asked and and and you know my team will ask me they'll say hey I'm not sure about this what do you think and then I'll give them my opinion but just going in and making changes doesn't seem like the best course from my experience but you know if I do want to get involved in the code I feel like it's reasonable to do things like I'll pick up a bug bug here. You know, I'll fix this bug. This isn't going to impact anything. This is a bug. I'll let my team focus heads down on the feature work, which takes a lot of focus and concentration, and I can pick up this bug. I'll knock this out in an hour or two or, you know, this dependency needs to be updated. So, I'll make the changes to to fit it in there. But for the feature work for for the for the main pro you know parts of the product I want the team to be to own that because the other thing is if you're going in and you're you diving into a to a feature the other problem is you're not in the code dayto-day and your your team is right. So you're making uninformed decisions based on your intuition which that just that just goes wrong in so many ways. And like for some people though like they you know if someone's listening to this they might say yeah but I am in the code every day like in my former life I was also in the code every day. So like that would have been fine but like certain like right now absolutely not. If I was going into the code for my team at Microsoft like they would they might not say anything but they should say something because I would be very uninformed. It wouldn't it wouldn't be a good move. And it's interesting like as you're kind of talking through that I'm trying to I'm trying to see if I have like my own mini lesson in my head that would be like hey this is what I would recommend to people like listening but I kind of come back to like I see my role as a manager I support right so as you were talking through like hey maybe I can fix a bug maybe I can update dependencies like I see that as support unless you have someone on your team that loves to do that pro and maybe some people do probably most people don't and they're like I don't want to work on that crap like we have to do it fine but like so if you're like cool I can let them focus on like the more engaging things the more interesting things you're supporting them by doing that now there might be situations that come up and depending on your team the experience there might be some feature or architectural change or something going on where they're like like we need help with this we don't have that experience and you can again you can support them by providing some architectural guidance maybe maybe you come up with the entire architectural spec This is one of those things where I would say if you notice that your team sort of has has that gap and it's not their fault or anything but if there is that gap it's not that oh don't don't do it to help them. It might be hey this has to get done but that's a good reminder maybe we should do something about this on the team. Do we need to skill people up with this technology? Do we need to see if there's like someone else that we can do an internal transfer? Is this a one-off thing and maybe I'm overindexing on it? I just try to take those as opportunities to reflect and see should something change or is this like a one-off kind of thing but support. >> Yeah, absolutely. Completely agree. >> Yeah, it's uh it's definitely an interesting challenge. So, in terms for your career would like So, you are currently an engineering manager leading teams. >> Yep. I've been officially in management since uh I think since 2018. 2018, right? >> Yeah. Okay. And so from what I'm hearing, there's still some work that is hands-on, but like do you feel like at this point like you're kind of gravitating more towards like I'm trying to think through the question my HR leader was asking me like to ask you like do you do you find yourself kind of going in that direction more where it is more people leadership versus like the the hands-on part because I know you also said it's hard to like remove yourself completely. Yeah, that's a I've that's a complicated question for me to answer. Um, I I sort of still like doing both things, right? I like being a manager. I like being able to have that effect on the organization. I like being able to to, as I sort of mentioned earlier, I like being able to sort of play facilitator for my team. Um, but I also still am very passionate about the tech. Right. Right. >> So, um, >> I don't know what direction I'm headed in. Maybe maybe my direction is the direct is is just um staying where I'm at now in terms of just being an engineering manager or a hands-on kind of senior engineering manager um for the rest of my career and that might just be fine. Um but you know I've said this sort of thing before. Um one of the things one of the lessons I've learned in my career is whenever I say I'm never going to do something that means I'm probably going to do it. Um, like I I said at one point, hey, I I don't want to do web development when I was a backend engineer. Well, I went into web development and I said, I am never going to be a manager. Forget that. Now I'm a manager. Um, and then I said things like and you know, when I was when I when I was promoting my book and when I was like working on a a open source project that I had to promote, before I did any of that, I'm saying I don't want to even touch marketing. That's dirty. I don't want any part of that. And then I realized, well, I mean, you can't say that you don't want to market yourself because that's just not a smart point of view. So, you know, now that I'm saying I never want to go into sort of I I was at the director level um for a bit at my last job before I jumped to the current job I'm at, but I was still more or less hands-on. Uh but, you know, now that I say I don't want to go into a true director level position, I'm sure that's going to be my next position. That's just sort of the way it works out, isn't it? >> And I I was going to ask, is that more like uh seems like coincidence or is that something where you end up challenging yourself like more consciously? >> Maybe subconsciously that is what's happening. You know, it's sort of something that circulates around in my brain and I'm saying I don't want to do this. And then, you know, the other voice is saying why don't you want to do this? Maybe you should try it. Okay, I'll give it a shot. Um >> interesting. Yeah. one of the like when I reflect on career lessons I've uh it's it's similar right you're in some cases here this is more like for for role changes and stuff but I found that um almost like from an imposttor syndrome perspective I found that if I'm dropped into this because this happens to me in my career so far I'm dropped into a position or like a project or something where I'm like oh my goodness like I don't know about this like I feel doesn't matter how much experience I have in whatever direction like all of a sudden I feel like I'm at zero and I go uhoh. Like am I going to am I going to make it out of this one? But every single time like you come out on the other end, you learn a ton. Uh are there was it perfect? Probably not because nothing's perfect, but like you made it through. You were successful. And it's like every time you do these things, it's like a, you know, another lesson for you in your career where you can say in the next time, hey, look, all of those other times I made it out alive, right? what things to learn. >> Yeah, that's I had a when I first went into management, I I sort of fell into management, right? So, I was interviewing at a couple companies ago, I was interviewing at for a lead software developer position. And midway through the interview process, they said, "Well, we have an opening for a manager. This has now pivoted to a manager position. Do you want to do that?" And I said, "I guess." Cuz I had already gone through like four interviews and and I thought, "Ah, whatever. I'll just do it." But, you know, from the the time when I had left my previous job and I had a couple weeks where I was going to start that job, I remember, and I'm sure my wife remembers this, too. I was just absolutely freaking out. Like, I was just thinking, what did I do? I Why am I going to management? This doesn't make any sense. I mean, I I don't know what I'm doing. I don't know how to be a manager. I've never been a manager. I was briefly sort of a manager my first job and it went horribly. Why am I doing this again? I even gave speeches. I I I gave I gave presentations a few jobs ago to to uh high school students about careers and one of the things I said is one of the things I learned early on in my career is I should never go into management. Famous last words. And I'm thinking about all these things and I and I know I'm going into management and like you said, I was dropped into it and I survived and I'm better off for it. >> Yeah. And like that that I think is such a tremendous lesson for people because imposttor syndrome and stuff happens for everyone, right? And some people like I don't know won't admit it. I don't know why. I've talked to lots of people online that are like that's not a real thing. And I'm like I don't know how you say that. But uh in fact the more people like the more experienced people that I have talked to like you know at VP levels and stuff they're like you know even to them at that level happens and it's not like it's infrequent but they have enough experiences where they can go okay like I remember this feeling like you know I can think about the hundreds of experiences before where this happened and like I got through. So, it's just a good reminder to folks that you're going to experience lots of things in your career and they're they're going to make you uncomfortable at different points because you you don't feel equipped and you know you will persevere. You'll learn plenty along the way and it doesn't have to look perfect. It's not >> I think that that feeling of being uncomfortable kind of is is more or less a good thing, right? I mean, it's not good. Nobody wants to be uncomfortable, but the alternative is kind of being bored and, you know, set in your ways and you're just sort of doing things and maybe those things are important and maybe they're not, but you're not really advancing at all. So that that that state of being uncomfortable means you are, you know, maybe hopefully evolving as a person or as a professional. >> Yeah, I I totally agree with that. the the more I've more people I've talked to, I've realized that there are subsets of people and I feel like and I don't have like data on this, but I feel like proportionally smaller subsets of people that are like, "Hey, look, like I don't actually care enough. Like I'm cool. I'm actually pretty comfortable in my role. Like, you know, it's interesting enough, but like there's not a lot of pressure. Like I'm I'm good being just kind of comfortable at this." And I've met some people like this or talked to people like this, but I feel like the overwhelming majority is basically as you described that includes myself where it's like, you know, I I feel like if I'm a little bit uncomfortable, I'm being challenged in ways I'm growing, I'm learning. Of course, as it happens, it's kind of scary because you're like, "Oh man, am I cut out for this?" But yeah, uh it's always that reminder that there's growth that comes from that and that means that you know hopefully you are growing and getting better as a software engineer. >> Yeah, I mean there there's that balance that obviously constant friction isn't a good thing but also constant comfort the other side of that is is is you know it's boring, right? And I'm I'm sure you know I feel this way and I'm sure you do too. I I I want to kind of enjoy what I'm doing and get something out and and not just sort of you dial in in the morning, so to speak, you know, type up my TPS reports and then go home. >> Yeah. Like that. For me, that's absolutely not what I want out of my career. And like I said, I think for some people they're they're totally cool with that, but I I don't know. I feel like I I don't I like to work. And I maybe that's part of it is like I like working. I like making sure that I feel productive, that I'm having an impact doing stuff. Like interesting challenges. If someone was like, "Here's a billion dollars. You never have to work again." I would be like, "I think I need to work cuz like I like to do it." It might just be that maybe I'm working on different things. I don't know. I like problem solving and I like building stuff. So, I don't think that's ever going away. >> Yeah. I I I've had I've had that same thought myself. I mean, sometimes I do think I'm sure you have this feeling, too, where you'll have like a day where you think, I'm done. I'm I I I just I I don't want to do this anymore. Why am I still in tech? I've been doing this my whole life. I don't want to do it anymore. This is enough. But then then you think, well, what am I going to do? Am I just going to watch TV all day? I'm going to drive everyone crazy if I'm not working anyway. So, I you know, I I this is what this is who I am. This is what I do. Yeah, >> but you know it's there there's definitely days where you think well maybe I could do something else. >> Yeah, it's uh you know the intrusive thoughts are there for sure but at the I think at the end of the day it's like like I said I I love to build things and I I don't think that that's ever going to change. Um sort of related to to role changes and things like that. one of the notes that you had sent over and I I'm very curious about this is like you had said don't take new opportunities for granted but know when to say no and I was I was curious about this especially given some of the background for like smaller companies and stuff. I imagine that there are plenty of situations you've been in where it kind of feels like, hey, I'm doing a lot already. Like I don't know if I'm gonna be overloaded, but like I wanted to hear your perspective on like those like things that are truly like opportunities where you're like this is new. This could be exciting versus like the like I need to say no to this and what that looks like for you. >> So early on in my career, um, one of the things that I tried to do all the time was just pretty much say yes to everything. Um and and because I was trying to make something of myself, right? So when I had the opportunity to go into front end development, yes, let's do it. Um when I had the opportunity to uh be the maintainer of a open source library, yep. Um do you want to write a book about that? Okay, let's write a book about it. Um do you want to start giving presentations to high school and college students? Yes, let's do that, too. um all these things and and before thinking if I actually had the time or energy to do it, I just sort of made it work because I felt like this was I just had this feeling like this was I couldn't see exactly why yet, but I felt like this this is potentially opening a door somewhere. Okay. >> Um and and in many cases that actually happened interesting story. So um there was this uh there was this library that I inherited uh back in 2011 called it was called Valum's file uploader and uh I inherited it the I because I I opened up some poll request and the maintainer said do you want to just do this and I said all right sure I'll maintain it and I grew it into a much larger open- source library renamed it fine uploader it grew exponentially over time and that did open a door for me later I was interviewing for a company a few jobs after that and I bypassed the entire interview process because they were their my the library that I that I maintained was the the cornerstone of their product which was interesting to find out. So I that sort of got me in the door there and you know it just saying yes to everything was tiring but it it gave me access to things that I wouldn't have otherwise had access to. It gave me new perspective. It made me a more well-rounded person and professional. But the no part I feel like is becoming more and more important as I, you know, evolve and get further on in my career. Um, because I have less free time now. I have to be more conscious of how I spend my time. I can't just be, you know, before I had a family and everything. It was just, well, I can work all the time. Who cares? Whatever. I'll just do this. I'll do that. I'll write the book. I'll maintain the library. Doesn't make any difference. But now I have to be more conscious of my free time. I have to I can't just be working all the time. So, the opportunities that present themselves, um, if they fit into my schedule and they seem like they're worthwhile, then I'll say yes. Otherwise, I probably will say no. Um, but honestly, the kind of the drawback of always saying yes early on in my career is I've kind of developed that reflex. Right now, it's hard to say no. Um, and sometimes I've regretted saying yes and I when I look back, I wish I would have said no. Um, so I'm kind of trying to I'm still trying to formulate when it's appropriate to say yes versus no, when I should just say no, I'm not going to do this. Did you find at all that working in smaller companies made you do that more too or like cuz we were kind of saying earlier like, hey, if it's got to get done for the company, like got to wear the hat, someone's got to do it. like do you do you feel that that had an impact on the saying yes part a lot or tangential? >> Um I think it probably did because you know the expectation that you wear lots of hats means that the yes is implicit, right? Um so this this customer is having an issue with their with their router. Um the customer support person is out today. Um can you can you the the can you part is sort of a formality, right? Yeah. what really what they really mean is fix this for them because there's no one else to do it and we're a small company and we can't just say sorry that your router's broken. We'll we'll uh you know reach out to you in a week when the person's back from vacation. Um so that probably was part of the conditioning, right? Working for smaller companies where you just have to do a lot of things and you're conditioned to do a lot of things. >> Yeah. as you were talking through that that was part of my own personal reflection because you also mentioned too like you know saying yes to a lot of things earlier on now it's like like I I don't have children anything but like uh I was basically single for almost my entire early career and now I'm married and like I certainly know that I cannot just work all of the time I would not be married um so like I know that I have to look at time management very differently now and I was thinking that before. Yeah. Say yes to like it's a startup. We got we have to say yes to things like it just has to get done and I didn't have any other commitments. I could just work all of the time, right? I was an individual contributor and a manager. I I had to work two jobs anyway. Like what's and I liked what I was doing. So like it kind of all just compounded. So it was just yeah like it's got to get done. say yes, you work more and you know every everything seems like it's better because of it. But now like that I certainly cannot do it. Um that like I find myself also being like hey even if that seems like a good opportunity I actually have to question myself and I also have a very difficult time going like should I be saying yes or no to this? Like I don't know. >> Yeah, that's that's true. I mean, it seems like a good idea, but then you have to weigh the consequences of committing to this additional thing, >> you know, given all the other things that are going on in your life. How is this going to affect those things and those people? >> Yeah, absolutely. And I've like it it's very interesting because as you were saying like, you know, saying yes to things afforded you a lot of like interesting opportunities that came up there. there there's more like I don't know like not self-help or like professional development kind of stuff that I'm either reading or watching where the advice is like very much learn to say no like you need to be able to say no and I'm kind of like I I still am struggling with that where it's like you know it's not I guess the answer is not to say no to everything it's to know when to say yes but that means there's an overwhelming number of nos and I I still feel like yeah but when you They know the door closes like oh no I don't know the answer. >> Yeah there is that I I I don't know what the answer is. I think it's just the answer kind of is whatever you want to do or it depends right because I've sort of heard both extremes. The other extreme being just say no to everything. Um and and you know eventually an opportunity will drop in your lap. And I don't know if that makes a lot of sense either. I I don't want to be the person that says no to everything that you know if someone really needs something that they're just going to stop asking you because you always just say no, >> right? Yeah. Like I I I align with that. Like yeah, it seems it seems like something that would not be a good fit for me, but as a result then I'm like I don't actually know what the like a better balance would be. Um, there was another thing on your list that I wanted to ask you about and uh, I hope you're comfortable to talk about this because you wrote it down, but uh, you said the challenges of being an introvert as an engineering leader. And I will break the ice a little bit on this one because it might not be obvious, but I am extremely introverted. When I people the whole day, which is my job, like there are some days if I do one-on- ones for the day, 5:00 hits, I nap. I have to nap because I am literally exhausted. Not because I don't like what I'm doing, not because I don't like the people I'm talking to, but the amount of energy that requires for me is like it's it is physically and mentally exhausting. Again, not anything to do with the people uh specifically, just peopleing in general is very tiring for me. So, I was curious to hear from you like your perspective on engineering leadership and being an introvert. >> And I firmly believe that is more or less the definition of an introvert, right, versus an extrovert. I I when when you know maybe I'm at a party or something and I I don't know somehow it'll come out that I'm more or less introverted and they'll be like no you're not you're what are you talking about you're talking with me right now or you give presentations or what what all this stuff right introvert doesn't mean you don't talk you just sit in a corner and like sort of mumble to yourself it's just kind of what you said is that engaging with people in conversation saps your energy right and the more you do that the more recovery time you need, the more alone me time that you need. That's exactly how I feel, too. Whereas, you know, I I know marketing people that, man, they could just talk all day long with people and and by the end of the day, they're just amped up from talking with people. At the end of the end of that day, just listening to them talk to people. I want to go to bed. Um, and and that that's the tough part. I I feel like that from my perspective that makes being an engineering leader or a manager a little bit more challenging sometimes because you're having a lot of conversations, sometimes difficult conversations even, which are even harder for me. Um, but you're you're doing a lot of talking, you're doing a lot of expressing yourself, and at the end of the day, you're kind of wiped. And it's kind of odd, you know, at the end of the day, I'll I'll I'll you know, because I work from home, I'll go upstairs and I'll be like so tired. I just want to go to bed. And my my wife's probably thinking, >> "You were just sitting at a desk all day. Um, why are you tired?" And it's kind of hard to explain because she's very much an extrovert, right? So, it's it's kind of hard to um it's kind of hard to explain to people who aren't like that, right? That you know, you just you just need some recovery time. Um I I still do like being an engineering leader. I like being a manager. I like, you know, engaging with my team, but I have to be mindful of my own energy levels. And I sort of design my schedule around that so that I can be effective and not a entire day's worth of meetings where by the last two or three meetings I'm just sort of voting in and not providing any value to the team. I I need to be I need to be self-aware. Right. >> Yeah. And so like if you don't mind me asking what is like a not hyper specific but like what kind of scheduling wise in terms of like meeting with the team and kind of laying out your week like what feels like like a good fit in terms of kind of making all that work >> there there's a couple things I like to do with scheduling. Um, I first of all, I like to group kind of I I I don't I don't like to group meetings one after the other. Like literally one after the other where you have one 9 to 9:30, then 9:30 to 10, then 10 10 to 10:30 because then I'm going to get really tired and and I just I I just need like a break in between those. So, I kind of like to cluster the meetings together, but I want a little bit of like a half hour or 15 minute break in between them so I can gather my thoughts so I can sort of, you know, just sort of meditate or get ready for the next meeting. Um, and I sort of like to have a day where I do all my one-on- ones. So, I'm mentally prepared to to go through all those one-on- ones. I'm I I have everything that I need to talk about all set on those on on the day for the one-on- ones and I get through them. And I know it kind of sounds like I'm talking about it like it's a chore and I don't really see it that way, but I need to again I need to be self-conscious, right? I need to I need to understand myself so that I can be effective for my team when I'm having these conversations. I don't want to be sort of uh just at the end of my at the end of my rope like out of energy when I'm talking with them. I want to be fully present and I want to be listening to them and I want to be engaging. It's funny, too, because as you were saying that and then saying you have a day of 101 ons, I was like, if I go to tell you that I also have a day of 101 ones, I was nervous that you would say, "Yeah, but that doesn't make any sense because don't you need the time to to recover?" I like to be able to cluster it and like you said, to be able to kind of prepare for like I have two effectively two days of the week where most like all of my one-on- ones happen across those two days and that allows me to kind of mentally prepare for that. Again, it's not, like you said, it's not a chore. It's just that like I know that I have to kind of have that mindset going into it. I have other like other days where they're mostly um like things I can either follow up with partner teams or work with some of my my PMs on things or or carve out time to go through like design documents and stuff like it's more I don't know uh like it's it's not like specifically like people personal kind of stuff going on and I can navigate that way more effectively. But I I have to compartmentalize some of those days for that. So, >> do you find that um and this I I ask you this because this is this is sort of what I do is I I like to and maybe you do the same thing. I sort of like to you know I I'll have meetings when needing meetings need to be had but I like to fall back on written communication as much as possible. And there's a lot of benefits to that. You know written communication is something that you can more easily share with others. It's e more easier to broadcast. But also I don't you know writing things down doesn't set my energy and it gives me time to really think over that what I'm communicating to everyone else. So when I have to jump into a meeting and have a face to face I will do that but I prefer to communicate in you know written form whenever it makes sense. And I feel like that is a good tradeoff and I feel like it's made me a better writer falling back on written communication as much as I have. >> Yeah. And so I'll I'll answer that. That might be a good kind of like a sort of last topic as well because one of the other things that you wrote down was leadership in a remote work environment. And I I think for my answer kind of ties into some of that. So uh yes I if I can if I think that something could be written communication I would much rather do that. I think that if I for at least the engineers I work with almost all of them kind of will default back to that like hey if we don't have to have a meeting like let's not like I'd rather actually work on my work. Um so yeah if I if I can approach things written that's I would rather do that. Um, and I think one of the things that I need to sort of navigate is like if I don't understand my team well enough, then then I can make the mistake of of that being an assumption that's not true where it's like I like written communication. Most other people on the team seem to like maybe I can just default to that. And I might have one person that's like, nope, I like I really need that face to face time. I need to be able to understand things better that way. And if I if I don't think about that, then I might be sort of excluding them uh in in a way that's like more effective communication. So, um like for me right now, uh at Microsoft, the first team I was on was effectively all remote. Uh including some people that are permanently remote and some people that just they weren't coming into the office, so we also didn't. The team I'm on now, um you know, is I also have permanently remote people and I go into the office a couple days a week. This is before the RTO announcement, so I was kind of doing it because other people would also go in, so why not? But yeah, I I find that I think as long as I'm situationally kind of leading and thinking about how other people on the team like to be communicated with, then I can balance that out. Personally, I do prefer uh written if I don't need to do face-toface stuff. Oneonone's will always be uh on a call kind of thing, but otherwise, yeah, written if I can. Yeah, if if it can be handled via, you know, typing something out on Slack or an email or whatever, I think that generally tends to be the better way to solve it because it gives everyone more time to think about what their answer is going to be or what how they're going to respond to that versus being on the spot, have 3 seconds to answer, just answer the first thing that comes into your head. >> Yeah. And like that's a a really important tip in general for like uh for folks that like if you lead a lot of meetings, right? uh that could be not you don't have to be a manager necessarily. You could be someone who is more senior or you're putting a design dock together or whatever it happens to be. You're organizing a meeting even if it's not that you do it a lot. Something to consider is that um I wish I could remember the framework for this. This was one of those times where we had manager training and I was like this is really interesting but it's so rare that it happens so the the terms don't stick. But there were these uh personality types essentially and they were describing that some people I am one of these people like must have information ahead of time to be able to like digest it to formulate thoughts to be able to talk about it. So for example if you wanted to walk through a design with me like if you were to just show me the design on the spot and be like here's why all this I would be overwhelmed and being like I I didn't have time to think about this digest it. Uh where are the numbers for this? like I'm curious about how that works. Uh oh, maybe it's on one of these pages. I don't know. Like I didn't, you know, I can't do it on the spot. And other people, there were like four personality types, but there was one that was almost the exact opposite of that. And they actually thrive in being able to just like kind of explore on the spot and like more spontaneous. But if you're not totally it, this might sound like it's like a I don't know like not really necessary, but I think it's very valuable to consider like the people on your team and how they are. Some people do better in those situations. I feel like most engineers are probably similar, but >> yeah, I I've I've I've met very few obvious uh extrovert uh engineers. most of them seem to be more more leaning towards the introvert side. I think it's just the way the trade is, right? >> Yeah. It's it seems like very like sort of stereotypically that way, but again, for anyone who's in a in a leadership position or even if you're just like, hey, how do I work more effectively with my teammates and stuff? It's something to consider. Um because people are different. So, and the more the more people you work with, the more of these situations are like, "Wow, like this interaction with this person seems kind of odd compared to everyone else I'm working with." Maybe that causes friction. Maybe it's actually a really good working relationship, but taking some time to go think about why that's the case, I think, could be super helpful. And just like, I don't know, having better working relationships going forward. But is there anything from like a like a your number one sort of either tip or uh don't do it kind of thing when it comes to remote work and and being able to navigate things that way? >> Um well I I think there's a number of things that I think are important for working remotely that make it more effective. Um one some of those things are just kind of good principles to follow no matter what. Um, I'm I'm a very probably obsessively organized person. Like I I I and I felt that's worked to my advantage significantly working remotely. Um, because you're kind of when you're when you're working remotely, I feel like maybe it's not the case, but it feels like you're more independent, right? It just I I feel like I'm more independent as a remote worker. You know, I I get up in the morning, I go down to my office, and it's just me here. There's no other people here. uh and I have things to do and I have to get those things done and there's no one tapping me on the shoulder and there's no one calling me um usually um and I just I just need to get things done and and I get them done right and I felt like being on top of things and being organized has helped me do that. So, I would say being organized. I mean, I I practice things like inbox zero. So, my inbox is like my to-do list. Um I and it's my only to-do list, more or less. Um just >> keeping your tasks organized in a way where you always know what the priorities are. You always know what you need to be working on. If a fire breaks out, once you put out that fire, if you know, if if you're able to go back to do what you're supposed to be doing and you understand, you don't have don't keep a mental model of all your priorities. Write stuff down, right? >> Good luck with that. >> Yeah. Exactly. Because I I don't know about you, but I uh I'm very organized, but I can't remember anything. So, if it's not written down, it probably, as far as I'm concerned, it didn't exist. So, that's another thing. >> The number one conversation with my wife is basically that she'll be like, "I just told you that." And I'm like, "It's not written. It's not like I heard it and it was in there and I acknowledged it, but it's not on paper. It's not in a calendar. Like doesn't exist. >> Exactly. Yeah. If it Right. If it's not written down, it doesn't exist. That's kind of how my brain works or doesn't work. >> Yeah. >> Um and then the the the asynchronous part of it is something that I feel like you really need to embrace. My my first fora into remote working was a pretty extreme version of remote working. Back in 2016, I worked so my team was in Madison, Wisconsin. Uh I wasn't a manager then, but I was I was sort of in a lead developer role and I was working on a project over in Thailand. So I was 13hour time difference and um I definitely learned a lot about how it to be effective and to not be effective working remotely in that particular scenario. And the good thing uh about it from my perspective was every remote working scenario after that is going to be much easier to deal with. And of course it was. And I sort of learned to embrace asynchronous communication. And that's kind of what's really important with remote work. Asynchronous communication can be it can be Slack or Teams or whatever you use. Uh it can be, you know, uh when you and the people uh the people that are really good at remote work tend to be good at this too. Uh this this just happened today. Someone on my team they I we I I noticed one of our development environments was having an issue where some of the API requests were taking a long long time to return. I was like what's going on here? Um can some can you know um can you look into this for me? And the person looked into it and he wrote up a document on Confluence documenting how he troubleshooted it to find out what the issue was and how he solved it. And then he published it in the how-to section of our Confluence page. So if anyone else comes across it, they would be able to just follow his playbook. That's how you remote work, right? You that's how asynchronous communication works, writing things down so that other people can discover them at their convenience. And I think that is a very important thing you would do as as a remote worker. The other thing is kind of my my favorite word is inculcation, right? And that's to instill with repetition. So you know, this probably works in person, too, but I've only been working remotely. I've been working remotely since 2017, so this is kind of all I know. Repeat things over and over and over again, but not the same way in different forms, in different mediums. So, it just sort of becomes something that's part of your subconscious, part of other people's subconscious, right? But really, going back to the last thing I said, asynchronous communication, if you can master that, I think you're going to be way ahead of the game as far as a remote worker. And good communication, verbose, but not overly verbose, right? So when when you're when you're uh trying to get help from a senior engineer uh in a remote work environment, don't like type out like every word is you're being charged for every word, right? You need to get as much detail to them as possible so they can help you out. There's that sort of fine line between being overly ver v ver verbose where you know the person is reading pages of information and their eyes roll back in their head and they say, "Ah, let's just get on a call. I don't know what's going on. This is too much." But, you know, highlighting important things for them to look at so that they can help you more effectively in providing useful details. When you're reporting a bug, for example, this is something that really doesn't have anything to do with remote work, but it illustrates the point. Um, when you're writing up a bug report, write it up not from the p not from your perspective. So, the person who's looking at the bug report cannot get into your brain and know what you're thinking and what you're seeing. You need to spell everything out for them step by step. What did you do? What variables did you set? What did you see? what did you expect to see? Um, that's just be detailed in your communication such that you can get your point across effectively. >> That's actually something like I I don't want to say struggle with, but like something that I have to consciously remind myself. I am naturally someone who communicates in a very very verbose way. I also have this problem when I talk like when I make YouTube videos, I have to like stop myself because I'm like, you've said the same thing like 10 different ways. like just move on. Um it's part of kind of like how I like to convey ideas. I'm already doing it right now where I'm talking too much and I don't know exactly why I do it, but I think it stems from the fact that I want to make sure that I'm giving enough information. I don't want people to to to hear what I say and they're like, "Yeah, but like where did that come from?" Or like where did where does that idea stem from or whatever? And I talk too much. And I do the same thing when I write emails or when I'm sending like a report on something. And I like one of the strategies that I'm trying to do more of is like I write it and like I have to do multiple passes and I try to bubble up like the important part. So I'm like, you know what, someone's eyes are going to gloss over after like line two because they're going to see that I wrote a novel and I need to write the novel cuz I want them to have the information if they need it. They can know where to find it. It's documented. other people can search it in their email, but like go through it. What's like the the point? Like I will highlight things. I will put it to the top and I'm like if you stop reading here, at least you got hopefully what you needed and I feel okay about that. >> What you said there, I should have mentioned that because that's what I do too. But that's a really good thing to do. When you write something out, don't just send it. Read it. When you write it, read it over and inevitably you're going to read it over and you're going to make a lot of changes or you're going to shorten. You're going to say, "This doesn't make any sense. Oh, what was I thinking here? Oh, that does that's totally incorrect." So, you know, proofread your own work. Read it. Try to I mean, it's not easy to do, but try to read it from the perspective of someone who doesn't know what you know or at least, you know, do your best to do that. It's absolutely a skill and like again for someone who isn't practicing that or they're hearing what you're saying and they're like yeah whatever it's just a message whatever just an email whatever like getting in the habit of trying to do that trying to refine it like it is a skill that you will improve on. Um, one of the things that you were saying that uh you said I uh happened I don't know if it was I can't remember sorry if it was yesterday or today I had something happened today where someone was writing documentation they said hey can you review this and for me I'm of the mindset like if it's net new documentation like I'm not going to be picky like get it in there I will I I basically I approve right now but I will read it and I'll give you feedback on it so you can enhance it. So, one of the pieces of feedback was almost exactly what you were saying where he wrote it and it's helpful, but it's from his perspective. So, what I tried to do was kind of like use it as a teaching moment to say, "Hey, look, like what you said here makes sense." But I said, "Imagine someone who's not as smart as you. They don't know this, right? You're you're in this spot. Like you're you know the tools. You said, you know, take this step." And I'm like, "Where do they find that?" Like, how do they know what that tool is? What if they've never heard of it before? And I kind of went through point by point and just to illustrate like these are all things that you know because you've worked on this. You are smart in this space. That's excellent. What about the person that you're trying to help actually does not that they're not smart. That's not the right thing to say, but they actually don't know this space. So like think about it from their perspective. And then he was like, "Oh crap, like really good point." And and went through and refined it. But yeah, you have to kind of think about who your audience is when you're >> right. Know your audience. who who's going to be reading this? >> Yeah, because it's probably not you because you're the one who wrote it to guide people through it. So, you probably at least have a pretty good idea what's what's going on for >> Yeah, absolutely. >> No, that's really cool. But, uh, Ray, I wanted to say thank you so much for this. Um, I don't know, um, if you have like if people want to reach out to you and get in touch with you, like is there a best spot like I don't know like LinkedIn or X or Blue Sky or anything like that? I think the only social media I'm on is LinkedIn, but that's just, you know, because we all kind of have to be on LinkedIn, more or less, right? Um, and and I I definitely lurk on Hacker News a lot, but that's about it. >> Okay. Awesome. Well, okay. Uh, any I guess not not to put you on the spot, but a little bit on the spot, any sort of parting words that you'd want to give to aspiring software engineers or someone trying to navigate tech? Yeah, it I know it's and I I can't imagine what it's like just breaking into into software engineering or tech right now with everything that's going on with AI. And I say that literally. I I can't imagine what it's like. It must seem just overwhelming like algorithms are going to completely make you redundant. And I honestly don't see that as the case. Um, I feel like there's always going to be room for good problem solvers, for people to, even if AI sticks around, which it probably will, to wrangle the AI, to enhance it, to evolve it, to find new uses for it, to productize it. So, uh, don't give up hope. There's this is just another evolution of tech and software engineering, just like there's been many in the past. Um, just figure out where you can provide value. >> I love that. Yeah, I'm of the same mindset and I'm Yeah, I'm glad to hear that it's uh yeah, people got to stick with it. Things are going to change. They're going to evolve, but we're not really going anywhere. So, just going to look different. >> Cool. Okay. Thank you so much, Ray. >> Thanks for talking with me, Nick.