How and Why We Do Planning in Software Engineering

Transcript is auto-generated and may contain errors.

Hey folks, we're going to talk about planning. Um, thought this would be a good one to go over. Says my drive is going to be like an hour, which I really hope isn't the case because I keep getting screwed like this. It's like after rush hour and it says it's going to be an hour, which is insane cuz like on a good day with no traffic, it's like 25 to 30 minutes. But as soon as anything's wrong on the highway, whole thing's screwed up. So I wanted to talk about planning for uh from a couple different angles and obviously on this channel is about software engineering and software development. So I'm talking about planning in regards to that and um I wanted to talk about like as the first part of this uh and this is you could probably apply to a lot of different concepts and stuff like that when you're trying to learn about them, get information online, get people's perspectives.

But when people talk about planning and software engineering, there's um obviously tons of different opinions. And I think one of the things that's kind of tricky is that you may be getting someone's opinion on a topic. Say something like planning and the context in which they are like sharing their perspective and experience like sometimes that gets left out and it's like it's no one's fault or anything, right? Someone's like, "This is my perspective on planning or pick a topic, right?" And they're talking about it. They're saying, "This is, you know, here's I do it this way. Here's why." Like all these reasons and for like depending if you're just trying to like learn about things or whatever, you might say, "Cool. Okay, that makes sense. I'm going to I'm going to go apply that or see how I can leverage that." We carry on. And then what happens is that we come across someone else who, you know, they're they're successful doing what they're doing.

And let's say we're talking about planning again. They're like, I've made a career blah blah blah and like I do planning this way in software engineering. And it's completely different than like the things that you were trying to like do and you know model from based on what someone else said. And like I said, I think the context is often missing. And it's like how can both of these people be right and be successful doing it if they're completely different worlds apart? Um, so I think a few different things are happening. One is that there's not just one right way to do things. Two is that context is often missing. And I think if you were to put two people down that uh sorry, put two people together and kind of write down the things like the the different uh constraints when they're talking about planning, the different environments they've worked in and the the things that they value and are trying to to model uh in planning.

And again, you can take this and apply this to different areas. I bet you you would see a significant amount of overlap, right? And the differences would come from the environments that they've worked in. So if they start prioritizing the the values in like what they're trying to optimize in planning in this example, they try to um the things that they're trying to optimize for are probably influenced by the environments that they've been in. So it's not that um you know someone who is working in like you know air quotes like more agile environments it's not that they probably see zero value in like upfront planning right but like how they approach planning or like you know design specs and stuff like that like this pre-work it's not pardon me it's not that there's no value to them it's just how much time and effort

they put into that activity probably looks different compared to someone who's worked in I don't know like government uh or you know building things like satellites and like infrastructure and stuff like that there the experiences probably just look very different and because of that what they're prioritizing looks different and that comes through in what they're communicating to you in the things that they want you know to to teach or share their perspective on. So, with that said, um I wanted to kind of get that out of the way because as we talk through this, I wanted to kind of reflect on some things uh in planning now that I've been at uh you know, in big tech for over 5 years and prior to that was uh at a startup that was like when I started there was like seven or eight people. By the time I left it was around 250 or so.

And uh you see things change even like in the startup times and um between these two worlds like yeah they're incredibly different um not just obviously from the planning perspective. I just was thinking about planning and figured we'd talk through it, but they're incredibly different, but there are still things that that make a lot of sense uh that are overlapping. What we value and prioritize the amount we value it shifts. Okay. So, um I wanted to kind of shift gears into into that part of the conversation. So, I got to talk a little bit more about u at least from my perspective like startup times. And what I maybe want you to keep in mind is that like I'm going to be talking about a startup that I worked at. Then I'll be talking about big tech. And so that would be Magnet Forensics and then Microsoft.

These are literally just two examples. I obviously can't represent all of startups and all of big tech uh accurately. And then of course there's everything in the middle, right? There's tons the majority is in the middle of that. So, I want you to be thinking about um you know, as I'm going through this kind of stuff, like different environments um maybe companies that uh aren't software first, right? Maybe they make other products and have other services and you're working in a software department at this company, right? That's not their main thing, but like you build the software that supports what they're building. could be all sorts of different environments. So, think about that as I kind of talk through some of my experiences here. That is not a left turn lane. Oh my goodness. Um, this person invented a third left turn lane and then came in front of me.

Um, uh, I think the word we generally use for that is stupid. Uh, another good one is reckless, but no one got hurt, so yay. Okay. So, while working at a startup, um, in the very very early days, I would say that planning wasn't like it almost didn't exist. It was sort of drinking from the fire hose of like uh customer requests coming in and uh like bug fixes, things like that. and the setup that we had uh we were very fortunate that we had a a techn well I'm going to say technical founder he was able to like he wrote the initial software he was a police officer and so technical founder in the sense that uh he he knew enough about software that we could talk to him about software things uh and he was also sort of like an expert user he was the user right so he built this out of necessity, was able to do it because he knew how to program.

Um, but like he was the user, so he built this for himself. And that was really powerful for a couple reasons. But the other sort of third part to that is that uh given when I started, he he had already gotten his business to a point where um through word of mouth, it was uh starting to grow. And I don't mean to say that like, you know, there's no sales or marketing effort involved like it was trivial. I don't mean that. I mean that there were people that could see what he was doing and going, "Oh, like that's interesting. Like I want to try that." Uh versus like trying to even discover like is anyone ever going to use this? He was already kind of proving that and there was some momentum there. So the the third part is really that we already had um like an engaged like small engaged customer base that was that was growing.

Okay. So I wanted to frame that when it came to planning it was kind of like like I said drinking from the fire hose. So everything was always the top priority right? So, okay, we're going to go build this new feature because a customer's asked for it. And then, you know, within the same day, it's like, oh, a customer reported a bug. So, like, drop everything you're doing. We got to go fix this bug. And then, uh, so you're fixing that and then you get that committed. And now you break something. So, like, we don't know about that until tomorrow. That's going to be tomorrow's next big surprise and next biggest priority. So there was so much chaos in the beginning and there was chaos throughout you know working at a startup even as it grew to like 250 or so people there's always chaos but we were able to start smoothing out the chaos over time.

Okay there was always situations where there was a new priority zero thing to go focus on. Uh we did a lot of work to try and minimize the randomization that way including and I've said this on other videos before uh including working with uh the CTO on this kind of stuff where you know he's extremely proud right of everything that that he's built that we've built and wants to like really cares about his customer base. So when there's something that gets escalated to him, he's like we like you know this is the most important thing and we'd have to kind of ground him and be like look we get it but like also here's all the other things and now that you're seeing uh you know a more complete picture do you still truly believe that is the most important thing?

over time there were fewer instances of him going, "Yeah, thank you like for letting me know and like and I still think this is the most important thing." That, you know, became less and less. Um, and the goal was not to to tell them to screw off or anything like that. Nothing like that. Uh, I don't work there anymore and I still think the world of this person, right, he like he came to my wedding um after I wasn't working there. So, you know, it was never about like screw off, let us do what we're doing. It was really just about trying to bring all of these high priority things to the forefront and say, look, this is what we're focused on. Do you need us to shift? If you do, we will shift. And a lot of the time as the company was growing, those uh those shifts would happen less frequently, at least at a large larger scale.

So when it came to planning early on in terms of like what are we going to do for an upcoming period, we didn't plan far out. It made no sense to plan far out because all that you knew was that you were doing the next high priority thing it was that was coming up and we had to keep shifting towards like how do we look a little bit further? How do we look a little bit further? Right? So we go from like complete chaos into okay we're going to talk about sprints right for us we introduced sprints we played with different things most settled on like as a consistency thing around like a twoe sprint how we did that looked different over time especially as teams and stuff grew and changed but um generally like a two week sprint and so we got into the

habit of like let's plan for the next two weeks let's plan for that and that was growing pains right um even to plan for two weeks out early on it was like dude like you know that even two weeks out we're going to be doing different so like why are we bothering but we built the habit of trying to go a little bit further out and a little bit further out and then we would get I think by the time I left we were still only doing like quarterly planning I think uh maybe at like a more strategic level um so at I don't even know like maybe at the VP level. Uh I'm assuming they would get brought in especially by the end cuz there was more people in those types of leadership positions like at the sea suite.

I think they were they probably had you know 6 plus month to to one year and then and probably some vision beyond like you know 5year kind of vision but that kind of stuff uh I think looking further out than a year at least my level invol of involvement we're pretty flat or for what it's worth um you know we would talk about that pretty infrequently it's not that it never happened right we would say like just to give you an example um because it was a forensics company. It was like we have investments in these major areas, right? Like we do historically it's like um desktop-based digital forensics. You get a hard drive, you go do forensics on that hard drive and then you have things like mobile devices that come along and mobile devices introduce a lot of complexity.

So like my team focused on mobile devices and then there was like cloud forensics and then so like we have these different areas of the business and we would talk about high level where to go invest uh and what that could look like but that was extremely uh like infrequent. we would do quarterly planning um and and talk about things like that. And one of the biggest things that came up there was really dependencies because by the time we were getting in the groove of doing that, it's like look, if you want, you know, if one team or one business area is trying to build out capabilities and deliver whatever to the customer, um you're going to be relying on another team to get some parts of that done.

So I would say a lot of those discussions were aligning to make sure that we're like as a as an engineering or aligned we work very closely with product so that would you know we'd come together on that we would figure out like are we aligned moving in the right direction um and if so if product uh and engineering were kind of on the same page for the direction we're heading engineering would need to be able to go off and talk about like how do we get these these priorities kind of lined up because if um just cuz we all agree this is the direction we want to go in. If my team wants to go build X thing first because that's most important to us, that might screw over, you know, team uh team A and B, team C doesn't care about it, right? They can wait.

So those types of conversations would come up in planning and um honestly even at a quarterly uh quarterly basis you'd still have a lot of uh churn and what the plans were most of the time most of the time we were moving in the direction and that stayed consistent I would say um because I was there for eight years I would say in the first few years there'd still be tons of at least for the areas I was in tons of direction changes and you know in the latter half of that I would say we were quite consistent with we said this direction we stayed there but the specifics of what we went and worked on changed um by the end of my time there we were working with uh an OKR framework if you're not familiar with that it's objectives and key results and

um everyone's going to have opinions about different frameworks and tooling and stuff like that uh OKRs I thought were a very interesting system I'm not uh I'm not a big fan of like trying to I don't know make things like regimented and strict and OKRs are a very specific kind of framework. So I liked the intention but uh people would waste ridiculous amounts of time because your key result needs to be a measurable like scale of things. So you can't just say like your key result is deliver a feature. Key result is not to deliver a feature. Key result is to move some metric from A to B, whatever that metric is. How you do that is not the key result. That's for you to go figure out. You're setting a goal to move a metric.

So I think where I'm going with this to wrap up the startup stuff to shift over to to big tech for Microsoft specifically is that the conversations around aligning on those things I think were the most valuable part of planning actually figuring out and like um you know making sure we're going to get these target dates and everything's going to line up perfectly and then how are we going to enforce like that was the most and we would waste way too much time on that. But I really think getting alignment on what we're trying to build, the direction we're moving in, how we plan to measure success, what that looks like. I think all of those the conversations is super helpful. I do think the time was wasted trying to be hyper specific because the reality is the plan is not going to be the actual plan.

You know, six months from now, we will have deviated. We need to accept that we will deviate from the plan along the way. How do we make sure that we stay as aligned as possible, that we're all going in the right direction? Okay, that was my biggest takeaway um from being in a startup from a planning perspective as things uh grew over time. Check in. Okay, traffic is terrible, but it's all over here. Um that's why we pay for the fast lane. That's why Code Commute subsidizes the fast lane by a few dollars every month. Um okay in big tech planning is a lot more regimented or it's supposed to be right. So the rationale behind that is of course that we have um lots of teams with dependencies on each other. Um I don't like I don't even know how many teams are in my part of the organization and I I rep like I work in the office 365 side of things.

like Microsoft 365. I have no idea how many teams are. There's a lot. And so it's really important that we can come up with at least at a high level present the direction we're going in. We do talk to leadership. They make sure that we're aligned with business uh strategy. Um there's this opportunity where we can make sure that the dependencies between teams are figured out, right? So as you're approaching your planning period, it's a really good opportunity from the engineering side to work with your product managers to say, "Hey, look, like we we need to go chase down this team. Uh see if we can get ahead of, you know, getting on their road map for the next semester, get some deliverables from them so that we can build on top, right?" like it's this dependency game where you you're trying to look further

ahead to get unblocked by other people because again um for these types of systems at least there is a lot of dependencies on other people getting their done right before like where I was working we were the we were the platform like you could kind of look over your cube wall from your little area and go talk to the person who's doing that and you see them every day. You're talking about this kind of stuff. I should have mentioned too, by the way, when I was working at that startup, everything was in office. Uh my entire time at Microsoft has been uh from fully remote to hybrid to now still hybrid, but we'll have more days in office coming up. So, just for what it's worth. So we need to get ahead in planning and the reason for that is making sure that we're on other people's road maps.

Um now planning that we do ends up being uh further out. So instead of looking at it on a quarterly basis like I used to do in a startup which already I was like I know this this is a direction. It's not going to be a regimented plan. It never works that way. Um here we do semester planning. So we'll do six months at a time and often because of what I was saying for those dependencies often we're going we're planning for 6 months but like we already need to be thinking like what what follows up in the next semester so that when we're talking dependencies with partner teams we can say hey look like we need you to go work on this in this upcoming semester because after that we're going to go build on top of it right so you're always trying to get further and further ahead from a dependency perspective The tricky part with all of this is that the same challenges happen.

And so like what do I mean by that? I mean that like things change. This is why I tried to call out by the way before I got into this that like you might be working on technology where it's like dude we're building a satellite. Shit's not changing because if stuff changes like we're screwed. Um there's going but in in every area there's always going to be un uncertain things or things that you didn't predict coming up always. Always no matter what. So it's just the amount that that happens. And it for us it's still like in in Microsoft where I'm working it still happens a lot right I like I work in a security space. If there's something that comes up where my attention needs to be drawn to something security related, that's going to take a priority over anything else I'm doing. And that means if there's engineering effort that we need to go do to address anything, then that's going to take priority.

That's it's it needs to, right? Because that is our top our top value. And so there will always be these things that we don't predict. And so because we are planning further out because we have dependencies, communication in in all cases is incredibly important, but it's especially in this case like you need to know your stakeholders. You need to be able to communicate early and often. So if you have like if you are owning the dependency for another team and they're relying on you. If something comes up and you're like we need we have no choice but to pivot onto this thing because it's a critical priority. If that's the case, what like what are you trading, right? It's always going to be a matter of what you're trading. So you know you have to know and understand your stakeholders for what you're a dependency for.

uh for your own road map, right? Like are you always um you know uh trading uh what a partner is asking for or do you have to give up some of your own road map? And how do you know, right? Like you need to be able to make these decisions about like from an organization perspective, from a business perspective, you might be like, "Yeah, we really want this thing." But like if you zoom out and you're like, but you know that we're playing a part for this other team that's an even bigger impact, even bigger part of the picture, right? There's going to be these types of trades that you need to be able to consider. So point is, it always happens. It always will happen. And I think that as much effort goes into planning up front, I think you always need to consider what it looks like to adjust.

Because if if all of your time and energy go into planning is about how do we make the plan perfect, right? What are all the things we're going to do to stick to the plan? I think if that's where you're optimizing your time and effort, that is not the right thing. Don't get me wrong. I think it's important that you're coming up with plans that you think that you can stick to and you're talking about what things keep you on track. I do think that's valuable. But making that the sole optimization I think is wrong because I think you really need to look at how are you optimizing for agility because it will happen. how much agility you need will be influenced by the industry you're in, your company, your team, all this kind of stuff, right? So, so I wanted to give you examples of like early stage startup where I'm at at Microsoft now, which is not not an early stage startup.

Um, and we're supporting a platform that's mature, right? Like these things look different. It's also the same reason I told you the areas I'm working in. And I'm not working in something with a physical product that's being shipped and has a timeline. It's not a new uh where I'm now is not like a new product launch again with something physical. It's not a, you know, 5-year government contract to deliver something. It's not, you know, building a rocket ship. Um, it's it's just different. Sorry, I got a one more lane change here. So, optimizing for agility I think is important. So, what does that mean and what does that look like? I think like I said back to stakeholders, understanding who your stakeholders are, having mitigation plans, right? One of the reasons OKRs are pretty cool, uh, even if you don't like the framework, um, I'll just talk about a concept, right?

I mentioned earlier with a key result, you have a something that you're you're trying to invest into to move a metric that you care about. Okay, metrics are tricky because if you pick the wrong metric, you're optimizing for something you can game the system. It's not valuable. So, not perfect. But what's nice about a key result is you're saying, "We care about this metric. We want to move this metric from A to B, right? We want to reduce latency. We want to improve throughput. We want to make sure that our rate of onboarding partners goes from this to this." Whatever it happens to be, you want to move a metric from A to B. How you do that, the how part, you may have lots of ideas from the engineering perspective. that might change along the way because dependencies because of uh what you actually design and plan for in practice doesn't actually work.

There's always going to be these uncertain things always. But you set out to move a metric from A to B, right? If you think about that being a constraint that you have and you're trying to operate within the bounds of that constraint, how do we move from A to B? Then what are the creative plans you need to come up with to keep moving in that direction. Right? So one of like I said one of the things I like about objectives and key results is that tries to bring alignment on these are the things that we want to go improve or you know move move metrics on and how you go do that can change from the perspective of the planning process. Right? So again, I don't love a regimented thing because the wording and the phrasing and key results is weird, but um I like that concept a lot where when you're talking about planning, you're trying to get that across.

Um it does leave out the specifics when you have a dependency, right? That part gets omitted when you're just talking about metrics, but that's where um one uh objective alignment and key results, that kind of stuff. I think great conversations. But the second part to it is understanding who your stakeholders are for the things that you're building, right? Who are you depending on? Who's depending on you? That way, if you have a clear understanding of what people are asking for, what they're trying to accomplish, as your plans shift, because they will, as early as you possibly can, you can work with the stakeholders that are relying on you. and hopefully they're doing the same for you so that you can shift accordingly, right? When when this stuff lags behind, right? When you have surprises, you know, you've been working according to plan and you're um you know, 3 months of the 6 months into the plan and then um you have a partner that's like, "Oh, yeah, by the way, like not going to happen.

Just can't get it done." And then it's like there were signs that they could have told you like a month or two ago that they were behind. Um, and this is your first time even hearing anything about being off track. Like there are ways to prevent this, right? To to prevent and reduce surprises. And that's the part that I think that if we spend more time optimizing around uh communicating this kind of stuff, having visibility into this kind of stuff uh can make a a really big impact because like I said the plans will change the uh scale at which they change the frequency a lot of uh different factors will influence that but plans will change. that part is consistent with startups from my experience in big tech. So I think some of the key differences are like the sort of the how far you're looking out when planning.

I think the number of dependencies that you have across teams and stuff like that can be um you know a really big difference. your um your ability to be uh you know nimble, agile, flexible in your plans, your ability to do that often seems uh I don't know, from my experience, it seems easier at a startup because you have fewer dependencies, right? You might be telling a product owner uh who needs to communicate to customers and sales people and stuff like, "Hey, like this thing's off track now." Um versus like 15 other teams you're about to disappoint. So your your ability to be uh like flexible I think is a a little bit better at a startup. So there are differences but there are a lot of uh similarities as well. Okay. So th those are some of my experiences. Obviously it was you know pretty high level stuff.

Um I hope hope that kind of makes sense. I think the spec like if you're listening to that and you're like, "Okay, well, how does that work?" or "What what do you actually mean here?" Just ask in the comments and I'll try to like I can make follow-up videos and do like specific examples or like uh specific hypothetical examples and go through stuff. Um there's a lot to discuss there and I will remind you that I, you know, I just talked about planning, but think about anything you're doing, right? Like what what does dev tooling look like? What does what do CI/CD pipelines and builds look like? Right? What do analytics dashboards and metrics and stuff look like? Like do we even care about that in some of these contexts? Um you like my my goal was to kind of get you thinking about all that kind of stuff.

Let's go over here. This is we'll do that today. Um because it's not just planning. I just picked planning as something that was relatively top of mind for me. Do we care about security at startups? Like, you know, all all this kind of stuff. Am I going to hit this poll? We're good here. Cool. If you have questions, leave them below in the comments or go to codemute.com. You can submit stuff anonymously there if you want to be kept anonymous. And of course, you can always message me devleader on any social media channel you find me. LinkedIn is a little bit easier. It's Nick Cosantino on LinkedIn. Twitter seems to hide my eight messages uh as requests, which is really dumb, but I do periodically go comb through that. Uh Instagram's another one. I'm on every platform. Send me a message or find a way. Uh and I read the comments, too.

So, I'm happy to try and help. See you in the next video.