The 4-Bucket Law Firm Process Improvement System - #218

Law firm process improvement dies when we rush it. I learned that the hard way after more than a decade of running Sterling Lawyers. 

Kelley Shaw reveals the 4-bucket system we use to prioritize projects, manage backlogs, and actually finish what we start at our family law firm. 

This is for the firm owners who have tons of great ideas and zero finished projects. The fix comes down to better prioritization, backlog discipline, and real change management. Kelley runs this playbook at Sterling. 

➡️ Register Here: www.RocketClicks.com/revive-dead-leads

📲 Subscribe Now: https://www.youtube.com/@jsterlinghughes

                                https://www.linkedin.com/company/rocket-clicks

📝 Get your FREE Law Firm Growth Guide: https://jsterlinghughes.com/

---

📄 CHAPTERS

0:00 - Law Firm Process Improvement Starts With One Question 

2:07 - Why Pain Points Matter More Than Solutions 

10:56 - The 4-Bucket Project Prioritization Framework 

20:51 - How We Rolled Out a Client Portal Across Four Quarters 

26:19 - Change Management and Getting Real Team Buy-In

33:58 - Accountability Across a Growing Family Law Firm

----------------------

Ready to find the accountability partner you need to build your dream family law firm the same way we grew Sterling Lawyers? 

Follow these steps:  

1. SUBSCRIBE TO JEFF'S NEWSLETTER: https://jsterlinghughes.com/  

2. BOOK A FREE 30-MINUTE AUDIT WITH US: https://rocketclicks.com/schedule-a-family-law-quick-audit/  

3. CONNECT WITH US: 

LinkedIn: Jeff Hughes, Tyler Dolph, & Anthony Karls, 

Facebook: Jeff Hughes, Tyler Dolph, & Anthony Karls, 

Instagram: Jeff Hughes, Tyler Dolph, & Anthony Karls

4. TELL US WHAT YOU WANT:  
Tell us in the comments if you liked this episode and what other kinds of episodes you would like to see.

Transcript

0:00

many of these projects start with a ticket, Okay, let's get those people in the room. Let's get that team or those leaders in a room. And let's talk through all of these issues and figure out, okay, if if the way it's working today is not what you want. How should it work and document that out. 呜呜 well, hello and welcome to the Sterling Family Law Show. I'm Jeff Hughes, I'm your co-host along with Tyler Dolph present as well, our co-host. And this this is an important and fun podcast for me to do today, because I have one of the most impactful teammates in Sterling Lawyers with us today as a guest, Kelly Shaw, to talk about project management within a family law context. Okay, so I know all of you family lawyers out there, you have projects going on, and some of you have projects that involve more than two people. And if that's the case, this is one of those podcasts that you're going to want to forward to other teammates, because we're going to go through some of the best practices that Kelly has discovered in putting projects together and completing them. That's the key point and completing the project. So project management is where the real progress is made to grow family law firms. So there are million ideas out there. I know because I generate them. Some of them are good, but Kelly takes the ones that are special in terms of the men to actual production dollars, client satisfaction, etc.. So Kelly Shaw, welcome to today's podcast. Thank you so Yes. Well thank you. And now, Kelly, one more thing about Kelly. Kelly started, I think Kelly, you're the third, maybe the second or third longest serving teammate in Sterling. Right okay. She started on the intake team and we have watched her finish her degree, get her MBA and move up and pretty much cover every position within our firm, with the exception of maybe a lawyer. Is that fair? That sounds pretty accurate. Okay. Well, we asked you to come on the show today and talk about how you manage projects within the family law context and you being the extremely prepared person that you are. I know that you've put some advanced thought into this. And so jumping into maybe let's start with where you feel like the best practices are. Maybe your flight. Let's start. Let's start with the philosophy you have toward managing projects within a family law context. Sure. So, you know, just think in high level here, when you're thinking about projects and what you have coming down the pipeline. The one thing it's the one thing we really focus on from the beginning of that project management process is to ensure that we really understand what pain point are we trying to solve. But, you know, if that's a user pain point, is that is this a client facing issue? Like what are we trying to accomplish with this particular project and making sure we have that really well documented? Once you understand that pain point, you need to ensure you've got a good holistic understanding of it, because a pain point to one team is going to look different to another team, right? So if it's a workflow, if you go and if you have a request to enhance a workflow, you need to ensure you're doing the research to understand the down the downward impacts of that change for other teams that may or may not be impacted. Right. So just making sure you're looking at the whole process and not looking at it from one individual perspective. Yeah, Kelly, I know when I look at projects that you and your team are performing on, I always look at the what is the outcome I want to see that look like. And so you're looking at it, it feels like from a little deeper perspective, like what is the ultimate pain that we are trying to absolve or to clean up or heal, so to speak. Right, Yes. okay. It's really hard to craft a solution if you don't fully understand the issue. think that's such a powerful point, Kelly. And I think every law firm owner needs a Kelly. Every visionary, every CEO needs a Kelly. Because we get stuck in having a million ideas, right? And without someone to vet those with us, we can get very busy very quickly running down the wrong path. And so I think one superpower you have is, is reigning those ideas in by asking questions like, well, what are we trying to solve here? What are we actually trying to get done? Absolutely. Yeah. That's that that Guardian voice coming out, irks you. Innovative voices sometimes. I know it's that's true. Kelly, you you fill a really important role in a firm because I know I've come to you. It's a hey, Kelly, let's do this. This sounds like great. We can conquer the world if we just did. Just did this idea. And you are asking me a couple of questions, and I go away annoyed knowing that while you're right, it wasn't the right timing. Sometimes a good idea is wrong timing, and you have a way to kind of cut through all that noise. So anyone running projects needs that. So how do you do that? Like what? What are some of the what are some of the character attributes? You have to have to have that kind of fortitude to tell, like your boss know or how do you navigate that so well? There's certainly a part of it that is innate and a part of it that is learned. Obviously, as you mentioned before. I've, I've, I've sat in a lot of different seats throughout the firm, which I think has led me to be a particularly well skilled for this because I really understand a lot about like, what are what are a lot of our different teams doing from day to day. So I know how to ask. I know just intuitively like, okay, if this is what you want to do, for example, you know, Hughes, you like to come up with lots of new service ideas. Okay, well how is intake? What is the pitch for intake sound like? How do we make it so that intake doesn't have to remember how to input that into Salesforce. So I'm just I'm I'm a lot of times what I'm doing is starting from that very first client interaction in my brain and thinking through, at what point is that going to touch that next team, and what are the systematic things that are impacted by that? Yeah. Yeah. That's so easy for me to kind of look over all of those teammates who have to put their input on that to go from my idea or someone else's idea to something that's actually serving the client that works for them, that we can do at scale. So. Okay. And you also seem to have a process for taking an idea and say, you know, now's not the right time. Let's kind of parking lot that to when I know we're going to have better timing around that a year and a half from now when we launch our app, for example, or whatever the case is, how do you how do you do that and what are your what are your learnings there? A lot of that comes in with managing our backlog. So Nathan and ISO Nathan is my counterpart. He's more systems focused. Like he knows I'm not obviously not a developer. Right. So Nathan, is that more technical counterpart to me where I sit more on the user experience side. But what you're describing, like how do we prioritize the timing? Things like that comes from managing that backlog of project. So we're looking at that list twice a week. And Nathan and I are like in lockstep. What is this? What are these pain points associated with each of these projects? And we're also documenting dependencies there. So for example document generation right. We are looking at and have on our backlog what what opportunities are out there for document generation. We have we're using a platform called stocks right now. We want to reevaluate that. Or is there another platform out there. Well, I'm keeping track of okay, when does our stocks contract expire? I'm also keeping track of okay. What other types of document platforms are we using. So we're looking and we're having those conversations. I mean, a lot of it comes down to just being having a lot of really good conversations and having well thought out agendas. But that backlog is, you know, to your point, where we're doing a lot of that. Okay. What conversations are we having about DAC Jen? Where is that project? Are we ready for that yet? No, because this contract isn't this contract isn't up for a few years. We're not going to start looking at another product for that until we get closer. Things like that. But that that product backlog combing is where a lot of that kind of prioritization happens. And Kelly, for our listeners, what project management system are you using today and do you like using Monday. And has that been effective for you? I like it because it's easy for our systems team to kind of interact with and stay organized. Yeah. I mean, it works pretty well. It's pretty easy to manipulate and pretty easy to kind of create your own dashboards. So yeah, it works pretty fairly well. Kelly, we recently did an episode with Jeff Kerlin on planning, and we talked through the best practices for planning. And I know you're a part of our executive leadership team. You sit on those planning and you in a large part, are touching all of the projects that are being worked on throughout a given year. And so you've developed some well-honed pointers on how do you prioritize those projects and those all those ideas that sit in your backlog or that come out of the blue, how do you do that? Yeah, I love prepping for planning that. Those are some of my favorite conversations to have. So part of that process leading up to those planning sessions that we have, I meet with each of the team leaders, right. So I have a conversation with Mary from a sales perspective. I'm meeting with the MPs about legal team projects, and I go through their backlog because my backlog is organized by stakeholders. Right. So I can pull up a list and say, here are all of the projects that impact the legal team and which like where are the pain points for your team? I generally have a fairly good idea of what those pain points are and what which of these projects on this backlog are going to impact that pain point. So I have that conversation before planning. Like here's what we've got on your list based off of what I know about your team. Here's my recommendation. Does that sound in line with what you think we should advocate for at planning for a rock? Usually we're usually because I actually have those project meetings with those team leaders, like the MPs I meet with once a month. Mary, I meet with weekly, and I utilize those project meetings for a couple of different things, but looking at that backlog as one of them. So by the time we get to planning, there isn't much of a surprise like we like we're in lockstep on what is probably going to get brought up at planning, but I still use that meeting to confirm and make sure I'm not missing anything. Okay. And what are your your, your best practices around prioritizing those projects that you that you're looking at are considering? That everyone you meet with believes that their idea is the best idea for the business, and that they should get it pushed through? How do you how do you help them understand the bigger picture? So helping helping teammates better understand that bigger picture. I mean, sometimes it's a lot of making sure they understand how their request might impact other teams. That is just, you know, because not everybody can be thinking about all of the processes all at once. Right. So there's that. But the other piece, like how do you prioritize really kind of falls into four main buckets. One is and these are very high level labels but business impact. So what kind of impact is this change or this tool going to have. Is this a client facing impact. Is this going to be limited to intake. Is this intake and legal. Is this going to impact reporting. So kind of evaluating that like how how big of a change or how big of a project is this. The next kind of bucket is feasibility and resources. So evaluating do we have the people in house to do this or do we need to go out and find someone. So there's kind of that cost benefit analysis there that happens. Is this going to require the assistance of our offshore development team enabler solutions? They are a really good partner for us. We work with them a lot. But how big of a project is this? What is the cost generally associated with this kind of development? So that's number two. Number three is urgency and dependency. So evaluating are there regulatory things coming down the pipeline that we need to consider. Like is there a recent decision that is making this project the forefront of our mind. Are there other projects that need to get completed before we can jump on this? So kind of looking at that holistic, that holistic view of what else is kind of is in the hopper, as it were. And then buy in is kind of that last one. So who is making this request? Are the users that are going to be impacted by this product or this change? Do they understand the benefit? Is there a risk that this will have an adverse effect on the stakeholders? Right. Because there's there's always that element as well. If this doesn't go well, what's the if this project doesn't roll out or this project flops, right. Luckily, I don't think we've really had an example of that. But what's our rollback process like if we don't do this right? Is there an impact to the client? Is there an impact to conversion. Is there an impact to cash flow. Right. So making sure that the stakeholders who are having those who have to prioritize and have these conversations really understand those downstream impacts. So those are kind of the for the four buckets. It's really helpful, I think, for our listeners, if we can kind of put this into a picture or to explain how you actually manage some of these projects. So I believe you've been working on our client app project for most of this year, right? Okay. So that project came to you at the planning for last year, right? Am I getting this right in for 24 for 25 year? So that has actually been on my backlog for a couple of Perfect. Okay. Walk us through Kelly. Like this project I know that we've talked we've talked about this going back to like, I don't know, 2019 probably. So it took a while for us to get to the point where we could actually execute on this. So that's a great illustration to help get a picture in your mind for our listeners on how they can see a project from start to finish or walk us through the history of that particular project, applying even these filters that you just gave on prioritization. Sure. Yeah. So I mean really the the impetus for the client portal came from like this. This was a strategic advantage that we as a business, as a leadership team knew we wanted to have at some point. We knew that that would improve client stickiness. We knew that having an having a way for clients to access their documents, to collaborate with their legal team, with something we wanted to prioritize. So This could be an app on their phone. You're calling on a client portal, but it's an app like you download. Okay, perfect. Okay. So we're talking about the same Yes, still talking about the same thing. And the the only reason portal kind of came in is because one of the platforms that was originally recommended for this was more of a portal than an app. So that's the only reason I'm using that. But so we had originally. So and this kind of goes back when we were working with Keith. So Keith actually kind of did some of the initial research utilizing Salesforce communities. They have this portal function. And we were we have been cataloging over the years. What are the benefits? What would this have to look like to be really beneficial to clients? So we had start we oftentimes have living what we call research documents. What what are we trying to solve for here. Well, some of the things we're trying to solve for with the client portal is we want to have we want them to be able to have one place to go to access all the documents that their attorneys have shared with them right now. And I'm sure anybody listening to this can sympathize with the the issue of having to just email things back and forth. Right. Or you're using a secure messaging. Right. So client feedback over the years has been it would be beneficial if I just had one place to look. I know where to go to find it every time. The other piece of it is sharing sensitive information, social security numbers, bank statements, things like that. Being able to give the client a link that says here you can put all of that stuff in this secure folder specifically for you. So we're kind of going back to your question, which was like, how did this all develop? We were gathering these requirements kind of over the years. And then when it felt like it was a good time to consider, okay. When do we it is now a good time to do this. Right. We're talking about expanding. We're talking about we're in a good place. Revenue and cash flow wise like now seems like a good strategic time to have this conversation about taking this client experience to the next level. So that conversation that we really kind of put the research into like 110% like full year, right? I did interviews with clients, past clients and said, this is what we want to do. What are the things in your opinion? Does this absolutely have to have? So I had a lot of good conversations there. That was a lot of fun. And we put together those requirements like, here's our bare minimum that we have to have. Here's the list of these would be nice to haves. Right. And then we took that and we worked with Nathan and we created a vendor matrix of, you know, how do each of these vendors that we're going to interview, how do they score on this. And then we that's how we chose. We chose we ended up moving forward with Hona. And we're now in the process of we're doing a phased approach to roll this out because we want to make sure as we're going through it, once we start having aspects that clients can test out, I want to start pulling in a couple of clients here and there to say, hey, how does this work for you? What do we need to tweak? Because the last thing I want to do is turn it on and have all of our clients have, you know, an experience all at once and not have that kind of like quality control over it. So we're really doing a very intentional, slow roll, phased approach to the client portal. Does that answer Yeah. That helps put some color behind the timeline to get there. Because you could have done all this in two years or three months. So how long did it take to get to this point where you're at now? Not taking into consideration like that the research Keith had done like years ago, I would say I mean, it's probably it's October now. I mean, it's between like the vendor analysis, like we took one quarter to firm up what we absolutely wanted to have for the clients and do the vendor analysis. Like we just that's all we did for that whole quarter. When was the last time your team called to book a lead who didn't book? If you can't answer that, neither can your intake team. And that means every lead. Who said I need to think about it is sitting in your CRM right now without an owner, without a follow up date, and no next step? That lead is not dead. That's revenue that you will not get that you forgot about. At Sterling Lawyers, 75% of our revenue comes after that first conversation, 75% meaning even if you just do this poorly, you will change your firm over night. We track this across thousands of cases, and we found the money in the follow up. We're teaching the exact follow up system behind that number in a free training. How do we prepare for every call? What do our agents actually say? And what is the cadence that runs behind every lead until they book? Please see the link below so that you can sign up today. So that would be like Q1 of this year in 2025, just that in Q2, you don't have to be exact on this, but Q2, what did it look like? Would you do in Q2? Q2, we started to do research on what. So in in the portal that we're using the platform, they have a they have like a phase display. So we started research with Kim and Rebecca. What do we want our clients to see. How is that going to look different for a divorce versus a paternity case versus a child support we identified? Okay, what cases are we going to do first? Because I trying to do all of the cases all at once was going to be just way too much. So we chose three case types are the case types that we handle the most of right. Divorce paternity custody placement. And we started there. We identified what should the client see when they log into their client portal. How what kind of information do we want them to have access to. Right. Are we going to have an FAQ. Are we going to have like phase description. So that's we spent most of Q2 really honing that in for these first three case types. And then it was how do we trigger that for the clients. So what is going to be what is going to be the trigger for the client to tell them okay, your case has now been filed and now you have your first court date coming up. We also had to think through what happens if it's limited scope versus full rep. So the really nitty gritty. Boring details that make it all the difference here. Yeah. So in Q3, rather, what was the priority in Q3 on that project? So Q3 the priority was we had to do some additional development to give our clients access to their box folder. So boxes are document management storage platform that we use. It's integrated into Salesforce. We needed to do a little bit of we needed to do some creativity to get our clients access to that. So we had to reach out and we actually needed to pull in some external resources to help us with that a little bit. So we were determining how do we get our clients access to their documents, how are we going to reformat or intake forms? Because in today's instance, we have several different intake forms based off of case type. We still wanted to keep that. We still because we don't want to have we need to get the right information from clients without having to create 10,000 different intake forms. So we went through we ended up having four different intake forms that are case based. So we were working through those details. How do we need to set up the sink between Salesforce and the client portal? Because the other thing we need to make sure is that we're not asking our legal team to operate in two different platforms. We need to make sure that these things are in sync together so that so the intake form and the box folder, and honing the triggers between the phases. That's what we spent a lot of Q3 What's the priority this quarter? Q4. priority this quarter is we are going to towards the end of Q4. We want to get some test users in and using the intake form. I also am finalizing the phases for all of the other case types. So prenup restraining orders, property division, etc. we're going to we've got those phases all figured out, all those triggers figured out. We had to we had to wrestle through the triggers for those. And how do we account for limited scope and coaching? Right. Because we have like the document review, we've got the court prep. So answering all of those questions as well, how do we how do we implement those. How do we how do those look and feel to our clients. But yeah, so the goal for the end of Q4 is to have a couple of test clients in the client portal, the client app, utilizing it and actively giving us some feedback on it for divorce, paternity, and custody placement. Yeah, let me just share this from the from the leader perspective. I'd like I struggle with patients, right. Like all like all many leaders do. And I would have tried to take a project like this and ram it through in three or 4 or 5 months. At the longest, I would have been excruciating long to me. And obviously you're laughing. I can see you smiling here, Kelly. You know what would have happened had that occurred? Just to kind of recap how you took this massive project touching many aspects of our firm and broke it down into bite sized chunks. So less is more on how you approach this. Each quarter Q1, you went through the select, you and the team went through the selection process, the criteria you just focused on that. You got that done in Q1. Q2 came, then you started getting buy in. You went to Kim and Rebecca. Two of our paralegal leaders got their input, got their involvement, that their fingerprints all over this project. Find out what the clients really want on a day to day in the trenches basis. Then you went into Q3, you you needed outside development to kind of get a lot of that stuff ready, prepared, put together and really get it client ready as much as client right as you can get within a quarter. And then now we're in Q4 this year, I would have expected this to have been launched back in Q2 and it would have failed. But now we're in Q4 and you're testing you're going through the slow, tedious process of testing it because we've got 970 plus clients active right now. We can't roll this out to all of them, or else it'll be a massive like, bang your head against the wall headache. If we start having breakdowns among that many clients. So you're in test with a few and then probably launch this Q 2 or 3 of next year fully across the full team as you've kind of vetted this out. Right. So that that's a for those project managers, that's smart. That's the way you get a project at the door. And for those of us that are trying to push the growth of our law firm, please pay attention to that. Because sometimes slow is fast. And it's taken me 11 years in my seat to start to appreciate that. And I get it all the way. Kelly, I know you're going to say that I don't got it all the way. I got that. But to start to understand that. So that's really, really smart and how you how you look at that. I think the beauty of that process, coming from someone who likes to get things done very quickly, is I was sitting here thinking, how many good or great ideas have we had that didn't work because we tried to push it through too fast. Right. There's got to be so many that if we would have had a Kelly that could have taken the time to do it correctly. That's where your whole low, smooth, smooth, fast approach really comes in. Kelly, I've watched you also launched some of these projects and that requires a lot of change management on your side on the team sign on our other leaders. Can you talk to that a little bit on how you take a project, whether it's this one or another one, and begin to enact the actual change in behavior and thought acceptance that you get. What are some of your best practices there? I think a lot of that comes from pulling the users in sooner rather than later, getting them involved in those conversations from the very beginning to identify that pain point. So, I mean, many of these projects start with a ticket, like an enhancement request for a couple of tickets, right? Like a you get a handful of tickets from the same team related to a dashboard or related to a task flow. Okay, let's get those people in the room. Let's get that team or those leaders in a room. And let's talk through all of these issues and figure out, okay, if if the way it's working today is not what you want. How should it work and document that out. And that immediately creates, well, one, it's demonstrating to your users, like your internal clients that heard them. And how do we how do we need to fix this for you so that this does it does the work you need it to do. So that right off the bat you're creating that by in for this project in the future. That doesn't necessarily mean you're going to work on that project or prioritize it right now, but you're laying the groundwork for, okay, now we have this documented. We know what the main pain points are. Let this may not be the right time to take the next step, right of starting that functional spec, starting that proof of concept doc. But at least we know that this is a pain point that we need to prioritize in the future. So that's part of it. From there, you know that a lot of it is just making sure you're keeping that communication open so that they know. And this is where those project meetings come in. Here's where we're at with that project. You know, if it's been prioritized to work on currently Im explaining, okay, we're in the we're in the process of a functional spec. Once that functional spec is up and in the sandbox, I'm going to pull you in. I'm going to walk you through it so you can see this in real time. What we developed for you, did this hit the mark or does this not hit the mark? Right. I'm going through my project plan as as we're going. I make my project plan for my research right after we have that conversation and I walk the the users through. Okay, here's what we said you needed it to do. Is this working how you wanted it to or is it not? And we we iterate from there. Right. So if we come back in that initial user acceptance testing and we miss the mark on maybe, maybe the end solution is correct, but how we got from point A to point B isn't doesn't work for the for the for the user for whatever reason. Okay, I have to I have to go back and do a little bit of a, of a tweak here with our coding or with a flow. We do that, I pull them back in and we look at it again. So it's really just a very iterative process, making sure that the team is aware of it the every step of the way. After that, you know, they they have the final testing and like, yes, this works the way I want it to. I start doing the documentation, the how to docs I coordinate depending on the size of the project. Right. If I need to coordinate doing in-person training, sometimes I will do that. Sometimes, depending on the project, the generally the department head will do it, but if it's a more complicated project, I'll hop in help or Nathan will train in and L10, make sure they know how to access the demo videos or the how to docs. And then the final piece is really after it's launched. What issues do we have? Right. Making sure that we're putting in tickets, like where did we miss the mark either in our testing or in our research? Yeah. So that I mean, that's I'm talking high level, but the change management process, I mean, we kind of build in touch points throughout our software development lifecycle to ensure that they know what's happening as the project is moving forward. So on that post launch, those postmortems that you do. I know that watching you push through quite a few projects over the years, you've developed a finely honed set of tools, your best practices. I think this is where the gold and what you have to share with us today is that, by the way, so walk us through what are some of your best practices that you've picked up and you've been honed over these years on how you push projects through and a family law firm? So I talked a little bit about the backlog meeting. So those are the meetings that I do with Nathan. That's a crucial part of just making sure nothing's falling through the cracks. The other is the project meetings, making sure that those team members know what's on their department's list and that they have by in on like I am in those meetings asking, what is the next thing your team needs developed like give me give me the prioritized list one through ten. What is it? And the idea there is when we finish whatever project we have, right when we come to the the next planning, or sometimes I'll move, sometimes I'll move smaller projects up in a quarter, depending on, you know, if I have available and resources. Right. So I know in that from that prioritized list, this is the next thing they need from us. Let's move it up. Let's look at that research. Let's start that functional spec wherever we left off on that project or wherever we're at with it. So having that, having that backlog, having those project meetings where those team leaders get to give that input is super important and has been a game changer. The other thing I will say as a best practice is just having these standing meetings that I know, like, particularly with some of our turns, Katie, Holly like their calendar, their poor calendars. So I just I have I have a recurring meeting with Mary, with Katie, with Holly, even Kim and Rebecca. And if I don't have anything that week for them, I let them know. And I just take it off their calendar for that week. But I'm putting on those calendars for that week. Sometimes I'll do it like weeks ahead of time. This week we need to test this dashboard. Or this week I need you to review the how to documentation that I created for this tool, so that they always kind of know if they're looking ahead or if they need to determine, hey, do I need to have this meeting with Kelly this week? We're either prioritizing your backlog. If we haven't done that and we're looking at user acceptance testing, but having that saved time with those users has been invaluable. And then the last thing I'll say is just my calendar, like I utilize Monday, as I mentioned for the sprint planning and I am that is just in lockstep with my calendar. So I go and I calendar out what are all the things I need to do this week? What research do I need to make time for? What testing do I need to make time for? Who is waiting for feedback on a functional spec? And I'm putting those details on my calendar so that I know, like, here are the things that need to happen and move these projects forward. Kelly, we've got, I don't know, going and getting close to about 100 teammates. And I know many of them are on some project that you're you're tracking. How do you how do you hold us accountable. How do you hold teammates accountable. What are some of the best tactics you do that you use to hold people accountable? Something that has worked well for me recently is I utilize like one of those meeting bots like fireflies to just record and transcribe, and I actually keep all of those notes because it does happen where someone's like, hey, we didn't want this to work that way, or why is this being displayed that way? And I can actually utilize because I'm not dealing with like client facing things I'll actually utilize like ChatGPT to say, hey, here's my meeting notes from like this whole project. Where did we talk about this? What was the consensus on this? And I can I can then pinpoint it back to a date and say, hey, this is what we said in this meeting about how we wanted this to work. if we're changing our mind now, this is a V2. Kelly's keeping receipts. I gotta remember that next time I I'm meeting with her. on this day at this time you said Yeah. Well, Kelly, this has been tremendous. This is I've just really enjoyed hearing you talk about this because some of the stuff I didn't know, it's a really, really smart thinking you've put into building our projects and getting them done. So thank you for coming on today and talking about them. 呜呜呜呜