Managing Stress When Leading Projects - Principal Engineering Manager AMA

All right, I think we're just getting started. Let me flip back over here. Let's see. Instagram live Substack do the thing. Let's go. Cool. I think I think the streams are streaming. Welcome. If you're new to the live stream, uh these are AMA style streams, so you can jump in, ask questions about anything you want. Uh I have a topic for today, but of course, uh this is like I I wanted to be geared towards any questions you have. So, please, you know, derail the conversation. Whatever you want to chat about, we'll chat about. But I usually use the live streams to go over my last week's newsletter. And so this time was about managing stress when you're leading projects. And this is a topic that came from code commute, which is the vlog channel I have where I do Q&A style um uh videos, I guess. And if I don't have questions and stuff to go through, I go to Reddit and basically pick a topic from experienced devs to chat through it. So let me refresh this. My chat is currently broken, of course. So, uh, for folks if you're I see folks on Substack joining, welcome. You know where the newsletter is because you're on Substack. Uh, for other folks, there is this link I'm just putting into the chat. That's where the latest newsletter is. And I'll remind folks that if you want to know the topic in advance for the live streams, just head on over to weekly.devleer.ca. You can treat it just like a blog post, blog entry. Um, you don't have to subscribe or anything like that. So, it's totally free to check out the latest newsletter issues. So, if you enjoy the live streams, please go do that and then you can see what's coming up for next week when I release it. So, this topic, managing stress leading projects, uh this came from code commute, but I think this was from Reddit and I don't think it was a submitted question to me. So, I wanted to talk through this one because uh I think it's it's a pretty common thing for software engineers to go through. And if you're junior, right, like it might not be something that you've had the opportunity to do yet, but the reality is like is you're going to get more and more experience. There's too many fluffs on this thing. uh as you're going to get more and more experience, the likelihood of you being in a situation where you're leading a project and going, "Oh crap, this is pretty scary. I'm pretty stressed out." It's going to be high likelihood and that's normal. It's okay. And there's still projects I've been, you know, managing engineering teams for 13 years now. There's still projects that I'm responsible for that when I start, I go, "Oh crap." Like, "I'm screwed. How am I going to do this? Where do I start?" So, it's totally normal. And I I think like sort of the meta point for this whole conversation is that like it's like many things in software engineering in our careers in general, right? There's there's going to be stuff that we have to get comfortable being uncomfortable. And instead of running away from this kind of stuff, just kind of embracing it and being like you get through this kind of stuff like the imposttor syndrome kicks in. you you can remind yourself of all the successes you've had and kind of just keep trying to make progress and then out of nowhere it'll start to feel like it's all clicking. So that's the meta point. If you want to end the live stream right there, there it is. But we'll talk through that a little bit. And uh anything else? Oh, the next thing is I got to block whoever this is in my chat. Get out of here. Too many too many spammy messages coming in from kick unfortunately, but still want to be able to stream there. Okay, so in general when we're leading projects, this is the kind of thing that when you're more junior, it's it's pretty common that and it's not because you're not capable or something like that, but generally as a more junior developer, what will happen is that you are given tasks that are less complex and less ambiguous. And that's on purpose because the people that you're working with, they want to set you up for success. They want you to build momentum. They want to give you things that you can learn, get better at, improve, build some independence, build confidence. And if someone were to toss you into the deep end and you have no experience, like it's going to feel overwhelming right away and maybe so much so that you're like, "This isn't for me." Hey, a random programmer. Good to see you. Thanks for joining. Um so in general as a more junior developer this is the kind of structured work you get and then as you get more and more experience what happens is that this type of work starts to reduce and you start getting more ambiguous work. Okay so sure you've done an awesome job building out these smaller features or fixing these bugs like these are mostly well understood. Here's a new challenge for you. We have this problem that needs to be solved. Here's what's going on. We actually need you to go figure out how to solve this though. So, we're not going to tell you how it's done. We want you to go figure it out and then make a proposal for it. And then you're going to have to go, okay, like so that your first type of project like this, you're going to be like, okay, like someone's not telling me what to do. I have to go figure this out. You might even go like, I don't even know what the constraints of this are. I don't even know what the full scenario or scenarios are that I'm looking at. But that's okay, right? someone's giving you a bit of a stepping stone that should get you a little bit uncomfortable, but not so much so that you're like, I guess this isn't the career for me. So, this is how things start, but they continue to progress and you start having more and more ambiguity. So, as you become more and more senior and you're responsible for leading more and more projects, the amount of ambiguity and the amount of complexity that shows up in the problems you're trying to solve becomes greater. So, um, and I just want to double check because I have a couple of like stories I want to go through. And yeah, I'll start with one of them, I guess. So, like, um, sorry, I'm just scrolling through my newsletter. the one I wanted to talk about and because I I I like giving stories and actual references to things so people know it's not just like like bull crap like this I'm talking about things that are real that I really believe in and this is my genuine perspective on this stuff but um when I joined Microsoft I joined to the uh Office 365 deployment team and up until that point in my career I had only worked on building desktop software I worked at a digital forensic software company for eight years. I built plenty of digital forensic software, but I have never had never built distributed systems in my life. I never worked in with systems or compute or storage that spanned hundreds of thousands of machines. I've never had responsibilities like that ever. And so, this will come up a little bit later if I remind myself to mention it again, but like I got hired on. It's not like I was lying to anyone. And I was very transparent. I don't have that set of experience but here's the experiences I have. Was you know interviewed was hired. Cool. So first project I get from my manager who's very supportive. I joined at a time where they were doing planning. Okay. So uh me being brand new to the team I'm not going to come into the team and be like okay I've never done any of this but I'm going to set the plan for the next few months. Like no. So my manager being very smart was like, "I'm going to I'm going to work on the plan and I'm going to loop you into it so you can understand what's up and coming, but like I'm not going to make you go figure that out and do it cuz you're joining like in the middle of it." So one of the big projects that he set in front of me for me to work with the team was being able to reduce deployment downtime. And for a little bit of context there, uh, when we're deploying machines, it's deploying and it's not actually being put to work, right? Like we need to deploy to update things, but we're not we're not paying money for capacity just so it can sit there deploying. It's not really being used for what it's purchased for if that's what it's doing. So my task was to reduce the deployment downtime. I had a target number we needed to hit. It's something that my manager set and like, okay, so if we want to talk about ambiguous and complicated, I've just joined a team. I've never done any of this before. I have a goal to make a number go down. Where do where do I start? Right? So, this is a kind of situation that becomes very very common in a lot of the stuff that we're doing as we become more senior. It's not well understood. It's not super straightforward and simple. There's a lot of questions, right? So, in this particular project, I know that I have a goal. Um, oh my god, block. Why am I even streaming to kick? This is the most useless platform. Um, so sorry if you're from kick. It's just that this platform is terrible. But um when I have to go start a project like that, I need to understand where we're starting, right? I don't I don't know anything that's going on in the beginning. And everything I have is a question. So I know that we have a target we have to work towards. Okay, where are we at right now? Well, I was told two numbers. I was told where we're at and where we're going, but okay, like what does that trend look like? Are we are we hanging out at that number? or is this something that like like where can I go to see how this is progressing over time and then I learn oh well we actually don't have that this is something that was measured you know it's like something that someone remembered this is the number we have but we're not trending what that downtime is okay well if I'm going to be responsible with my team for making sure that number starts to go down I need to see a trend of this I need to make sure we have information for it so that's going to be step one near the beginning is figuring that kind of stuff about the other things I have to figure out at the beginning are like, well, it's deployment, right? I'm I'm brand new here. How do we deploy machines? Oh, wait. There's more than one way we do that. Okay. Well, what are those ways? Well, wait a second. Those are very different technologies. You're telling me I have to get one number down to this other number. Is that actually the same for all of these deployment technologies? Wait, no, it's not. Okay, this one's way slower. This one's way faster. They're used in different scenarios. So you start exploring the problem space just to start understanding things. Okay? And like that's going to be one of the key things when you're trying to work on projects like this is that you're going to have tons of questions. It's going to seem like you have no idea what's going on. But that's okay. You have to start incrementally making progress on building up your understanding of the scenario. So for me with this project, I'm going to wrap this up in just a second. There was like understanding of kind of like what the current state of the world is like. That included like for me understanding the technology that meant clarifying what our targets were. So I was told the goal I had to clarify what that was. I needed to make sure that I had a way to measure that and then once we had some of those things in place I started working with the team so that we could go look at like okay like where do we start actually trying to make the improvements? Okay, well, we have a couple of spots we can look at and we can try. So, if we do those, how do we measure that we made an improvement? And how do we measure where to keep going? And we started to realize that yes, our trending metrics were helpful, but we needed more granularity. Okay, so like now we have more things to like we have a direction to move in. We have numbers, but it's not going to tell us overall like where the next opportunity is. It kind of tells us just the trend. So we kept iterating on this and sort of kept exploring the problem space and made enough progress that we could chip away at this whole initiative and it came out very successfully. But the point is this is one that along the way there's no way anyone could have sat there and listed off like do this work item then this one then this one and this one and we've hit the goal. The entire thing was just like we have to move in a direction and we have to keep exploring it. So it becomes more common that you don't have clear like clear structure for how you have to go approach that stuff. Um what's the next thing I think when you're getting stressed about like starting a project and being responsible for it. A lot of what I wrote down in this article to talk through was really about like kind of like introspection and self-reflection because like when you're working on something that's ambiguous and you feel like you're getting stressed out by it like where where does that come from? I think it's maybe maybe I hang out with my wife too much who's a therapist, but like she reminds me because as a you know stereotypical software engineer in terms of emotions and stuff like you know I feel like emotions are bad I'm robotic like let me just be with the code but like she's very good at reminding me that when we have emotions and we have like an emotional response to something doesn't matter what it is you know frustration anger sadness fear you having a stress response to something. It's really important to listen to this kind of stuff and it doesn't mean to let it like overwhelm you or take you like take over, but it's important because it's a signal. So, you're you have some project that you're responsible for. Like why is it that you're stressed? Like where what's where's this coming from? And I think a lot of the time like I feel like is that it's kind of two things. One is that you might be kind of making yourself feel through imposttor syndrome like I'm not capable of this. I'm not capable of this. You're like doubting yourself. But that's going to be something that always comes up periodically. And I think the other sort of main component to this is that you actually just don't have clarity. And that's okay. Like that's it's literally going to keep coming up as well for every project you're working on. So trying to listen and understand for yourself. This might be different for anyone you know listening or watching this but understanding why you feel that stress like where is that coming from. So, if you can, and I recommend this not even just for this talk, but like when when you're having some type of stress response or emotional response to things at work, even outside of work, like try to provide yourself a moment to think about like not just like turn off the emotion or let it, you know, uh take over, but like where is that coming from? Right? And I do this when I get uh trying to do a better job of this when I get frustrated about something like why why is it that I'm frustrated with this? And a lot of the time I'll do this reflection and I'm like okay I had an expectation of something that's not being met. It's like okay so like if you you kind of start separating like your like understanding the emotion from feeling the emotion. You can start to see where it's coming from and then maybe make some decisions or like think about ways that you can make that better for next time. It doesn't quite happen like that simply, but just something to think about. So, when you're starting a project and you're feeling that kind of like, oh crap, feeling like, what am I going to do with this? I would say like don't ignore that feeling cuz I don't want to sit here and tell you it's wrong to feel like nervous or scared or like overwhelmed. Those are real emotional responses, but like where is that coming from? Like, let's let's think about that and try to to kind of dissect it. Um, I wrote down in here, and this is where I said a little bit earlier, I got to remind myself to bring it back up, but especially with imposttor syndrome, this talk's not going to be all about imposter syndrome, but especially when you have that coming up, I think it's really important to over time, you're going to build up these experiences in your career or whatever else you're doing. And you will have this bank of experiences where you're like, "Look, I felt this way before. This time, this time, this time, this other time, and every single time, I made progress. I came out on top. I learned a lot. It was uncomfortable, but I did it." And like the more of those experiences you have, the more you can remind yourself when you're feeling imposter syndrome, like this keeps happening and I keep coming out on top. It's not going to make it go away, but it makes it easier to kind of deal with. But the other thing that I wanted to mention is that when we have this kind of stuff happen, especially if this is like for managing a project, leading a project, this is one of the first times you're doing it, it's probably I can't guarantee it, but it's probably not an accident that you're doing this. You're probably in a position if like a sort of like typical working environment where someone was like, "Okay, we have this problem that needs to be solved. we need to kick off this project and I want you to be responsible for it. And I want that to be a reminder to you that it's like I said, not an accident that someone was like, "Oh crap, like the only person left is Jimmy and like Jimmy, you got to you got to do this project for us. So like we're all, you know, the world's counting on you." It's probably not that way. It's probably that someone said, "Jimmy, I think that this is actually going to be a really good opportunity for you. I think that you're capable of this. It might be it might be a stretch. It might be challenging, but I think you're capable. And I want that to be a reminder that someone like if you don't believe in yourself in that moment because maybe you haven't built up those experiences or um your imposter syndrome's still getting to you like just another reminder that someone believes in you because they gave you that opportunity because they believe in you. Okay? So try to remind yourself that you know, yeah, there's going to be challenges. you're always going to be facing new things, but there's people that believe in you. That's why you're in that situation. So, when I was doing my uh that that example I was walking through where I had to uh work with my team to drive down the deployment downtime, yeah, I'm going to have imposter syndrome. Yeah, I'm going to be secondguessing myself. I'm like, "Oh crap." Like, I I have never done this kind of stuff before. Like, am I screwed? Like, did I take the wrong job? Am I going to embarrass myself? And it's like, no, I've done I never I didn't go to school for digital forensics. I was very successful in that field. I had never done, you know, never pulled data off of mobile phones and I built a whole product and team around doing device acquisitions. Like there's lots of stuff I've never done before. Felt scared doing it and totally kicked butt at it. And this is going to be another one of those examples. But I reminded myself, look, you didn't trick people to get here. people believed in you. They literally knew that you didn't have experience in this field and they still believed in you based on your other experiences. So for me it was a good reminder to say I'm here for a reason. People believe in me. I believe in myself too. It's not quite that simple but good reminder. Um, next thing I want to talk about is like, and I kind of hinted at it a little bit earlier, but when we're getting started on projects and they feel scary, you're stressed out, you pro, for most people, you probably want to start by getting clarity. Okay, so a lot of the time, cuz I hinted, I feel like it's probably two things most of the time, like the self-doubt, but also like just lack of clarity. So aiming to get clarity in the beginning, I think can be tremendously helpful and trying to manage stress when you're working on a new project. I feel that a lot of the time, at least personally and from what I've seen, that people get stressed out about this stuff because it feels very overwhelming. Like there's so many directions we could go. Um there's so many like uncertainties I have or questions that are kind of just like I don't even know where to start. But you can start chipping away at this stuff and we do that through clarity. So I think a lot of the time we feel that stress of like I'm responsible for this. I need to come up with an answer. Still more hair on this thing. Um I need to come up with an answer, right? I'm responsible. People are expecting this of me. Like and like I I need to be the one to do that. And you might be the one who has to come up with the answer, but the reality is like you can't answer a question or come up with the solution if you don't know what you're solving for yet. If you don't understand the scenario. And a lot of the time the reality is people don't expect that you know right away. You kind of have this like this false sense of like like we made up the problem ourselves. It's like no, you have to go figure out the the problem space first before you can make progress on it. So like understand it. take that time to figure out like what you do know and then from there try to expand on that. Where are all the gaps? Right? The example I walked through was like, okay, you gave me, you know, two numbers, a current number and a target. And then I had to even dig in and be like, what's the trend for the current number? We don't even have that. Okay. So like let me start drawing this out and see where like like what things I know, what information is sort of a fact and then like what are these other areas that I need to explore more and you will need to do this for your projects so that you can understand the problem space. So in my newsletter I wrote down like literally like write down a checklist of things. I just gave like an example um of a like a mini checklist like who owns the current painoint like is there a subject matter expert already working in that space and if not like are there people that you can connect with that are at least familiar with that space because you're going to want to build those relationships like as early as possible because if there are people that know about that space and you just keep them omitted like you're sort of missing out on this opportunity to like leverage their intelligence leverage their like their ability to navigate this space as well. So like try to partner with people early kind of figure out who who should be involved. Um try to understand like what what is like what are you trying to fix or trying to add a solution for. Right? I think if you if someone has come to you and said like here's the you know the the challenge if you don't actually understand where that's coming from like it's going to be really difficult to make progress in again the deployment example that I was providing like I didn't know what deployment modes we had that we have a handful of different types and I had to go understand that so like what exactly is broken here well the one we're talking about is this deployment mode. And yeah, there is this other deployment mode over here and it's slower. So, probably what's going to happen is cuz they share a bunch of uh you know, common pieces. If you can make one faster, it's probably going to make the other faster. But we're really focused on this one over here. Cool. Okay. So, like now I can start to carve out some of the problem space. I can park some other things on the side. I can start to focus on where my attention needs to go. um figure out like this is it's funny this one I feel like it's missed all the time and it's uh I don't know why I feel like as software engineers we're not very good at it but um and I I say that like as a manager and as a software engineer but like why does it matter and I don't mean that in like a uh in a way like I want want to reject what I'm being asked to do but I mean genuinely like why is it that we're solving this problem? Like why is it important? And it sounds funny but like I think when you understand why then you can actually navigate problems in different ways. So for example when I was I'm going to keep going back to the deployment one. When I was told like we need to get the deployment time from X to Y like understanding why that matters is important. And there's actually a couple of reasons why. One of them is like a cost savings thing. So if we think about efficiency, like you literally can plan your capacity better if you know that you have that capacity is more available for doing what you purchase it for. So it's like a monetary incentive for it. But there's actually like a whole other layer on top of that that has nothing to do with just like quantifying dollar values. And the reason that's important at least in this context is that when we're doing deployment and literally the name of the the team that I was running was called deployment agility. So why does it matter? Well, if we can deploy faster that means that if we have an issue, we can actually get to a good state faster. We have more agility when it comes to making things right. And that has, in my opinion, a significantly better dollar, like a translation into um like dollars. Uh it's not as obvious, but it's worth a lot. And it's worth a lot because if there's a problem and I said, "Sorry, it's going to take you twice as long." You're going to say, "That really sucks. Like, I wish it could go faster." Right? And if I said, "I can make it half the time." That's going to feel a lot better. So like being able to have agility when you're making changes is incredibly important. So understanding why means okay I'm not going to be necessarily hyperfocused on like well okay if this project's kind of stalling like and the goal the why was just to save money like are there other things I can do to save money. It's actually a different question. Like if if the goal is really agility, like maybe in some cases, and this came up before, maybe it's worth spending more money to get agility. Maybe not from specifically the downtime perspective, but maybe there's other situations where that is important. So understanding why you're doing something can really help with your decision-m process. I realize it sounds kind of silly because as I walk through it, it's like, well, what do you mean you don't know why you're doing it? The the why is not because someone told you. The why is like what is the business value behind it? Why does that matter to customers? Why does that matter? Um, I wrote down like how uh make for your checklist like how are you measuring things today? In some cases, actually in in many projects I work on if it's not just like here's a feature, right? Here's a new feature for new functionality to unlock. Sometimes like that that question of like how are you measuring it today? That might not make a lot of sense because you're like this is just net new stuff. So there is no current today. But in a lot of cases we're making improvements to things, right? or even you're adding new functionality to replace something else. So like is there a quantifiable thing you can look at and see how you're measuring it today? Because as you make progress, ideally it's not you finish the project and that's the first time you can ever see the progress all or nothing. Hopefully there's a way in your project where you can see that you're making improvements towards that. It's not always going to be the case, but if you can, that's great. And at least if you have some current measurement to understand where things are at today, then you can make decisions as you're going. Uh if you if you kind of are blind to the current measurements, it's really difficult to know if you're heading in the right direction because you're like, "Oh, like I I don't know where we're at and if we make this change, I don't know if that's going to improve it at all or make it worse." Like having ways to measure really helps. And I already kind of talked about subject matter experts. So yeah, like I would recommend, especially if you're new to it, even if you're seasoned at it, having some type of checklist that you go through when you're starting a project to help you build some clarity can be really helpful. Um, this one is going to be a bit more like therapist, Nick. Um, but this is also, um, my wife gives me crap for this one, but she's she's right. So I am very much like a worst case scenario kind of person. And it's just the way my brain works and it's how I problem solve a lot of the time. So I do worst case scenarios not necessarily because I'm panicking or going like you know the the world the universe is against me like what's the I'm always uh you know being pessimistic and imagining the worst case because I'm expecting it to happen. I do a lot of worst case scenario analysis because like I'm trying to understand where there's issues or where there's opportunities and sometimes in decision- making if I'm looking at the worst case scenario and I'm like yeah even in the worst case it doesn't seem that bad like that that's a for me that's helpful framing but going through that thought experiment of like what is the worst case scenario for me helps me think about ways to mitigate things or things that I should be mitigating There is a problem with this though or like a a side effect I guess. And I think that like I keep making the argument because I had this conversation with my wife in general. She is a therapist and the argument I make for doing this is like like I just said, it helps me think through problems. But the I think I make this argument that it's coming from the right place. like because I'm doing it, it's right. Uh which sounds kind of ridiculous, right? But um I think there are situations where people do this and it's almost like dwelling, right? So for example, I've been given this project I'm working on and you know, I don't really fully understand it and I'm responsible and I don't know if I'm going to be able to do it and like what's going to happen if I don't get it done or people are going to think I'm stupid. Maybe I'm gonna lose my job or maybe maybe they're gonna keep me but demote uh demote me and like maybe that's even worse. And like you do this like dwelling this vicious cycle like it's a downward spiral. Like to me that's also worst case scenario thinking. I just think that that's for the wrong reasons. Right? My way is right, this way is wrong. Um, like I said, I know it sounds silly, but that's the kind of thing where like I would caution against that because you are you're not unless you have a way to do this, I guess. But I don't think that you're focused on the problem solving. You're focused on you're like literally living out each of these bad cases. And what's extra crappy about that is like a lot of that, like basically almost all of it, especially if you're imagining multiple like of these terrible worst case scenarios. The reality is you're not going to live out every single one of those paths. You're not going to live out multiple worst case scenarios. Um, in the worst case, you live out one of them. And when you're going through this having this vicious cycle and dwelling on this stuff, you are literally like feeling the negative impact of like of living these things out. And I know it sounds kind of silly, but like it stresses people out when they do this kind of stuff. And it stresses them out because they're they're imagining it. They're going through all of this and it has a toll on you. So the thing I wrote down in my newsletter for managing projects and dealing with stress was like stop living out these worst case scenarios like you are you are literally doing this to yourself and I don't necessarily have like what I would call a good solution for this except having awareness of it right um I think when it comes to managing projects and stuff like that like I don't do a worst case scenario like um what's going to happen to me kind of thing. But like I kind of go through that that logical thought experiment of trying to figure out like how can I mitigate problems? But I certainly like in my personal life I live out worst case scenario sort of like the wrong way, right? Like I will do this a lot. So I'm trying to be like transparent and vulnerable here. Like I'm not perfect at this by any means. I think I have a pretty good handle of it for work, but for personal stuff, no. I still I'm very guilty of doing that. I'm not like happy about that, but I I'm just being honest that I I still do that a lot. So, I I think it just takes a lot of work. Um, we talked about this in the checklist part, but I think the next thing I just want to mention is like when you're working on projects, uh, especially when you're going from like a more junior role where you're working on more individual tasks and that kind of stuff. Um, it's not that you don't have a network of people to work with, but you may, it's kind of weird. Um, when you're really junior, what might happen is you're paired like not necessarily paired up with one person, but you could be and they might be like your mentor, your onboarding buddy, or someone on the team who's kind of giving you guidance. And in the very beginning, you're kind of like you're working closely with them because they're helping you get ramped up and figure things out. You have a bit of dependence on them, but their goal is to kind of get you to this spot where like you can be pretty independent in your work. Independent doesn't mean isolated, but like you're kind of like relying on them less and less and getting more and more uh independence. But this funny thing happens because when you have to start leading projects, you kind of have to turn things around because you're likely going to be working with other people. even if they're like stakeholders for providing information or guidance or you know they're the the end user the customer there's going to be people that you need to work with and you actually do need to build up like a dependence back on them so that you can work with them so I think it's important that when you're leading projects you think about your network of stakeholders and the role that they're going to play in that project. I think if you don't have clarity on that in the beginning or at least some to get started like that's another thing that can contribute to stress if you know like who um I'm thinking like I work on platform teams at Microsoft if I know the partner teams that will be impacted by the work that we're doing like great okay well I want to think about communicating with them when we're landing stuff I want to make sure if there's opportunities that we're making progress early I can put that kind of stuff in front of them so they can give feedback back. Okay. Um uh in other cases, we're working on a project and I have a partner team that's collaborating with us. Okay. So, like can I build out a mental model of like who I need to be working with to actually get done on deliverables? I've worked in situations where I have um like a program manager or project manager and they're helping coordinate other dependencies. Like great. If I understand that that's going to be the responsibility they're taking on, then I can really lean on them to make sure that that's getting done. like be be very clear about the expectations there, but I can lean on people for that. It's a I can start to help get my stress managed by knowing who's going to be looking at what, right? Can I hold someone accountable to working on this, right? So, the the project manager case I was just giving, I can hold that person accountable to making sure that if they're looking at what the other stakeholders are doing and meeting deadlines and stuff like they're going to be doing that. That means that's something I don't have to stress as much about. I might get stressed if that project manager is coming back to me and going, "Yeah, all of the other stakeholders like they can't get their stuff done." I might say, "Oh crap." But it's one of those stresses that I don't have to go chasing people down from different teams. And that's a huge benefit. So I think it's really important to figure out who your stakeholders are, who are you going to be partnering with, what do those relationships look like? And it might not be very obvious in the beginning. Some of them might. In some cases, you might be working on something and realize part way there's like, oh, there's another stakeholder we have to incorporate, right? There was a one of the projects I was working on at the beginning of the year, I was working with uh an engineer on delivering something and he was doing design reviews and stuff and literally after going through design reviews and having like people signing off on stuff, there was like this aha moment where we were like, "Oh crap, there's like literally a whole team that we should be talking to about this because they have something that actually fits into this model very well." And so like yeah, like we wasted time like wasted uh I don't like saying waste because I don't think that that was not productive in some way, but we spent extra time on something and kind of like knew that in hindsight, but the reality is like that was a stakeholder that kind of showed up part way going through this effort. If we would have known about that right at the beginning, we could have saved some time. So it's not always perfect, but I think it's important to understand who you're going to be working with. Um, I've talked about this next topic uh in videos, in live streams and stuff, but I'm a really big believer in being transparent. And I think that if you're trying to hide behind like knowing everything or being an expert when you're not and like that's how you're trying to present yourself, I think that can lead to a lot more stress, right? Right? I think people have this this fear that like you need to come across as the expert. People are going to, you know, uh look at you like you're stupid if you don't know everything or they're going to go, "Oh, well, you m you must be a real impostor if like you actually don't know." And uh the reality is like that's just not that's not really the case. It's actually more the case when you're pretending and people can see through it. If you're trying to act like an expert and people are like, "Uh-huh." like pretty sure you're not. So instead of trying to pretend, instead of trying to, you know, be this person that has all the answers or knows everything and is going to be the expert in the space, if you are genuinely new to it, I think it's a really good opportunity to practice being transparent, especially if you find it hard to do. It's totally okay to say you don't know things. in was it last week's live stream? One sec. One sec. I can't The days are blurring together. Last week. Yeah. Yeah, it was last week. Okay. Um, last week's we were talking about asking stupid questions and like one of my my takeaways from that is like you there's going to be things like you don't know, you're not going to know everything and like no one expects you to know everything. So instead of putting this artificial pressure on yourself that you need to be this person that everyone comes to and like you know everything about this project, you don't. And that's okay. So, who's in your like back to the stakeholder network thing, like who do you know that you can get questions from or that you can ask questions to to get answers from? I don't know why that didn't come out of my mouth properly. Um, like who are those people? If we go back to asking for or figuring out clarity, right? One of the things I said way earlier in the stream, like you you are going to have questions. You don't want to go into this project just being like, I'm going to make assumptions about things, go rock and roll, because you were, you know, too afraid to ask or you didn't want to look silly or something like that. So, I think it's very important you practice transparency. Not only because you're actually going to get answers to things that you that you need guidance on, but like you're going to build trust with your team and it's like a you will learn that it's a lot less stressful. It sounds kind of funny, but it's a lot less stressful to like give yourself that room and that grace to be like, I don't know, and that's okay. I'll give you another like parallel example because it just happened. Uh like for example when I started doing live streams instead of YouTube videos just uh straight I was very nervous about live streams because if I've been making YouTube videos and they're a lot more polished because I have like I was editing them and then now I have an editor doing it but I'm like oh crap like if I go to speak on a live stream people are going to know obviously that like I don't speak perfectly that I mess up a lot that I go uh and I'm thinking here and I'm looking around like people are going to know, right? And like or I'm going to I'm going to be speaking and say something and lose my train of thought and then look stupid. I'm going to look like an idiot in front of these people watching these videos. But it's again, it's uh it's way easier said than done, but I had to give myself that space to be like we're you're going to screw up. It's gonna like literally it's going to happen. You're human. You're going to forget things. The dog might, you know, my I have one dog. She farts and snorts a lot. She's known to barge in here when I'm streaming or recording YouTube videos. It's going to happen. She's been on the stream before, but like there's going to be stuff that happens. So instead of trying to pretend like it's going to be perfect when it happens, I had a stream where like my power was going out and stuff like it's fine, right? Give yourself some grace. And once you start doing that, the amount of stress you have from this stuff starts reducing. Just one more note on streams and stuff. I used to like sit here getting nervous before the stream because like it's not a it's not a thing I do. I've done I don't know I don't know over a hundred of these now. I think it's over a hundred. Maybe not. No, I've done over a 100 newsletters. I've done over a year of streaming once a week. Somewhere between 50 and 100. Right. There's me messing up. I don't know what I'm talking about. Right. So, now that I've done enough of those, like I feel very comfortable before getting on camera. like I will be doing stuff around the house or whatever up until a couple minutes before the stream starts and I just get on and start talking. So when you're working on projects like you're going to keep getting projects in your career, there's going to be stuff you don't know. You don't need to pretend like you're an expert. In fact, you're going to build a lot of trust working with people when you can straight up acknowledge, I don't know this. I'm trying to get the answer and if you don't know it, we'll get the answer together. But we need the information to be able to proceed. Um, this one is about um celebrating milestones. And I think when it comes to projects, I'm I'm definitely guilty of this still, but I think that we do I say we in software engineering in general, we do a bad job of like of celebrating milestones. And I think that it's it's kind of crappy because you might be working on some project that's long. It's stressful. And it's kind of like you don't um you're going through it and like the only time that you're going to like feel like you've accomplished something is right at the end, right? And it's not it's brief. Project's done. We've did we've done it. Succeeded. Great. Well, right away like, okay, well, here's the next thing, right? That you go through all of this time working on something have to have a brief moment of celebration before it's like, okay, back to the grind and you repeat the whole thing where you're like, oh no, I have another project and and uh it's ambiguous and it's seems pretty complex and I don't know the space perfectly and back to it only to have this brief moment at the very end. And so I want to remind you to celebrate progress for at least two reasons here. One of which is so you have a little bit more keeping you going personally, right? If you're only waiting until the very end, that's going to feel like it's a crappy experience to only have that very brief window of celebration at the very end compared to all of the work that goes into it. So having some milestones along the way to feel good and accomplished about I think is a really good idea just to keep you motivated as a minimum. The next part to that is of course you have these opportunities to share progress and updates. And I've talked about this I think a lot on code can be recently. I think it's I I feel like I didn't value this stuff as much before. Maybe because I worked in a startup and it was like almost like happening automatically just because it was small. But um especially at bigger companies like I think it's really important to be able to communicate out like accomplishments and milestones. So if you're working on a project, right? Like instead of just saying like okay like it's going to take us four months and at the very end for the first time you're like tada here it is. Um, keep your stakeholders up to date. Cool. You're not done, but you made progress on this. Cool. Give an update about what that progress means. What's coming up now? Awesome. Okay. Wait till the next milestone. Share that up. Share that out and repeat that. So, not only is it an opportunity for you to celebrate, but it's a reminder for you to share status, and that way you can keep the right stakeholders engaged. Okay. Uh, I think that's mostly it. You know, the last part I just kind of wanted to wrap up here was like it's normal, right? I said I said this right at the beginning. It's normal to like for stress to come up. Um I think again I will always say these things and I'm like I realize it's like way easier said than done, but the stress part is normal. It will keep coming up. You will get better at these things. You'll get better at managing your stress. There's going to be new projects that scare you in different ways or make you uncomfortable in different ways and you'll overcome that. Like you will keep doing that. But I think what you need to do is lean into that and like acknowledge it. Like go in head on. Don't run away from that kind of stuff. Don't be like, "Oh man, I got another project. Like this is the worst. Like I don't want another project. I don't want to do this." It's like if you keep doing that and you shy away from opportunities then you're going to feel like you're kind of stuck in you know a particular whether it's a level or kind of just particular set of work whatever it happens to be. So the growth that you can experience from these like that's an optional thing for you to lean into. It's going to be stressful. it's going to be uncomfortable, but if you go into it like taking it on head first, I think that there's a lot of growth that can come from that. So, just my reminder to you that even though this kind of stuff might scare you, might make you feel stressed out, if you think about the stuff we've talked through so far, these are going to be opportunities for you. And I hope that that's something that you can leverage and take advantage of so that you continue to have awesome opportunities in your career. So, I think that's going to be it for this part of the stream, folks. Um, chat was super quiet today. I appreciate a random programmer jumping in to say hi. I feel like my Twitter chat is busted. Like, I don't feel good about it. I'm just going back over to Twitter, like actual Twitter. What's going on? It says there's like just to give you an example, it says there's 35 people on Twitter right now on the stream. On my side, it says there's zero. There we go. Rex says, "Hi." Perfect. Thank you so much. The chat works. You guys are just being super quiet. Must be Monday, right? Okay. Instagram's usually quiet, but there are some people watching. Substack folks don't chat much, but I appreciate you being here, but I think overall this is a pretty quiet week. Um, there aren't I'm trying to poke around. I don't see any questions that were submitted. Coding and listening. Perfect. I'm cool with that. I am very happy that you're making progress with your code and hopefully I'm not too distracting, but thank you for being here. I appreciate it. Um, folks, I'm going to kind of do my sign off. Um, but of course as I'm doing that, if people just have questions, it is an AMA kind of style like always. So feel free. Um, as long as it's not math questions, I'm happy to try and answer. So let me flip this over here. Um, cool. I shared this out earlier. I'm just going to put the link to the newsletter right here. So if you're joining late or didn't hear what I said in the beginning, uh, weekly.devleer.ca CA brings you to this page. Uh that's where my newsletter is and that's usually what the topic's going to be for the live stream for next week. So you don't have to subscribe if you don't want to get email. Totally cool. Don't worry about it. Um in fact, I encourage you to not subscribe if you don't want to get email. I don't want you to just get email that goes to junk. Um but it goes out on Saturdays. So, you have Saturday, Sunday, and Monday to see if you want to hang out at the live stream. Uh, or just come hang out because people can chat unless it's a quiet day. So, that's the newsletter. Next up is this is where what did this not refresh? Oh, it there it is. Okay, it didn't refresh. So, the uh Dev Leader podcast channel on YouTube is where I stream to now. And I gave an update on this before, but basically I split up my YouTube channel so that I could focus uh on different niches because uh in terms of the YouTube algorithm uh did not like what I was doing. So, my main channel was pretty uh stalled, which is pretty unfortunate. But um yeah, this channel has uh interviews with software engineers from uh all sorts of different walks of life, different career journeys. I interviewed Scott Hansselman. I interviewed Hassan Hhabib. Um I have who uh Derek Martin is going out this week. So he was awesome. Some of these people you might know, others you might not. Um, but yeah, for me it's a it's a really fun opportunity to be able to sit down with people that I look up to and then there's other individuals I meet along the way and there's always something super interesting to learn. So, uh, that's the podcast. Um, this one is just my main channel. So, this is Dev Leader. This is where everything started. And so, on here, I'm primarily focused on, you can see my estimated monthly earnings. Wow, that sounds about right until you factor in the fact that I have to get videos edited and that covers um one. So, this channel has programming tutorials. So, if you want to learn about um you know how to program in C, if you are interested in like AI tooling and stuff like that for developing, then you can check out Dev Leader. That is where you know the bulk of my content is. the other channel that I have because yes, there are a bunch of them. This is Dev Leader Path Tech. This one is all about ré reviews. So, if you are interested in having your resume reviewed, you can head over to this channel. Check out one of the videos. Um, we use my same face a lot. I got to I got to tell the editor we got to switch it up. This one has sunglasses at least. It's behind my head. One sec. See? Where'd it go? Come on, man. Oh, you can see it just poking out. There we go. Um, wow. Now, Twitch is also terrible today. There we go. Bye-bye. You are blocked. So, that's Dev Leader Path to Tech if you want to check that out for resume reviews. And otherwise, my fourth channel is Code Commute. Um, not a lot of people from Code Commute today. Letting me down. I had a lot of people come from Code Commute to to check out the live stream which is awesome. Um, if you weren't aware, Code Commute is the channel where I do Q&A vlogs and the topics from Code Commute actually feed into my newsletter article. So, I generally look at the week of videos that go out and then whatever one was the most engaged with or most viewed, that's usually what I'll write about and then do a live stream on. Oh, last week's you can see uh about fearlessly asking stupid questions. That one had the most views kind of out of this period of time. So, I make the the newsletter on that and the live stream on it. So, if you're interested like in like and I mean this genuinely, if you're interested in having these live streams and like the newsletter and stuff like focus on a particular direction, if if you have questions, send them in. I will answer them on code commute. You can go to codemute.com. There's this contact form. You can submit anonymously if you want. Otherwise, just comment on a YouTube video. Um, and you know, if there's another topic that I've talked about on code commute and you're really interested in it. If you're having an engaged conversation on there, that might be the one that I just go do a, you know, a newsletter article and a live stream on because I just want it to be a useful period of time for people. Otherwise, it's just me blabbing to a camera in my room. So, um that's that. And then I do have choruses for sale. I really need to get my next um what's it called? See, I said I was going to mess up earlier. Give yourself grace, Nick. Um course outline. Thank you. Thank you, Nick. Um thank you, Nick's brain. So, I have to get my next course outline sent in so that I can start working on that. But I do have C courses if you want to learn how to program in C. And then I have some other courses that I did with Ryan Murphy about, you know, working as a software engineer in your career. So whether that's interviewing, uh, promotions, career management, that kind of stuff, it's all available on dome train. So I'll put a link, if my keyboard will paste. There we go. That's dome train. And then finally, just to close things out, brand ghost is this tool that I am building on the side. Um, I talk about this a whole bunch, but Brand Ghost is an ASP.NET Core web application hosted in Azure with a MySQL backend for everyone who is curious. And so, this is a platform that I use for uh cross-osting and scheduling all of my social media content. So, if you are on like if you're on Twitter, because most of you are on Twitter, all of my tweets come from Brand Ghost. I write them, but they all come from Brando. Same with my LinkedIn. Same with my Instagram, my Tik Tok, my blue sky, my threads, my I don't have Tumblr anymore. My Reddit posts, like everything comes from Brand Ghost. I create content, I put it into Brand Ghost, and then it schedules it out for me. So, Brand Ghost is totally free to use. Literally no credit card required. If you just want to do crossosting and scheduling and if you have uh other needs like some of the more advanced features, we do reposting, content recycling, that kind of stuff. Um, those are paid for features, but they might not be applicable to you if you have a small business and you're trying to get some help with uh being more regular with social media posting. If you're trying to get into content creation, building in public, learning in public, reach out to me. I'm happy to have a conversation with you and see how brand goes can be a fit. Of course, like I said, there's a free tier. If the free tier works perfectly for you, just use the free tier. I'm not here to try and force you to go buy something you don't need, but I would be very happy to help you get started using it so that you can actually make more progress with your social media content creation. So, I think that's it for today, folks. Thank you so much for being here. And uh, of course, we'll do this again next week. I have vacation coming up soonish, not next week, though. So, we're on for next week. So, I'll see you all then. come with your questions and I will answer as best I can. I will see you all next time.