Staying Technical When The Role Gets Strategic - Principal Engineering Manager AMA

Okay, I think we're ready to rock and roll here. Welcome. Um, I just got to get Instagram going. That's the last one. Welcome to the live stream. Thanks for being here. Uh, had a couple weeks off there. I was on last week was a shorter shorterish stream. I was hoping to get into more coding last time. It didn't really happen. We did little bit of walk through on some AI stuff. We're going to shift gears a little bit. I still want to get something scheduled where I'm walking through, you know, more actual building, um, coding, that kind of stuff. I kind of miss doing that on stream. It's just really tricky because when I have time to do that, I actually want to spend time coding. Um, and I find that if I am trying to stream and code at the same time, like it's not a it's not a productivity thing. I can't balance them. So, it ends up being like more, you know, educational discussion, which I think is great, but it's not me getting time to go build stuff. So, uh, I want to figure that out cuz I think it would be good. I was doing that before. I had like, um, at one point I was doing like two streams a week where I would do coding one day and then I would do one like the uh, like I have been doing more of like a discussion, but I'm not I'm not there again. And it's just a big commitment. So, I I do want to figure it out though. But today, we're going to talk about the latest newsletter issue, which I will put into the chat. Um, and I remind folks that like the the newsletter that I'm sharing there is, yes, it's an email newsletter, but if you, you know, like the live streams and you just want to see what the topics are, then you can check that out. It's just at weekly.devleer.ca. You don't have to subscribe. Um, you don't have to, you know, pay for it. You don't have to get it to your email. Um, but if you're like, "Hey, I like the live streams." and you want to know what the topic is, definitely check it out on the weekend cuz I put it out I try to get it out on Saturday but it's more recently been Sundays and then you can see what the topic's going to be and for what it's worth the topic is usually from code commute. So code commute is my vlog channel and it's primarily question and answer based. So people submit questions and then I make video responses for them based on you know career stuff in software engineering that kind of stuff. So um if you watch code commute or again if you don't and you like these kinds of discussions and code commute is very much like that and then I write a newsletter about you know one of the videos from the week and then we do the live stream on that as well. So, that's the rundown if you're new here, but uh thanks for being here. This one is going to be about staying technical when your role is evolving. And I when I was talking about this on code commute, I thought this one would be a really good one to talk about because this is not it's not just like unique to you know like just people going from being a you know individual contributor as a developer into a manager role. uh I think it is very relevant for that but I also think some of this is quite applicable to people that want to remain in an IC role right you are a software developer you have no intentions of you know you don't want to move into management or anything like that but something that happens over time is that you know your your responsibilities your expectations the uh the sorry the expectations on you change over time as your role evolves and as you gain more seniority and to you know to summarize sort of in a nutshell what that looks like is that you have things that you're responsible for uh you know say in your IC role they're things that are sort of like on you as an individual especially as an individual contributor and then that shifts towards this expectation that you're contributing more to like um a strategic point of view right and So if you think about this like as an individual contributor, if you think if you are a junior software developer or um if you are not and you can recall being a junior software developer or working with more junior developers on your team, for the most part, I'm going to be speaking generalizations here, right? But for the most part, as more junior developers, we're spending time doing more um sort of like bite-size work. It's stuff that is not uh totally ambiguous. Usually you have people on the team that have uh you know a good understanding of the problem space right and you are able to go tackle things that if you needed support or clarity or help on them as a junior developer you could turn to someone else on the team and and get that support. So um if you think if you think about that like a lot of your dayto-day is very much like you know as an individual contributor I am being technical I am solving technical challenges and your ramp up path in terms of like how you how you get better how you become more effective in your role is like more and more and more of that right like you are trying to become effective at getting through work right so you So you can take on more features, you can take on more bug fixes, you can you can be doing this kind of thing and not relying necessarily as much on others. Okay, so pretty pretty straightforward, right? Again, I'm generalizing. Some people are junior developers. They're dropped into the, you know, the the deep end in a startup or something and it's like go figure everything out and there's no one to help you and like hopefully have it done by tomorrow. Um, so it can look totally different, but the idea being that especially as someone more junior, your ramp up path and you becoming more effective in your role is is really like kind of doubling down on on the technical stuff. So over time what happens is that uh you know you continue into mid-level and senior and on this trajectory like yes it's true of course you're staying technical you're you're staying hands-on with things you're still contributing to you know the codebase of course and then what starts to happen more is that now you're going to be designing things right and so interestingly and at least in my opinion when I think about this moving into more design work is already one of the first steps in like moving towards more strategy. And I'm not saying it's like full-fledged strategy. I'm not saying you're like talking about like five-year company vision just by doing a design doc. But it's already kind of starting to remove you a little bit from being purely hands-on. A little bit. Okay. It's it's a step in that direction. And if you think about the types of design work that you would be doing, say as someone who is, you know, mid-level, um, you're going to be working on, you know, bigger features, bigger parts of the system. As you get more and more experience, now all of a sudden you might be designing stuff with other teams. You might be designing stuff that impacts other teams. The point is that your scope is increasing, right? So the areas that you're responsible for delivering on that you're interacting with are bigger and bigger and as a result like this you kind of need to have like a bit more strategic view. So continuing to move in seniority and having more scope of things that you're designing for will ultimately continue to push you to have a bit more of a strategic view. Right? So, if you're if I'm kind of losing you on this, just to to maybe reframe a little bit, imagine that you're building I'm I'm terrible at thinking of examples on the on the fly, but imagine you're you're responsible for a feature for your team, okay? And you need to go build this for your product or service or whatever it is, but you know that you're going to have to um either interact with another team because you have dependencies on them or they have dependencies on you, right? So, especially when we start thinking about dependencies, if you weren't thinking about strategy at all, not at all. Right? You might say, well, okay, well, we have a dependency on team A and so like uh there's basically there is no other option except for team A to have this done right now. Then we'll do our part and you know team team B they depend on us. But like I like I don't know or care what they're doing. So like their problem to go worry about it later like whenever we're done. And so like you know people don't really I don't think people really think like this but if you're just ignoring these kinds of interactions like you're ignoring some parts of the strategy right the strategy around planning. How are the how are these things going to work together? You know uh team A might have their own roadmap team B might have their own road map. Your team has their own roadmap. How do these things fit together? When you start talking about risk mitigation, what's going to happen if you know one of these teams is delayed along the way? That includes team A blocking you. That includes you blocking team B, right? So if you are thinking through these things, you have to start thinking more and more about strategy. What's going to happen to stakeholders when things are not on track? Okay. So, all of this so far I'm still talking very much about like technical roles. This is all stuff that as an individual contributor you'd be doing. And so the the point that I wanted to make here and why I wanted to talk about, you know, IC stuff first is that I want to, you know, I I believe most of my audience is not engineering managers, but I wanted to kind of show you that as I talk through some of these other pieces that might seem more like, hey, this is what happens as a manager. I I want to remind you that a lot of what I'm going to talk about is still very applicable in an IC track. And I feel like there is some type of cat hair or dog hair in my eye. It's super super itchy and it's like floating in front of my face. But sorry. Okay. So So this is mostly thoughts on so far on like an IC track, right? And if we just kind of shift gears here now, imagine that as uh an individual you're moving, you are moving towards an engineering manager tracker. You want to become a manager. You want to start doing more of these things. In some recent uh videos that I've recorded, I guess they're I just realized now they're they're not live because I they're they're scheduled for like a couple weeks out now. But in one of the videos I recorded recently, someone had asked a question for code commute and they said like, "Hey, could you could you talk to us about like how do you quantify, you know, engineering manager skills?" Right? Really interesting question, right? I think it's, you know, I I when I was recording the video, I'm thinking like, okay, like here are the different areas that I think you need to have responsibility over, expectations as an engineering manager. How do you quantify your skill set there? Quantifying things is quite difficult. Um, so it was a great video to Sorry, I thought it was a great topic for a video. It's up to you if the video is good or not, but the the thought process there was like there are some parts of the role that are very much like people focused. There's an element that's like how do you you know what is your technical ability? There's an element of like how are you planning and strategizing? And in my opinion that was a good conversation to go through because it it does talk about some of this stuff. Their focus was really like how do you quantify it? But talking through it was a good reminder that like there's only so much time in the day. you know, individuals aren't going to be perfect at, you know, all sorts of skill sets required for such a role, but this reminder that like, okay, like if you're not an engineering manager and you can kind of picture engineering managers you've interacted with, maybe some are very technical, maybe you've worked with some engineering managers and you're like, I don't know how this person even works in software development, like they don't seem to know anything technical, right? So you have this element of that. Um on the strategy side of things, you might have engineering managers you've worked with where you're like that maybe they seem very tactical like they can in the moment they can get stuff done or they can help you navigate things but then it's like everything's always on fire because there's not enough time to actually step back and look at strategy. And just seeing now LinkedIn user it's not sharing the username. Who are you LinkedIn user? I will find you. One sec. I hate that this reream stuff sometimes just does silly things like that. So, I am motivated to get onto LinkedIn and join my own live stream so I can see who I'm talking to. But, by the way, thanks for being here. I appreciate you. I still don't know your name yet. I'm trying to get there. Come on. Watch my own stream. Tim, good to see you, Tim. Thanks for being here. Um, so we have to figure out how to balance these things, right? And so this topic is is yes between just technical and strategic but especially in an engineering manager role there's like there's the people side of it too and I'm mentioning all this because in that video I was trying to highlight like there's this whole other part that's people and a lot of the time uh I I mean I've certainly worked with people as engineering managers or you know even more senior uh roles that are like they seem to be neglecting the fact that people are um the ones they're working with. So balancing technical stuff and strategic uh in my opinion certainly applies to um you know the individual contributor track, right? Um it's going to happen. If you imagine someone who is more junior to mid-level versus someone who's like an architect, right? Someone who's like an architect is going to be thinking a lot about strategy probably from the technical perspective though, right? And then you might have someone who is like a product manager who is thinking about strategy but from maybe the uh like the the user perspective maybe not from the user's perspective but related to the user. You might have an engineering manager who's trying to balance a bunch of things like technical direction, product direction, and even people, right? Strategizing around like how are we going to build the team? How are we going to make sure that we have individuals that are growing in their careers, that kind of stuff. So, engineering managers kind of get stuck in a mix of stuff. And that means the strategy portion can apply to that mix of things as well. Um being a tech uh being technical doesn't have a high bar. Uh it's defined by Mariam Webster's going right to the dictionary. Having special and uh usually practical knowledge which is not very specific definition technically. Yeah. Um interesting. Yeah. Learned as I've grown. You have to get comfortable in some degree of ambiguity. Agreed. Yep. And how some things get done especially if other teams have responsibilities you don't get visibility into. Yeah. Absolutely. Right. And I think just on that note too, I think that's such a good reminder because be because it's reality, right? There's going to be stuff that you can't have full visibility into, right? It's impossible for you to have full visibility into everything. And sometimes when things are going in directions where like it's not aligned with you and you're like, well, I don't see what's going on. It's almost like an easy default for a lot of us to be like like it's almost like it feels like it's malicious, right? Or it's like they're they're neglecting us or they don't care or like it's cuz this this team sucks or whatever. Um but like they have you know different teams are going to have their own different uh road mapaps their own different goals and like we have to ultimately in companies and organizations we have to think about as much as possible trying to align to the overall goal when you work more in isolation this is where you can get more and more friction but ultimately you know I think this is it is a great reminder you're going to have you know lack of visibility into everything and that's okay. But uh as much as possible trying not to default to like oh it's because this team is malicious or they suck or they're negligent. It's probably not the case. It's probably just that you don't see the priorities that have been put in front of them or why they're focusing on those certain things. So okay. So how do we stay technical? It's an interesting challenge. Um, my general opinion with trying to, you know, improve on things, right? If you're trying to build a skill of any sort, doesn't matter what it is, uh, I I always like giving examples of things that are like wildly outside of outside of software engineering just to make a point, but it's like, you know, for people that are new to software development and they're asking like, how do I how do I get better at programming? How do I get better at building software? Uh it there's lots of different tools like you can read books, you can read blog articles, you can watch YouTube videos, you can join live streams and come talk to me and other people. But the best way in my opinion is to is to build the stuff like to spend time doing it. And I think that that is the best way to get better at basically anything, right? So, it's like uh I let me pick something that I'm terrible at. I'm terrible at basketball. I'm terrible at probably most sports. Uh I'm terrible at basketball. So, if I wanted to get better at basketball, how would I do that? Right? Like I I I could go start watching YouTube videos on basketball, right? that might teach me like how some things work, like how the rules work or different techniques and strategies, maybe different training things. Um, I could, you know, I could go read articles, right? I could go see like I could go look up, I don't know, like celebrity basketball players and like learn about them. But like if I wanted to actually get better, I should probably play basketball, right? It's the same for any sport. If I wanted to get good at an instrument, I could do all those things, too. I could go reading, watching videos, but I should probably practice the instrument. And so, I would say if someone said, if I want to get better at being technical, say, you probably need to spend time doing it, right? So it might be, you know, I'm saying all this and it's like, okay, well, sure, like I get that if you're, you know, a junior software developer, you're trying to get into the industry, like, yeah, that makes sense. And then, well, once you're in, once you're already a software developer, like you're just getting that experience, that exposure anyway, right? That's your that's your job, right? So, yeah, you're going to stay technical because you're doing that stuff, right? Well, as soon as your expectations start to change, this is why I wanted to talk a little bit about like, you know, even doing design documents and and things like that, the more that your role starts to evolve to have things that aren't just more and more time writing code, the more that there's opportunities for you to focus on things that aren't purely technical. So, if you're not spending proportionally as much time in the day purely writing code, how do you stay as technical? Um, back to the chat. Um, I think is this still all Tim? I can't see because the names aren't refreshing and it's not on LinkedIn either. Let me just give her a Okay, it's Tim. Cool. Um, I don't know why it's still saying there's no name. Um, so for getting uh this is from Tim for me getting more strategic, trying to find ways to find more repeatability in what I build. Yep. Can find a way maybe make a script that helps me get quicker start on the next client project. Yeah, I think that's a great idea. Or maybe find something I can do, use which enables me to do a bit more work in a shorter time. I think that's a great idea. Um, you know, that's it's actually in my own development more recently. That's actually one of the things I've been focusing on. Um, literally that because I've been building stuff outside of work, you know, building stuff with AI, learning about AI tools, different harnesses, different ways to leverage skills and things like that. And then going, okay, like I'm repeating this like many times now. Like can I can I stop repeating myself and start reusing? Then uh Tim saying for la for for example last week wrote some scripts to pull data from HTML reports to try to combine and run data for me in Excel. Now I have that for the duration of the project. No more copy pasttor for reports. Awesome. That's great. Saying technical is not just about hard skills like coding dependency. Sometimes learning something about a subject that's unrelated. Yeah. Might reveal something that helps you with something that's very technical when refrain to our developer context. Absolutely. Um it's like so the the examples I was giving to start are purely around programming right but like it's not just going to be that and we'll see that as as the conversation goes on that like there are absolutely things that aren't just code that can help you stay more technical. And before I go to the next sort of uh question there in the chat um you know one one thing to consider here is like when we talk about software engineering I I've said you know one of the reasons I think software engineering is so cool is that it's applicable for any domain you can think of right like if you can think of anything you can think about software for that thing or that industry in some way. So, um you might say, "Okay, well, you know, I've been I've been spending time writing code like um I, you know, lots of things to learn there and you know, as time's going on, I'm I'm starting to like master my tech stack, the programming language and stuff. There's always room to improve, but like maybe the pace is kind of slowing down, but like what about the domain you're in, right? like are you also investing you know uh into learning more about the domain becoming an expert in the domain? Um, you may find that like going deep on some of the domain stuff could have interesting transferable skills to how you write code. Could be interesting transferable skills if you switch domains and you're like, oh, I went really deep on this and like hm there might be some interesting parallels in this other domain and I wouldn't have even thought about some of those things without having that exposure and going deep. Right? So if you take an engineering mindset in my opinion at least when you're doing these types of you know deep dives to learn about things doing analysis there's so much that you can sort of abstract out and then think about those things and try applying them into other areas. So I think it's a great point from Tim. Um, Harry KTS, uh, this I'm not sure exactly what the the specific question is, so I apologize. If you want to if you want to add a little bit more clarity when you see how I answer, please do and I'll try again. Says, what are your go-to articles exploration source? Um, I'm not I think this question is like if I wanted to go exploring like new topics and stuff like where do I go? Um, I don't do a ton of uh I don't jump to reading articles first. My usual exploration path is either I'm trying to solve a problem and I start looking it up and then and that that's usually like YouTube videos or or code repositories on GitHub. And I think the other sort of like this is kind of started to realize this more but it's it seems kind of weird. One way that I discover new things for myself is honestly just like if I go to the on my Android phone if I go to the news tab like what is it? You go to what do they call it? If I open my phone, it's like the Google news feed or whatever. I guess because it the more things I interact with, the more it's like, oh, this this person likes to program, I guess. Um, I periodically will just open that and scroll through. And sometimes I'll get literally I'll have Git repositories that are recommended to me. Um, there's sometimes like AI topics where I'm like, "Oh, I didn't know that, you know, someone is putting together uh, you know, tooling that looks like this." What did I just see? I saw someone was doing like a uh, what do they call it? Squads for for co-pilot CLI. And I was like, "Cool. I've seen other sort of multi- aent stuff for Claude and for C-pilot, but I hadn't seen that one. Maybe I'll go look at that." Right? So, a lot of my discovery like truly out of out of nowhere versus driven by a need for learning about something is my my Google news feed. I will give it a scroll through and sometimes, not every day, but sometimes there's something that stands out and I'm like, "Hey, I should probably go check that out at least to go learn about the topic." So, yeah. Uh Harry, sorry if that doesn't answer your question, but just uh let me know if there's something else I can clarify there. Uh Tim says, "Sometimes I think being technical is code for curiosity." Yeah. Uh not just in what things are, how they operate, how they might break, how they work, and might integrate in ways that expand value proposition for what we build. Um no, no. And Tim, like this is the whole point of the live stream is is this. So thank you. And the this word curiosity I think is such a good one because I've heard over the past few years um and it's not like so I've been at Microsoft for you know for the past few years but it's not just unique to Microsoft so I don't mean for it to sound like that but uh the past few years at Microsoft and yes before Microsoft been hearing more and more people that are say maybe more more senior or tenured in their role. Um, talking about people that are more junior than them. And I and I I don't mean to classify this as like all junior developers because I don't think it's like I don't think that's the case. I think it's just more senior people referring to more junior people than them. having some type of um realization where if they're if they're finding that some of these individuals are not I don't know like I want to say like not meeting their expectation like in in these types of interactions it seems to be really anchored around curiosity and I'm just saying this because uh because I I thought it was interesting word to use because um in these conversations someone might be like, okay, like I'm frustrated because person X seems to like have kind of just stopped at what what appears to this person is like doing the minimum and they're like, you know, they got stuck and then they were like, I don't know. I guess that's it or I guess I guess that's it's broken or I guess that's just how it works. But the the frustration comes from like why like why aren't they curious, right? Like isn't isn't that what we expect? Isn't Aren't we software engineers? Isn't the whole point to like really try and pick things apart, see how they work and understand them? And so I, you know, whether you agree with that or not, I just thought interesting to see, you know, being technical is code for curiosity, right? because I I'm sharing with you that from some interactions I've seen people get frustrated because basically what they're saying is like these individuals whoever they are some people don't seem technical enough because they're not expressing curiosity and it's almost like if you spent the time being more curious it doesn't automatically mean that like you become better right curiosity does not instantly equate to therefore or better. But being curious and spending time being curious probably does allow you to to move towards being more technical. Um software testers have this idea of focus defocus heristic if you zoom in too much. Yeah, I think that's an interesting perspective on it. Right. So zoom out, look at something else, come back. Yep, I think that's a really interesting framing. Um, yeah, Medium is for uh this I think going back to Harry's question, right? So, Medium's interesting. I think some people are completely bent out of shape for Medium. Uh, I say this as someone who I have a Medium subscription and I don't even read Medium. Uh, not because I'm against it. I got it because I have it for, you know, creator purposes. I also put stuff on Medium. I haven't in ages, but um I know that when I share a Medium link, people get completely bent out of shape. But Medium's pretty interesting because if there is a paywalled article, the way that it works is that it's like revenue sharing. So if you and unless they've changed something and I haven't paid attention to this but the idea being like if you're willing to basically pay a few dollars every month that if you go reading articles that are paywalled then you know depending on what you read and how much like that gets divvied up across the people that you're reading and I think that's a kind of a cool idea. Um, so you know, I've I've told people that, hey, if you see stuff on Medium that I posted, like it's also for free on my blog, right? I'm not trying to trick anyone. I'm not trying to I'm not trying to do that. But my philosophy is like if I can put it on Medium, there's some SEO reasons for doing that, but if I put it on Medium and someone's already paying for Medium, then I get some of the profit sharing. And for me, we're talking like like cents. Like I think I think I just got a medium payout that was $10 after however many months because it doesn't pay out unless it's over $10. So medium I think there's lots of people that post on medium. I have not um not used boot.dev. I have heard of it and yeah interesting also like you know using AI to go explore um I don't personally no I guess like I I use like I'll use chat GPT for um if I'm curious to go down a path but um so yeah when we say exploration I guess it depends like if I'm trying to solve a problem there are sometimes I'll go to chat GBT get an overview. I find it's still hit and miss where I get results and I'm like I you know I trust or I believe in that. Sometimes I like see it I see a couple of quick sources and I'm like I don't think that's actually I think you're like citing something and it's not even saying that there. So I have to go dig a little further. But yeah, AI can help with that. And I agree, Tim. So more if you have folks that are more junior um yeah you you might have this p uh this experience where people are have gone to to college university some type of schooling right and it's a lot more streamlined. So in in sort of air quotes like the real world uh there are ambiguous problems to solve and so yeah you kind of you need to lean into the curiosity more. Oh and this is this is an interesting one. I'm going to I'm going to read Tim your last message here. Um one thing I've seen sometimes it's not even technical curiosity. Maybe it's advice about professionalism and the junior doesn't seem to receive it or doesn't land or doesn't land and you wonder what you said wrong because you meant the advice to be helpful. When it gets ignored, you go off and you're doing something else and you might begin to wonder not just about maturity but culture fit for someone in your organization. This is interesting because when I've seen, you know, I can't I can't take your words and say, "Oh, like I know an exact situation like this. That's not fair for me to say. There's still more cat or dog hair on my face. That's what happens when you got five animals. Um I I've seen what I believe are situations like this. And I in some of my experiences where I've observed this, I think there's like I mean miscommunication uh in general, but um I've definitely seen some stuff like this where you know the the person who is communicating something intends to be helpful. Um, and for whatever reason, like the person receiving it, um, doesn't know it's coming from a good place or doesn't understand it. It could be so many different things. And unfortunately, what doesn't happen is like there isn't more time spent communicating around like, hey, remember that time we were talking about this thing and I wanted to make sure you were clear with it. or the other way where someone's like, "Hey, I know you mentioned this thing and I didn't totally get it or I thought that when you were conveying that to me like it was condescending or you know people people avoid this type of stuff." And so yeah, I it can be so many different things, but I think a lot of this stuff is improved when we spend more time trying to to clarify and communicate. So, um, yeah, Medium often locks high quality helpful articles. Yeah. I mean, the reality is like I'm I'm going to say this as a as a content creator, right? Like people spend time making content. So, some people want to be compensated in some way for it. Uh, I try to do as much free content as I possibly can, but you know, it's like I run ads on my YouTube channel. My one YouTube channel does not cover the cost of me, you know, commuting uh in the fast lane. Uh, you know, it's it's making content is uh takes time, right? But and yeah, the another thing on the on the content creation just because it's uh you know, in the chat, but low barrier to entry, some of it's rage baity, some of it's clickbaity. Um this is the nature of things on you know it's media you know every YouTube video unfortunately like people get and I'm not saying this is happening in the chat right now but people get bothered by this right where people will say oh clickbait title um clickbait thumbnail uh you you made a social media post and it's got like a rage bait hook like you're just engagement farming but the the challenge is that like This is actually human nature and it ends up getting rewarded in social media, right? So, just to give you an example, if you make YouTube videos and you don't have a thumbnail that stands out, and standing out can just mean like purely emotional reaction, right? It makes you pause for any reason. If it has a title that's going to make you go, hm, like I don't agree with that. Anything to get emotion, anything that's going to get you to pause and be curious. And I'm saying, and unfortunately, I'm not saying curious has to be a positive thing. You might say, "Oh man, like I hate what this guy is saying right now in the title, in the thumbnail, like I don't agree with this." Anything to get you to click is like if you don't do it, then people do not click. there is far too much content to be, you know, putting stuff online and just like hoping people will stumble across it. It just simply doesn't work. Uh, and I can say this as someone who makes tutorials that are software engineering and programming because those aren't sexy topics. It's really difficult for me to go make what I consider a helpful tutorial, post it, and be like three secrets doctors don't want you to understand when you're building a repository pattern in C. Um, and then having a thumbnail that's like clickbay, right? It's like it's educational on, you know, inherently boring topics, but they're supposed to be helpful. And so for me the way that translates is that I don't get a lot of clicks initially and then you know not exaggerating if I go to some videos um it's like six months into it I will actually start seeing traction like no exaggeration sometimes it's dead for 6 months and then it starts going um but it's kind of like I said it's what ends up getting rewarded. Okay, so back on track. Um, I would say one of the things I want to kind of get into next is like I think it's important to understand as your role evolves, what it means to be technical. And this is kind of going back to something we were talking a little bit about earlier. It's like I was giving examples of coding things, right? Then one of the examples I was giving was like, okay, you're going from coding maybe into more design documents. That's kind of pulling you into a little bit more strategy over time because you have to start thinking about these things, planning them out. That's right. C for the win. Um, and so as your role is changing, your responsibilities are changing, the expectations of you are changing, what it means to be technical will also evolve. Okay. So I I like using the engineering manager example in this kind of context because I think there are rightfully so like wildly different opinions about what it means to be an engineering manager and specifically around the technical portion. Okay. So there are some people and when I say these things I'm not saying any of them are right or wrong by the way but there are some people that will say hey engineering managers are I would expect them to be coding you know x% of time that that is an expectation of an engineering manager they must do it if they're not coding then I've heard people say if they're not coding like aren't they just babysitters right and the the framing and the language is strong like that because they're saying as an engineering manager I would expect that this person is extremely technical right they should be hands-on they're the ones who are supposed to be responsible for a team and an area the direction that things are going why wouldn't you expect this person to be one of the most technical people on the team and then you have uh let's if let's go the complete opposite end of the direction right or end of the spectrum which is like okay as an engineering manager you have built teams and sometimes you're managing multiple teams of extremely technical people, right? And you have a range of people from junior up to staff or principal and those people at the top end of the skill level are your technical experts. So, should you be coding? Well, if you're spending more time coding, then you're not spending as much time facilitating strategy for the team, planning, um, unblocking could be whatever. So if you're spending time coding then you're not actually spending the time doing the expectations of an engineering manager. You're not managing the people properly. You're not managing the strategy properly. You're not managing the road map or the the projects properly. All right? So again, neither of these are necessarily right or wrong. I'm just picking two completely opposite ends of a of a spectrum. And so okay, well what does technical mean in either of these cases? Well, in the in the first example, being technical would mean like literally being able to write code, understanding the code base, understanding how to navigate that, understanding the architecture, literally dedicating time daily to writing code, getting poll requests in, shipping code, right? Not only that, but uh helping others do that effectively too, but like literally hands-on in the code. In my second example I gave, you might argue a lot less of that, right? You might say like, okay, they're not coding every day. So, I don't expect that they're uh delivering code, they're not shipping code, they're not uh maybe they're not even reviewing code. And then you might start to go, well, then what technical thing do they do? Okay, well maybe that looks like architecture. Maybe that looks like, you know, uh system design, right? like how how technical you are might not be a matter of like can you code or not but it might be sort of an expectation of what you need to be doing in your role. Okay. So I think I'm saying all this not because I'm saying there is a right or wrong answer. I'm saying this because I think it's important that that you understand this for yourself because it's not for me to say, right? I've I've worked in those two examples I gave you. I've done both. Uh I did eight years where I was an engineering manager and writing code in the codebase daily, right? I at the end of that I was managing two small sub teams and still writing code every day. It was a lot maybe not every day the way that I would have when I was managing two teams doing that because started to not be scalable and in my current role I don't write code at work. I I don't I don't put up pull requests and contribute to the codebase but I also manage three teams in a routing plane but three separate areas completely. So what it means for me to be technical in the same engineering manager role but different environments looks very different in like and to continue on you know these examples in both cases we have uh we have C as some of our tech stack right I program in C all of the time at home I programmed in C# for years so in the first case I was writing in C at work and I was writing in C at home. Great. I could be super technical on C topics. Now I'm not contributing to the codebase at work, but I can absolutely help on C code reviews, right? I can there is going to be parts of the codebase that I don't know because I'm not contributing to it regularly or at all. But if people put me on to code reviews, I can at least talk to them about what I'm seeing. I minimally I can offer feedback on like the C code I'm seeing but at least I can understand what code is being written and then talk to developers about what I'm reviewing. So yes, I can still contribute to code reviews, right? So like there are some things that are going to they're going to move back and forth. They might be relevant in both cases and in some cases they might not be. Right? If someone came to me in my current role and they said there is a bug in this uh in this service, you need to go fix it. Could I go do it? The answer I would feel confident to say yes, I could go do it. Could I do it effectively? Probably not. Are there, you know, junior people on the team that could get that done quicker than I could? Perhaps, right? But it it's not because I'm stupid or I'm not technical. It's because I'm not actively working in there. And I don't because it's not an expectation of me currently. My time is spent doing other things. On the technical side of things, I do spend time on design documents, on architecture reviews, on strategy in terms of where product and service is going. So the technical part looks different for me now. And if you're like, "Hey, Nick, that's all lovely from an engineering manager perspective. Like what about me as a developer?" It's the same kind of idea. It's just that the responsibilities may look different, right? Like you may not be responsible for people on the team. That's not part of your role. You might not be responsible for a product roadmap because that's not part of your role. But the more senior you become and the more that your role expectations are changing, the more that you're likely interfacing with more parts of the strategy, right? There are very technical principal engineers that I work with and like if I am working with a product manager or other teams and we're starting to talk about what things need to be built and priority ordering it's like it's extremely important for me as an engineering manager to try bringing one of those principal or one or more of those principal engineers in to have conversations about that to involve them in the strategy. And it's not limited to just principal engineers. This would be senior or mid-level or junior, right? Like you need to bring in technical people to those conversations and involve them in the strategy. It's just that more often the more senior someone is, the more exposure they get to it. So hopefully that makes sense so far. Um, I I wrote in this article and like when I talked about it on code commute, I was saying like at least for me, one of the things that I I try to make sure is that I don't want to be like a gatekeeper on everything. I don't think that makes sense. I don't think it's scalable. But I I think that it's helpful to be like automatically in the path where you're exposed to it. Might sound kind of weird, but what does that mean? So if people are doing design reviews, right, I personally don't need to be a gatekeeper on every design review, certainly not for my greater team. And I would also say for, you know, the people that report to me, I don't need to be the person to give it the seal of approval every time. Now, does it make sense if by default design documents from people on my team also come through me? Yes. you know, if we set things up so that that happens, yes, I think that makes a ton of sense because at least by default I'm exposed to these things. I would also say as an engineering manager in my broader team, is it helpful if by default I am more exposed to being on this path where people are like I have a design document and like it needs review? Yes, that would be great if I'm automatically on there. Does that mean I have to sign off on every single one of them and like be you know people can only go forward if I've approved it? No. To me that doesn't make sense because it doesn't scale right. So putting yourself in a situation where you're automatically on the path for exposure to the more technical things I think is great and then from there you have to figure out like what what level of involvement you need. So I wrote that for and talked about it for code reviews uh and design documents. So you know if people have me on poll requests by default they can like great if I have time I can go give feedback if they're really like seeking my input specifically. Most people on my team they will tell me like hey I have this code review like I really want your perspective on this or they might say like someone's not available. could you kind of step into to do that? And that's all great, but otherwise like I I treat it as like this is exposure for me at least. And if I can, I will keep on top of being able to to read through things, but I don't see myself as being the person that has to gatekeep. Now, I don't think this is unique to just an engineering manager role and myself. I would say the same thing for, you know, technical people on the team. Do I think that it's even more helpful specifically for them? Yeah. Like if you are a tech lead, right, I as an engineering manager am kind of leaning on you as a tech lead to be able to sort of facilitate that role of like yes, I can try to look at everything. I can try to sign off on everything. I also understand that if you're a single point of failure, that doesn't make a lot of sense if no one can uh you know move code around unless you sign off on it. Like I think that's a bit extreme. But I do think it's a really good idea to position someone so that they are mostly, you know, on that path. So you can you can do things in your team setup that kind of make that more automatic for being exposed to technical things, right? We do this even uh I was talking about design reviews, but we also have this like at least the team that I'm on now and I've seen different flavors of this over time. Like cool, you talk about technical things, you know, with your immediate smaller team, you share design reviews and stuff like that, but but even going a little bit more broad, right? So within a greater team being like, hey, we have this design and like we will put it in front of people so you can see it. You can see the technical parts that are coming together. And again, just giving more people exposure to to these things. But I do think it's important for you to understand like the level of technical depth that you should be getting exposed to in your role, right? It's like I if you use the IC um framing again, right? Someone who's in an architect role as an individual contributor, do they need to go sign off on every single poll request? I would say no. Is it helpful if they see as much code as they can coming through? I would say yes. They can see the patterns that people are using. They can say, "Oh, like you know, everyone keeps going down this path and like there's some anti patterns here. How can we start restructuring the code to make sure that we're doing, you know, uh better things here over time?" Kind of a paved path for people to do the right thing. So, I think it's all beneficial, but you don't have to be a gatekeeper. I already talked about this one for pulling in experts early. Again, as an engineering manager, when I think about um myself in technical situations, right? So, there are some conversations where they might be technical and I feel very confident talking through them because my level of understanding for what the stakeholder I'm talking to is looking for. I feel comfortable doing that. can dive into it. No issue. Now, quite regularly, there's going to be things where I'm like, "Hey, like you're we're either having a conversation that is starting to talk about implementation of things, right? And I might have some insights because I've been talking with people on my team about it. Maybe it's a a conversation we've had, you know, historically. Um and maybe I can still talk about some of those things but it's a very regular thing in my experience where especially in software engineering start talking about like strategy for things ultimately shift a little bit towards like how how could we build this right like what are we building how would we build it and when things start to go down that path a little bit too much even for myself if I'm in a situation where I'm like I think that I know how I would want to build I need to make sure as early as possible that I can try bringing in an engineer. Not because I'm like I need to I need to not do anything. Let me just delegate this away and forget about it and go on to the next thing. Um not at all. It's actually because I want to make sure that whoever is going to someone who is potentially doing this work or has vested interest in doing this work because they've worked on similar things as an example they should be brought into the conversation early does it mean that I can't talk about the topic without them? No. Is it, in my opinion, is it a wise idea to bring in a subject matter expert early if we're starting to talk about what we're building and how we're building it? Absolutely. I don't want to end up wasting time in something that we're discussing building without having a technical expert there. So, one of the things that I've, you know, thought for myself is like use it as an opport like in those conversations, use some awareness to figure out when to bring someone in because I've sat in too many calls where we basically like end up designing it in the conversation and we're like like what now? We're going to go tell an engineer just just go build it this way. Not a good idea. they are the subject matter experts. Um, you know, we can help influence if we have, you know, other ideas and stuff, but really leaning into uh the experts, I think, is a good move. So, I've just seen too many times where that doesn't happen. So the other side of it and this is another awareness thing. If you find yourself in conversations right where say it's like a more of a strategic conversation and then you start to have questions that are coming up uh either from your own exploration or from other people you're talking to. If they're asking you technical questions and it feels like basically for everything you're like, I don't know. I have to go ask someone, right? Like, oh, I don't I don't know. I have to go ask the the theme, the subject matter expert. If you feel like that for everything in every conversation you're going into, I would say there's probably some some work, right? It's a bit of a litmus test. there's probably some more work you need to do to to get some confidence in some of the technical areas. Now, that doesn't mean that like I've had I've been in conversations where someone's ask they're coming to me as someone managing a team and they're like, I need to know more about this and I'm like, I know what you're talking about, but already the level of detail you're asking for like I don't know the answer and I have a subject matter expert that can get that to you like right away. I'll defer, but that doesn't mean that I go cool. I never have to I never have to think about that again. The goal is not, you know, out of sight, out of mind, like let's pretend that never happened. It's more like, let me get you unblocked. Let me get you the information you need and either you can leave that with me. I'll go follow up and bring it back or let me direct you to that person because it's more effective if they explain it. Now, even in those situations, I'll try to make sure that I'm learning something from it because again, if you keep finding yourself in situations where like, I just don't know that. Back to what Tim was saying earlier in the chat. Curiosity, right? If I don't know something, kind of curious, right? I should be curious. I want to understand it because I want to be able to be more technical, more capable in future conversations related to it. And this happens a lot. Um I'm trying to think like without giving specific examples I so I work on a routing plane team for for Office 365 and I think it's important to kind of to kind of share some I don't know like examples of this because it's a little bit vulnerable and I feel like it's it's good to hear personally. There are things related to whether it's networking or operating system level things where I genuinely don't know right my my life as a software developer has only been sort of routing plane related things for the past couple of years before that I did deployment for a few years right but even those two things that's only five and a half years together. I didn't do any of those things prior to that. Now, do I understand some networking concepts? Of course. Do I understand some deployment and change management concepts before these roles? Of course. But the level of detail that I would expect to be have like in the role very different point is there's always stuff that I don't know. There's always going to be stuff that you don't know. That's okay, right? But it does come up where I'll have someone who has a question about something related to uh like how websockets work or how this how like some request is going to be handled at the operating system and network layer. And I'm like I actually just don't know. Now again I'm like I work in this space. So if I don't know, if someone's asking me about this because they need help or they need to make progress, they need to understand something. Yeah, let me go help you get the answer to that. Whether that's a person or finding the answer some other way with you, but it's in my best interest to go, pardon my language, like, oh I don't know that. I should also I should also know that, right? So, I think if you use those opportunities to be like, "Hey, that's not something I know. Let me get you the answer. Work with you to get the answer." And like remain curious instead of, "Cool. Let's get that out of the way." Um, stay curious. You'll also learn. It'll be helpful for next time. I think this is still Tim because the name's not coming up but sometimes an area of knowledge you might know a lot about something but a particular sub area with within it you might not even have a shallow uh not even feel shallow deep in it opportunity to bring in someone else to learn is huge. Yeah. Um, for sure there's we're doing some of this stuff uh with some of the performance work we're doing. Um, it's, you know, Created, right? And I'm like, I've been programming in C as long as I can remember. And there's some stuff that we're doing where I'm like, I like I I know of these things, but I don't have hands-on experience doing it. And what's you know kind of to connect some of the dots here how technical do I have to be there right is it my responsibility to go solve those problems no like I have an extremely capable set of engineers that are working on that and the role that I play in some of those conversations especially is like is having the conversation with them about the results and when they're you know they're doing the analysis on which direction to go and things we can try being able to contribute to those conversations not in a way that's like oh did you change this line of code but to be like hey wait like you know I see when you're talking about this I see maybe a different pattern or you're describing something that looks like a bottleneck this way or you know uh you've talked to me about these three things but we've never looked at this other thing like do we have a a pattern for that or we haven't gone back and revisited this other thing from before. Maybe it's a good opportunity now. Like there's so many different ways to participate in that with you still need some technical understanding but not the same level of like cool I'm going to go back to my computer and go program it. And this is someone who is a car developer for many years. Like I would still not be effective at doing that. And that's that's okay. At least in my opinion, that's okay because I have other experts to do it. I'm still trying to learn and understand. I'm not neglecting it. But my role and responsibilities, I need to be spending time doing other things as well. Cool. Um I think one other at least one other thing I just wanted to kind of mention briefly is like a lot of the stuff that I've been talking about in this conversation is like very much things that are happening at work right and you might say cool like whether or not you agree with all these things or not but cool okay sure but you know in my experience I still feel like I'm not getting some of the technical exposure to things that I want to be getting Right? Maybe that's because maybe you feel like you've maxed out in the area that you're at at work or whatever the reason is. I would just say like side projects are still an opportunity where if you're like, I want to go learn about something, back to something I said at the beginning here, if you want to learn something, spending time doing it will be extremely helpful. Okay? Okay. So if you're if you're like hey um I work in this space and like I feel like you know as a software developer and you could apply this to anything but feel like as a software developer I don't know anything about mobile development and like for me in my career I'm thinking you know that's kind of that feels like a risk for me or like I want to move into mobile development or be closer to whatever it is. Um, maybe it's not mobile, maybe it's like doing stuff with LLMs, right? I think this is a lot more common now where people are like, there's a lot of people doing this, I should be doing it, too. It's very, it's a very fair like framing. So, if you're realizing like I don't have technical expertise or maybe expertise is already too strong of a word. I don't have technical knowledge of any sort or it's very minimal in some of these areas. We don't do that at work or we do but not on our team. Like I it's it's very unnatural for me to get that experience at work. Side projects. I would say like try to spend time building these things. They don't have to be perfect. They don't have to be something you're going to sell. Just spend time building things. Like get your hands on it. Get exposed to it. I think it's very much something I recommend. Uh the example I put on, you know, in this article was I was trying something out and I needed a website and like I used um you know I used Astro to go do it and I'm like I've never used Astro before but I went to go read about it and I was like hey Astro seems like a like a technology fit here. I should go use Astro and I did. And like am I an expert on Astro? Absolutely not. But do I know more about Astro than I did before that? Yeah. And as a result, I had a follow-up situation where I needed something else and I was like, I think Astro is actually a good fit here. Instead of me going and doing what I always do, which is like, I know C and I can do it in C pretty quick. I know it's not the best tool, but it's a good tool for me. So getting exposed to things on the side I think is great. Um, yeah. I think one of the other things that I have on here to kind of wrap up some thoughts uh and I kind of touched on it, but like the at least my opinion is the answer to all of this is not to overindex the other way and to say like well if for me to stay technical means I have to always have my hands in everything. Um I don't think it scales. Uh especially like as an engineering manager, I think it's not a good move. Um it is it is the reason that my career has evolved. I think it's a natural progression. If you are responsible for more areas of things, the scope which you're responsible for increases, it's it's impractical to try and be as technically involved as that happens. It's just it doesn't scale. I felt this even I mentioned already like when I had two teams at a startup, right? I was still coding every day until it got to a point where I'm like I'm not I'm not able to do this. I was having you know more strategic involvement even across other teams doesn't really scale for me. So the you know one answer is like okay I could work more hours and code more but that's not like that's not a scaling solution that's a you know do do more things solution that doesn't scale right if I if I'm saying I need more output I need more efficiency in the team this the way that you solve that long term is not you add more hours to your day it's you have to go figure out how to optimize or how to grow a team, how to scale the team. So, you need to spend time doing that. Um, Tim says, "I once saw some guys getting to work on some new tech for another project when when Tim was a junior and there was a license required to learn the thing. So, I asked my manager how it came to be." Decision that these two people got to do this. My surprising answer was the boss didn't know I might be interested in that. Yeah. Or other areas. uh to potentially grow and thank me for letting him know. So, he's actively looking for something that once resulted in a whole shift in my career. Awesome. And wouldn't have thought of it because I had not expressed openness to learn new things or be in an area I was less comfortable in. Absolutely. I think that is such an awesome, you know, awesome example. So, thank you for sharing that. Uh there's a and there's a couple couple things about that that I think are awesome. Um so one is that this idea of like you know I can say this as an engineering manager I would love to to tell you know my whole team anyone I ever work with all of you watching I would love to sit here and say look I'm so good at being an engineering manager that I always know the direction that people want to grow in their career and where their interests are. I would love to sit here and tell you that. I don't I can't. Um, you know, do do I strive to be able to do a better job of that? Of course. Right. I feel like that is part of my responsibility is to help do that. But I'm not perfect and I don't read minds. So, I I do try to remind people, encourage them, hey, like if you have an interest, right? if there's something that you're like this would be engaging for me. Uh and this can look different. Some people might say like I know this is a weakness of mine and I really want to get some exposure. Right? So the idea of like can I communicate this to my manager because maybe there's some opportunity. Please please do. Uh I would tell that to anyone that works on my teams today and in the future because I think it's important. I am still working on mind readading but it's not there quite yet. So I love that example. I think that's really good. And then um this other part too in Tim's message, right? So um resulted in a whole shift in my career that I would not have thought of because I'd not expressed openness to learn new things or be in an area I was less comfortable in. This last part on being less comfortable. I cannot recommend this enough and it's a very difficult thing because as humans we're we're going to, you know, gravitate towards things that feel more comfortable over time, right? You start something new, it's uncomfortable, you get better at it, you get more experience, becomes more comfortable. It's easy to stay there. Um, I I say this as a person who like when I think about doing different things, switching in like what my my focus area is, it's really scary. It's scary because it's uncomfortable. It's unknown. Like we we get used to being comfortable. More recently, I've talked with some people that that have been doing bigger changes, right? I've had a couple of people that are on my teams that have switched to go do other stuff and like when we've talked about that it's it's it's always interesting conversations right because I think about these things kind of on multiple levels where it's like one is like sure as an engineering manager if I have someone leaving the team there's some logistics to that there's you know how do what what's going to happen when this person leaves but the other part of it is Like really like I was saying my responsibility one of the expectations that I I believe in for all engineering managers is like you are trying to help grow people in their careers and so if someone is like I want to go do something different something uncomfortable I think that is one of the best ways to go grow one of the best ways to do it because everything that you do is going to feel new. Everything is going to be a learning experience and it's going to be wildly uncomfortable and that's okay. It's okay because you're probably kickass. You are a smart person. You're a successful person and while it's going to be challenging, you'll you'll make progress in, you know, you'll get to the other side of that and you'll reach the point where you're like, "Hey, I'm comfortable doing this." you're going to adapt and it's going to be awesome. I think it's one of the best ways to grow. So, I've talked to some people that have left my team to go do different stuff and it's bittersweet, but it's so exciting because I'm like, I know I know that they're going to have a crazy growth opportunity from it. um you know whe whether whether or not that directly translates to like specific career growth versus just like truly like exposure, engineering abilities, knowledge without a doubt. Uh they'll get all those things. Um I talked to someone recently who's going from an engineering manager all back to an individual contributor. Right? For me that thought is terrifying. That's so scary. And it's not scary because like I'm like, "Oh, I can't code." I code every day. Code every day outside of work. But it's scary for me because like I'm I've been an engineering manager for 13 years. So like what what what does that mean? It's different. It's very different. But I can guarantee that you will have, you know, amazing growth from that. So uh I think that's a really cool share. So, thanks Tim. I appreciate that. And I think I'm going to wrap it up here because I'm a little past 8. Um, I'm going to go share my screen here. So, for folks that are curious, um, this is sort of where I was getting information from. This is my newsletter. This is going to be pasted into the chat if I can. Where's the link? Copy it. There we go. Um, so just a reminder, it's at weekly.devleer.ca. Um, no, you don't need a subscription. You don't need to get you don't have to pay for it. You don't need to sign up for email. If you just want to see what the live streams are going to be about every every Monday, these newsletter articles go out on the weekend. So, you can always check it out just by visiting weekly.devleader.ca. Try to do these every Monday. Um, there's some exceptions if I'm crazy busy with work, uh, like happened a couple weeks ago. Uh, or if I'm on vacation, uh, but I do even do it on my birthday, which is today. Uh, I am, you know, I will try to be here when I can because I really like doing these uh, and I enjoy the conversation. So, you can check out Dev Leader Weekly. I have a couple of YouTube channels as well for folks that are interested. So, um, let me pull these over. One sec. What's a good way to do this? What is a good way to do this? Um, let's do this. One sec. One sec. I have some extensions that are putting too many things on my my browser. Okay, let me get this pulled up here. And thank you for the birthday wishes. I wanted to sneak that one in there. But yeah, I have a couple of YouTube channels. I'll I'll kind of share two here. One is Dev Leader. This is my main YouTube channel where I have uh programming tutorials primarily in C because that's what I like to code in and then uh focus a lot more on getting some AI tutorials and stuff in place. And my goal with these is really just to, you know, to to show you how I do things. I I never mean to come across as like this is the only way to do it. Um, but the AI ones are primarily like here's things I'm trying, here's things I'm learning, and um, and the the C ones are like, you know, here's here's ways that I do stuff, and hopefully it's helpful. So, that's Dev Leader. This is my main channel. You can see the clickbait. We were talking about clickbait uh, titles and thumbnails. Like, just to prove it to you, like look at this one that has my dumb face, right? and it's got more views than any of my other like you got to have these dumb YouTube faces. It's the only way people click stuff unfortunately. Um anyway, that's Dev Leader. My other one of my other channels is called Code Commute. So, this is the one I was talking about where um my newsletter and live streams are generally based on on these topics. So, Code Commute is primarily like a Q&A vlog channel. So, if you have any questions, like say as we were kind of going through this live stream, if you're like, "Oh man, I like wanted to ask something in the chat but didn't because I'm whether that's totally fine. You can go to codecommute.com. You can submit questions there." I will make a vlog entry for you. Um, it gets shared for everyone, so I generalize it. So if you leave comments, it's public. So there's that. But if it's a general question, you're not shy, go ahead. Otherwise, if you go to code.com and you submit it anonymously, then I will it's I literally can't see who you are. And uh even if you said in the email that it sends uh I would I would keep you anonymous because my goal is to to take the topics, navigate them with my perspective and then hopefully it's helpful for you and and anyone else. So that's that. Then a quick note, I got some other things going on. I got brand ghost. So, Brand Ghost is the uh social media content posting, crossosting, and scheduling platform that I have. This is how I post all of my content. We are getting some more things in place to help businesses as well, more specifically. So, we're getting that up and running. But, if you engage with my content on any social media platform, it is posted through Brand Ghost. And so this allows me to essentially still code things. It lets me focus on uh not having to literally manually copy and paste content every day. If I have a period of time like I did a couple of weeks ago where I was on call and you know kind of like unable to do anything except work for that period. I didn't have to say oh I guess I can't do any content posting. So, Brand Ghost already has the content that I've created and it would repost it for me. So, um if you are interested in posting stuff, you can check out Brand Ghost. If you have a business and you're looking to get some SEO help, then you can check out our launchpad for businesses. Um happy to try and have a conversation to onboard you to that. Um so, you can check that out. And then otherwise I do have courses on dom train. So uh if we go to dom train. So that's me. That's my face. I got some courses either on C if you're interested in that or I've partnered with Ryan Murphy who's an engineering manager at Yelp. And we have some other courses that aren't C. Crazy, I know, not C, but um so we have career management, promotions, behavioral interviews, and soft skills as well. So you can check those out on dom train if you are interested. But that is the stream and Quinn again thanks for the happy birthday and a little bit late but yes it's all recorded. It's a good reminder too for folks if you missed the stream. All good. It's always recorded. It's always on on YouTube. That's on a different YouTube channel called the Dev Leader Podcast. Um but yeah you can check it out on YouTube. it's recorded. If um if you prefer a different format than whatever you're tuned into, I stream it to Instagram, which is usually a bit trickier. Uh it's a vertical only video. So, Instagram, Kick, Twitch, X, Facebook, LinkedIn, YouTube, it goes everywhere. Um it would go to Substack again, too, but they uh they screwed that up. they broke their live streaming. So, if it's uh if you're watching on a platform that didn't seem so great, I would recommend YouTube. It's probably the better one. Uh LinkedIn for the most part seems to work. It's just like the the chat is comments. It's kind of kind of wonky, but I appreciate you all being here and I hope to see you next Monday. Take care and have an awesome week.