Planning in Software Engineering - Principal Engineering Manager AMA

All right, we'll get things started here in just a sec. Make sure the the bites are flowing through the stream. There we go. And I got to connect the LinkedIn. What happened? What happened? I didn't pick the event. Oh no, man. It won't it won't go. [laughter] Come on. It won't pick my my LinkedIn event. That's super annoying. I don't even know how to to change that now that we're streaming already. Well, that's annoying and embarrassing. How does this happen? I do this every week and it's not it's just not going. Your event is streaming now. Please edit directly on LinkedIn. No, that's not not what I want. [clears throat] And I feel like I just nuked my stream because it browsed away. Oh my goodness. This is arguably the worst start. Are folks here on the chat like, is this even working right now? I don't know what the heck happened here. Oh, it it Man, it made a new event. This is so dumb. Who made this, man? Who made this software? Let's Yeah. Well, the good news, Devin, is I think that thanks to the feedback from last time, I actually got the delay on the on the YouTube comments and stuff fixed. So, it should be a little faster. But, oh, I I made this event on LinkedIn and now it's like streaming to a different event. This is so dumb. It made like three events. I don't I just need one sec, folks. I'm so sorry. Oh, okay. So, I I can apparently edit the title of this one. So, planning in software engineering. We'll save that. My god, they don't make they don't make this easy. And I don't know. I got to edit this other one. Apparently, it started streaming. Well, that's what I get. Please go here. Okay, we're almost there. We're almost there. Of course, that would happen. Okay, let's get back on track. So, welcome. [laughter] Hopefully, no more crazy live stream starts like this. Um, if you're new to the live streams, generally how this works is it's like an AMA format. So, you're welcome to jump in, ask questions about software engineering, career advice, that kind of stuff. Happy to try my best and answer these live streams. Usually have a topic that comes from my newsletter, which is then uh coming from another YouTube channel I have called Code Commute. And so I use code commute to be able to uh talk through questions that people submit or I go to Reddit and go to experienced devs and try finding interesting software engineering topics to chat through. And generally like I said they're focused on career development, that kind of stuff. So um usually we use these streams for that. So if you have not seen before um and you're interested the thing that I'm talking about I just put in the chat. It's weekly.devleer.ca. CA. Uh, you do not have to go subscribe to the email newsletter. You can kind of treat it like a blog because if you want to join in next time and you're interested to see what the topic is, generally speaking, that's where you'd find out what it's going to be. So, this one is on planning. And I wanted to talk about planning on code commute because um it's a topic that comes up a lot in software engineering. And this is one of those things that I find everyone has their own opinion on it and much like everything we see on social media and stuff like that when you ask different groups of people you will have different people that seem to be you know experts on it and what happens a lot of the time hello on Instagram what happens a lot of the time is that you'll have someone who says you know I've been in software engineering space for x number of years and you're looking at them you believe that they're successful about it and they'll tell you here's how we do planning here's why and you know looks good right and then you'll hear from someone else who's also you know been successful in software engineering in their career and here's how we do planning and it's completely different and this kind of thing happens uh not only in software engineering and with planning but like with anything and the the thing that's kind of tricky is that as individuals that are trying to learn from others, right? Especially with things on the internet, social media, we often look up to people. We're trying to take this information and and then we have conflicting opinions that we come across, right? And like that's why I said this is not unique to like specifically planning and software engineering, but we'll see this kind of thing happen all of the time. So, when you have two people that you believe are um you know experts or have experience that you'd like to model and learn from, you have two people at least that have conflicting viewpoints. Does it mean that they're both right? Are they both wrong? Like how do you figure out like what to listen to? And so I wanted to talk about planning because I think it's one of those things. So I wrote my most recent newsletter article on this. I talked about it on Code Commute. Let me just say I should probably put the code commute link right in the chat so folks want it from the start they have it. So um it will be in the chat. You can go to um just search code commute on YouTube if you're interested you can see it. And so that's what this conversation is about. And from my point of view I will be sharing like what things look like for me working at a startup what they look like in big tech. Uh and for context I spent time in both. you know, I've been at Microsoft now for five and a half years. And before that was at a startup that grew into like a, you know, mid-size company for for eight years. So, these are just my perspectives on these things. But that's why I like this kind of stuff because it's a live stream. There's a chat. If you're open to it, please, you know, leave your thoughts and comments and stuff in the chat. We can get different perspectives going back and forth. My goal is not to to tell you like this is the one way or the only way. It's actually the opposite. It's to show you different perspectives on these things. But unfortunately, given that I am one person, I will have my own bias. And so it makes it kind of tricky because we have to try looking at it from different angles. Okay. So there's going to be a couple of meta points that I'm going to come back to as we talk through this. Um, and I just see a question. Give me one sec for Instagram. I just want to introduce this kind of uh this concept that uh when we talk about planning and I'm going to talk about it from the perspective of working in a startup and in big tech. I'm going to try to call out the differences and similarities. But I want to get us to abstract some like meta concepts as we go through this. Like why do we plan? What is the point of it? Okay. So, I'll be trying to share that because even when we see that there's differences in practice, there's like things we're trying to accomplish with planning and benefits that we get in both cases. Um, okay. So, the question on on Instagram is uh my brother, he's working in sales. He suggests is it good or not for future for cold calling? Um, yeah, honestly, I'm probably the wrong person to ask about that. I am extremely uh ineffective at cold calling. Um I think that from what I'm seeing at least as a being on the other side of it when I have people messaging me and they're using AI automation to reach out and stuff like uh I immediately block [laughter] I immediately block and depending on the account sometimes block and report um just because I don't want to deal with it. So I do think that uh you know if you want to be effective at sales yeah there's going to be a volume game you have to play which is why people try to automate it with AI but I think that there is a um I think we're going to see this a lot personally that you know the the human element will start standing out more uh and people will appreciate more human element as we go forward uh and perhaps not perhaps AI generated things will be so seemingly human that we won't even notice But um yeah, I don't know. I think if you're if you want to go down the sales path, I think there's absolutely, you know, a future in sales for people. I'm the wrong person to ask about that though, unfortunately. So I I would say if you're interested in it, pursue it. Okay. So when I worked at a startup um especially in the very very beginning there like it's almost like planning didn't really exist and we kind of started with zero of like everything actually. So like we didn't um from the perspective of building software like we didn't have a build system. We didn't have you know tests in our code. We didn't have um I don't know like we didn't have planning. We didn't we just didn't have things right. It was like we were getting hired on and we were working in a code base that was uh written by one person that was when I started which was right near the beginning they had just used an automated tool to migrate from one language to the another. So uh from VB over to to C. And so we're we're literally starting with nothing. And so what it felt like in the very beginning was you I don't know maybe some people have or have not heard the analogy like drinking from a fire hose, right? Which is it's like overwhelming obviously. So that's what it felt like. So every day was like we're just trying to to ship value to customers is like probably the easiest way I can summarize that. So it was quite chaotic because it would be like um you know the CTO was very much um what's a good way to explain this sort of like he was the expert user right he started by building this tool that we were you know uh now onboarding to to help build him with uh build with him sorry uh he built this out of necessity and so he was an expert user in this case and he had from word of mouth like people that were using it and could give him feedback. So, we were constantly like what's the next thing to go build? Like he's here's the list, right? There's always something. And because we don't have these other things in place like you know tests and CI/CD, it was like we're we're breaking stuff almost as fast as we're adding stuff. So, it's just non-stop like, you know, feature feature feature. Oh, wait. bug fix, bug fix, bug fix, and feature feature, feature, pivot, pivot, pivot non-stop, right? And it's a I feel like it's a good problem to have when you have customers. If you don't have any customers and you're like, oh, we just got to keep building stuff, it's like, are you building the right things, the wrong things? Given that we had customers and we had a CTO that was really like an expert user, we had a really good uh inclination of the things that we needed to go build. It was like um at least when I think back on this most things that we would go build would probably be adding lots of value. Was it always going to be did we always select the highest value thing? Maybe not, but all of them would have value. Um Baron Bites, good to see you. I know that expression I feel like that uh that on my pivoting to tech back internship being signed to create an API for the first time. Yeah. Um just like you know that that expression drinking from the fire hose and just about uh getting uh you know overwhelming amounts of information. There's one more uh question here in the chat um on Instagram which is not the same common chat. So sorry folks you can't see it but um that question says what one advice would you give for a developer with six years of experience but still not promoted to senior he wants to be a dev uh lead tech lead. Give me one second I'll come back to this question because I just want to wrap up this thought about uh this perspective of drinking from the fire hose and and having no planning. So early on at a startup, it was really just like there's so much to do and um and we were kind of being fed like here's the next thing, here's the next thing. Um and it's like an unlimited supply of just like go do this next. And in those early days, it's I don't I don't know exactly when it started to happen, but I think we started to notice pretty early on like we're just not organized. [laughter] And so out of necessity, you start to feel things like, wait a second, um you know, if we want to keep moving at this pace, we are breaking a lot of stuff as we're going. So like, okay, how do we stop breaking things as much? is no one wants to be in that situation where you're like, "Oops, like my thing is the thing that broke it. Now we're staying up late fixing it." Like, how do we make these things better? And that means we have to start compromising, right? We have to start going, "Wait, wait, wait, wait. Maybe we can't move as fast on this because we have to start thinking about how we write tests or we have to spend some time building um a a build system, right? So all of a sudden now we have these different competing priorities and we have to start balancing. So it was really cool to be in this uh this sort of position where we're so early where we have to start introducing these things to to have different competing priorities. Okay. So I'm going to come I'm going to pause on that and go over back to the chat on Instagram. So what one advice would you give for a developer with six years of experience but still not promoted to senior? Um this is probably something that on code commute I would talk about a whole lot and so um usually in this kind of situation I would like it's really difficult to answer without knowing the sort of the working relationship that this person has with their manager. Okay. Because uh without knowing anything about this person the only thing I know is that they have six years of experience. Um, so what like what has the feedback been? What areas have has their manager told them to focus on? Have they not had that conversation? Have they had different managers uh repeatedly and they're not really getting traction with building up sort of like demonstrating what areas that uh they've been effective in? Have they demonstrated impact consistently? Do they have soft skill challenges? Right? without knowing more. The only thing that I could say very generally is like going from midlevel towards senior and then wanting to to kind of be a dev lead or tech lead. When you are going for senior uh at least from my perspective, a few different things are happening. One is that you are demonstrating more impact. Um you are uh working through more ambiguous sets of problems. And sorry there's one more piece of context here. A lot of senior developers are there and his impact is not visible mostly. Okay. Uh no uh it says viable but I think it means visible. Yeah visible. There we go. Um so impact right needs to be greater and greater. Um uh dealing with ambiguity right. So, just to give you an example, as a more junior or uh you know, just above junior into mid-level level developer, when you're very junior, a lot of the things that you're being assigned are very much like um for the most part, and I'm generalizing, of course, they're they're more understood. There's less ambiguity because people are assigning you that work with a more clear understanding so that you can make progress on it, so that you can be effective, you can build momentum. But most software engineering tasks that we have to work on, there is ambiguity, right? That's where the software engineering part comes in. The engineering part specifically where we go, cool, there's a challenge. We have to come up with the solution and there's going to be multiple different variations to a good solution. How do we weigh the pros and cons? How do we figure out like the direction we need to be going here? How do we really understand this problem? There's ambiguity. So kind of navigate that kind of stuff. what was mentioned in the chat and I think is important is like when we talk about impact the visibility of that I've had I've struggled with this a lot myself because um when I was working at a startup before I always felt like I can work on things and because of the nature of the size of the company and the team setup and stuff it's like the visibility is just there like you just know what people are working on and like the features landing and stuff so it was never really a concern but at a larger company. I remember hearing like oh visibility visibility and I'm going look if I'm doing what my manager and my skip level manager say then like like where like why is visibility a problem and one of the challenges is that um based on what you are doing one yes you want to be aligned with your manager but as you're becoming more senior you do want to be finding those opportunities that are the impact must be great enough that other people can start to observe Because as you become more and more senior, your manager is going to be the minimum that needs to speak up to put you up for promotion, but it's not the the only thing that matters, right? If your manager doesn't support your promotion, it's not going to happen, but they need to support it. Plus, maybe your skip level manager has to also chime in. Uh depending on your level and your organization, maybe they actually need feedback from other people, right? So if other people can participate in that feedback and they don't have visibility into your work, then perhaps the amount of impact that work is having is not visible. That's not always your fault. That can be that uh maybe um how the organization or the team is set up. It could be that you're not getting assistance from your manager to be able to make that more visible. Um, so there's a lot of different things, but at a minimum without knowing more details here, I would say um if if you're feeling like it's potentially an impact or visibility challenge, like talk with your manager about where they perceive the gaps. And when I think about this as a manager working with employees, if I had someone come to me and say, "Hey, I think I'm ready for promotion, like what's up? Like how do we like where where am I at on this? Like how do we move forward?" Um, one of the one of the things for framing is like I I want to be able to promote people of course, right? But that means that I need to have evidence of them operating at that next level. So I would have to go through this process with every individual that I manage and kind of say cool like where are the growth opportunities? um if I'm not seeing uh enough sort of demonstrated in one area, how can I work with them to make sure that I have evidence for that? And that way when I put their whole promotion case together, it's like there's just enough evidence demonstrated consistently across these different areas that are expected. Let's say in this case as a senior. So I will always go back to what what have you and your manager talked about for those opportunities. If visibility is one of those areas, cool. what what have you guys been working on to go address that and make a plan for it? Okay, so that's always going to be my go-to is go talk like it sounds so like I don't know generic but like go talk to your manager and if that conversation is not happening and you're not getting clear details that's a whole other followup. So, um, if you have more specifics that you want to share on that, if you go to and you want to keep it private, go to codecommute.com. You can submit a question totally anonymously there and then I can make a dedicated video response for you. [snorts] Hope that helps. Um, okay. So from the perspective of planning at a startup and how this evolved is like yeah all of a sudden we're we're seeing like okay there are these pain points or like the teams are growing and you start to to notice like yeah it's going to continue to be chaotic but we have to start reducing the amount of chaos so that we can continue to be effective. And this it comes up in so many ways, right? Because now teams are growing, the the product and service, the platform itself is growing. And so it's like, okay, well, we could go work on this, we could go work on that, or there's now there's a whole second team and they need this and they need that. And um the complexity of what's going on is greater and greater. So when things are moving in so many directions, you have to start slowing down a little bit to align. Okay? And it's I feel like if you're not slowing down to get that alignment, then um you you really start to feel it because it starts to feel like you're grinding to a halt. Um and yeah, Deon said, "Make sure the code commute question has some detail." Yeah, because if you submit a question on code commute and it's like, "Hi, I need help." I'm like, "Uh, you're going to get a generic response. I will make it for you and I I will try my best, but the more detail you provide, the better." Deon knows. [laughter] Thanks, Devin. and LinkedIn user. I can't see who the person is in the chat. Who are you? Um, and my LinkedIn event's all screwed up. So, I'm so sorry, but your your name's not coming through. Thanks for being here from LinkedIn. Um, so out of necessity in a startup, we kind of start introducing some some process, right? And like one of those things I can remember we were like we had this whiteboard and it was like we're going to start doing post-it notes like user stories, right? Like we we wanted to try adopting things like agile and we're super scrappy. We're not like it's not like we hired an well at some point we did hire an agile coach to like talk with us but it's not like we had you know agile experts in house like we don't know what we're doing [laughter] which is what made it crazy and fun and chaotic but um we're not experts on it we don't know we're trying our best and so what was cool about it was like we would look at things that we could take from agile like what are people doing there right okay well user stories why do we need user stories. Okay, so at least we can minimally track things. We can talk about priorities. We started to say, "Cool, like maybe we should do something like sprints, right?" Like if we can start time boxing some things and saying, "Here's what we're going to commit to." At least we're taking the opportunity to try aligning and like over how long of a period? I don't know. We tried one week, we tried two weeks. Two weeks seem to be pretty good. So okay at least for the next two weeks what we would like to do is have some kind of agreement that if we are going to start here and end here in the twoe period that we should have alignment on what those things are and I think we we stumbled a lot with this because naively thinking like okay well this is what people do they put these sprints in place and that's going to protect us from from having these typ of problems. And inevitably what would happen is like you'd get to the end of a sprint and you'd be like, "Okay, well, we we didn't do all the things we said. Okay, well everything we're doing must be broken then because like the sprint has to be perfect and how do we go make this work?" So in hindsight it was kind of funny that like you know we were saying okay well if if there's supposed to be this perfect process that solves this problem like we need to do things to adhere to the the process so that it it like that's the only way it's going to fix it. But really what was happening was that given the nature of where we were at as a company and as software engineering teams, there were literally going to be things that we needed to pivot on within a given sprint. I know a twoe time window is not that long, right? But when you're drinking out of a fire hose, a twoe time period is still a long time. But what this showed us is that we started to have some tools to actually have discussions around and this is going to be one of those meta points that you'll see coming up in the rest of this conversation which is like the the idea of the sprint for me at least when I reflect on this wasn't so much of like a you have this mechanism that that guards things um and it will be perfect if you follow the sprint. It was like you have checkpoints. You have alignment checkpoints and conversations that can come up because what started to happen and I've talked about this so many times on code commute and I will continue to talk about um you know some of these things uh from my startup days but um the the founder and the CTO we had uh was amazing. Um you know I still absolutely respect this person tremendously. Um, and so when I when I talk about things this way, they're not meant to be negative. It's just a reflection of like how things were. And I can remember he would come to the team and say, "Hey, like you know, we got to we got to do this thing. Like this is this is coming up. I think it's the most important thing we need to do right now." And again, like I was saying, we we trust him a lot, right? He is the expert user. He is I mean he's the the founder and the CTO of the company as well but he he has a really good understanding of like really what needs to happen. And so in the very beginning it used to be we'll drop everything and just do what he says. And then over time what would happen especially as we started to put some of these these processes and systems in place was like we had tools to have better conversations. So he would say, "Hey, we have to we got to drop what we're doing and go do this or or hey, like I need someone to go do this." Right? That was usually the the framing like is is someone able to and instead of instead of being like in the beginning like oh man like it sucks because that's going to you know that's going to break the process or like we have this thing we have to be strict to adhere to. Instead of doing that, it started to shift to like, hey, look, no problem. Totally get that like that you've identified a new priority and I'm not going to sit here and tell you that like this thing or this other thing is is clearly more important. Like I'm happy to have this conversation with you and and truly trust what you have to say about it, but that means that we only have so much capacity as humans, right? like we can't just make more time out of nothing. And if we've already committed to a certain set of things and many of these things are things you've asked for or other people have asked for that you've kind of aligned to, we need to start trading something. So those conversations started to shift towards cool. You want to bring in thing A now feature A, fix A, whatever it is. Thing A comes in. You may not know this, but we're also working on thing B, thing C, and thing D. And now that I'm putting this in front of you, I can tell you the status of those other things. I can tell you some background if you're not familiar with what some of those things are, like so we can align on the language and and talk about what those things are. Now that you know that, would you like to trade out any of those things? Because if we need to pivot, if we need to, it's got to be one of those things, right? Like that is what we're working on. So unless you can, you know, snap your fingers and bring new engineers on that are ramped up to work on this stuff, someone has to to figure it out. And it it was a really good tool for us because either he could say, "Yeah, like I actually I actually do think this new thing is more important than than one of those." And I get that it's a pain in the butt to randomize people and to shift priorities, but like um if that's something that we can that we can navigate, then I think that this is the the most high priority and we should stop what we're doing to do it. In other cases, and it would happen more often this way in later days, what would happen is that like, okay, I have this, you know, this huge priority. It's got to happen. It's got to happen. And we'd say, here's all these things. And it became the more common thing to say, oh, okay, I actually I do think that all of those things you're currently doing are the priority. So, can we make sure that this is next? Right? Let me not interrupt the current set of uh of work that's going on because we have all agreed that's important. I do understand that. Can we make this the next priority after that? And so it not a perfect system, but like I said, it gave us tools to start having those conversations. Um, I'd say that I don't know how how far along at this point now it was, but we over time, you know, we had like these these twoe sprints and over time we went to like some type of like almost like quarterly planning where we would talk about, you know, here's what we were thinking of doing over the next quarter. um kind of like le less um less specific like you know so and so is going to work on this so and so is going to work on that and more like a strategy kind of conversation like this is high level what we're going to think about doing. So we moved over to that. Uh we still had the sprints of course but um started to introduce this more like strategic kind of planning and um you know just to kind of share like that was way less tactical and way more strategic. And again, if you were to look at that over time, like I don't know what they do anymore cuz I haven't been there in a few years, but um I could imagine that sure maybe quarterly planning exists, but they probably have planning at an even larger uh time horizon. And if you're not familiar with this kind of concept, the larger the time horizon, the more uncertainty there is. Okay, so there's probably at least a handful of software engineers on the live stream right now. And if you're watching the recording of this and you're a software engineer, you will have experienced this. But um we're not the best at predicting things. [laughter] How long is that ticket going to take? Oh, it'll take me, you know, a couple hours. It'll take me a day. No, it's always a little bit longer. Uh we're notoriously bad at uh at predicting things. Someday will be better, but today is not that day. And when you start having a larger time scale, the your rate of prediction falls off uh rapidly, there's just so many more uncertain things and if you factor in what I was already saying with the pivots and the new priorities coming up, it's going to change your plan. Okay, so we kind of like we were learning this the hard way, right? You'd have these planning sessions, these discussions that would be over a larger time horizon and it was like, okay, cool. this is a better opportunity for us to go, you know, schedule all the work, but um it doesn't it doesn't work that way. Like you don't have the same degree of confidence in things getting done and you have to start remembering the next time you plan you're like, "Oh yeah, like every time we do this, you know, half of what we talk about is not going to make it in the plan." So how do we how do we start accommodating, you know, uh having the opportunity to pivot, right? So what we started to realize over time and at least I say we as in this is what I perceived that we were learning about ourselves was like we need to understand that we do a lot of pivoting and that that's not wrong. Uh in fact given that we had a lot of really good connection with end users and customers getting really good feedback coming in. I say good feedback as in clear feedback right if you're if you have a really good feedback loop to your users then being able to pivot and doing that uh you know uh quickly effectively is a huge huge huge asset. So, it's not that it's wrong to pivot. If you have a really good feedback loop, it can be tremendously helpful because you're not wasting time on the wrong things. You can bring in new priorities. So, I think over time, we learned that about ourselves that it wasn't so much about getting a perfect plan. It was about aligning on the direction we want to go, aligning on what things we value, and then having this shared understanding that we're going to need to pivot. Like accept that. Accept that your plan is not going to be perfect. Don't waste time trying to make it perfect because it won't be. In fact, spend more time thinking about how you will pivot because it's going to happen. So, we did that especially towards the latter half. And then I would say something else that we looked at, I'm not sure people are totally familiar with uh objectives and key results. They're called OKRs. But we um we started introducing this towards the last little bit that I was uh at Magnet Forensics. And I I like the concept of OKRs. I can see the I don't know from my perspective, the benefit. I can see also why they're a pain in the butt. But if you're not familiar, objectives and key results are a framework. You can go search objectives and key results. I actually put a link in the in the article. So, this is from Atlassian. I'll just drop it in the chat there. Um, objectives and key results allow you to set a highlevel objective. And then the key results are the things that go underneath that that are quantifiable goals that you're setting that help you achieve that objective. So, we're going to set some objective and then here are the things that if we move this metric from point A to point B that will um help accomplish that objective and you would set a few of those. And what was cool about objectives and key results in my opinion was that it did a couple things. One is it got us to align on what things we want to measure and what things are important that we're measuring. Uh that also highlighted a lot of the time being a startup like maybe we're not measuring enough. [laughter] We're doing a lot of things. We're not measuring a lot of things and like we should be building systems and uh processes that help us measure so that we can understand what's going on better. So highlighted a lot of gaps that way. But what what it didn't focus on, especially from like a a planning and strategy perspective, was the specific things that you needed to do, which might sound kind of confusing, but it meant that planning wasn't give me all of the spots in the code you're going to go touch and the specific features that you're going to go build. Um, and you know, like you're not so hyperfocused on implementation when you're planning. The planning is like we're aligning that we want to go improve these metrics, right? We're talking as a group on this from a strategy perspective. We feel that these are the the things that as a business we we're going to go move over the next uh 3 months, six months, whatever it is. We agree on that. Okay. Right. Now, you as the groups of engineers and product owners that are going to go deliver on these things, we're putting trust into you to go do that. During those planning sessions, we can talk about features and things like that that that could help contribute towards those things, especially because dependencies and stuff will come up, which is really helpful to talk through. But it shifted from being like what are we going to go specifically implement which may actually change over time to these are the goals that are measurable that we want to accomplish. So I did really like OKRs. The thing I didn't like about OKRs was that like any type of process you can get overly pedantic about it. So if you're following OKRs like they have there's a they're pretty prescriptive in like the naming and like the style of things and sometimes I just felt like are we wasting so much time on like it's it's like bike shedding in software engineer just wasting time on on these details that like don't really matter and we can just continue to try and get better over time at this. Um but overall I really like objectives and key results. home. Now, I'm going to shift gears and talk about um big tech because there's a lot of similarities and some differences. And so, working at Microsoft, this is my only big tech experience as Microsoft. Um, we also use objectives and key results, which is pretty cool. I can't speak for I realize as I'm saying this, I need to make it very clear. I'm not speaking for all of Microsoft. Microsoft is outrageously big. I work in the uh Office 365 side of Microsoft. So, it is a part of Microsoft. It's a big part, but it's it's still a part. And Devin's just saying in the chat, by the way, I think this is good to call out. Any pedantic system can also be gamed 100%. And this is why it became really tricky because with objectives and key results, um what you measure improves, okay? And so if you pick it's really and the more time you spend on this, the more you you really realize it's true, but if your metrics are not good, if they're not the right things, uh I'm not saying the quality of the metric, I'm saying the intention of the metric. Okay? Uh if the intention of the metric is not aligned, what ends up happening is that you have uh people that will that will optimize for it, but they will find ways to effectively to game it. Um, and it's kind of interesting because at the end of it you go, "Hey, like we set a target and we're like we actually achieved like 150% of the target and like amazing and it's like but did things actually improve the way we wanted and it's like well no they didn't but we we did so well on the target. So you you learn over time too like how to how to try and pick the right things to measure which is very interesting. it's uh it's challenging but yeah any pedantic system can also be gained okay so Microsoft we do use objectives and key results uh at least in the organization that I'm in and there's a little bit like I would say there's some flexibility there so I've switched teams I've been on two teams uh in office 365 and on both we talk about objectives and key results, but I would say on the team that I'm on now, it's a lot looser and that that works pretty well in my experience to not be like hyper like pedantic about it. But we do have a much longer uh planning uh cycle. So for us, we talk about things on a six-month period. So I was saying when I was at a startup you know we were doing quarterly so that's three months and now uh Microsoft six month period. So what did I say earlier right like the longer the time horizon the more uncertain the difference I would say is that a lot of the stuff that we're building given the scale and complexity that we're at um there's a lot less of this situation where it's like oh like customer just asked for this feature like we really want to prioritize it and like you know bring it in right now like yeah it it happens when we have partner teams because we're uh we're a platform at least the teams I've been on where partner teams are asking for things like yes that will that will continue to come up but the frequency that that happens compared to where I was at before is you know orders of magnitude different. So, um, we plan on a larger time scale and we also do have fewer things that are coming up to interrupt us to pivot at least from the perspective of other teams like, hey, we need this new feature out of nowhere. Okay, does still happen. It's just way way way less common. The thing that does come up more is the amount of because it's a live service and where I was working before was desktop software. Because it's a live service, there are there are more opportunities for live service type things to come up that you didn't plan for. Right? We always want things to go perfect, but it's a big complicated system. There are opportunities for things to not go right. And that could mean because of what our team is doing even though we're perfect or it could be what other teams are doing in having an impact on the things that we're trying to do. So there were certainly things that would interrupt but planning was on a much larger time scale. The other thing to mention too is that uh the rate at which we ship software. Okay, so I didn't explain this but at the startup we would ship software at once a month. Um, but that meant that ideally it took took a long time and only a couple of sub teams by the time I left could truly do this. But we we strived to make sure that any build that we had was something that you could ship. Okay. Not every team was able to to quite nail it, but that's what we strive for. And so it meant that technically even though if you're releasing once a month for desktop software, if you were if you were two weeks in and you had enough value, like there's no reason that someone couldn't cut a a build and you know post it on the website and ship it to customers. um at at Microsoft, at least in the space that I'm in, uh you know, we're we're constantly delivering things, but the the time to go deliver a feature across the entire fleet of capacity that we have takes a significant amount of time. And that's on purpose. It's not that the technologies not able to do it. It's uh it's purposefully not at light speed. And that's because if you go at light speed to everything across the planet all at once and there's a problem now you have a problem everywhere all at once. And if you recall over the past few months across uh unfortunately including Azure AWS Cloudflare did Google have something too I don't know. I feel like you know every single major [laughter] the cloud provider had some type of issue and when you look at the the post incident reviews of those things a lot of the time it's because they had uh call it their safe deployment practices they had changes propagate through the system much much much faster than intended and it was a broken change. Okay. So technology can move things faster. We purposefully go slower. And so if you factor in all those things I'm saying like being able to plan on a larger time horizon does check out it works reasonably well. Um we don't want to fall into the trap of not being able to to pivot. So, as an example, if planning's every six months, that doesn't mean that if a partner team came to me and said, "Nick, I know it's three months into our our current plans, but we have this urgent ask and it would be so helpful if your team could help with this. I'm not going to sit there and go, "Hey, yeah, too bad. Come back in three months and we'll talk about it." Like, no. Like, we we all work for the same place. And if that means that in the grand scheme of things, if there's something that is a higher priority that we can be a part of, we should at least have the conversation. It doesn't guarantee that we have to go pivot, drop everything we're doing because that can create a lot of chaos, right? If if I had to randomize my team every single time a request came in, that's going to mean that we have partners we're disappointing, right? There's teams that we said were going to go deliver on something and now we have to go randomly delay it. So the conversations need to happen. They should happen. And it's one of those things that if you don't try to have flexibility still, you end up missing out on things. So it's kind of interesting when I when I reflect on both of these scenarios, right? In both scenarios, they have different time horizons for planning, right? I'm going back to like really early at the startup, it was like every two weeks and then we were doing like our sprints plus like uh like quarterly planning. So on the the time horizon of like two weeks to uh to three months and where I work at Microsoft, it's six months. Sometimes uh because you're planning six months, you're like if it's not this six months, it's the next. So sometimes you're looking at the whole year. Um, we have dramatically different time scales, but in both of those, we need to make sure we have agility baked in, right? We need to be able to pivot. It's like a fundamental thing that comes up. We need to be able to do it, right? It doesn't mean you pivot for everything and it doesn't mean you pivot for nothing. Usually extremes are not helpful. Making sure that you have the ability to pivot and you can. So, don't can do so effectively I think is very important. So that's a commonality between both. I would say another thing that is tremendously valuable in both cases regardless of the time scale is communication and alignment. Right? So if you're talking about a twoe sprint, the communication and alignment between the people in that conversation is like everyone who's part of this, we're we're in agreement. This is what we're striving for, right? Because if you don't agree with it, this is why we're having this conversation to get on the same page. Like, do you think that there's another priority that we're not discussing? Are you not clear about what we're building or why we're building it? Are you not clear about what success looks like? Let's talk about it so we're all on the same page. You can also do that at the quarterly type of plan. You can also do that at a semester plan that's, you know, every six months. And those conversations in my opinion are some of the most important parts about planning. Not in my opinion way less about the specifics because we pivot and far more important to get alignment on what and why. Okay. So, if we're not aligning on those things and saying we want to at least go in this direction as a group, then what's going to happen is that inevitably when we do have to pivot on things and things come up now, we're I'm just making this up on a six-month plan, we're two months into it and there's some scenario that comes up and we're like, you know, some people are like, we really should pivot for this. If no one agrees on on the direction we were trying to go in the things that we value, if no one agrees, it's going to be super chaotic anytime something comes up. But if we mostly agree on the direction we're heading in the things that we value, then when something new does come up, we can have that conversation more effectively to say, "Look, like this thing uh you know, we have similar values on this. This thing aligns to that or doesn't, you know, um give you an example. We spent uh a period of time last calendar year really, really, really hyperfocused on resiliency. So everything was going to be around resiliency for our platform and so um if that um you know things were coming up that weren't tying into that then it wasn't a priority for us. If there were things that came up and someone was like look this is going to help with resiliency we're like that's our theme right now like let's talk about it. Okay. So being aligned on things uh maybe not always the the specifics but the values and the direction I think is super important and planning helps with that. And the thing the final thing that I'll say um on this is that I I think that when it comes to planning conversations that regardless of your two week, quarterly, six month semester planning, uh it can be very easy for people to hyperfocus on details and try to like spend too much time making things perfect. But the reality is nothing is ever perfect. And if you are spending time trying to perfect a plan at any one of those time horizons, the value of that starts to diminish uh rapidly. Right? So I will come back to saying you your plans have to have uh you know the ability for your team to adapt. If your plan, if the only way your plan can succeed is if everything is perfect, then your plan I can basically guarantee will fail. Cool. Hope that helps. That's mostly what the topic is. So, I know we got a few minutes left. There's another question that just came in on on YouTube. Uh, hi. Any advice to someone joining Microsoft as a new grad? I just bought your course off Dome Train. Awesome. Well, thank you so much. I appreciate that. Um I hope that you find it valuable and if you have any questions obviously just reach out to me. Uh LinkedIn is usually the best if uh if you send me a message there. My uh profile should be open so feel free. Um any advice to someone joining Microsoft as a new grad? So uh the thing that I tell everyone is like the number one spot to look is the careers page for Microsoft because I will have people that will message me and they're like hey like you know give me the scoop. And I'm like this like literally the scoop is the careers page. It is the thing that everyone has to use. Um there are a couple of different internal movement programs that are like sort of um like experimental I suppose but historically the number one and only way to to move around is like is the careers page. So if a manager has a job posting on the careers page you go through that. when I joined Microsoft careers page when I transferred between teams internally over the past few years when I did that it was use the careers page. So uh number one is use the careers page to go look for those opportunities. Uh number two is uh this says joining Microsoft as a new grad. So um what I would recommend here is like try to see the job openings that you're interested in. look at the job description itself and see which things are on there and compare them to your skill sets, compare them to what's on your resume, your experience, that kind of thing. And what I recommend you do is start looking at this of like a almost like a ven diagram, right? What are the things that that you can do, you're confident in, that you do well, that um that are being called out in that job description, where are the the gaps, right? And as you're moving forward pursuing this, I would say try to look at where the gaps are in terms of what those expectations are in the job role and try to create those opportunities while you are applying whether it's to Microsoft or other places. Okay, so just as an example, if you're if you're interested in a particular type of role and you're like, okay, when I look at those job openings, I'm seeing I'm just making this up, right? I see C development, I see ASP.NET net core. I see um some of these different uh I don't know like infrastructure type tools like you're going to be using Azure or something like that. If you're like, "Okay, cool. I've used C before and I I have AWS experience and uh or maybe you don't have any of those things, which is totally fine. At least you now have like a a list of things to to start working with, right? build side projects, explore those things because inevitably when you start working somewhere, because it will happen when you start, you're going to be using those things. So try getting a head start on learning them. Don't don't kind of wait for like how do I how do I get the job and then I'm going to go learn everything. You will be learning on the job, but you can also start creating that experience for yourself. So, one is do that sort of ven diagram of what's expected and what you got. I would do a few things from there. Build your side projects and your portfolio up. Make sure that your resume is capturing those types of things. Um, oh, sorry. The there's a little bit more context is why the context helps. Oh, sorry. I meant I will be joining. Uh, it'll be my first full-time job and scared about how I'll perform on the job. Okay, great. Thank you for the clarification. So, to wrap up the other thought, um, just so I can switch gears a little bit on this, um, get resume and portfolio. Make sure that you're trying to network with people. So, look for the recruiters that are part of that. Um, if you're seeing them post on LinkedIn and stuff like that, and then the other thing is I don't think it's a good strategy to just message random Microsoft employees and be like, "Here's my resume." Um, I do think that there's nothing wrong with being curious and asking questions to people. um because you can learn more about the role and and the the culture. So uh the reframing of this is I will be joining it will be my first full-time job and scared about performing on the job. Okay. Um so I would say that at least in my experience I have not been at Microsoft with uh early in career engineers where there was some expectation that they know everything. In fact it's quite the opposite where I've had people join uh say we use C and on the team I'm on now C++ there's also Rust. I've had people that join and don't know any of those. And it's not, well, you better be an expert by next week or else you're gone. The expectation is like, you know, we're we're a big company. We have the, you know, we have smart people and resources to make sure that you have an environment where you can learn these things. And that is sort of the expectation is you will be learning. So, uh, even the intern that I have right now, I I told him as an intern, like my goal for you as an intern is to learn and to have fun, right? I think that if you're doing both of those things and we have a project for you, you will be kept engaged. You will do awesome work, but we need to give you this environment where you can learn and feel supported. So, at least in my time at Microsoft, there has been a very supportive environment for for new uh like early career folks. So, I think just want to call that I recognize that it can be scary. Uh I would say some some ways to help with this. I would try not to isolate yourself. So, I don't know if you're going to be remote or not. Um if you are remote please do not fall into the trap of oh I don't want to message someone because I don't want them to be bothered. Uh people are very willing to help right so please don't be shy reach out ask questions um if you're you know in office I guess depending on where you're living and all that kind of stuff be a little bit more back to in office kind of thing going on. So, you know, try to try to uh communicate and work with the people and don't shy away and have this fear of like, oh no, if I ask questions, I'm going to look stupid or um you know, asking questions or not knowing things is a weakness. People know you're going to have questions. They expect you're going to have questions. Reach out, ask um and try to get yourself unblocked. There is a balance between asking uh questions and trying things on your own. So, uh, time box, right? So, try things on your own, but make sure that you're time boxing them so that you're not like, I'm just going to make up an example. I know I need to use Visual Studio, uh, and it I, you know, I tried for a week to install it on my own before I asked anyone for help. Like, nope. Like, make your time box more realistic, right? You installing Visual Studio, there's probably some things you can learn on your own and that's helpful. But if you're spending like more than a day trying to get Visual Studio installed or something like you're you're probably not bringing new helpful information to the team and someone could get you unblocked pretty quick. So um time box your sessions when you're uh troubleshooting ask questions. Um, I would say one of the things that I think is really helpful is understanding that it is a big company and depending on the space that you're working in, there might be many teams. Uh, just be considering your network early on. So try to learn about like what teams around you do, who are you going to be interacting with, like what what does this environment look like, right? Because those people are going to be the people you're working with. Right? The more people that you network with and you know and you know what their area does, you know where their expertise is, the more that's going to help you in terms of making progress on things, you can start uh certainly within your team, right? As a new person, I would absolutely lean into that. You know, understand what different people work on so you can go to the right expert for things like that. Uh and then I would also recommend that early on um just try working on that that relationship with your manager. Okay. So, um they might set you up with like an onboarding buddy, that kind of thing. That's great, right? They're literally someone set up to try helping you out, making sure that you're comfortable. Um but, you know, don't um don't shy away from the working relationship with your manager because inevitably what's going to happen is you're going to be wondering how your performances. Are you doing okay? And sometimes depending on your manager, like they might not be telling you directly, you might be looking for feedback at a different cadence that they're offering it. So have those conversations early, right? That way you don't find yourself being like, "Oh, I'm too afraid to ask or I don't know how to ask." It's like there there's someone that's there to support you, right? And you know how to have those conversations because you've been open from the beginning about it. So let me know if that helps. Um, I wish you success getting started. I realize it's uh it can be scary because it's a big place and uh you know maybe first time first time working at a big place. Uh you'll do great and um yeah send me a message on teams once you start say hi. [laughter] Be great to hear from you. And if you have other specific questions that you want answered in more detail on this, you can also write into codecommute.com and I'll make a make a video for you to help. Try my best at least. Okay, folks. I'm going to wrap up the stream there. I did my second overnight on call shift last night. So, I was up from from 6:00 p.m. till 6:00 a.m. this morning. So, I think I'm going to wrap it up and uh and head to bed. so I can catch up on some sleep and get a good start for the next day. So, I appreciate you all being here. Um, some things to share for over the week. So, um, yeah, if you like this, tune in next week, same time, same place, right? So, 700 p.m. Pacific, I try to do these streams. Um, if you thought this was fun and you're like, "Hey, I want to know what the next topic's going to be." Like I said at the beginning of this, if you go to weekly.devleer.ca, CA you can check it out. This is I'm just putting in the chat again. It's the newsletter that I was talking through around planning and if you want you can see similar topics and maybe have an idea even before I write the newsletter. If you go to code commute dot or code commute YouTube channel, I just posted the link in the chat to the um the video that was on code commute for this topic in particular. But um otherwise, I am behind on dev leader videos. I probably have a whole bunch of AI ones to put out because I've been doing a ton of stuff there. Uh I just didn't record this weekend. What else? Oh man, I've been writing. Got some technical blogs coming out. Thanks, Alex. I appreciate that. Alex says, "Code commute is great." Yes, got Alex on uh on Twitch. That's cool. That's cool. Um but yeah, you can check out CodeKit during the week. There's always stuff, but uh technical articles are going out. I have a lot more code examples. Um, what else to say about that? I have a bunch of articles that'll be going out that have uh have GitHub projects in them so you can follow along with them. There's going to be a lot of stuff on design patterns going out. Um, there's going to be Microsoft uh agent framework articles. There's semantic kernel. So, I didn't realize Microsoft agent framework was even coming out. It's like the I guess like the successor to semantic kernel. So, um you'll have a bunch of stuff on that. So, if you're reading those articles and you have questions like just send me a message. I'll make I got to make a bunch of YouTube videos on that stuff. There's a lot there. And thanks for thanks for joining on LinkedIn. And yeah, it's I posted the wrong started streaming to the wrong event. So, I apologize, but thanks for being here. And that's it, folks. Thanks so much. I'll see you next time.