Detailed Notes
In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche revisit a cornerstone of successful software development: the project kickoff strategy.
Originally explored in our episode “Mastering the Project Kickoff – Setting the Stage for Success,” this updated take uses AI to revisit key lessons, expand on real-world insights, and help teams launch projects with clarity.
🔍 What we cover: • The real purpose of a project kickoff • Common red flags that derail projects • Why defining an MVP early matters • Using documentation and role clarity to avoid burnout • How to audit your kickoff strategy before coding begins
Challenge for dev teams: Audit your current kickoff process and make sure your MVP, roles, and communication flow are crystal clear.
🎯 Watch now and upgrade your next project kickoff.
📌 Full blog and notes: https://develpreneur.com/project-kickoff-strategy/ 📧 Contact us: [email protected] 🌐 More episodes: https://develpreneur.com/category/podcast/
#ProjectKickoffStrategy #SoftwareDevelopment #Agile #MVP #TeamAlignment #DeveloperPodcast #BuildingBetterDevelopers
Transcript Text
record. I forgot to tell. So, Oh, wow. That's an invisible glass of wine. Do not chuckle. Ah. I got what's their names? The muppets up in the stands heckling back there. Waldorf Salad or whoever it is. Anyways, all right. Captain Nemo, Captain Evil. All right, this is going well. Uh, let's see. So, we have Do I have it? Uh, let's see. Master the project. Okay. Mastering the project kickoff set setting the stage for success. I'm going to move around a little bit so I can read this thinking stinking thing a little bit better. And um we're just dive right into this one too because we got to get moving on this stuff. Um oh okay, my timer reset because I had to reload everything because my phone blew up. So apologies to everybody if you're seeing me like uh max headroom a little bit. That's me. My bad. Working off my phone today. Check the bad the last episode. It's because I'm somewhere where I'm having to work off my phone instead of where I normally have like better internet connections. So, it is what it is. A three. A two. Oops. Over here. Well, hello and welcome back. We are continuing our season where we are building better developers. We're developing our podcast. And this time we're doing it with AI ching. one of those little things we have little star or something like that, you know, like that little thing up like a logo up on the top, a little super script because it's really actually it's not even close to the same thing we did two seasons ago. We're just actually reusing the title, the topic, and then we're saying AI, what would you do? And then we're talking about that and we've actually had some really good conversations. So, I want you to just like, you know, buckle up because this should be a fun one as well. This time we're going to talk about mastering the project kickoff, setting the stage for success. Actually, I think going to be a fun little topic. We'll see if AI fails me or not. I am not going to fail to tell you who I am. A little introduction here. My name is Rob Broad. I am one of the founders of developer. Also the founder of RB Consulting where we are your buddy in technology. Basically, we sit down with you. We walk through what does your business do? What are your needs? What is it that makes your business your business? And then we craft a recipe for success for you. This is essentially a uh an IT assessment. We look at what we can do through integration, innovation, implement uh simplification, automation. Too many shuns out there. But we don't shun the the work itself. We help you build a road map and either implement it or you can do that yourself as well. It includes things like if you want to build a team, whatever it is. Some people refer to it as like fractional CIO services and stuff like that, but really it's about helping you leverage technology better and reduce that technology sprawl. Get rid of that technology junk drawer that you have and instead turn it into that like, you know, front dining room that everybody wants to see as they walk by your house. Somebody everybody wants to see in the front of their house is Michael. And he's going to introduce himself. But first, I need to do good thing, bad thing cuz I almost forgot that. Uh, good thing, bad thing. Um, this has been one of the that's like I am in a road warrior mode the last few weeks. And the good thing is that I'm able to do this. I'm able to like sit down almost at the drop of a hat, rip out a a web a laptop or something along those lines. Maybe it's a, you know, a phone or tablet or something and I can get stuff done. I can write code. I can crank out emails. I can market. I can network. I can do a lot of stuff. That's a good thing. The bad thing is is that there is like a there's a rhythm that we get into in whatever our normal place is to work. And if we're constantly shifting that, it can be hard to do. So, and if you're somebody like me that loves to have that like heads down focused, talked about it the Pomodoro technique and stuff like that, those kinds of things, those focus time to get stuff done, it can be very u challenging, we'll say. So, that's a bad thing. As I've been running around a lot, I've been very happy with what I've done. I've also learned some tools that I need to make sure that I'm uh upgrade or that I gather as part of my road warriorness. But uh and my you know my digital node ma nom madness that I'm going on to but uh that's my good and my bad. Now I will go back to after I faked you out earlier. We're actually going to go over to Michael. Introduce yourself my friend. >> Hey everyone, my name is Michael Malashsh. I'm one of the co-founders of developer building better developers. I'm also the owner of Envision QA. We help startups and growing companies improve their software quality through services like test planning, automation, and release support. Why do companies work with us? Because buggy code software costs time, money, and customer trust. We make sure products are reliable before launch, helping teams move faster and avoid costly mistakes. If you're building something great and want to run smoothly from day one, visit envisionqa.com and reach out and give us a call. Good thing, bad thing. Well, good thing there is so many good movies coming out or movies coming out. I don't want to say good because I haven't seen them yet. Uh I want to see along with some great video games that are coming out and I have no time for any of them. That's the bad thing. I I have so much work to do, so many things get done because the rain still comes and goes, which unfortunately makes yard work longer. Because if you get rain 4 days a week in the middle of summer when usually you can mow the lawn once a month, you now have to mow it twice a week. Uh but one good one additional good thing with that, my wife's tomatoes have been producing about 20 to 30 tomatoes a week at the moment. We are canning canning canning. But like she decided to plant heirloom tomatoes this year. Those things are freaking huge. Um it's they started out small and we're like, man, we need to plant more. We overplanted. We have so many tomatoes just popping out. But I have to say after the last few years, kudos to my wife. We finally figured out what we need to do to the soil to get it right before she did this because last year every single tomato had bottom rot, which I guess is uh lack of nutrients in the soil. So, we had all these wonderful, beautiful tomato plants and zero tomatoes. >> And that is your farming minute from Developure where we build better tomatoes. Uh, I just want to say like this is a little bit of a sidetrack before we get into this topic is that being someone who has just recently downsized, there is a good and bad to that. is that there are those moments where I'm like, "Ah, it'd be so cool to be out and have my little garden and be able to work in all these little things. I blame my wife because she got me hooked on hydroponic stuff a couple years ago and the next thing you know, I was like, I should plant stuff." Suddenly, I'm out in my yard. I'm like that old guy working in his garden. Not very well all the time. But now it is nice. It's a good thing is that I don't have to deal with the house. But sometimes I wouldn't mind like, you know, putting around in the yard and having a little garden and stuff like that. Moving on, we're going to talk about AI. Actually, more importantly, we're going to talk about mastering the project kickoff. What has AI said? Well, once again, because it must have hurt us. It starts with great episode idea. It's gotten back into the like over-the-top positive AI answers again. Uh, this one's again giving me one that's a little more like we got in the last episode, which really it's like an act one, act two, act three, not really covering the topics, which is interesting because I I've got to figure out what I did because whatever I did before, uh, I was pretty consistent the prior whatever it is dozen episodes in the how I phrased what we were doing and who we are. Uh, and I would just I'll throw that out as like a little bonus to everybody is that when you are talking with an AI, when you are having a conversation with an AI, how you phrase stuff and the background that you give is incredibly valuable. If you want to learn more, one of the things I highly recommend is work with one of the APIs because there's always going to be a setup essentially of who the AI needs to present itself as. Then having those settings and figuring out those prompts and how they should be done will really help you when you're just sitting on a com a, you know, for lack of a better term, a command line version of a chat agent or an AI agent. Moving on, episode focus. Equip developers, tech leads, and PMs with the mindset, tools, and rituals to launch projects intentionally, not just start writing code. Oh my gosh, that's like that is step one of building better developers. You need to do something besides dive into code. Cold open. I love this. Cold open. Let's see how it goes this time. 1 to 2 minutes. Imagine this. You start coding on day one. Tickets are flying. Two weeks later, no one agrees on the goal. Wow. That has never happened before. That happens every stinking project. It is amazing how often, including the customer. This is why every project proposal I talk about, I start with the first thing we're going to do is we're going to sit down and figure out what the heck we're building. I have been in way too many projects where we all sit down and we're sort of like, yeah, this is what we're going to do in a little 30, you know, 30 minute or 30 secondond discussion and next thing you know, we are going in completely different directions and we really can't even agree on the why. We don't even know what problem we're solving anymore. So definitely let's make sure that we as Michael showed for those of you watching the YouTube channel, document this stuff. Like write these things down. Let's make sure we all agree exactly on what we're doing. Uh use a quick anecdote of a project that lacked a proper kickoff and spiraled into chaos. I'm not even going to bother with that because it's like almost every single project. And the sooner you wrangle that stuff back together, the less chaos you're going to spiral into. So let's dive right into why kickoffs matter. This already I'm like pumped up about this one. Kickoff isn't a formality. It's your project foundation. Misaligned expectations equals missed deadlines, wasted budget, and burnout. Set the tone for team culture, communication norms, scope clarity. Quote worthy line. Start slow to go fast. I am going to call out everybody that thinks that agile methodology means that you don't spend time in design requirements gathering documentation and some of these other things. Go back and look at the manifesto itself. Go look at the agile manifesto and you will see that there are all of these things are critical. However, there are some things sometimes that are more important. But that doesn't mean that those things go away. A kickoff. I got into the habit of a kickoff with a company I worked with years and years and years ago. They they always did a project kickoff. There was always an internal kickoff and then a with the customer kickoff because this was a also a boutique consulting company very similar to RB Consulting. And I have I always loved it then. That was part of what attracted me to working with them and I've loved it ever since is you need to have a point where you sit down and this is not where you sell the project or you know get sign off on it. This is where you say okay we're going to do this project. This is the starting point and at that starting point you need to make sure that you are actually walking through where we at and where are we going to go whether it's A to B or A to Z. What is a and what is that last point? You don't have to get all the details, but the most basic stuff is where are we and where do we plan on going? Sometimes that where we plan on going will change, but we need to have at the start what d it's literally like if I'm going to start a journey of a thousand miles, which directions do I face first to take that first step? And there are a lot of things that are involved in a good kickoff. Introduce a team. Oh my gosh. Make sure that people know who everybody is. Whether it's the the customer, the team itself, even if they never talk again, the fact that they know those people exist is very useful to success for a project. Make sure you swap whatever it is, business cards and contact information so the people that need to communicate with each other can communicate with each other. Have a talk about things like where is your document repositories going to be? Where is it that I'm going to be able to find the requirements, the current requirements for this project? Where am I going to find design material? Where what are we going to do for code repositories? What are we going to who is the customer and what are we going to do to get stuff to them? What kind of like a rhythm are we going to have? Is this what is the SDLC approach that we're going to take? There's all these things we take for granted. And particularly if this is the first time that we're working with our customer, let's have a kickoff where we lay out these ground rules and basically say this is the rules we're going to work for and look work with and this is how we're going to proceed. Because sometimes that alone will turn up problems and we'll very quickly be able to say oh my gosh this customer, this is what happens many times. this customer doesn't actually understand the data that they work with to a level that they they're going to be able to provide the mappings and the functions around the data for the integration that we're going to build. That's just a random example, but I will like I will call out Netswuite, Salesforce, every big CRM and ERP solution. And it's not those tools fault. It is the customer a lot of times that is not ready to take that step and nobody sits them down and says you need to understand your business and how it works and what is critical and how to communicate that to the implementers before we move forward because a lot of times there's stuff that lives in somebody's head or it's sitting in somebody's drawer somewhere in a desk in an office you know the other side of the country and that stuff ends up being critical to the success. I know I'm being a little vague. I don't want to call people out too much, but I just want to say that kickoffs matter and make sure that as part of that you line out, outline what is it that we need for success, which includes where do we need to go to be successful. Little bit of a sandbox, a soap box. Sorry about that. I'm going to set that aside. I'm going to let Michael get on his soap box and talk about what he thinks about this. I'm just going to add a little bit to because you kind of went pretty in-depth on this one and timewise we probably should be getting to the next topic pretty quickly. Uh but with this one, you're absolutely right though. The project kickoff sitting everyone down internally and externally. More times than not, the customer really doesn't know what they want. So really establishing the why. What is it that you're building? what is it that they need needs to be established right up front. That's why we when we do our intros, we talk about doing assessments. Assessments are a great way to figure out what they have and what they need and then you can refine that into a uh proposal for something to build them or what you can help them customize what they have for something that will improve their business or their overall uh workflow within their organization. What I have seen lacking is when you do get to the internal, you're like, you may have the documentations, but if you don't really sit down and bring everyone on board, it can be timely and costly to do it upfront, but it you have to kind of get everyone on the same page. Maybe not do a full brainstorm session, but at least walk through the project at a high level. Make sure everyone's on the same page. And yes, open it up for questions. Don't make it a total silo, but do keep it restrictive because that initial kickoff is not where you're going to be doing all the brainstorming and things of that nature. You will be doing that over the course of time through your sprints and hopefully through your roadmap. >> We we covered a lot of stuff right there and so I'm going to actually dive right through the the second section because I think it's very val. This is some of the things this is essentially says the anatomy of a great kickoff. And we've touched on a lot of this, so I do want to like fly through these and then because I monopolize too much time, I'm going to throw this to Michael for the next one. So, heads up, you're going to be on the hot seat. Uh, now we have a great kickoff. Walk listeners through a bulletproof structure. Before I go into any further, I want to say that this if you are putting proposals out to customers or potential customers, prospects, these things are awesome to cover in your proposal. It's amazing how often addressing some of these things and talk about things in a proposal will improve your chances for success, including I've had multiple customers, actual customers that I, you know, I won the proposal that said that that was one of the things that helped me win it. Of course, if you're proposing against me, please do not do this, but otherwise, feel free. Uh, purpose. Define the problem the project solved. This is the why. Establish project establish project goals. OKRs, smart format, PKIs or whatever it happens to be. What is it that essentially is like, okay, what is it that we can say we can go verify that we actually solve the problem? People, this goes back to what I said. Who's involved? Who's accountable? All who owns certain decisions. Who are the decision makers is key to the kickoff of a project. Clarify roles. Developer, project manager, designer, stakeholders. Set collaboration rules. Slack, standups, async updates, stuff like that. Roles are critical, especially when you have people that cross rolls or you have small teams where people have multiple roles. Make sure you're clear on those process, agile, conbon, water, scrum, fall, deployment frequency, branch strategy, review your flow, deadlines, demo, rhythm. Ask what can go wrong. Discuss past similar projects and what to repeat or avoid. It's almost a retrospective and a review in itself just to do your kickoff for those of you that you understand the agile side. If you don't check out our agile stuff for what those rituals are like uh playbook docs, centralize your documentation. Do we use conflicts? Do we use notion? Readmes, Dropbox, whatever. Record the kickoff meeting. I will add to this. Record meetings all the time. Just record everything. It's so easy to do. We have done it. Yes, I've got gig and gig and gigabytes of stuff that I will never look at again, but some of it we do need. So, record all the meetings just in case. And now we're going to go to act three. Michael, get ready. You're about to >> quick on that last bit though. >> With the recording stuff, especially nowadays with the AI tools that a lot of them have built in like Zoom, you will get pretty decent transcripts. At least keep the transcripts because they are searchable through your system. So you can just have all your meeting note or transcripts out there. And heck, you can even have AI create meeting notes from your transcripts. But if you're like, "Hey, we talked about this." Go search your folder directory of all your transcripts. You can find the meeting. And if you can't figure out what it is, open up the video and then jump to that section and it's like, "Ah, yeah, now I remember." So >> that is that is an incredibly good suggestion. Um, it is so much faster to search for text and find like that like where did we talk about X? Use th those transcription notes are very valuable. That kind of stuff. All right. So, red flags of a bad kickoff. No written goals or timeline. Unclear responsibility. Wait, who owns testing? Stakeholders missing in the room. We'll figure it out as we go. Many rant opportunity. This I don't know if I want to give you this. Code doesn't solve confusion. People do. All right. I'm going to toss this right to you. Thoughts? So, where do you want to go with red flags of a bad kickoff? >> Oh, let's see. Uh, I I can almost picture one right off the bat. So if you have a small team, a large project, and a very small budget, you are going to red flag is right there because chances are you're automatically going to be going in with the mindset of how can I cut costs and still deliver. And if you do that right off the bat, you're going to be, well, we'll figure that out later. Or you'll kind of go the easy route. What is the lowest hanging fruit that we can pull right now to get started to kind of get a small MVP or at least something visible for the customer to see to start getting feedback. The other red flag that comes from that is if you did not define the requirements, the why from the customer beforehand, you could be immediately running down rabbit trails of nope, that's not what I want or oh, this button isn't right or you could get way too confused and lost in things that mean nothing that are not the MVP. Um it just and roles defining roles because especially on smaller teams testing is important and if you are both the developer and a tester getting people to understand where you're coming from depending upon what hat you wear is very critical because you could be asking questions one day as a developer and it's very open less critical but the next day you turn around you're testing you have to come in more critical. You have to be asking more deep you you ask different questions and it can offset other people on your team that are used to you being in one role or they're they're developers. They they used to developer speak. Coming at them with tester speak, you get more defensive. You run into this in almost any organization and company. So bear in mind if you are wearing those hats and you see some confusion or miscommunication going on as you're going through the project from the beginning, you need to stop, reset, and redefine those rules. Otherwise, it's going to be complete chaos by the time you get to the end. That's all of that is 100% you know that's kind of those are things that you need to be worried about and the it how it can go wrong basically. Um I'm going to I'm going to focus on the we'll figure it out as we go. This is very much an agile approach because there is a level of we're going to figure it out as we go. That's part of what agile does is it says I'm going to take I'm going to put a couple of stakes in the ground but then there's other things that I don't have to worry about. It's it's not that we're going to figure it out as we go as much of it's more of an 8020 rule. It's a these are the things that are critical and then we're going to get mostly there and we're not going to finish them out until we're sure we really need to finish them out. More importantly, I have found more and more and more that the idea of an MVP should be part of every single project. Because too often you get further down the road and suddenly budget becomes an issue, time becomes an issue, uh capability becomes an issue, whatever it is, and suddenly you find yourself changing gears, fighting fires, and converting everything into an MVP mode. Everybody loves a big project when you start because we've got all of this like we've got all of this runway. thinking about a plane on the runway. It's awesome when you start and you've got a 10,000 foot runway, but when you've been lolly gagging now, you've got a hundred feet left and you're only going, you know, one mile an hour and you've got to get to 100 miles an hour to lift that sucker off the the ground before it goes off the runway. It is panic time. We do not want to get there. So I highly, this is through literally now decades of experience with this in commercial development, internal development, scripts and utilities, you name it. Whatever the product is, I would highly recommend always, always, always, I'm thinking I should write a book just on this. Always, always, always have an MVP. have a this is our minimal goal and that should be part of your why. That should be the thing that you can measure every single choice and decision against and say, does this contribute to an MVP? Now, that doesn't mean that you're going to stop at an MVP. But that does mean that you need to at some point in your project achieve or s exceed what an MVP does. that is really going to help you particularly early on. It's going to help you figure out where do you spend those resources and agile projects are as bad as anything else about this where we will sometimes start out and we don't feel the pressure of time and resources enough and we spend too much stinking time building a green versus a blue button as opposed to solving an actual problem. And I know this sounds a little judgmental and I am judging myself too because I have been there. I have I I have been in those situations. I'm like, I've got a whole week I can spend chasing down random CSS cool stuff that I can do and I get to the end of that week and realize that I really didn't provide value. So I would bonus tip recommend to you always have an MVP and then use that as sort of like your your guiding light. It's like we've got to get at least to here in order to be successful. I'm going to throw it back to you before I dive into the next one. >> Yeah. So, if you're struggling to understand what an MVP is or how your project that you're working on, what is an MVP for your project? Flip it on its head. Write user stories for your MVP. Turn those user stories into tests. And if your code does not complete a test in your test suite, you're not working on the MVP. >> That's not a bad way that we'll call that testdriven development. We quoted it here. That's trust me, we're the ones that invented that. Um, honestly, that's ex almost exactly what it is. It's saying what does this need to do? build the tests that say okay if that means if it does this then that means that this test will succeed and then you build the application out to that. So that is literally test-driven development and it is if you're struggling with MVP as Michael said that is a great way to do it is is you do you start with the user stories is it's it really is it's focus on the why focus on the problem you're solving and then break that down. It's like okay to solve this problem what do I need to do and that starts to become your test and the next thing you know you're like this is what we are implementing towards. I don't want to go too far into this because we're going to leave some bonus material for the people that are out there on YouTube. Those of you are not on YouTube, you should be because we have bonus material literally every episode. Sometimes more, sometimes less, but there's always some extra stuff, especially this season. We have had some pretty cool stuff that we've thrown out there after every single episode. Sometimes very key stuff. Some we only gotten through like half of the response of AI. So check us out. Also, shoot us an email at info@odvel developer.com. I do not get enough of these emails. I would love to see that. Yes, I know we have you guys give us, you know, we'll get responses. We'll get reviews and things like that. I would love to get some emails because I want to I want to actually connect and hear from you. What do you like? What do you not like? What would you love to see us do? That's why we're here. We are here to not only build better developers. We're also here to build a better you. To entertain you, to inform you, and do the things that matter to you. Yes, you. I am talking to you, whoever you claim yourself to be. That being said, we're going to wrap this one up. As always, there's so many ways you can reach out to us. I'm not even going to bother listing them this time around, but I am going to tell you to go out there and have yourself a great day, a great week, and we will talk to you with AI next time. >> Bonus material. Let's see. I'm going to start with I'll throw this out there. Um, it's got developers point of view, why this helps you, and then optional segments, and then we'll see where you want to go there. Uh, act four, developers point of view. Why this helps you? Less rework, fewer last minute fire drills, more confidence and autonomy. Bonus, you're seen as a leader, not just a coder. That could be a good one. Optional segments. Kickoff horror stories from listeners or guests. One pager kickoff template. Offer downloadable asset or example. Kickoff in 60 seconds. A rapidfire checklist for solo founders. I'm going to let you go first. I'm like I'm chomping at the bit a couple of those, but I'm going to let you handle this one first. >> So, I already talked about test driven development, but the the biggest problem you're going to run into with any project kickoff is there are going to be things you don't know and you're going to make mistakes. Be conscious of that from the beginning. I've done this. Just about everyone has done this. You think you understand a project. You think you have all the pieces you need at the start of the project and very quickly you find out you do not have all the pieces for the project. Even doing scrum or uh can not necessarily fix that problem. You need to stop, reset, get the information you need to make sure that you're not going down the wrong path. You could be starting out at the right path, but very quickly you could be digging a trench down versus walking forward. I am going to go with the one pager kickoff template. Offer downloadable asset or example. I literally in this moment do not have that thing. If you shoot me an uh email at info developer.com and ask for one, I will create one and if you're the first one, you will get the first copy of it and everybody else will get a copy of that because it's actually a really good exercise. Uh honestly, if you don't trust us, really, you don't trust us? Come on. No. If you don't trust us to do it, uh it would actually be a really good exercise for yourself to create a kickoff template. I actually do have something like this. It's not actually a kickoff template as much as it is a project template. Uh actually, there's a book that sort of goes through this. If you go to the uh rb-sns.com, you go out there. We've got a free book. You can go check it out. It's uh software development something something something. I forget what I titled it because it's been a few years. Um but it does have some of those kinds of things. It talks a little bit about a kickoff, but I would love to actually go back and do that. And I think for yourself, this is one where I'll say, you know what, you don't even have to shoot me an email. If you think about sending me an email, it would almost be a better exercise for you to create your own and then send me it and I would love to talk to you about it. I will literally like we can schedule a call and talk through what your kickoff looks like because I've been through literally I bet a hundred project kickoffs in my career. Some have gone well, some have gone very very bad. Some have killed the project almost immediately. Um, and there are there are commonalities across these. There are certain things that will help you make your project success and there's certain things that if you don't do it, you are more likely to fail. So, I'm going to leave you with that little like very heavy like, you know, thought for the day and wrap this one up. As always, I thank you so much for your time. We really do appreciate you the the time you spend listening to us, checking us out, give any anybody that gives us feedback. We love you. More and all that kind of stuff like you guys are awesome. Uh we're that's why we're here is we want to build better developers. We want to build ourselves as better developers as well. So as always, however you want to reach out to us, we're happy to do so. Thank you for what you've done and go out there and have yourself a great week. Get more effective. Become a better developer. Come back next time going, I actually got better since the last time I saw this show. Have a good one, guys.
Transcript Segments
record. I forgot to tell.
So, Oh, wow. That's an invisible glass
of wine. Do not chuckle.
Ah. I got what's their names? The
muppets up in the stands heckling back
there.
Waldorf Salad or whoever it is. Anyways,
all right.
Captain Nemo,
Captain Evil.
All right, this is going well. Uh, let's
see. So, we have Do I have it? Uh, let's
see. Master the project. Okay.
Mastering the project kickoff set
setting the stage for success. I'm going
to move around a little bit so I can
read this thinking stinking thing a
little bit better.
And um we're just dive right into this
one too because we got to get moving on
this stuff. Um
oh okay, my timer reset because I had to
reload everything because my phone blew
up. So apologies to everybody if you're
seeing me like uh max headroom a little
bit. That's me. My bad. Working off my
phone today. Check the bad the last
episode. It's because I'm somewhere
where I'm having to work off my phone
instead of where I normally have like
better internet connections. So, it is
what it is. A three. A two. Oops. Over
here. Well, hello and welcome back. We
are continuing our season where we are
building better developers. We're
developing our podcast. And this time
we're doing it with AI ching. one of
those little things we have little star
or something like that, you know, like
that little thing up like a logo up on
the top, a little super script because
it's really actually it's not even close
to the same thing we did two seasons
ago. We're just actually reusing the
title, the topic, and then we're saying
AI, what would you do? And then we're
talking about that and we've actually
had some really good conversations. So,
I want you to just like, you know,
buckle up because this should be a fun
one as well. This time we're going to
talk about mastering the project
kickoff, setting the stage for success.
Actually, I think going to be a fun
little topic. We'll see if AI fails me
or not. I am not going to fail to tell
you who I am. A little introduction
here. My name is Rob Broad. I am one of
the founders of developer. Also the
founder of RB Consulting where we are
your buddy in technology. Basically, we
sit down with you. We walk through what
does your business do? What are your
needs? What is it that makes your
business your business? And then we
craft a recipe for success for you. This
is essentially a uh an IT assessment. We
look at what we can do through
integration, innovation, implement uh
simplification, automation. Too many
shuns out there. But we don't shun the
the work itself. We help you build a
road map and either implement it or you
can do that yourself as well. It
includes things like if you want to
build a team, whatever it is. Some
people refer to it as like fractional
CIO services and stuff like that, but
really it's about helping you leverage
technology better and reduce that
technology sprawl. Get rid of that
technology junk drawer that you have and
instead turn it into that like, you
know, front dining room that everybody
wants to see as they walk by your house.
Somebody everybody wants to see in the
front of their house is Michael. And
he's going to introduce himself. But
first, I need to do good thing, bad
thing cuz I almost forgot that. Uh, good
thing, bad thing. Um, this has been one
of the that's like I am in a road
warrior mode the last few weeks. And the
good thing is that I'm able to do this.
I'm able to like sit down almost at the
drop of a hat, rip out a a web a laptop
or something along those lines. Maybe
it's a, you know, a phone or tablet or
something and I can get stuff done. I
can write code. I can crank out emails.
I can market. I can network. I can do a
lot of stuff. That's a good thing. The
bad thing is is that there is like a
there's a rhythm that we get into in
whatever our normal place is to work.
And if we're constantly shifting that,
it can be hard to do. So, and if you're
somebody like me that loves to have that
like heads down focused, talked about it
the Pomodoro technique and stuff like
that, those kinds of things, those focus
time to get stuff done, it can be very u
challenging, we'll say. So, that's a bad
thing. As I've been running around a
lot, I've been very happy with what I've
done. I've also learned some tools that
I need to make sure that I'm uh upgrade
or that I gather as part of my road
warriorness. But uh and my you know my
digital node ma nom madness that I'm
going on to but uh that's my good and my
bad. Now I will go back to after I faked
you out earlier. We're actually going to
go over to Michael. Introduce yourself
my friend.
>> Hey everyone, my name is Michael
Malashsh. I'm one of the co-founders of
developer building better developers.
I'm also the owner of Envision QA. We
help startups and growing companies
improve their software quality through
services like test planning, automation,
and release support. Why do companies
work with us? Because buggy code
software costs time, money, and customer
trust. We make sure products are
reliable before launch, helping teams
move faster and avoid costly mistakes.
If you're building something great and
want to run smoothly from day one, visit
envisionqa.com
and reach out and give us a call. Good
thing, bad thing.
Well, good thing there is so many good
movies coming out or movies coming out.
I don't want to say good because I
haven't seen them yet. Uh I want to see
along with some great video games that
are coming out and I have no time for
any of them. That's the bad thing. I I
have so much work to do, so many things
get done because the rain still comes
and goes, which unfortunately makes yard
work
longer. Because if you get rain 4 days a
week in the middle of summer when
usually you can mow the lawn once a
month, you now have to mow it twice a
week. Uh but one good one additional
good thing with that, my wife's tomatoes
have been producing about 20 to 30
tomatoes a week at the moment. We are
canning canning canning. But like she
decided to plant heirloom tomatoes this
year. Those things are freaking huge.
Um it's they started out small and we're
like, man, we need to plant more. We
overplanted. We have so many tomatoes
just popping out. But I have to say
after the last few years, kudos to my
wife. We finally figured out what we
need to do to the soil to get it right
before she did this because last year
every single tomato had bottom rot,
which I guess is uh lack of nutrients in
the soil. So, we had all these
wonderful, beautiful tomato plants and
zero tomatoes.
>> And that is your farming minute from
Developure where we build better
tomatoes. Uh, I just want to say like
this is a little bit of a sidetrack
before we get into this topic is that
being someone who has just recently
downsized, there is a good and bad to
that. is that there are those moments
where I'm like, "Ah, it'd be so cool to
be out and have my little garden and be
able to work in all these little things.
I blame my wife because she got me
hooked on hydroponic stuff a couple
years ago and the next thing you know, I
was like, I should plant stuff."
Suddenly, I'm out in my yard. I'm like
that old guy working in his garden. Not
very well all the time. But now it is
nice. It's a good thing is that I don't
have to deal with the house. But
sometimes I wouldn't mind like, you
know, putting around in the yard and
having a little garden and stuff like
that. Moving on, we're going to talk
about AI. Actually, more importantly,
we're going to talk about mastering the
project kickoff. What has AI said? Well,
once again, because it must have hurt
us. It starts with great episode idea.
It's gotten back into the like
over-the-top
positive AI answers again. Uh, this
one's again giving me one that's a
little more like we got in the last
episode, which really it's like an act
one, act two, act three, not really
covering the topics, which is
interesting because I I've got to figure
out what I did because whatever I did
before,
uh, I was pretty consistent the prior
whatever it is dozen episodes in the how
I phrased what we were doing and who we
are. Uh, and I would just I'll throw
that out as like a little bonus to
everybody is that when you are talking
with an AI, when you are having a
conversation with an AI, how you phrase
stuff and the background that you give
is incredibly valuable. If you want to
learn more, one of the things I highly
recommend is work with one of the APIs
because there's always going to be a
setup essentially of who the AI needs to
present itself as. Then having those
settings and figuring out those prompts
and how they should be done will really
help you when you're just sitting on a
com a, you know, for lack of a better
term, a command line version of a chat
agent or an AI agent. Moving on, episode
focus. Equip developers, tech leads, and
PMs with the mindset, tools, and rituals
to launch projects intentionally, not
just start writing code. Oh my gosh,
that's like that is step one of building
better developers. You need to do
something besides dive into code. Cold
open. I love this. Cold open. Let's see
how it goes this time. 1 to 2 minutes.
Imagine this. You start coding on day
one. Tickets are flying. Two weeks
later, no one agrees on the goal. Wow.
That has never happened before. That
happens every stinking project. It is
amazing how often, including the
customer. This is why every project
proposal I talk about, I start with the
first thing we're going to do is we're
going to sit down and figure out what
the heck we're building. I have been in
way too many projects where we all sit
down and we're sort of like, yeah, this
is what we're going to do in a little
30, you know, 30 minute or 30 secondond
discussion and next thing you know, we
are going in completely different
directions and we really can't even
agree on the why. We don't even know
what problem we're solving anymore. So
definitely let's make sure that we as
Michael showed for those of you watching
the YouTube channel, document this
stuff. Like write these things down.
Let's make sure we all agree exactly on
what we're doing. Uh use a quick
anecdote of a project that lacked a
proper kickoff and spiraled into chaos.
I'm not even going to bother with that
because it's like almost every single
project. And the sooner you wrangle that
stuff back together, the less chaos
you're going to spiral into. So let's
dive right into why kickoffs matter.
This already I'm like pumped up about
this one. Kickoff isn't a formality.
It's your project foundation. Misaligned
expectations equals missed deadlines,
wasted budget, and burnout. Set the tone
for team culture, communication norms,
scope clarity. Quote worthy line. Start
slow to go fast.
I am going to call out everybody that
thinks that agile methodology means that
you don't spend time in design
requirements gathering documentation and
some of these other things. Go back and
look at the manifesto itself. Go look at
the agile manifesto and you will see
that there are all of these things are
critical. However, there are some things
sometimes that are more important. But
that doesn't mean that those things go
away. A kickoff.
I got into the habit of a kickoff with a
company I worked with years and years
and years ago. They they always did a
project kickoff. There was always an
internal kickoff and then a with the
customer kickoff because this was a also
a boutique consulting company very
similar to RB Consulting.
And
I have I always loved it then. That was
part of what attracted me to working
with them and I've loved it ever since
is you need to have a point where you
sit down and this is not where you sell
the project or you know get sign off on
it. This is where you say okay we're
going to do this project. This is the
starting point and at that starting
point you need to make sure that you are
actually walking through where we at and
where are we going to go whether it's A
to B or A to Z. What is a and what is
that last point? You don't have to get
all the details, but the most basic
stuff is where are we and where do we
plan on going? Sometimes that where we
plan on going will change, but we need
to have at the start what d it's
literally like if I'm going to start a
journey of a thousand miles, which
directions do I face first to take that
first step? And there are a lot of
things that are involved in a good
kickoff. Introduce a team. Oh my gosh.
Make sure that people know who everybody
is. Whether it's the the customer, the
team itself, even if they never talk
again, the fact that they know those
people exist is very useful to success
for a project. Make sure you swap
whatever it is, business cards and
contact information so the people that
need to communicate with each other can
communicate with each other. Have a talk
about things like where is your document
repositories going to be? Where is it
that I'm going to be able to find the
requirements, the current requirements
for this project? Where am I going to
find design material? Where what are we
going to do for code repositories? What
are we going to who is the customer and
what are we going to do to get stuff to
them? What kind of like a rhythm are we
going to have? Is this what is the SDLC
approach that we're going to take?
There's all these things
we take for granted. And particularly if
this is the first time that we're
working with our customer, let's have a
kickoff where we lay out these ground
rules and basically say this is the
rules we're going to work for and look
work with and this is how we're going to
proceed. Because sometimes that alone
will turn up problems and we'll very
quickly be able to say oh my gosh this
customer, this is what happens many
times. this customer doesn't actually
understand
the data that they work with to a level
that they they're going to be able to
provide the mappings and the functions
around the data for the integration that
we're going to build. That's just a
random example, but I will like I will
call out Netswuite, Salesforce, every
big CRM and ERP solution. And it's not
those tools fault. It is the customer a
lot of times that is not ready to take
that step and nobody sits them down and
says you need to understand your
business and how it works and what is
critical and how to communicate that to
the implementers before we move forward
because a lot of times there's stuff
that lives in somebody's head or it's
sitting in somebody's drawer somewhere
in a desk in an office you know the
other side of the country and that stuff
ends up being critical to the success. I
know I'm being a little vague. I don't
want to call people out too much, but I
just want to say that kickoffs matter
and make sure that as part of that you
line out, outline what is it that we
need for success, which includes where
do we need to go to be successful.
Little bit of a sandbox, a soap box.
Sorry about that. I'm going to set that
aside. I'm going to let Michael get on
his soap box and talk about what he
thinks about this. I'm just going to add
a little bit to because you kind of went
pretty in-depth on this one and timewise
we probably should be getting to the
next topic pretty quickly. Uh but with
this one, you're absolutely right
though. The project kickoff sitting
everyone down internally and externally.
More times than not, the customer
really doesn't know what they want. So
really establishing the why. What is it
that you're building? what is it that
they need needs to be established right
up front. That's why we when we do our
intros, we talk about doing assessments.
Assessments are a great way to figure
out what they have and what they need
and then you can refine that into a uh
proposal for something to build them or
what you can help them customize what
they have for something that will
improve their business or their overall
uh workflow within their organization.
What I have seen lacking is when you do
get to the internal, you're like, you
may have the documentations, but if you
don't really sit down and bring everyone
on board, it can be timely and costly to
do it upfront, but it you have to kind
of get everyone on the same page. Maybe
not do a full brainstorm session, but at
least walk through the project at a high
level. Make sure everyone's on the same
page. And yes, open it up for questions.
Don't make it a total silo, but do keep
it restrictive because that initial
kickoff is not where you're going to be
doing all the brainstorming and things
of that nature. You will be doing that
over the course of time through your
sprints and hopefully through your
roadmap.
>> We we covered a lot of stuff right there
and so I'm going to actually dive right
through the the second section because I
think it's very val. This is some of the
things this is essentially says the
anatomy of a great kickoff. And we've
touched on a lot of this, so I do want
to like fly through these and then
because I monopolize too much time, I'm
going to throw this to Michael for the
next one. So, heads up, you're going to
be on the hot seat. Uh, now we have a
great kickoff. Walk listeners through a
bulletproof structure. Before I go into
any further, I want to say that this if
you are putting proposals out to
customers or potential customers,
prospects,
these things are awesome to cover in
your proposal. It's amazing how often
addressing some of these things and talk
about things in a proposal will improve
your chances for success, including I've
had multiple customers, actual customers
that I, you know, I won the proposal
that said that that was one of the
things that helped me win it. Of course,
if you're proposing against me, please
do not do this, but otherwise, feel
free. Uh, purpose. Define the problem
the project solved. This is the why.
Establish project establish project
goals. OKRs, smart format, PKIs or
whatever it happens to be. What is it
that essentially is like, okay, what is
it that we can say we can go verify that
we actually solve the problem? People,
this goes back to what I said. Who's
involved? Who's accountable? All who
owns certain decisions. Who are the
decision makers is key to the kickoff of
a project. Clarify roles. Developer,
project manager, designer, stakeholders.
Set collaboration rules. Slack,
standups, async updates, stuff like
that. Roles are critical, especially
when you have people that cross rolls or
you have small teams where people have
multiple roles. Make sure you're clear
on those process, agile, conbon, water,
scrum, fall, deployment frequency,
branch strategy, review your flow,
deadlines, demo, rhythm. Ask what can go
wrong. Discuss past similar projects and
what to repeat or avoid. It's almost a
retrospective and a review in itself
just to do your kickoff for those of you
that you understand the agile side. If
you don't check out our agile stuff for
what those rituals are like uh playbook
docs, centralize your documentation. Do
we use conflicts? Do we use notion?
Readmes, Dropbox, whatever. Record the
kickoff meeting. I will add to this.
Record meetings all the time. Just
record everything. It's so easy to do.
We have done it. Yes, I've got gig and
gig and gigabytes of stuff that I will
never look at again, but some of it we
do need. So, record all the meetings
just in case. And now we're going to go
to act three. Michael, get ready. You're
about to
>> quick on that last bit though.
>> With the recording stuff, especially
nowadays with the AI tools that a lot of
them have built in like Zoom, you will
get pretty decent transcripts. At least
keep the transcripts because they are
searchable through your system. So you
can just have all your meeting note or
transcripts out there. And heck, you can
even have AI create meeting notes from
your transcripts. But if you're like,
"Hey, we talked about this." Go search
your folder directory of all your
transcripts. You can find the meeting.
And if you can't figure out what it is,
open up the video and then jump to that
section and it's like, "Ah, yeah, now I
remember." So
>> that is that is an incredibly good
suggestion. Um, it is so much faster to
search for text and find like that like
where did we talk about X? Use th those
transcription notes are very valuable.
That kind of stuff. All right. So, red
flags of a bad kickoff. No written goals
or timeline. Unclear responsibility.
Wait, who owns testing? Stakeholders
missing in the room. We'll figure it out
as we go. Many rant opportunity. This I
don't know if I want to give you this.
Code doesn't solve confusion. People do.
All right. I'm going to toss this right
to you. Thoughts? So, where do you want
to go with red flags of a bad kickoff?
>> Oh, let's see. Uh,
I I can almost
picture one right off the bat. So if you
have a small team, a large project, and
a very small budget, you are going to
red flag is right there because chances
are you're automatically going to be
going in with the mindset of how can I
cut costs and still deliver. And if you
do that right off the bat, you're going
to be, well, we'll figure that out
later. Or you'll
kind of go the easy route. What is the
lowest hanging fruit that we can pull
right now to get started to kind of get
a
small MVP or at least something visible
for the customer to see to start getting
feedback. The other red flag that comes
from that is if you did not define the
requirements, the why from the customer
beforehand, you could be immediately
running down rabbit trails of nope,
that's not what I want or oh, this
button isn't right or you could get way
too confused and lost in things that
mean nothing that are not the MVP.
Um
it just and roles defining roles because
especially on smaller teams testing is
important and if you are both the
developer and a tester getting people to
understand where you're coming from
depending upon what hat you wear is very
critical because you could be asking
questions one day as a developer and
it's very open less critical but the
next day you turn around you're testing
you have to come in more critical. You
have to be asking more deep you you ask
different questions and it can offset
other people on your team that are used
to you being in one role or they're
they're developers. They they used to
developer speak. Coming at them with
tester speak,
you get more defensive. You run into
this in almost any organization and
company. So bear in mind if you are
wearing those hats and you see some
confusion or miscommunication going on
as you're going through the project from
the beginning, you need to stop, reset,
and redefine those rules. Otherwise,
it's going to be complete chaos by the
time you get to the end.
That's all of that is 100% you know
that's kind of those are things that you
need to be worried about and the it how
it can go wrong basically. Um I'm going
to I'm going to focus on the we'll
figure it out as we go. This is very
much an agile approach because there is
a level of we're going to figure it out
as we go. That's part of what agile does
is it says I'm going to take I'm going
to put a couple of stakes in the ground
but then there's other things that I
don't have to worry about. It's it's not
that we're going to figure it out as we
go as much of it's more of an 8020 rule.
It's a these are the things that are
critical and then we're going to get
mostly there and we're not going to
finish them out until we're sure we
really need to finish them out. More
importantly, I have found more and more
and more that the idea of an MVP
should be part of every single project.
Because too often you get further down
the road and suddenly budget becomes an
issue, time becomes an issue, uh
capability becomes an issue, whatever it
is, and suddenly you find yourself
changing gears, fighting fires, and
converting everything into an MVP mode.
Everybody loves a big project when you
start because we've got all of this like
we've got all of this runway. thinking
about a plane on the runway. It's
awesome when you start and you've got a
10,000 foot runway, but when you've been
lolly gagging now, you've got a hundred
feet left and you're only going, you
know, one mile an hour and you've got to
get to 100 miles an hour to lift that
sucker off the the ground before it goes
off the runway. It is panic time. We do
not want to get there. So
I highly, this is
through literally now decades of
experience with this in commercial
development, internal development,
scripts and utilities, you name it.
Whatever the product is, I would highly
recommend always, always, always, I'm
thinking I should write a book just on
this. Always, always, always have an
MVP.
have a this is our minimal goal and that
should be part of your why. That should
be the thing that you can measure every
single choice and decision against and
say, does this contribute to an MVP?
Now, that doesn't mean that you're going
to stop at an MVP. But that does mean
that you need to at some point in your
project achieve or s exceed what an MVP
does. that is really going to help you
particularly early on. It's going to
help you figure out where do you spend
those resources and agile projects are
as bad as anything else about this where
we will sometimes start out and we don't
feel the pressure of time and resources
enough and we spend too much stinking
time building a green versus a blue
button as opposed to solving an actual
problem. And I know this sounds a little
judgmental and I am judging myself too
because I have been there. I have I I
have been in those situations. I'm like,
I've got a whole week I can spend
chasing down random CSS cool stuff that
I can do and I get to the end of that
week and realize that I really didn't
provide value. So I would bonus tip
recommend to you always have an MVP and
then use that as sort of like your your
guiding light. It's like we've got to
get at least to here in order to be
successful. I'm going to throw it back
to you before I dive into the next one.
>> Yeah. So, if you're struggling to
understand what an MVP is or how your
project that you're working on, what is
an MVP for your project? Flip it on its
head. Write user stories for your MVP.
Turn those user stories into tests. And
if your code does not complete a test in
your test suite, you're not working on
the MVP.
>> That's not a bad way that we'll call
that testdriven development. We quoted
it here. That's trust me, we're the ones
that invented that. Um,
honestly, that's ex almost exactly what
it is. It's saying what does this need
to do? build the tests that say okay if
that means if it does this then that
means that this test will succeed
and then you build the application out
to that. So that is literally
test-driven development and it is if
you're struggling with MVP as Michael
said that is a great way to do it is is
you do you start with the user stories
is it's it really is it's focus on the
why focus on the problem you're solving
and then break that down. It's like okay
to solve this problem what do I need to
do and that starts to become your test
and the next thing you know you're like
this is what we are implementing
towards.
I don't want to go too far into this
because we're going to leave some bonus
material for the people that are out
there on YouTube. Those of you are not
on YouTube, you should be because we
have bonus material literally every
episode. Sometimes more, sometimes less,
but there's always some extra stuff,
especially this season.
We have had some pretty cool stuff that
we've thrown out there after every
single episode.
Sometimes very key stuff. Some we only
gotten through like half of the response
of AI. So check us out. Also, shoot us
an email at info@odvel developer.com. I
do not get enough of these emails. I
would love to see that. Yes, I know we
have you guys give us, you know, we'll
get responses. We'll get reviews and
things like that. I would love to get
some emails because I want to I want to
actually connect and hear from you. What
do you like? What do you not like? What
would you love to see us do? That's why
we're here. We are here to not only
build better developers. We're also here
to build a better you. To entertain you,
to inform you, and do the things that
matter to you. Yes, you. I am talking to
you, whoever you claim yourself to be.
That being said, we're going to wrap
this one up. As always, there's so many
ways you can reach out to us. I'm not
even going to bother listing them this
time around, but I am going to tell you
to go out there and have yourself a
great day, a great week, and we will
talk to you with AI next time.
>> Bonus material. Let's see. I'm going to
start with I'll throw this out there.
Um, it's got developers point of view,
why this helps you, and then optional
segments, and then we'll see where you
want to go there. Uh, act four,
developers point of view. Why this helps
you? Less rework, fewer last minute fire
drills, more confidence and autonomy.
Bonus, you're seen as a leader, not just
a coder. That could be a good one.
Optional segments. Kickoff horror
stories from listeners or guests. One
pager kickoff template. Offer
downloadable asset or example. Kickoff
in 60 seconds. A rapidfire checklist for
solo founders. I'm going to let you go
first. I'm like I'm chomping at the bit
a couple of those, but I'm going to let
you handle this one first.
>> So,
I already talked about test driven
development, but the the biggest problem
you're going to run into with any
project kickoff is there are going to be
things you don't know and you're going
to make mistakes.
Be conscious of that from the beginning.
I've done this. Just about everyone has
done this. You think you understand a
project. You think you have all the
pieces you need at the start of the
project and very quickly you find out
you do not have all the pieces for the
project.
Even doing scrum or uh can not
necessarily fix that problem.
You need to stop, reset,
get the information you need to make
sure that you're not going down the
wrong path. You could be starting out at
the right path, but very quickly you
could be digging a trench down versus
walking forward.
I am going to go with the one pager
kickoff template. Offer downloadable
asset or example. I literally in this
moment do not have that thing. If you
shoot me an uh email at info
developer.com and ask for one, I will
create one and if you're the first one,
you will get the first copy of it and
everybody else will get a copy of that
because it's actually a really good
exercise. Uh honestly, if you don't
trust us, really, you don't trust us?
Come on. No. If you don't trust us to do
it, uh it would actually be a really
good exercise for yourself to create a
kickoff template. I actually do have
something like this. It's not actually a
kickoff template as much as it is a
project template. Uh actually, there's a
book that sort of goes through this. If
you go to the uh rb-sns.com,
you go out there. We've got a free book.
You can go check it out. It's uh
software development something something
something. I forget what I titled it
because it's been a few years. Um but it
does have some of those kinds of things.
It talks a little bit about a kickoff,
but I would love to actually go back and
do that. And I think for yourself,
this is one where I'll say, you know
what, you don't even have to shoot me an
email. If you think about sending me an
email, it would almost be a better
exercise for you to create your own and
then send me it and I would love to talk
to you about it. I will literally like
we can schedule a call and talk through
what your kickoff looks like because
I've been through literally I bet a
hundred project kickoffs in my career.
Some have gone well, some have gone very
very bad. Some have killed the project
almost immediately.
Um, and there are there are
commonalities across these. There are
certain things that will help you make
your project success and there's certain
things that if you don't do it, you are
more likely to fail. So, I'm going to
leave you with that little like very
heavy like, you know, thought for the
day and wrap this one up. As always, I
thank you so much for your time. We
really do appreciate you the the time
you spend listening to us, checking us
out, give any anybody that gives us
feedback. We love you. More and all that
kind of stuff like you guys are awesome.
Uh we're that's why we're here is we
want to build better developers. We want
to build ourselves as better developers
as well. So as always, however you want
to reach out to us, we're happy to do
so. Thank you for what you've done and
go out there and have yourself a great
week. Get more effective. Become a
better developer. Come back next time
going, I actually got better since the
last time I saw this show. Have a good
one, guys.