ERP111 - The Unofficial Project Manager

It's interesting, there's a lot of people both in the official project management world and unofficial that end up like in some organizations you can go on a leadership track, or you can go on a like a technical genius track, right? And so a lot of people are like, nope, I don't I don't lead people and so but then they get projects. And it sort of boomerangs on them because it's matrix, they've got a bunch of people that they need to work through to get the work done. So if they don't have people skills, it's a bit of an issue because you're usually not working on a project by yourself. Welcome to Evolved Radio where we explore the evolution of business and technology. I'm your host Todd Kane. This episode is brought to you by Evolved Management training courses, a whole series of courses built specifically for your MSP training needs. There's a project management for MSP's course, an MSP service manager boot camp, MSP security fundamentals, and an IT documentation done right course. Check out the full suite of courses at training.evolvedmgmt.com or look for a link in the show notes. Today I'm speaking with Corey Kogan, VP of content development at Franklin Covey. Corey and I dive deep into the world of project management. Corey shares invaluable insights on the practical skills of managing projects whether they're official or unofficial. We'll explore how breaking down tasks and setting specific deadlines can reduce risks. The discussion extends to the attributes of successful unofficial project managers emphasizing that good organizational and people skills can often outweigh technical expertise. Corey provides actionable advice for those managing teams without formal authority, stressing the importance of high trust leadership behaviors such as respect, listening, and accountability. Corey also highlights how everyone is a project manager in some capacity their life, so I'm sure this episode will be valuable to everyone. Now, let's get started. Corey, welcome to the Evolved Radio podcast. Thank you, Todd, delighted to be here. Yeah, so we're going to be jumping into one of my uh uh favorite topics, which is project management and uh having read through your book, you definitely see this through the same lens as me, which is amazing. So glad to see that uh uh we see the importance of project management uh to some degree how underserved it is in some areas of business and how uh it's maybe not as difficult as we tend to think, it's it's a practical skill that, you know, anyone I think can learn. Do you think that's true? I do and uh it's always interesting because I think, wow, uh people must say, Corey, get a life, how could you be so excited about something like project management? Um, but it is a skill because I always say, we probably didn't aspire to be project managers, but we do it intuitively at home too. I mean, if we plan a dinner or a wedding, we're doing project management and if people knew what to look for, they would see dependencies and durations and all those things that go into project management that we love to talk about that they don't know about. But they're doing it. Right, yeah, it is everywhere, right? Like that's that's a great way to phrase it is like project you're project managing in all all sorts of areas of your life without recognizing it. Which I guess lends to sort of the the the title of your book is Project Management for the Unofficial Project Manager. And I think that's a really important um distinction, right? Because like I I another term I've heard used is the accidental project manager. As you say, like you don't talk to a lot of people that are, you know, going into uh college or graduating and saying, I'm going to be a project manager. It's there may be some, but it's often not a focus area, it is something that people sort of end up doing. Like they they either are they uh they're good at it, they have some administrative skills, people rely on them for these types of uh uh areas of work in a business and they end up doing this. So, um I I think it's important to sort of highlight this that, you know, it can be accidental, you it can be unofficial. You're you're you're lending a skill set to an organization that you tend to really be good at or have an interest in, right? Well, the word uh no pun intended, but evolve, right? Evolve management, it's it's an evolution. And where where it's actually happened is this move from the industrial age, the knowledge worker age, we are knowledge workers. We are paid to think, innovate, create, and execute. And so when you think about it, uh without artificially, we have sort of slipped into this role of making things with a beginning and an end to serve a purpose. And I think the pandemic really highlighted this uh for us because when everybody went home and you have all these new systems that had to be built and new ways of working and all of that kind of stuff, we were innovating and creating and making things more and more. We just as as I've heard you say, we're not officially building bridges and hospitals and all that kind of stuff. But we are making things, whether it's learning programs, marketing campaigns, new systems for remote work, all those kinds of things. Uh and uh we've just sort of been pushing our way through with our talents. When in fact, there's an underlying set of skills that can be used. So it is sort of cool these days to be or have evolved into being a project manager because it is the thing and it's only going to get more intense over the next few years. Yeah, absolutely. It I mean, it's really true, like um I I the other aspect of this is I feel like somebody has to do this, right? Like I see a lot of organizations that are, as you say, like projects are everywhere, they're pervasive. Uh but we don't tend to either formalize them or think about them in this way. Uh and I think it is important to to bring a bit of that rigor, right? You like like I've I've said before, you uh you're kind of quoting the we're not building bridges because, you know, do you need to be a PMP in order to be a project manager? No, you don't, right? There's a lot of these fundamental skills that you can pick up, you can practice um that will lend itself. And as I say, someone has to do this stuff. So, you know, who are you picking in your organization to be the project manager if you don't have them? There's a lot of important skills that you can continue to develop and evolve uh once you get into the practice either intentionally or not. But I I think just getting started to have someone designated as a project manager is crucial. And in a lot of cases, I've told people, you know, who who needs to be the project manager, it doesn't need to be someone ultra technical. It doesn't need to be the King Tech in the organization, it doesn't need to be the most advanced programmer, the smartest person in the room. In a lot of cases, I've seen great project managers come out of administrative people, like office managers that were just somewhat organized. They had good people skills and they end up being incredible project managers once given a chance. So I I think you need to look sort of farther a field or around who could potentially pick up these skills. And I know that you are pretty adamant about people skills being a central theme to this, right? Uh, I am. But I love what you said because anybody, I mean, you know who they are. It's like, oh, Mary's so organized. She, you know, she knows how to get things done. Keep in mind the definition of a project is things that begin and end that serve a, you know, a purpose or whatever. So Mary gets things done. Can Mary get things done with and through other people? So, because it's interesting. There's a lot of people both in the official project management world and unofficial that end up like in some organizations you can go on a leadership track, or you can go on a like a technical genius track, right? And so a lot of people are like, nope, I don't I don't lead people and so but then they get projects. And it sort of boomerangs on them because it's matrix, they've got a bunch of people that they need to work through to get the work done. So if they don't have people skills, it's a bit of an issue because you're usually not working on a project by yourself. Although there is some of that out there. And so, um it is if you do not get that, that to win at a project, to get it done with high quality on time, on scope. Um, or whatever the value was supposed to be. Uh, if you don't get that I need to empower people, engage people to want to play on my team and want to win, that's a problem. And we're not talking about a functional, I'm the vice president and so you need to do it the way I said so. That's a whole another show we can do on how that doesn't work. But it's usually people that don't report to me and so it's about informal authority. How do I engage with people so they want to play on the team and want to and want to win even when the going gets tough? This is a really, really crucial aspect that I want to underline as well. Because as you say, a lot of project managers exist in a matrix organization where they're directing people that don't report to them for a short period of time. So A, it's difficult to build rapport with someone in a short period. Uh and B, you have no authority over them, which technically shouldn't be necessary if you're doing it right. But, you know, it certainly helps to to be able to have someone respect the authority and to to sort of uh provide the the necessary respect. Uh to organize something and get get some priorities done. Um so, you know, because a lot of people are existing in this unofficial project manager phase uh that like they don't have the authority to draw upon. So any any bits of advice for people that are sort of falling into this, recognizing they have a team that doesn't report to them and how can they best influence them? Yes, I I I do. Um, and it just an interesting point we, you know, a lot of times when I do this work, I will poll or get data around asking people, why why do projects fail? And the list comes out the same, I'm sure you've seen the list. No matter where I go in the world, the list, it's become status quo. No clear objectives, not communicating, wrong people in wrong roles. Scope creep, all those things. And you think about and then you say to somebody, hey, you're going to be on the project team. And and they're like, oh gosh, you know, we know the I'm okay. And let me get myself ready for unclear objectives, no communication. So it's become status quo. So there's another layer that we need to help people get through. We need to minimize those failures. But the mindset of people working to work on projects is are they inspired at all to work on any projects because most of them fail because we don't have the right systems in place or the maturity in project management to really get through to win. Having said that. I will also say for a lot of these project managers, they had, like I said before, no intention of being people leaders. And you and I know Todd, there's a million leadership courses out there, including our own and yours that people can take to get better at it. And we said, you know what, these people don't want a whole thing. They just want to know what are the few things I can do. So we borrowed from some other content of ours uh the speed of trust by Stephen M. Covey. And where he highlights the 13 behaviors of high trust leaders. We took five of them. And we said for the unofficial project manager, if you can just be very good at these five and I'll tell you what they are. That if you can just master those, you are better than some leaders already out there today. And they are as follows. Number one, demonstrate respect. Second, listen first. Third, clarify expectations. Fourth, extend trust and fifth, practice accountability. Now, your listeners and you can say, oh, well, you know, our parents taught us we should demonstrate respect and we need to listen. We always hear that. Great. And tell me how you do when you are under pressure. Because and I'm originally, I'm born and raised New York, you can tell how fast I talk and all that, not to stereotype myself. But as an executive leader for many years, I have to tell you when I'm under pressure, the thing that comes to my mind is just do the work. Just stop asking me questions. That's real life. And so how do I learn, how do I discipline myself knowing that I need an inspired team that will go out there and really fight for this project. And so in the heat of the battle, how do I demonstrate respect, listen first and do all of these things? So if we can just master those five most of the time, you're going to be way ahead of a lot of others out there. Yeah, awesome. And let's key in on accountability because this is something I talk a lot about. Um uh my favorite description of accountability lately is uh accountability is inherently a social action. Which is really beautiful, simple way to encapsulate what I think is misunderstood about accountability. Is that people want people to just be accountable, right? As I like I wish the team would just get these things done, I asked for something, it didn't get done, I wish they were accountable. And missing the fact that there's a social component to this, it has to be a feedback loop, right? And I think the you you put really well in the book, I'll read this quote about accountability is by keeping your own commitments regularly and consistently. Uh you can consistently hold people accountable for theirs, it might surprise you, but strict accountability makes people more engaged, not less. And I strongly agree agree with this. Because um what I often tell people is like your team and your company is often a reflection of its leadership. And as much as you want people to be accountable, they're watching your actions and if you sort of make commitments and don't hold to them, uh your deadlines slip, then, you know, it's okay for everybody else. So why are you holding people to a separate standard? And inherently, I think teams want to perform, they want to win. And if you're a part of a performance culture that it has a high expectation and it's it's an it's a sort of a standard that is maintained. Everyone that is the right person on that bus will pull the line and get behind that and start to perform together. But, you know, if you've got two underperformers in a team of six, you know, it's it drags it down to the lowest common denominator. So, those are my thoughts on on accountability, I'd love to sort of hear yours or build upon that if you like. Yeah, all great thoughts and love the way you uh established your thinking around around accountability. Um, and, you know, I I I don't need to repeat what you said. You need to be the role model, so if they don't see you being accountable, they're not going to be accountable. But it's also how you have to hold part of your accountability is holding them accountable. So, like you said, it does enhance performance. But if you're in a project meeting and and we call a particular meeting a team accountability meeting. I'll come to that in a second. But if if you're in a meeting and, you know, Mary shows up late a couple of times in a row, nothing and the team doesn't see you holding the team accountable. Then Tom is going to go, ah, nothing happens, I'm going to take my kid to school tomorrow. You know, because I can show up late. That's a problem. The whole thing, you know, once you break a standard, it's broken. And so that's, you know, that's a bit of a problem uh as well. So the team needs to see you holding accountability. Remember, you have to demonstrate respect and all of those things. You can't embarrass people in the meetings. Uh so we do a lot of, you know, if we you think about those five behaviors, how do I do it in a way that's respectful? That the team is not going to turn, but everybody is like, no, I get it, I'm I'm going to make sure I show up to every meeting, you know, accountable. The other thing that I'll say about accountability is when you give the team voice. Uh, they choose to be more accountable. So we strongly recommend and it's part of a lot of our processes. We say bottom up, we don't mean that in a in a bad way. But the the project manager shouldn't necessarily be telling people what to do. The project manager, you know, should be, you know, diagramming out the project, making it a visual. I mean, today with today's technology, everybody can see it whenever they want, you know, go online, see what's going on, so they know where they fit into this whole thing. And essentially, the team should be, I mean, listen. We're not doing one project at a time, we all have like seven. We're completely overwhelmed, so it's not that I want. But that the team is able to be responsible to go, listen on this project, knowing who we are, you have my commitment next week, I'm going to get no matter what, I'm going to get this one thing done. Uh and and I'll I'll report out on that and and and our meeting is about keeping those commitments and making those commitments. So the team is making the commitments around make it saying by next week, I'm going to make sure this is done right on time. Uh and the project manager's job is to what we call clear the path. Is you're not telling them what to do, they are making the commitments and your job is that when you can't get a hold of facilities. That the leader at their paygrade does what they need to do to clear the path so the team can do what they need to do. That's great. I love that example too, it's very similar to an example that I suggest to people around what you can do to sort of own things and win some respect with the team. Is, you know, I've called this person, we need to get access to this building and, you know, I've called them twice and not heard back. Like, you go do the other things that you need to do, I'm going to go chase this person down. The person's like, oh, wow, okay, cool, like they're actually like doing things for us and not just telling us what to do. So I think it's it's an excellent sort of simple example, like anyone can do that, right? But it can really win a ton of loyalty when someone sees that you're kind of stepping up and taking on some of the dirty work to help them be more successful, right? Yeah. All right. So, let's get into some practicals. So, some of the things that you're you're you you sort of lay out in the book uh goes through sort of the stages or the life cycle of a project. And uh I keyed in on a couple that I really like and and sort of wanted to to dig into. Uh first one is um you have a description around sort of proper scoping and planning and describe it as the sensitivity to initial conditions. Um and then the idea that the project will inevitably require course correction and you just have to understand that that is a given. Right, so those these two things I think are super, super crucial. Um I feel like, you know, 80% of the success of a project is built into the planning of that project before you even sort of get started. Uh maybe pre-kickoff, certainly sort of as a part of that kickoff and launching into the project. The more sort of scoping and planning that you can do, the more success you're likely to have. But regardless of how much planning you do, it's ultimately going to go sideways and get pair-shaped at some point. So, that has to be the expectation of constantly sort of reshaping this thing at a high cadence in order to sort of bring it back on track. Uh your description of, you know, you want to fly from uh from London to New York, but if you're not course correcting on the plane along the way, you're going to land in Rio, right? And that's that's a great description of of projects is like inevitably these things go off track. So, uh let's let's dig into that idea of scoping and proper planning and then just the inevitability of course correction as a part of the project. Yeah. Um, and a lot of what you're talking about, I'm going to throw lingo out there. They're I'm sure you you know, but your audience. You know, we we blended in this day and age, uh it was really essential, we blended some of the best practices of uh waterfall project management. So if you're building a bridge, right, uh and agile, so if you're a software company. Uh, you know, you and we blended the two because what we don't what we don't what what can't really be anymore. Is that we lose sight of the value of the project holds when it's released to the client. And so, you know, if you were doing a, you know, scoping as an unofficial project manager before, uh and you got to a scope statement. For a while there, it was like, oh my goodness, somebody wants a change. That's terrible, you can't go off scope, right? What we've learned and the whole agile movement really helped with this. And the software industry sort of led out, but we're not talking about necessarily IT and software at the moment. It's across the board, but some IT projects. Um, is that the the overall ideal is are you providing value to the client? And instead of waiting until the the project is finished. And then getting all the feedback, which I'm in the middle of one right now, so I'm not perfect either. Uh where the feedback afterwards is making us go back into the project, we could have done that differently, we've learned our lesson. Um, hopefully. On on on that. Um, and so this idea of I'm going to scope the project up front and I'm going to keep value as my target. And create feedback loops along the way and again, even if it is a marketing campaign I'm building or a training program. I'm going to I'm going to you know, put feedback loops in along the way. And we're going to track the possible changes and adapt when it will continue to add value to what the key stakeholders are looking for. So, all to say, the scope statement is not in concrete, it's in wet concrete. And in this day and age, we we don't want to get to scope creep, but we want to carefully manage change along the way to make sure that we are achieving value. That takes time. And if you're not doing the scoping up front carefully. You're I I I'm sure you've heard a million horror stories. I've seen people cry when there's no clear objectives and some of the things we mentioned before. Yeah, the the the change management uh aspect of this I find fascinating, right? Because like people uh really want to avoid scope creep and that's that's a sort of a valiant objective. But, you know, not to constrain yourself into that. And there's there's a great meme uh little picture that I share in in a presentation that I do that I I love to sort of encapsulates this perfectly. That uh there's a yacht and a dingy that's being towed behind it. And the dingy says uh says original scope and then the the yacht says says uh change control. Right? Like there's a lot of money to be made in adapting and and adding value and changing the scope of of a of a contract or project. The problem is is you can't do it for free, right? Like you don't cannibalize the project in order to drift into scope creep. And I think that's what people get wrong. Is by all means, propose a scope change or and go through change control in order to get that approved into the project. If someone wants to pay for it, fantastic, let's do that. If someone doesn't want to pay for it, at least you've sort of given them the parameters of why you didn't do it, right? Like, okay, let's add 15k to this project, are you good with that? They're like, yeah, no, maybe we'll continue on the path that we were already on, right? Totally fine, yeah. Well, and and I'll say, you know, even with the dingy and the yacht, what was the original objective, I mean, that's again, the key stakeholder interviews and finding what is this, what's the value of this project to the mission and vision and strategy of the organization? Because the dingy, they might have needed a small fishing boat for two people to go out and do some work on and they ended up with a yacht, which has no value for them. So, you, you know, that's that's part of it is always asking this question. Is it serving the value of the outcome of the original objective, you know, of the project? Yeah. Yeah, and I think like you're so you're you're really laser focused on what is the value produced in the outcome for the client, right? And understanding who the stakeholders are and what can produce value for them. And I think that's a really important way to sort of view it is not being uh tunnel visioned on what is the project, this is what we were told to do. No, the intent is to make the client happy and to produce value for them and to and being able to adapt to that need. Uh sometimes requires a bit of a pivot as well. Yeah, it does. And sometimes you have to remind the client. You know, clients get excited sometimes when you're like, oh man, well maybe we should add that. And and I find it's a stewardship too as a project manager to say, you know, I I just want to go back to what your original objective was. That you can't that we're here to do this event to increase. And now it's turned into a, you know, a yacht. Um, is I you know, is that is this is this is this good for this project or something like that? To not just because clients get excited too. And they're like, oh no, I'm really good and they see you as a trusted advisor that way as well instead of like, oh yeah, hey, give me 15 grand and we'll get it done. And say, hey, listen, before you spend your money, you know, let's just explore how this fits what we, you know, the original scope or the original objective was. Uh out there and they'll love you for that. Right. Excellent point as well. All right. So the other one, um that I really liked here is um again, sort of a really important fundamental, like should be obvious. But somehow gets we drift far from this when we're in the mix with projects or certainly from a planning perspective. So, uh the quote here is uh work is the amount of time it takes to do a task, duration is the amount of time it will take. Uh and this is the fundamental of work does not equal duration. And this is something that even intermediate project managers and certainly technical people that are scoping a project get wrong, right? Like, like. How long will the project take versus how long will a task take are vastly different. Um and one of the things I I really advise people strongly when they're scoping a project is. Uh whatever the longest period that you have a task set for is the risk to the project. So if you say something's going to take a week, it potentially will derail the project for two weeks. Because like we missed the deadline, we have to adapt the deadline and then we have to actually execute on it. Whereas if you chunk these things down to say this is going to get done this day, this is going to get done this day, this is going to get done that day, then, you know, your risk is basically a day delay. Versus a week for saying, was this done yet? Right, so that duration versus work, I think is a really misunderstood and misapplied aspect of projects. Uh I love the way you I just you taught me something there to be more clear. Because, you know, in a chart, whatever, it's the timing is, you know, if it takes a week, it's going to start here and end here. And sort of the sub of that should be the chunking of, so, on this day we'll do this and then on this day we'll do this. So that you are mitigating uh risk. Uh this is where people this this is where people will say. I can't believe Corey's so excited about these things because even with the chart, when I demystify a chart. And I say, honestly, dependencies and duration, I use just even day-to-day in my head for time management of my life. Uh, right? Like because my boss, I'm, you know, I'm driven like everybody else and my boss will call and say, Corey, listen, we need blah, blah, blah. How long will it take you to and I'm like, oh, four hours. And there's no way I need, I need, you know, Amachi and I need, you know, and I and I've got this other thing going on. But my snap reaction is four hours. When actually it's going to take those four days. And so really this is such a life saver for a lot of project managers to understand the difference and then do it the way you said to do it. And then of course, just to add to that risk is that a lot of people will go, oh, duration. Great. Let me pad the time. Yep. And you are now in Parkinson's law is I think what it's called that people are going to procrastinate. And you're really going to be in trouble. So it's not the easiest thing. To figure out what duration is, there's some formulas out there. Per and all that, but a lot of it is by experience and just your your know-how and what's going on to try to come to what a good duration is and mitigate risk at the same time. Yeah, fantastic. All right. And then uh to to run towards sort of the end here. Uh the one like closure is a really important part of any project, right? Because like the ability to be able to reflect on how the project went, the good, the bad. Things we could do better in the future, things that went really well, let's double down on those. Uh is a really easy part of a project to skip because everyone's busy. And we're like, great, that's done. Onto the next thing and people just sort of rush off and and as you said, you're never working on one project. So it's very easy to just disappear onto the other ones, right? Uh and the team just sort of dissolves dissolves into the background. Um some of the aspects that this problems this creates is around documentation, uh the lessons learned. Those types of uh of feedback loops that you can produce more value for future projects. Um. So those are some of those important aspects. The one I really wanted to touch on that you you know is an important part of a project closure is the celebration aspect. And this is I think such an underserved area of knowledge work. Because, you know, I often joke like we're not if we're not building uh again, building bridges or building houses at the end of a project. We can reflect on and say, look, like that's what we built. There it is, there's a produced product. And in knowledge work, that's really hard. Because sure, you can maybe point to a product like a uh a piece of software or a feature or something like that. But it's so ethereal. Like there's no real world sort of visible aspect to that. You can sort of know it and reference it. But it it has less tangible outputs in an in a knowledge-based industry. And I think that's part of the reason that we're really bad at celebrating successes and being able to sort of stop for a minute. And say, look, like we did great on this project, look at what we produced. The the client is so much further ahead, uh they're happy. People are more productive, whatever that aspect is. But I I I really think that this is an underserved area in the technology space of just not pausing to celebrate the great things that have been done when a project is completed. Yeah. And uh you know, again, without stereotyping, when I work with more technical teams, organizations. The whole people skill thing really is where we. There's there's not a lot of IT people we need to teach a chart too. Do need to work on the people side. And there's some people that it's just not natural, neurodiverse and you know, just not into, you know, being able to detect this. And you know, all of that. Factually, celebration is a really good way to connect with people. Even when you're not good at connecting, although it needs to be done authentically. Right. Particularly in today's world, where we're not necessarily in the same office, we're spread out there, recognition from a neurological point of view. Uh studies that they have done, uh that when somebody is told, hey, you really did a good job, let me give you an example on this. That their their the reward center lights up like a Christmas tree, uh more than if you give them cash. Right. So, and I always like to say, that's good and I'll take the cash too. But, um. Uh, but but it's real it's really important, uh again, particularly when we're alone in an office somewhere. So, I too, when it's time for our closing meetings, honestly, I'll get the email and I will roll my eyes. Like, oh God, I don't have time for the, you know, this kind of thing. But I also am very sensitive to my teams and how important it is. And uh I find after even though like I'll I drag myself to the meeting, after the meeting and seeing how good everybody feels. And doing all the other things, like you said, lessons learned and do the tough stuff. I'm like, I'm so glad we did that meeting. I'm so glad we had that time and didn't just rush to the next one. So, do not miss a closing meeting. And do not forget to celebrate your people and not just at that meeting. Along the way is helpful as well. Catch people doing good things. Yeah. Yeah, I agree. I've I've seen I've I love those studies that that describe sort of. Uh how advantageous a simple thank you can be and especially if you can be descriptive about how a how your particular action produced value for the team or for the client. That stuff is incredibly powerful. But often, as you said, just sort of overlooked. Right? Um, but there's there's tons and tons of evidence that suggests that this is powerful stuff for everybody. Even if, you know, the prickly person who just doesn't seem to be uh uh keen to sort of being emotional about uh any of this work and, you know, they're they're they're kind of cold about it. It still gets through to them, their brain reacts in the same way as everyone else does. Even if they, you know, somewhat don't recognize it or, you know, won't be externally sort of uh uh uh admit to those things. That it matters, right? It it does. It does. Everybody has a reward center, everybody has dopamine and everybody, you know, again, like you said, whether it's observable or not. Uh we all we all like to be recognized. Yeah, absolutely. This has been fantastic, Corey. I really appreciate your time uh and going through this. Um I I encourage people to to pick up the book. Project Management for the Unofficial Project Manager. Uh you can get that on Amazon and probably the Franklin Covey store as well. So, uh this is great stuff, really appreciate your your uh your attention to this. And bringing more people into the fold to produce great project outputs. Thank you, Todd. Thanks for having me. Uh take care. Take care.