Latest / You've Been Heard / 348- How To Speak To Your IT Leadership For Big Results with Denise Hatzidakis

Transcript

348- How To Speak To Your IT Leadership For Big Results with Denise Hatzidakis · You've Been Heard

• 0:00
  Speaker A: If you don't understand it, you think it's an assembly line. You put something in and something comes out the other side. Right. You don't interact with it throughout the process and all of a sudden the widget falls off the line. You actually have to help teach the business to talk to you about the what and the why, not the how.
• 0:19
  Speaker B: All right, everyone, welcome back to dissecting Popular IT nerds today. Very excited. I've been talking about you a lot behind your back. You didn't even know that secretly, even inside our secret community. Denise Hatsadakis. I pronounced that correctly. Such a big deal. I mean, CIO, CT, CTO, CISO. What other Cs can we throw in there? Probably some other, I don't know, certifications of sort. But what I want to do is really break this up into the most meaningful and impactful things that we can do for your fellow IT leaders. Number one. And the first question that I have is, and you can take, I'm going to give you like six minutes on this one. It's probably not enough time. It might go longer. But I want to try to. I really want to try to make this as impactful as possible. So first question. How do we teach executive management how to talk to it?
• 1:15
  Speaker A: Yeah, that's a good question. And it's usually at the crux of whether it is a good business partner or not. I think there's a lot of things that we can do to help the business work with it. One of the first things and one of the things that I see IT people do often is over explain technology to the business. We often, because we are tech and we're excited about tech and we want to talk about tech, we over explain it to the business, which actually causes confusion. Right. Because they're wanting to understand everything you're explaining because they're trying to be a good partner and. And obviously it misdirects from what the problem being solved. I think the biggest way to be a good partner with the business is it really needs to take a step back and make sure we understand the what and the why. So I often talk to the business about the business. You own the what and the why, we own the how. And together we'll figure out when. Right. So what I mean by that is the business is the best interface to the customers and what they need and why the business needs to do it and that kind of thing. They often come to it with how or a tangible. I want to build a mobile app that does xyz. Okay, great. But what do you accomplish and what are you trying to come why and why do you expect it to be impactful, etc. And so, and the reason that helps it work better with the business is because we often have the broad spectrum of what's going on entirely in the business in the back end with technology, right? So taking that technology and knowing, oh well, there's a piece over here that looks kind of sort of like that, should we marry it to this? Should we think of that? We also are very ingrained in the latest technologies and what's going on and how to best use them, et cetera. And then so having that collaborative discussion with IT and creating that good collaborative business relationship is what makes it most successful and how we teach them. So it's a matter of they come to. There's a real good example from Disney with Magic where the business wanted to create basically a system for better interacting with the park system, right? They wanted to create a band, an armband kind of system for it. So if you have this armband, you usually get into rides and et cetera, et cetera, et cetera. And what happened was they started building it and they started getting user feedback that was like there wasn't really adopting it, people weren't using it. And it was actually IT that drove the hey, but what if we were getting all this other user feedback over here about long lines and being able to do this? What if we integrated with a mobile app? Because people want to use mobile apps, right? And it was actually IT that drove that, that actually then collaboratively they worked together with the end users and came up with Disney Magic plus. So it's it bringing that art of the possible to the situation and then working with it to, to figure out the when or so the business owns what and why, it owns the how together you figure out when. Because at the end of the day, doing a project, there's only three constraints, right? There's time, money and resource. And. And you can't constrain all three. So implementing a project always has trade offs along the way. So working well with the business to be transparent and help them understand what goes into those trade offs. If you can change the scope, you can make it bigger or larger, you can invest more money, more people, or you can adjust when it can be delivered, right? Time, money and scope are the three things. So building that, building that vocabulary and that working relationship to have those conversations on the when make it give, give businesses a big edge. Because IT and the business are on the same, on the same Page.
• 5:14
  Speaker B: Love it, love it. Time, money, resources. If people can start to learn to speak the language of business and understand these three different things, then it will help you at the negotiating executive roundtable considerably. Just understanding those three terms. If I'm understanding you correctly, it should be asking executive management, what are you trying to accomplish? And we should be training executive management to come to us with this is what we're trying to accomplish, not this is what we want you to do.
• 5:46
  Speaker A: Yeah, I think it's an interesting point. So they're always going to come to you with, here's what we want you to do. Because that's how they think about it. That's always going to happen. I think it's incumbent on it to help facilitate the conversation on the what and ask the right questions. Right. So you want to do that. Why do you want to do that? What is you're trying to accomplish? What do you expect the outcome of doing that to be? Right? So it's just the nature of the beast. They're always going to come to us in what they want done. Right. And here it I need you to do X, give me a list. And then the conversation goes well. So why so the outreach people can work that list. What are they trying to do with that list? What do you expect them to accomplish with that list? Then it facilitates a conversation with Isaac. But what if we put that list over here where they're already doing X? Oh. And it creates that collaborative discussion where it really takes it to the next level.
• 6:45
  Speaker B: What I have a follow up question there, but I think it would go down a really long, deep hole of how we manage our teams, which is how do we get our teams to think like that and to not just have the engineering blinders on? And I'm doing work right? So I'm doing work. Sometimes it we're doing a lot of work. I'm doing work, I'm doing coding or I'm answering tickets or I'm doing this, but I'm not doing work that is the most beneficial or the most important thing at the time that could benefit the company and the team. I it's how do we get the team to think like that?
• 7:23
  Speaker C: At dissecting popular IT nerds, we expect to win and we expect our IT directors to win. And one of those areas where we know that we can help you win is Internet service providers. As an IT director tasked with managing Internet connectivity, few vendor relationships can prove more painfully frustrating than the one with your Internet service provider. The array of challenges seems never ending. From Unreliable uptime and insufficient bandwidth to poor customer service and hidden fees. It's like getting stuck in rush hour traffic. Dealing with ISPs can try one's patience even on the best of days. So whether you are managing one location or a hundred locations, our back office support team and vendor partners are the best in the industry. And the best part about this is none of this will ever, ever cost you a dime.
• 8:14
  Speaker A: I think it's a couple things, right? One is, one is having the frameworks in place that enable them to think like that. Right. So it's having an agile framework in place. I'm a big proponent, I'm a certified agile leader. I'm a big proponent of agile. And agile doesn't mean things get done faster. It really means agility. It means you can react more quickly to the feedback that you're getting back. So but in order to do that, it's not just engineers at the table. You have to have a role. There's a role, for example, called a product owner. And that's really the interface between engineering and the business. Right. They're representing the business to it. Right. They're ingrained in the business, understanding what the business wants, understanding. And they're there as a day to day partner with the engineering team because the engineering team is making micro decisions every day. Right. And they don't understand the what and the why that they're headed for. Then they're likely to go off and go left and not end up in the right position. So using product owners, business analysts. Right. It's about having a rounded team and not just engineers in the conversation.
• 9:23
  Speaker B: Can you give me a quick 30 to 60 seconds? Paint a picture for me of what a product owner and business analyst and how they interact with it inside this Agile framework.
• 9:37
  Speaker A: Yeah. So the product owner is representing the what and the why.
• 9:40
  Speaker B: What do they do? Are they quizzing people and getting feedback?
• 9:45
  Speaker A: Yeah, they're working with the business. They're ingrained in the business. They're in the day to day operations of the business, understanding what the business is doing. They're really the SME in the business. Right. They're the SME in the business. Then the business analyst works to say, okay, how do I turn that into stuff the engineers can make actionable. Right. So how do I turn that into epics and features and stories and that the engineers can then work off a backlog prioritization. They're also working with the business to do continuous backlog grooming. Right. What's the most important thing? Because arguably and it's a conundrum you always get with the business. Well, I can't prioritize until, until you tell me how long it's going to take to get this done because I might want three small things instead of one big one. Right. That is that you have this conversation all the time and arguably if you step back, if it's the most important thing to the business, why does it matter how big or small it is? So it's about creating a framework where the business owner and the product owners and the business analysts can work together and keep making sure we're keeping an idea of the prioritization. What's the highest priority thing that the business needs next? So the engineers are just really focused on grabbing the next important thing and working on it, grabbing the next important thing and working on it and then having the product owner and business business analyst there to help answer the questions, guide the what and the why and interface with the business to make sure that's defined effectively enough for the engineers to execute on.
• 11:15
  Speaker B: What's the best spaced out? How often should we have meetings and with our teams and iterations with all of these people, what's the, in your opinion, what's the best meeting gap? Once a week?
• 11:26
  Speaker A: Once a month? I tend to like two weeks sprints.
• 11:29
  Speaker B: Yeah.
• 11:30
  Speaker A: So two week sprints. Where, and there's, there's, it depends which version of Agile, if it's Kanban or Scrum or you know what, whatever you want to use. But there's, there's certain pieces of that or practices of that that become very beneficial. Right. Which is, and one of them is a demo, right. So at the end of every sprint you're demoing something. Right. Even if it's a technical story, even if it's a, hey, I've got a rest service that does X, Y, Z. But what you're also doing is educating the business on what, what it takes to get this done. Right. You start creating that shared language of what it takes to get work done in it. Right. And then you also have the retro is really important, right. And it includes the. It's a, I usually use like a stop start keep framework. Right. It's not a wit to hunt, it's a what are we going to stop doing? What didn't work well? What doesn't serve us anymore, what are we going to keep doing? Because it really worked well. And what should we start doing? Because we have some lessons learned out of this iteration. Right. And those iterations. It can depend. Just because you finish a sprint in two weeks doesn't mean it goes out to the end users in two weeks. Right. You can accumulate sprints because you don't want to overwhelm the end users with change. Right. You have to dovetail that into organizational change management. Right. And make sure the organization and the business is ready to accept the change. Right. Because there may be training and enablement that goes with it and, and that kind of thing to allow the end users to effectively absorb the change.
• 12:59
  Speaker B: If I was to ask you. Okay, I'm going to ask you. What are the top three things executive management values most in it do or they should? Let's do both. What are the top three things that executive management should value in IT that we're not doing the job, forcing them to know?
• 13:19
  Speaker A: Yeah. So I think what, what it should be doing is, is making sure things stay transparent, making sure we're accessible and making sure we're not over explaining technology.
• 13:32
  Speaker B: Transparent, accessible. Not over explaining.
• 13:36
  Speaker A: Yes.
• 13:36
  Speaker B: Text planing people.
• 13:38
  Speaker A: Yes. And engineers are very good at it.
• 13:40
  Speaker B: Let's break each one down real quick. Transparent means, by the way, we could.
• 13:44
  Speaker A: Get what work is being done, what work is being done, what's being impacted. If we pivot, what does it mean to these other, other pieces of work that's about prioritization and project management at some level. Right. If I do these three things, what it means these three things are going to have to go on hold. Is that okay? Right. That's that transparency and, and progress. Right. Because when you're making, when you're doing, when you're doing agile, you're also having conversations about what are you focused on right now and what are your blockers.
• 14:17
  Speaker B: Right.
• 14:17
  Speaker A: What are the things and what do you need help with? It's not a conversation about deadlines and micromanagement and it's about moving the ball forward. So it's about using that as transparency foundation with the business about how the ball is moving forward and what help you need from the business. Hey, we need further information on X, Y, Z or we found this out. So it's going to have this impact. What do you want to, what do we want to do about it?
• 14:43
  Speaker B: Transparency. Accessibility.
• 14:46
  Speaker A: Accessibility on both sides, right. When you're stuck on something, having access, having the business partner available to you, you can't be in a situation where you're, you've got to make some decisions or you've got some junctures or you've got some important information needed and the only person who can give you that answer is the chief xyz and you can only get to them once every three weeks or once a month or once a quarter. Right. So it's accessibility, but it's accessibility both ways. Right. Then the key IT leaders also need to have the bandwidth to be available to have those conversations in an effective timeframe and an effective manner.
• 15:26
  Speaker B: Transparency, accessibility. And the third one, I think it.
• 15:30
  Speaker A: Was the techsplaining one.
• 15:32
  Speaker B: Yes, yes. And don't over explain technology. In other words, what happens when you do that?
• 15:41
  Speaker A: Yeah, what happens when you do that is multiple things. Right. One, we know in tech, things go bump in the night all the time. And in tech, we're trained to. We're engineers. We're trained to think about all the potential possible outcomes. And you can over explain and create panic in the business, oh, my God, this is gonna happen. Or that could happen, or the next thing could happen. And it's really just the way we think about solving problems. And it's. You often find a situation where you're in a room with the engineers in the business, and the engineers start going down the what if, what if, what if, what if, what if, what if? And the business goes, oh, my God, you're overcomplicating this.
• 16:17
  Speaker B: Could you give me someone that's more confident and knows their job and doesn't do all this crap to me? I think I need a new IT guy.
• 16:23
  Speaker A: Well, then, yeah. I mean, it's. It's.
• 16:26
  Speaker B: That could be what they're thinking or actually, that is what I know that many of them are thinking.
• 16:30
  Speaker A: They do. And, and they also. There's also. You're arming them with enough, but not. You're arming them with enough to. Where I've seen it happen. Where you explain the technology to the point how it works because you want them to understand. We do it. We're proud of technical and complexity and all that kind of stuff. And we want that. We feel good about our jobs when we do that. Right. But when you're over explaining how the tech works, they're going off assuming they understand how the tech works, and they'll make decisions without even involving tech. Oh, I know that. That part of the system works this way because that's what they explained six weeks ago when we had this conversation. And so that won't work.
• 17:12
  Speaker B: Well, blew it up. Just. Just blew up your own department. And that's why it is lonely at the top, because eventually you learn that you should not do that. And now you're all alone. You're all alone.
• 17:22
  Speaker A: You're not all alone. You're A valuable.
• 17:25
  Speaker B: You have dissecting popular IT nerds to listen to. No, go ahead. You're not alone. Why?
• 17:30
  Speaker A: Why? Because if you part of IT is creating trust and confidence in the business, you know you're successful as an IT organization when you're a go to partner for problem solving.
• 17:40
  Speaker B: We got to get in the door. Some of us still need to get a seat at the executive roundtable. Some of us still need to earn that trust. So we're going back to the second part of the same question, which is what are the top three things that executive management values most in it?
• 17:58
  Speaker A: Problem solvers. Right. So you're solving the right problems. Right. You're helping the business make an impact. And you are. IT is seen as a key collaborator or a key enabler to the business.
• 18:12
  Speaker B: So if you can solve problems, make an impact and enable the business, you're on fire.
• 18:17
  Speaker A: Yeah, you know, you know you're in the right spot when a conversation happens that you're not involved in and someone says, oh, we need to get IT involved in that conversation.
• 18:28
  Speaker B: Boom. That is great. That might be the best thing I have heard in years. Yes, that's. That's on fire.
• 18:34
  Speaker A: That's the goal.
• 18:35
  Speaker B: What you don't want them to say is they keep the blinky lights on. Blinking, blinky, blinking lights. I get.
• 18:41
  Speaker A: Or don't involve them. They're going to make it too complicated. We should go do this over here. Because they're going to make that way too complicated and it's going to take them 10 years to do it and blah, blah, blah, blah. And now you've got shadow it all over the place.
• 18:51
  Speaker B: I don't like that guy. He's weird.
• 18:55
  Speaker A: Or. And next thing. Because that's one of the indicators that you are being successful as an IT organization is you have. You're minimizing or you have very little shadow it. The shadow. It usually shows up because they feel like they have to work around it because it isn't a collaborative partner or it is not enabling them.
• 19:13
  Speaker B: I have a. I have a. What are we going to call this pop question. The Pop question of the day. The Pop Chat GT Jet Chat GPT question of the day. I don't know what I want to call this, but. Okay, but the question is, how can IT leaders convince executives that AI is an enabler, not a replacement for their workforce?
• 19:33
  Speaker A: Good question. I started a podcast on this the other day, actually. So AI is, I believe that AI is not going to replace people, but people using AI are going to replace people. So AI Right now in all its, there's a lot of hype, right. It's totally in its hype cycle. AI is best positioned in a business as a decision maker assist. Right. In assistance type. You can't totally take the human out of the loop yet in AI And I don't know if you win and if you will be able to. Right. So it's a go ahead.
• 20:14
  Speaker B: But I'm, I'm listening. I'm just, I was going to follow it up with then. What is the one AI trend right now that is overhyped the most and what AI trend is the most underrated?
• 20:29
  Speaker A: Um, I think the most overhyped is AI is going to replace people. Right. That you can. AI is going to, is going to replace people. It's not going to replace people. There's still bias, there's still, there's a tremendous amount of training that still needs to happen in IE with industry specific solutions. But I think one of the most underrated, in fact ChatGPT just showed this, announced this, the operational pieces, operational agents I think they're called, that allow you to interact with applications. So right now AI is, is good at giving you answers. It's not good at doing things yet. So the operational agents are the first foray into doing things.
• 21:20
  Speaker B: What's the most underrated AI?
• 21:22
  Speaker A: Book me a table. I've got a business meeting and can you find me the best. Find me the best Chinese restaurant for five people in the next three days. Oh yeah. And book it for me. It's the, and book it for me. Which is the new thing that's coming that I think is going to be transformational.
• 21:41
  Speaker B: Super cool. Let's do one more.
• 21:43
  Speaker A: That means I get easy answers, right?
• 21:45
  Speaker B: Yeah, I mean we could do. Yeah, but then we could probably just see if this thing can mimic me. It can already do my voice. They've already done that, had me speaking in French and all kinds of things. Here's a good one. Let's go security for a second. How can IT leaders educate executives on cybersecurity without scaring them?
• 22:03
  Speaker A: That's a good one. I think the best way to educate leaders on cybersecurity without scaring them is one, making it tangible. Right. It can end up a little bit in that AI hype kind of thing. You know, nothing's, nothing's ever a hundred percent secure is the first step. It, it's about security, is really about risk mitigation. So what is your risk tolerance? So it's about having conversations around risk. What's the risk of this happening to our business. Right. And then how do we prevent it? So for example, the business I'm in right now, we have 100% remote users. We have clinicians who go into patients homes. They're on public networks all the time.
• 22:50
  Speaker B: Yep.
• 22:51
  Speaker A: So gee, we really need some. We need to just make the fundamental assumption they're on those public networks and build our infrastructure to support that. There's also using frameworks that things like hitrust and NIST and frameworks that a lot of energy has been put behind of. Here's the control points you need to address to mitigate 90% of the risk.
• 23:14
  Speaker B: I love it. You just made me think of my soon to be 90 year old father and computers and many other funny things that have happened. We could probably go through the. We could probably go like a highlight reel of the things that have happened to him. From Steve calling from Microsoft to help clean up his computer. To taking everything and throwing it out the window to Steve then calling and sending a letter in the mail from Microsoft. Support that. Dr. Howard, you have to call Microsoft immediately. We have a problem with your computer. To my dad calling him after we changed the phone number three times. And then now Steve from Microsoft who will never call. Who's Microsoft will never call my father.
• 23:51
  Speaker A: Has my mom had. My mom a similar situation. She had a check forward or not faked to her church contribution check and she rightfully so panicked man.
• 24:06
  Speaker B: All from I even had my dad's friends calling me saying I was at how's your sister? I'm like how's your sister? I'm like what? What are you talking about? How's your daughter doing? Did she break her leg or something? I'm like what are you talking about? He's like yeah, I was at Walmart buying the gift cards and trying to scratch off the things and give the numbers to the guy on the phone. And I was like oh my gosh. I was like what are you talking about? No one's broken their leg. I have no clue. That person doesn't exist.
• 24:30
  Speaker A: Oh yes, we know every time we onboard a new user they're gonna within 30 minutes they're gonna get a text saying our CEO is in a meeting and wants to needs decent needs you to go buy gift cards for him.
• 24:44
  Speaker B: Man just still works, you know, Keep doing what works.
• 24:49
  Speaker A: Social engineering is tough and that's what a lot of people. It really is. It's also about education. Right. The number one risk point in security is users.
• 24:57
  Speaker B: It's they, they can get real good at it. Okay, let's do. Maybe you have a few good one liners. Do you have any good one liners? One liner cybersecurity truths. Do you have a one liner cybersecurity truth for me?
• 25:09
  Speaker A: When in doubt, don't click.
• 25:11
  Speaker B: We got more. We need a bunch of these. I think we should do like a whole highlight reel of cybersecurity one liner truths.
• 25:17
  Speaker A: Yeah. When in doubt, don't click any one liners.
• 25:20
  Speaker B: What else do we got in tea?
• 25:21
  Speaker A: It's not real if it, if it seems, you know, it's no difference. It's scammed, think scam. Right? If it's too good to be true, it probably is too good to be true.
• 25:32
  Speaker B: I had this really trust had like a trust issue thing that I wanted to ask earlier or something about. Oh, I know what it was. Are do IT people have IT leaders have trust issues.
• 25:41
  Speaker A: What do you mean by trust issues?
• 25:43
  Speaker B: Like being just in general, do they have trust issues? I'm just curious. It's kind of a joke because I was going to ask because most people that ask if IT leaders have trust issues, they say, yes, absolutely, they have trust issues. And I'm like, okay, well then why do you think we went to the moon then? Why does every IT leader think we landed on the moon? I just like, I think it's just kind of funny because if you've got high trust issues, then you should be highly skeptical of everything. Don't click on that. Don't do this. We literally have a term in our industry that is zero trust. That's why I'm saying, I think psychologically we might deal with a lot of trust issues.
• 26:14
  Speaker A: I think, I don't know if it's trust as much as it is. As engineers we want to understand everything and then when we don't understand it, we don't trust it.
• 26:26
  Speaker B: What about the AI hype scale?
• 26:28
  Speaker A: A lot of people don't trust it because they don't. They want to understand it. They don't understand it, don't trust it.
• 26:33
  Speaker B: Okay, is there something to be said about the amount of AI that we're being fed on a daily basis and the amount of solutions that are being thrown at us? So I guess my we'll end with this. How do one evaluate. How do we evaluate the best AI solutions beyond the vendor. I hate the word pitch, but beyond the vendor sales pitches, how do we evaluate real AI solutions?
• 27:02
  Speaker A: Proof of concepts.
• 27:03
  Speaker B: Proof of concepts. Love it. The best answer ever. So true.
• 27:07
  Speaker A: I mean, you gotta use it, you gotta do it, right? You Gotta. At the end of the day, AI is just another toolbox. Tool in the toolbox has a lot of potential, a lot of things you can do with it. But at the end of the day, if whatever you're trying to do with it doesn't solve the business problem, so what.
• 27:20
  Speaker B: So I guess the better question is then how do we, how do we stay away from all of the context switching? Because we could have a proof of concept going on with 50,000 apps at the one time. I've already got, maybe I understand this. On just this little podcast alone, we probably have 50, 50 applications. Let alone you, you might have 120, 180 applications. So we can't do a proof of concept with everything. So I don't know. How do you deal with the pace of change in product overwhelm?
• 27:48
  Speaker A: Yeah, it's a good question. So I think it's twofold. One is creating enough bandwidth in the tech organization to be able to explore. Right.
• 28:01
  Speaker B: How much percentage of time should people, what percentage of time should you be giving your team to upskill, learn and I don't know, research, whatever we want to call that.
• 28:09
  Speaker A: Um, I mean, I, I, it, it's all over the map, right? It's we, we, I tell you what we did in our organization. We created Wednesday afternoons, as we called it shush time. I, as the lead, the IT leader, put on everybody's calendar four hours of time on Wednesday afternoon. No meetings, no go work on whatever.
• 28:33
  Speaker B: Four hours.
• 28:34
  Speaker A: Four hours.
• 28:35
  Speaker B: Wow.
• 28:35
  Speaker A: Not a lot.
• 28:36
  Speaker B: It's, I mean, man, the Lord above bless you. I don't think many people have that time. Four hours of shush time.
• 28:43
  Speaker A: Hard to protect, but you have to, it's hard to protect and you have to. Right? And you have to set the culture for it, right? So I tell my team, look, this is what we're going to do. And we're not going to schedule meetings. We're not going to, if you want to take meetings, that's fine. It's your time to explore what you want to explore.
• 29:01
  Speaker B: Is there anything, is it anything like health and wellness or is it no technology around the business focus time.
• 29:08
  Speaker A: It's around technology around the business focus time.
• 29:10
  Speaker B: I love it.
• 29:11
  Speaker A: Wow. And it's, and if you, and if it's focused time, you need with somebody else on the team to collaborate, that's all good. You don't have to be heads down. You're the only one doing something during that four hours.
• 29:22
  Speaker B: It's keeping the technology fun, keeping the fun and technology in the business. So it's not a grind all the time. I love has been an absolute pleasure having you on the show. And I know you have another meeting coming up because you're a very busy person. If there was one message you had to give out to the audience of your peers, Fortune 500 IIT leaders looking to get into the, I don't know, become Elon Musk or something. I don't know, Whatever it is, maybe it's. Maybe it's Bezos or something. Grow in it, retire, love your job, whatever it is. What's that one message? Love what you do when you stop. Okay, so I got to ask a follow up question then. When you stop loving what you do, what's usually going wrong?
• 29:56
  Speaker A: You're not feeling valued or appreciated or you're not feeling as you're not feeling that you're contributing or you're not making a difference.
• 30:03
  Speaker B: I'm gonna be vulnerable for a second. Sometimes I care too much that I try to do too much at one time. Ever had that happen? Yep. And you're doing what you're doing because you love what you're doing, but you start doing too much of what you love doing so that you start hating what you do.
• 30:19
  Speaker A: Personal problem.
• 30:21
  Speaker B: Thank you.
• 30:22
  Speaker A: Sorry.
• 30:24
  Speaker B: Thank you, everyone. Make sure not to edit that one out.
• 30:29
  Speaker A: I mean, I say that flippantly, but it really is. It's right at the end of the day, you own what you do and how you react to things and how you. And it's. It's on you to pull back and say, okay, this isn't working. This isn't working for me. I'm getting. And usually that happens when you get buried and you got too much going on. And I know for me personally, then I get, I get irritable, I get snippy, I get I'm not a good partner. I'm not right. So know yourself well enough to know when you're hitting that and consciously take a breather or a step back to kind of reset and figure out what it is that's getting you in that position and adjust.
• 31:07
  Speaker B: I think it's realizing that sometimes it's okay to say I really don't care what the outcome is because you can't work. You can't do a thousand things at one time. You care what the outcome is, but it doesn't need to be immediate. And I think the two week sprints and the agile piece and all of that helps a lot. A lot of people try to take on too much. Maybe this, maybe they haven't been agile maybe they haven't gone through the waiting process of like, does this add that much value that it's worth this amount of time and resources?
• 31:33
  Speaker A: Engineers can't be productive without prioritization. Prioritization is key. Knowing what the priorities are to work on and learning to get good at. It's not. No. It's not now, right?
• 31:45
  Speaker B: It's not. No. It's just not right now.
• 31:48
  Speaker A: Right.
• 31:49
  Speaker B: That's a great one liner. It's not. No, it's just not right now.
• 31:52
  Speaker A: Yep.
• 31:53
  Speaker B: Again, thank you so much. Very, very a super pleasure having you on the show and really a some very, very valuable information. And thank you so much for giving back to the community, the community of your peers, IT leaders and all of that and helping change the face of it.
• 32:11
  Speaker A: Always gotta get out.