How To Manage Stress When Leading a Software Development Project

Transcript is auto-generated and may contain errors.

Hey folks, I'm just driving to the office. Uh just a bit of an awkward start to the day. I'm just going to uh or I guess I'm leaving Crumble Cookie to bring in cookies to the office. Figured I'd try and do something small just to do the promo celebration. So, just a little thing. I'm going to go to experienced devs for a topic. this one. Um, I'm not going to like hyperfocus on their specific situation and just kind of talk about this a little bit more generally. And the framing of the post is around like like how to manage stress as sort of like a lead on a on a project, right? So, we'll go through that. I think this is something that, you know, many people will experience in their careers if they're sticking in software engineering. You'll eventually hit something like this where, you know, as you grow in seniority, you're responsible for for more and more things, more ambiguity, more scope, that kind of stuff.

And um and yeah, it can be kind of scary. Um so I wanted to talk about it because I think I don't know. I don't I don't know exactly the things I want to touch on yet, but I'm hoping something useful comes out of my face at some point. So, um to start things off, I I think it's important that like the way that this one was framed was around like I don't really know like I just it's kind of ambiguous, right? And this is this is something that happens as you become more senior in your role that the problems that you are tasked with start off as more ambiguous. Right? It's um when you're more junior and I'm generalizing of course so please bear with me. When you're more junior, it's like, hey, like there's this problem we know and understand at least reasonably well and like we'd like you to work on it because we feel safe with you working on it because we can help you with it, right?

Like we understand it or at least enough to guide you. You know, if you get stuck, we can help and like we want you to build some momentum. And then as time progresses and you're getting more comfortable building up more skills, more domain knowledge, this shifts a little bit so that it's like here's a bigger problem, here's a more ambiguous problem. But it's like it it continues down this path and the as you become more senior, you're entrusted with working on more complex, more ambiguous problems. And that's the case because you've been proving over time with incremental steps that you can do that. So the very first time you encounter something like this, like obviously these types of things aren't like perfectly linear where like everything you're working on perfectly scales up and ambiguity and and uh scope, right? Like it's just not real.

But um the first time you work on something where you're like, "Oh crap, like this actually feels a lot more ambiguous than I'm used to." It might feel a little uneasy, right? like and I think for most people you'll probably have your first one of these where you're like oh like I'm responsible for this and the um there's probably a bunch of things that will go through your head like number one you might have some imposttor syndrome kick in right like wait I I need to be the one to do this am I even capable of this I've never done this before you know um Jimmy and Suzie on the team they've been able to do this but they're way more senior than me like I I like am I am I worthy of taking on such a responsibility? You'll probably have some thoughts like this.

And then the other thing is like depending on what task you have, what project you're on. This this realization like wait a second, we don't just have the answer. There's not like the solution is in the Jira ticket, the problem is in the Jira ticket or the problem is in the conversation, right? like in the the project kickoff like, "Hey, there's this thing that we need to fix or make better." That's how it starts, right? It's ambiguous. The solution is not well understood. And I would hope for most people that when you're going through this that there is some type of scaling to this, right? Like it's not the first time you do this, it's such a big crazy problem that there's no hope in hell for you to to be able to navigate it.

And like it's it's probably unlikely because the people that are tasking you with it um you know I would again generalize here but I would like to assume that they have at least gone you know what this person has prove proven to us before proven to me before that they are able to do this kind of thing. I believe in them and like yeah this might be a challenge for them but I do believe in their capabilities. So, I would like to task them with this. And I wanted to to kind of frame it this way cuz I think that's the first important reminder is that likely someone who is tasking you with this, they literally believe in your capabilities. So, when you're starting to doubt yourself instead of going, "Oh like am I even am I even capable?" And the imposttor syndrome is taking over like you probably are.

like someone at least one person really believes in you or else they would have said hell no like give it to someone else right I don't trust this person to do it there's too much risk here but they're looking at you going I do think based on your track record you should be able to do this so try to keep that one as a reminder I know that it's not going to like cure your imposter syndrome but like just I'm saying it out loud so that hopefully that you know if you're experiencing imposter syndrome whether it's now or at some other point in your career like it's one more voice in your head to try and help you, right? Like remember someone believes that they have confidence in you to do this. Okay, so that's one part. The next is like well how do we navigate ambiguous problems?

Right? There is a thing that needs to be solved if you don't yet understand the problem space. Step one's clarity, right? You you are an engineer. You are resourceful. You get to the bottom of things. You seek to understand. You're curious. We got to solve this problem. Okay. Well, like what's the scope of this? Like tell me more about it. I need to understand it more deeply. I need to understand what we're actually trying to solve. Not just taking things at face value. Not just making assumptions about them and then going off to go do whatever. It's like you need to understand the problem. And that might seem kind of scary, right? cuz you're like, "Oh this is new. I don't know this, but this is going to keep happening." So, like building up that that comfort with like, "Hey, I don't know this, but every time I'm in a situation where I don't know something, what do I do?" Well, instead of running away from it being like, "Oh, no.

Something I don't know." The only way that you've gotten to where you are as an engineer is because you have been curious. It's because you learn things. because you do seek to understand how things work. So, you have a new project that's a little bit ambiguous. I understand that that might feel stressful and that might seem like new and kind of scary, but like if you don't understand what problem you're trying to solve for, start with getting clarity. Try to understand the problem space. Right? I give you a quick example. as an engineering manager. When I came into Microsoft, my professional career had uh since university had only been in digital forensics at one company. We built desktop software. When I was hired at Microsoft, I was managing part of the deployment team for Office 365 and we deploy hundreds of services across the planet. I had literally never deployed services to data centers ever.

ever. My first task was around reducing the amount of downtime that we experience when we deploy software. This isn't quite the same as like, oh, just spin up a VM. Slightly different world. Um, so like I've never done this before. I've never had to do things at scale like this. So I have to start by understanding the problem, right? My my manager is super helpful. Um he was like, "Hey, like I I believe that this is feasible. This is sort of like a it's not groundbreaking in terms of the team has never worked in the space. Here's here's sort of like it's not necessarily an incremental improvement, but here's something familiar to the team and we want you to go drive this effort to reduce this cost." Great. Okay. Sounds sounds scary to me, right? I have never done this. What's step one? Well, why are like why are we reducing downtime?

Like help me understand this. I want to understand the problem space more. Oh, when we're deploying things through this mechanism, there's downtime. And that means the machines aren't actually being used for why we buy them. Okay. Well, why do we buy them? That's to serve uh compute and storage for Office 365 products. Okay. So, when they're deploying, they're not being used. Okay. This problem space is making a little bit more sense. Cool. Okay. like I don't I've never I'm new to the team. How do we deploy things? Let me understand that. Oh, there's different ways to do it. Cool. At least let me get a broad overview of that. Okay, now I'm starting to understand this more. Cool. Where are we at? What's our deployment time right now? Oh, we don't have like week over week or day uh daily like metrics that we can trend like this.

Okay, we have some gut check. Okay, I have a rough starting point, but I know one of the first things I need to do if we want to be data driven is we need data, right? So, I can start carving this path because if I know the end goal is to reach some percentage in reduction, I can't prove it unless we can measure it and then we start chipping away at it. Come on, do the merge. So anyway, like you know, I'm not saying it's trivial. I'm not saying it's easy. What I am saying is like you need to lean into it. And I realize it's kind of scary and I promise you it gets easier. Every single time I am put into a new space, I am not kidding or exaggerating. Every single time I'm put into a new space, I have this exact same feeling where I go, "Oh crap, this is new.

I don't know it. And I have the imposttor syndrome kick in, right? Like I don't know this. And then I have to keep reminding myself every time this happens. What do you do? You don't know it. Start understanding it. Okay. So, we spend I'm not like I'm not a therapist and I'm not a psychologist, but we spend a lot of time like creating problems that don't actually exist. Right? So, the person who wrote this Reddit post, they're talking about like literally feeling sick to their stomach, not being able to get out of bed because they're so stressed about having to take ownership of this. And like I'm not I'm not saying that they're not allowed to feel that way. Like I get it. I understand that like stress can be like real, right? Like you can have real physical responses to that. But what I am going to call out is like a lot of that is fabricated in this person's mind.

Okay. So, and I'm not trying to diminish their feelings or anything like that. I'm trying to literally acknowledge that it's it's normal to have a physical, you know, response to this kind of stuff. But what's happening is that they're dwelling on like, I don't know, how am I ever going to do this? But like, they're literally living through the worst case scenario on repeat. They're they're dwelling on it. It hasn't even happened. They start re like living out in their mind like, "Oh, I'm not going to be able to do this. I'm going to look stupid. I'm going to get fired. It's going to be embarrassing. Like, none of those things have happened, right? But you are living them and experiencing them because you are imagining them. So, I'm very guilty of doing this, by the way. So, I'm talking about this from the perspective of someone that does it, but it's a little bit easier for me to just like talk about it as a, you know, a third party.

So, I I just want to like call it out to you that, you know, use it as a gut check. If you're like doing this this dwelling or you're having like this vicious cycle of like psyching yourself out, you're not worthy and you're stressing like you are probably fabricating a lot of that in your head. And it's, you know, it's okay that you're having those feelings, but you have to start breaking the cycle, right? Like, I don't know how this works. I'm going to fail at this. Well, if you don't know how it works, like really like what what do you need to do to start understanding how it works or what your what the challenges you're trying to accomplish, right? Ask questions, start digging into things, start networking, start understanding who your subject matter experts are to engage with. Go through these steps and you'll start seeing that you're in control, right?

as an engineering manager, like I'm not given tasks where my my manager is like, "Hey man, like here's a thing you got to go do and like I expect that you sit down, you know, lock yourself in a room and go figure it out." Like absolutely not. I work with other people to go figure that stuff out. In fact, it's expected that I work with other people. It would almost be ridiculous if every like engineering problem that came to the team, I'm just like, I'm going to go figure this out and then once I figure it out, I bring it to the team to just go, you know, press the keys on the keyboard to make it happen. Like absolutely not. So when you're leading things, dig in, understand, but you know, recognize that there is this expectation that you're working with other people. And this is a skill.

You do need to practice it. And yeah, it's probably going to be a little weird in the beginning if you haven't done it before. That's okay. Like this stuff is going to be bumpy the first few times you do it, but it will get better. And there will always be like curve balls and stuff you don't expect. That's part of it. That's okay. So, you start building up your understanding. You start building your network of people who you know that you can rely on as resources to understand things more deeply to follow up on stuff to you know check your understanding. So you build up your network. This is it's critical. You're a team right? And even if we're talking outside of your immediate team, you're still part of a larger team that's at a company, right? And I just wanted to say that like you will you will start to realize that you'll build some momentum with it.

And um I don't know, you might get through projects and the whole time you're stressing about it and in the end is kind of like when you have this relief where you're like, "Oh my god, we did it." Um, like please take a moment and like celebrate that for yourself because the reality is that once you start getting into like this type the scope of work, there's going to be more of it, right? Like this is this is one of those things like as you become more senior, this is what work starts to become. There are literally people that I've talked to from like interviewing on my podcast um where either they or other people that they're sharing from their work experience literally have turned down promotions which sounds like to me that's like unheard of like why would you ever do that? They literally turn them down because they're like nope I'm very good at this level.

I make money that I'm happy with my work life balance and the tasks I have I can execute very well going one more level having those expectations being higher um is not something I'm comfortable with and like it's not worth it for me. So definitely there are people that just do not try to keep going above and you know further and further up the career ladder. So it it's like a it's a relatively normal thing that you'll experience that like as you become more senior, you know, the type of work that you're tasked with is going to be bigger and more ambiguous. But you will get better at doing it. I promise you. I just don't want you to think that like it disappears.

It's not like one day you get to a certain level and like you know the only problems you work on are well understood problems but I don't know you'll become more and more senior and what will happen is you'll become more and more comfortable taking those types of problems on right because you'll have enough track record for yourself not even from external validation where it's like well my boss believes in me it's like yeah I'm sure your boss does believe in you that's why they gave it to But you know what? You can remind yourself the, you know, tens, hundreds of projects that you've done. Every single time you get yourself into a spot where you're like, I don't know this. And every single time, you make progress on it. Okay. So, um, I think, you know, to kind of uh to summarize, I I unfortunately think that a lot of the stress and stuff can be self-inflicted.

And um I feel like I don't really have good answers for that because it's it's just very it's easy to say like, "Oh, just don't worry about it. I know I know it doesn't work like that." Um, but I I think that like personally, again, not psychologist, not a therapist, but I think that you need to find mechanisms that work for you that come from you to remind yourself because if you're relying on external factors for that, that's I feel like that's not really a sustainable thing. So that's why I think building up some of that experience for yourself over time, draw upon that. I like as I was talking through this I reminded all of you of you know my onboarding to Microsoft and not knowing I had a very similar thing when I switched teams like three and a half years in the

current team I'm on right and then it wasn't just deployment it's the routing plane but I managed three sub teams on the routing plane that do very different things so that whole experience of like oh I've never deployed things for like this is scary. I had that times three in my next sort of transition, right? I had when I was on the deployment team, I inherited another deployment team. So, did I understand some things about deployment? Yeah, I've been doing it for a couple years, but I inherited a deployment team that had completely different deployment technology. Guess what? I don't know anything about it. Guess what? Got to start learning because I have to lead the entire team. And you know what? I think one of the things that worked really well with doing that was being transparent with people, right? Like, yes, this is my new responsibility.

No, I don't have all the answers, and I don't want to pretend to. So, please, I'm here to help all of you. I'm here for this to be successful. So, I'm going to have questions. Please help me help you, and we'll do awesome work together. And I had, you know, I think personally, I feel like a lot of success doing that. I had great people to work with, super helpful. But like, you know, could you imagine how fast I would erode trust if I was just pretending like I know all these things and I just don't? No. Got to ask, you know, talked about this recently. Got to ask the stupid questions, right? But like I got to ask them so I can learn. So it does get better. I can promise you that. Are there gonna be curve balls and other fun stuff along the way?

Absolutely. But it gets better. So, I think that's it. I'm at the office now. I'm just going to park. Uh, I wanted to remind folks, come on. Is there no good spots? Come on, man. Bull crap. Um, I got to park between cars and get my door dinged. They're all like these super super small spots. Gross. I'm gonna do another lap. I'm gonna remind folks uh this is Code Commute, but I have other YouTube channels. So, if you want to learn, uh C programming and see programming tutorials, you can check out Dev Leader. That is my main YouTube channel. And I have a couple others. I have the Dev Leader podcast. Uh that's where I interview other software engineers, hear about their career journeys. you can see just how many people have like completely different career journeys and still are very successful. And I also live stream every Monday at 7 p.m.

Pacific. Usually going over a topic from code commute, so you can check that out. And then I also have dev leader path to tech and that's where I do resume reviews. So you can check that out and I'll probably have some other type of content in terms of breaking into tech, but right now just resume reviews. So thank you so much for watching. If you got comments, questions, leave them below or go to codecute.com and you can submit anonymously. Take care. See you next time.