Leading With Why Over How as a Software Engineer

Transcript is auto-generated and may contain errors.

Hey folks, I am headed to the office. Gotta make sure that this thing's actually charging. Why aren't you charging? What's going on, man? Okay. Well, I got to pay attention. This video might cut short cuz I don't think my camera's getting any juice. Um, I don't feel good about that though. How do I How do I make this better? Let's see if this will do it. One sec. Bear with me, folks. juice. Okay. Um, let's do it. So, I couldn't find a good topic on Reddit. I don't have any pending questions. Um, I didn't It says it's going to be an hour drive, which is ridiculous. But, uh, I want I had a topic in mind that I wanted for a shorter drive cuz I I feel like I like this topic, but I feel like it might devolve into like a rant and I don't want it to do that because I don't think that that's helpful.

Um, so I figured if it was shorter then I can kind of stick to my points and then and then move on. I wanted to talk about like this is more of like a leadership kind of thing. And I don't mean from like a manager perspective necessarily, although I think it's very applicable for managers. I think this can make sense for people that are in like team or tech lead positions, people that are leading projects, that kind of stuff. So I wanted to to talk through that. So that's going to be the topic. Uh, I really hope 1 hour to get to work is a a joke because I can't survive. It's the fourth day this week and every every drive in has been like 1 hour. Like, nope, I didn't sign up for this kind of life. Um, so we'll see how the fast lane is.

But a friendly reminder, if you're new to the channel, uh, this channel is all about the questions that you want to submit and then I can answer them. So if you want, please leave a comment below about software engineering or career related questions. Happy to try and answer. Uh if you're not comfortable leaving a public comment, that's totally cool. You can look for dev leader on social media. Uh I will you send me a message on any platform you want. It's Nick Cosantino on LinkedIn and I'll keep you anonymous so you can write more detail, kind of walk me through whatever is going on and uh I just anonymize it and kind of try to uh explain my thoughts on what's up. So, Dev Leader is my main YouTube channel. I do have uh edited down C tutorials. I have a resume review series if you want your resume reviewed for free.

And then there's a podcast there as well. So, with that said, let's jump into things and talk about this topic. So, what I want to discuss is um a how versus why kind of leadership approach. And uh I think that especially for folks that have like a strong engineering perspective, people that are very technical, people that are that are very experienced, it's it's sort of easy to fall into a trap of uh of leading by how. And what I want to do as we talk through this is I want to explain that I do think there are scenarios where like how like explaining how when you're leading things can be effective, but I think that it can fall apart and actually become um like detrimental to a team. So when I talk about how versus why, I I quite literally mean like what these words are, right?

So when you're trying to lead something and explaining how it should be done, you are basically it might not seem like micromanagement, but you are effectively doing some type of micromanagement because you're telling people that should be smart, should be very capable, should have their own opinions, should be able to be informed. So when I say opinions, I don't just mean they wake up and have some feelings that day and that's how they're going to go build stuff. They're smart engineers, right? If you trust your smart engineers, they should be able to collect data, make decisions on that, collaborate with people, and do the best they can with the information that's available to them. When we talk about leading by how, you are effectively saying, "Hey, very smart people, here's how you're going to go do it." Right? You've now removed the part where they're doing essentially the engineering part and you've given them structure.

perhaps too much. And I think that's the the real danger with this. And this is the thing I want you to keep in mind. Um when I'm talking about leaning by how, this often ends up being uh folks that are being very prescriptive with their how. Sometimes it starts not by um like not intentionally. And I think, you know, I want to let me clarify when I'm talking about this being good or bad or whatever. I don't mean that when I'm saying something is not good. I'm not saying like people are being malicious. They're terrible people. They should feel bad about themselves. I often think they're doing the absolute best they can. They're trying to help as much as they can, but it's it's all coming from a very good place, but it ends up being uh counterproductive. So, leading by how is uh you know could start by being very much like I have ideas for how this could work.

so I will share them with you and then you go great thank you so much um good to know right nothing really wrong with that but then what happens is you're like okay those are some options either and depends on the person and what's up but um sometimes it's like okay well are those my only two options because basically someone put those two in front of me do I got to go figure out which of those two um are there more options that should be explored sometimes people finally go to explore the more options only to realize that whoever was giving them some examples and starting them off was basically suggesting like no those are your two options like I am dictating how it's supposed to be done even though it starts off not that way even though when I'm saying dictating how it should

be done that's not even how they're communicating it it's basically like they've already made up in their mind that it has to be these two ways one of these two ways sometimes even just one way. So you start to have your autonomy removed. Okay. So this is the the how sort of approach. The Y approach steps back from that, right? Um and you I'm not saying that they're it's like totally black and white. These things can get mixed. Um but I I like thinking about things kind of like on spectrums, right? So um the amount of how that you put into something, the amount of why you put into something. Um, these can overlap, they can mix, but I like to think about them as spectrums. When we talk about why, it's sort of like this is the significance or this is the value of this.

This is the importance of this. This is why we're doing it, right? I think that it seems I I think people struggle with this because it seems a little bit more vague sometimes like we're not talking about specific implementation details. Like it feels good to talk about how because as engineers we're like we know we have to go build something. How are we going to build it? Like ultimately this is what we're doing. But it's uh it's almost like who is making those decisions? who is having that input. Um so when we talk about why from a leadership perspective if you're leading a project if you are uh the the manager you're the team lead the the senior engineer that happens to be responsible for this project I think why is extremely important because what that enables you to do is set up framing for the people working on the project that are contributing to be able to have a framework for for what's up right?

Like why are we doing this? I'm just making up something totally random off the top of my head. We're doing this this project because um you know we really value uh user experience and there's a lot of latency and that's the biggest thing affecting user experience right now. So why we're doing this is to drive down latency because that is the biggest factor for user experience and that is the thing that we really value. That's why we're doing this. Okay, so there's some what in there, right? Like what we're talking about latency, we're talking about user experience. But why we're doing this is because uh the latency is the biggest factor that we've determined and we really value customer exper or the user experience of whatever is being used. Right? This is why um from there this kind of opens up discussion, right? like, well, now we know why we want to go chase down some work, why we're doing this project.

How you're going to do it is going to depend on many factors, but this is where I think that you want to lean into the engineers that are responsible for carrying out that work. Because if you are leading the thing and you start telling people here's how it's going to be done are like what happens and I'm going to exaggerate this a little bit is that those individuals effectively become the people that press the buttons. That's all that they're there for now. They're just the button pressers. You've already told them how they're going to do it. Right? I'm exaggerating. There's some nuance. you have to they have to go figure out the code. They actually have to go like figure out the details, but you've essentially removed a lot of their autonomy because they don't get to decide how it's going to get done, the overall solution approach.

They're really just now responsible for like sort of the nitty-gritty details about like what classes am I going to touch, which methods. Like it's almost like you just left the boring for them. Don't get me wrong, it still has to happen, but you've removed a lot of like what could be considered the engineering part. You've told them how it's going to be done. So, one sec. It's the highway. You should be going the highway speed, not below the speed limit. I don't understand. Um anyway, I hope that the framing so far is making sense, right? I know kind of might sound like a little bit wishy-washy, whatever. Sometimes people don't think about this stuff. Uh which is I think exactly why this kind of thing happens. But ultimately leading with why is going to provide framing for the people that are responsible for ultimately carrying out the work.

They get to decide how it happens. They have to back it up. But that's what engineering is all about. Oh my god. What is going on today? Must be an accident. It's like the Google Maps is saying like plus 20 minutes of traffic right here. But also like what's happening is this is where the fast lane starts and I can see up ahead the fast lane's totally clear and people are just like getting into the fast lane going 20 m hour under the limit. There's no need. There's people being like I don't know. Anyway, back to the topic. Um I think sometimes what happens is that people um that are leading things they need to have or they have this feeling that they like need to have some some control over it, right? It's your responsibility. You're the one leading it. You're accountable. You're responsible. You got to make happen even though you have these other people that are that are working for you.

uh I feel like I am able to talk about this because as an engineering manager like in my career this is what I have to do across absolutely everything that I'm involved in. So when you are leading things and sometimes you might be like a technical lead for something you're you're also participating you're part of it um but there's other people that are like you know responsible for their parts of the project ultimately it might bubble up to you kind of thing when we have accountability for things again I I feel like this I is like an engineering kind of mindset So part of me is like I don't blame people for this. I think I I understand why it happens cuz we have to like fight this urge, but you'll have people that are working on the project with you. You're responsible for it ultimately cuz it's the project you're leading and someone is like hm like okay here's what I'm thinking.

Here's what I'm the path I'm going to go down. And you're like oh like no that's not that's not it. Right? And you see it, you do this enough times and you're kind of like I think this is why people fall into the how trap. You just start telling people here's how it's going to work. And sometimes like if you do enough projects like this, you end up it's not even like someone has proposed something else. you're just like almost shortcutting that whole thing and you're like, I'm not even giving these people this opportunity to suggest how. I'm just going to get right in there and like I'm accountable for it. Like I'm going to propose it. But then you end up even though like you have this bigger project, other people are supposed to have their responsible areas, you kind of just take over the whole thing right now.

Technically, you're doing too much. like you're responsible for all of it, but now you are literally also sort of doing the um the how for all of these sub areas that you might have other people that should be responsible for. All because like a lack of trust, a lack of um or like inability to actually effectively lead projects, right? You might just as an example when I'm saying like lack of trust it might not be because you like oh this person's stupid or something like that it might be such that you have been ineffective at communicating goals or setting timelines or anything else and other people are trying to operate within those bounds and as this project is moving along you're starting to go like this isn't working this isn't working we're off track we're off track and instead of trying to clarify goals. Instead of trying to clarify timelines or unblock people, you go to solution mode.

You start skipping all of it because you're going, I'm not seeing the results that I'm expecting. I'm responsible. I'm jumping right to how. Here's how you do it. Here's how you do it. right now. These people go, "Okay, well, whatever I was doing, like I I guess I'm just stopping what I'm doing because you've just told me how." Um, this I think is more dramatic when you have like sort of a like a role difference. So like as an engineering manager talking to the engineers that might report to me, they might go, "Well, Nick said so. I guess I have to, right?" Like that's my boss. Okay, fine. Um, if you have uh tech leads that are kind of mixed and there's not like a direct reporting kind of structure, they might be like you might start seeing different kinds of friction like who the hell does this guy think he is?

Or people just like kind of butdding in and being like I'm not doing what you say and then there's a lot of tension. But ultimately I think this is coming back to I'm calling it like a lack of trust but that's sort of the the symptom. you are not trusting things to get done because of what you're observing. But the uh the root cause of that could absolutely be things like failure to communicate goals effectively, failure to get status adequately, failure to um talk about timelines uh actively, failure failure to unblock people, right? And these things go multiple directions, right? you might um if you're not doing a good job and like I can be guilty of this plenty of times on timelines, right? Sometimes for work that is a little bit less structured, I'm significantly more lenient on timelines, right? Like we have a lot of that's got to get done.

Okay, makes sense. But there is no um the timeline for something is really like get it done as fast as you can given the quality needs to be high. But it's not um it's not a matter of like a partner needed this yesterday to unblock them kind of thing. In situations like that, I'll be more lenient on timelines because there isn't actually a hard deadline that we need to abide by. But but it works only if the person on the other end of that on the like that's carrying out the work understands like I still got to get this done. I still have to keep moving along cuz if they don't have that mindset all of a sudden things can blow out completely out of proportion for timelines, right? Especially if people are more junior. I think this is very common. So if all of a sudden if I start, let's use this as an example, right?

Let's say I'm working with a more junior developer. Um, and it in this example I'm just talking about like a feature. Okay, so we've assigned a feature to a more junior developer. I've been very lenient on timelines, right? This is the next work you got to do. Great. Makes sense to you. Awesome. Okay, let's get started on it. In my head, I'm going, "Okay, shouldn't shouldn't take them too long. It's pretty straightforward. They seem to understand it." But we never talked about a timeline for it. If like my more senior engineers are like, "I know I got tons of to do. Like, I'm going to get through this as fast as I can because I have other stuff that I like that I know I have to get to." And sometimes the more junior engineers, not blaming them by any means, right? I think this is natural.

They'll go, "Well, I don't like we didn't discuss a timeline, so and I this is a newer area for me, so I have to learn." And I think that's totally fair. Absolutely want people to spend some time learning in the area so they can get up to speed. So that's going to be a little bit of extra time, but all of a sudden, like they don't have this constraint to work with it. Okay. So, they're going to it's going to likely likely go longer than I'm expecting unless they're the type of person that's very very eager, which I can't expect that everyone is. So, this goes on and then I go, hm, like it's been a little while. I haven't seen like I'm kind of thinking like this isn't working so well. Touching base with the person, figuring things out. Okay, you're not actually blocked. Okay, cool.

If it goes on a little more and now I'm like, "Okay, like I'm responsible for this ultimately and it's not getting done." If I jump right into, well, look, man, just here's how you do it. Go get it done. Like, this is how it has to happen. All of a sudden, I've shortcircuited the other sort of like I think important parts of building momentum in a software engineering life cycle, right? We don't end up addressing the fact why is this happening? It's happening because there were no clear guidance around timelines. It's happening because maybe the goals weren't clear for this person. They were too ambiguous. It's happening because the individual like we kind of share the responsibility. The individual is not asking for help even though they're blocked. It's happening because they're blocked and no one is noticing that they're blocked. So there's some inefficiencies in other places, but there could be a million things to go address.

And instead of trying to address the sort of root cause of what's going on, we look at the symptom and we're like, well, I can't trust that you're getting this done. I'll just tell you how it's done. Go do this ABC. Go get it done. And I feel like I feel like what happens is like that's your short-term win. You're like doing damage control. Like, okay, it's got to get done. Here's how. Boom. And then we go, well, that sucked. Try again next time. But like, we didn't we didn't address anything. Nothing got addressed, right? Like we didn't go improve the process. So I think that we often use how as a crutch if instead um and I I'm I'm kind of explaining how was sorry I'm explaining how we use how as a crutch but then you might say well how does why work in this situation and I'm not saying that why is the solution to all of these.

I'm just saying that how can be used as a crutch in this example. Um I think so and there's I'm trying to give different examples. So trying to use the same thing and saying well look why if I lead with why it's just going to fix this not necessarily. Um, I think why is a lot more important for um situations where you want to have people that are um sort of engaged and doing like engineering work. Sometimes when it's more junior, sometimes they do need a little bit more specific guidance. Um, so that's okay. If we were to talk about these spectrums again, I would say on the more junior side, a little bit more how is really important, but more structure in general is important. When you start going the other direction, okay, to more senior engineers, if you are stuck in this mode of like, well, giving more specific guidance to the juniors has been helpful that must translate for the the seniors.

It's that's where I think it's mostly counterproductive because now you have these senior engineers that are capable of having much more autonomy, dealing with ambiguity, doing analysis, coming up with conclusions. That's why they're senior. They've been doing this for a while. They know what's up. Now you start prescribing how to them, they're going like, "Well, what do you need me for?" Right? it it doesn't and often it doesn't seem like that obvious or that direct, but I think that that's the kind of thing that absolutely destroys engagement. But I do think this is something that often creeps up. I don't think that it's an obvious thing uh most of the time. And I think that's why this kind of thing can sort of sneak through, become a common practice, and then you end up with groups of people, teams of people or projects that are going on for a while where people are like, "Man, this project sucks.

I don't like working on this." Why don't you like working on it? Because you actually don't have any input. You've already been told how, right? like your fate is decided. Someone's already told you you got to this is this is the path you follow. Enjoy. I I often find that for engineers this I mean I speak for myself in in this as well like there's enjoyment in the problem solving and being creative and doing the analysis and being like these are the paths and like like that's why we do software engineering. I think for many of us, I can't speak for every single person, right? But I think that process is like that's intriguing, that's interesting, that's engaging. I have to get the data. I have to analyze it. I have to come up with the paths forward. I have to pick one now. I have to go implement it.

But if someone just cuts all of that out and they're like, "Here's how you got to go do it." Then what? So, how much time we got left here? Says 30 minutes, but I think we're actually uh through the bulk of it. This is just the normal normal drive. So, as long as this person in front of me starts going the speed limit in the fast lane, I think we'll be all right. But let me I want to shift gears a little bit because I'm talking about like um I feel like a lot of this focus has been like how to not do things for my my opinion and um I I might want to shift a little bit to like um suggestions I guess. So going back to this framing of like um of looking at like how much how you put in, how much why, and levels of experience, right?

I think that one of the things that I've mentioned a handful of times now in these vlogs is like situational leadership. And I think that this is a good example of where it really comes into play. Okay. So, if you have a cookie cutter approach, I'm about to do another like don't do this kind of thing, but I want to kind of frame it this way. If you have a cookie cutter approach, right, and after everything I've said so far, I've been kind of suggesting like it's going to look different for different levels, right? More junior people need a little bit more how to clear up uh clear up the ambiguity, right? They need a little bit more guidance. More senior people need a lot less how and a lot more why so that you can give them the framework to work within the reasons the goals and then let them have the creative autonomy to go solve these problems.

If you take a cookie cutter approach and we go to either end of the spectrum, if you're like, "Look, I'm telling everyone how those people that are more senior, they're going to be disengaged more often than not because you've taken away a lot of the thing that they should be responsible for." It might work really well for the more junior people cuz they're like, "Great, I have a lot of structure." That's what they need. If you go the opposite direction and you're saying, "Okay, you know, I have a a project and there's a mix of uh levels and stuff and here's just why we're doing this. This is, you know, super important work." The latency, the customer user experience example I gave earlier. The more senior people might say, "Great. Okay, like we have to go collect this data. We have to go do this analysis.

We have to go see like what options we have. Um, then we're going to go explore them. We're going to weigh out the path we should take and then figure that out. Then we'll come up with a proposal for how we implement it and again like how much time do we have like which design are we going to pick based on that future proofing testability blah blah blah all these things that the senior engineers are just used to doing you've now given them autonomy to go do the things they need to do. The more junior people might be like what the hell am I supposed to do here? You just said latency bad, customer experience good. What do right? Like what? I don't know where to start because it's too ambiguous for some people, right? I'm not trying to say that junior engineers are stupid or something like that, but depending on how the information is delivered, if it's too ambiguous, they're like, I just don't know where to start.

There's too much surface area. So you might have a problem the other way for the more junior people where they're like, "Hey man, I feel lost on this project." And I wouldn't blame them. So this is why sit situational leadership is really important because if you're looking at who's involved in the project, oh man, I got to move over a bunch of lanes here and this is going to be gnarly. Does this make any sense? It's telling me Google Maps is saying like your exit's right here. And I'm like, I know it's not. It's just talking about the next exit. And then even the map shows that I need to go to the one after which is where I need to go. So I don't understand. So it's telling me exit right here. You can't see the road obviously or my map but it's saying exit right here.

It's not my exit. But even the map itself is like ah keep driving straight. So which one? Google. Um, oh, Google Google picked up on something. They're doing a ton of construction on this road. Okay, let me let me apologize. They're doing construction on this road on this highway and they've literally split the highway. So, Google's not saying to exit, it's saying go on this other part because of the highway split. Okay, I stand corrected. I was picking on Google. Okay, police. Um, so situational leadership in a situation like this, if you have a mix of skill levels and experience on a project, what's going on, man? Cops pulling over a Tesla, but they're stopping all of the traffic to do it. Thankfully, I passed up. Um, we want to make sure that we can for the more senior people, make sure that the why is established.

Make sure that they understand the significance, the importance, and in my opinion, move the hell out of their way for the most part, right? Make everyone can get blocked. Everyone can get stuck. Unblock them, but like don't tell them how unless they're asking for help. Even then, I would still try to give them guidance so they can come up with the how, right? But the more junior people situationally, you need to give them a little bit more. Help them set more specific milestones. Help them figure out like how they might go do it because to them it might be far too ambiguous. Where do I start? Right? So, you need to go work individually with these people. Now, I'm not saying projects can't be successful if you don't do this, right? You will have some juniors that are just like they can deal with all kinds of ambiguity.

They're very motivated, very engaged. They're going to be, you know, they're reaching out for help. They're like they're proactive, all this stuff. So, absolutely can happen. Um, all the things I'm saying about more senior engineers, you might say, "Well, that doesn't work. I got senior engineers that I work with that absolutely need to be told how. I get it. Even more reason why situational leadership is really important because those individuals don't fit what I might say is the norm. Not that that's good or bad, just saying not the typical case that I find. Situational leadership will always be helpful. So my guidance here is not this is the only way it works. I'm just saying that if you're not thinking about these things and then you're frustrated why people aren't engaged on projects or why people are missing timelines or like whatever else like I

think these are contributing factors and a lot of the time I find that uh people leading things when projects feel like they're shitty to work on as someone who is more senior I find they get like the motivation drops s when someone is telling me how. If it's a completely new area for me and you're trying to help out, I appreciate it. Thank you. Right? I don't know. I deal with ambiguity all the time. But if it's really ambiguous, hey, if you want to give me a little pointer, thank you. But if you're getting to the point where you're just telling me like step by step what to do, I don't know, man. Like, I don't think you need a a principle for that. It just doesn't feel like a good use of my time. Not that it can't be done, not that I won't do it.

It's just probably not going to be engaging if I don't have to use any thought process. The same thing for I think for senior software engineers, right? The same thing for people that feel very competent in an area. If you tell them how to do it, probably not going to be a ton of engagement there. So, I think that's the the gist of it before I start repeating myself. So, um I hope that makes sense. I hope it's helpful. Everyone has different leadership styles, right? So, all the situational leadership stuff I was talking about how you help individuals, the leaders have different styles. And if you're new to leading projects and stuff, you might not even know what your style is yet. And that's okay, right? Like this is the kind of stuff that you figure out over time. It's not going to be perfect the first time through.

I've been an engineering manager for almost 13 years now. I I'm not doing anything perfect. Zero things I do are perfect. Right? That's why I tried to give you an example earlier of like um I I don't like micromanaging. But that does mean that I will have more junior people that need more help, that need a little bit more how because that's what they need. They need more structure. It's okay. I just don't default to that because I know from my experience being told how like too much how is like it's going to ruin my my interest. So, hope that makes sense. Um be curious to hear your thoughts on it. You know, do you feel an engagement change like based on your experience level? If you're a junior, intermediate, senior, principal, staff, whatever based on your experience level, how much like autonomy do you expect in the decision-m process versus how helpful is it when someone's telling you more how?

I would be very interested to hear. Um, you know, if you have a completely different perspective on what I'm saying, awesome. Share it. It's the whole point of the comments, right? We can talk about this stuff. And uh, I will remind folks again. Leave comments if you want questions answered. Happy to try and answer software engineering career related questions. I didn't mention earlier, but the uh my main channel, Dev Leader, is where I do my live streams every Monday at 7:00 p.m. Pacific. And I often take a code commute topic. Could be something like this. Um, right. I I basically look at the the video that had the most engagement. Uh, whether that's views or comments, whatever. If it's if there's a, you know, a tie, then I kind of just pick one of the videos and do my own tiebreaker. And uh I will write a newsletter article on it generally.

So that will go out on Saturday mornings. So my newsletter is just called Devleer Weekly. It's at weekly.devleer.ca. Yes, CA because I am Canadian. And uh at the time, how many years ago now? In 2013 when I first registered the domain, devleader.com was taken and someone's literally squatting it right now almost. They're doing more than squatting. They have devleader.com and then it's like a newsletter registration. There's nothing else there. So, I think someone's like trying to sabotage me or some Um, and I bet you if I try to ask them to buy that domain, they'll be like, "Give me a million dollars." And I'm like, "Dude, I'm literally losing money making YouTube videos." So, you keep it, man. I'll keep the CA. Uh, yeah. So, weekly.deleer.ca. It's a email newsletter. You don't have to sign up for the email.

If you just want to see what the topics are, just check it out on a Saturday, Sunday or Monday and then you can see if you want to join the live stream and talk through whatever the topic is. Um there's a lot of pe it's cool. I I love it. There's a lot of people that come from Code Commute to the live streams. There's a lot of people that are um repeat on the live streams which is great. Um, so love seeing folks from Code Commute come over because I I know that these videos like obviously I'm just talking to a camera. I get it. Uh, but there's comments and stuff that come in after. So I feel like I do get to talk with you guys directly, but then the live stream happens and it's actually like there's the chat, right? So I am interacting with you guys individually and I really enjoy it.

It's fun for me and I'm hoping that it's helpful. So um the other thing I'll mention too is um there's you know my videos are just my my perspective. I try to share some other viewpoints but a lot of smart people in the comments right they're sharing their perspectives they're offering their insights and on the live stream the folks that can make it and they're joining in the chat you get the same thing right you get those other like smart people with different perspectives jumping into the chat. So, um, you know, I thank you all for for participating. Uh, and even if you don't want to jump into the chat, like thanks for thanks for coming to hang out on the live stream. So, that's just at the the Dev Leader YouTube channel. I think um usually it's Friday nights pretty late. I post up the um the live stream link.

It gets scheduled. I think you should be able to see it on the YouTube page. But anyway, the link to it is um it's just at the newsletter site. So, weekly.devleer.ca. So, that's it. I'm at the office. I think we did okay for time. 40 minutes, just over roughly what it took me yesterday. Um I got one more drive into the office this week. It's every day this week. It's a lot of driving. If I could avoid traffic, it like honestly wouldn't be bad, but the traffic is just stupid. We don't like it. But it's cool. I have uh I've mentioned in some of the other videos this week that I've had have employees that are from out of uh the country traveling in. So, it's really awesome to spend some time with them. Um I have a team event today. had a couple of small team events this week.

Like we did lunch yesterday which is awesome. Who doesn't like lunch? It was a ironically like pizza party. Um but like we just wanted to make sure that we could have lunch together. So kind of nice. We had pizza and then we're doing a team event today and then I think people are heading out on the weekend. So thanks so much for being here. I'll see you next time. Take care.