Latest / You've Been Heard / 465- From Department of No to Department of Risk w/Jeff Posluns

Transcript

465- From Department of No to Department of Risk w/Jeff Posluns · You've Been Heard

• 0:00
  Speaker A: I don't want to be the department of. No, I want to be the department of Risk. So if someone comes up with something that is absolutely ridiculously unreasonable or even somewhat unreasonable, I'm not going to tell them no, I'm going to tell them. Have you consulted with the GRC team, the governance risk compliance team to perform a risk assessment? So if we do this then you have to accept the following things. If you don't fund this other thing, you have to accept the following things.
• 0:48
  Speaker B: Jeff, welcome to the show. Welcome to. You've been heard. Introduce us what your current job title is.
• 0:54
  Speaker A: I am the CIO of Traffic Tech, a logistics company that has global presence, about 40 odd offices around the world, about 1200 people and move a heck of a lot of freight from anywhere to anywhere, any way you can think of getting it there. My role and responsibilities are related to the technology teams. Everything from the infrastructure, communications, telephony, data security, governance risk. If it has to do with technology, the tech part of Traffic Tech, that's my team.
• 1:36
  Speaker B: Sweet. Love it. Love logistics over here. We love logistics. We've done a lot with. We've had a lot of logistics people on the show all through various different facets. Obviously it's a fairly large industry where sometimes blockchain comes into play and certainly AI as of recently. If anyone can figure out the right use cases to use there. Do you guys have. So are you. Do you guys have your own, for lack of a better word, truckers or do you hire like is it third party or something? I'm forgetting all my logistics terms nowadays
• 2:14
  Speaker A: is a third party and fourth party logistics company. So there are no internal truckers that gets outsourced to the people who own the trucks? Pretty much.
• 2:27
  Speaker B: And I'm assuming you have. Okay, so do you have have to do a lot of. I don't know what's wrong with me. Booking of loads and stuff like that that's on. On book on boards and stuff like that and negotiating of rates and all that type of stuff.
• 2:41
  Speaker A: Absolutely. And that is the. The core technology of Traffic Tech is the transportation management system. There you go.
• 2:53
  Speaker B: I threw of your acronyms, a few
• 2:55
  Speaker A: logistics acronyms but yeah, warehouse management system, the edi, communications using whatever mechanism third parties have to send us and receive data from us. Then all of those systems together are what my teams ensure keeps working.
• 3:15
  Speaker B: Fun. I get nerdy about this stuff. I'll be honest with you. Do you have refrigerated loads that you are moving anywhere at any given time?
• 3:23
  Speaker A: I'm going to say I'M certain that there are, but asking me about the operational details is probably not the greatest use of time as I would defer questions like that to the team responsible for such. I know there's a produce department because they often wake me up at 4 or 5am when they have a challenge, but outside of that, I can't really tell you very much about the types of trucks and the like. I do know that we have a fantastic GPS tracking system for them as I was involved in some of the scoping, specking and the, the data surrounding that.
• 3:59
  Speaker B: Okay, so yeah, so let's talk about that a little bit. I mean, we can talk about whatever you want. I mean, it's Friday, so I'm open the but logistics, obviously the reason why I like it so much is because an IT leader can make a big difference there can make a big difference from the aspect of getting something delivered on time, cutting costs, being more efficient, even potentially growing revenue so that it is not just a, you know, pigeonholed into a cost center, so to speak. What are your thoughts there?
• 4:34
  Speaker A: That is a very subjective question and it's really going to depend on the organization, the team and how well aligned they are with the business. And aligning technology to business can be very challenging for many people. Although it depends how you look at it as should IT and the IT leadership own the technology solutions or should there be a business owner of those solutions? So if you don't have a business owner, my opinion is a project should not start. The business owner should be the one who defines what the outcomes are that they are looking for. Without that, without that guidance, without that business analysis and managing of expectations and outcomes, you have a technology project, which as a technologist, I can say is a heck of a lot of fun to put things in place, especially as we're getting to emerging technology's latest and greatest type of scenarios. But it's wonderful to put something in place and AI is a very great example of this type of situation. It's great to put something in place. A lot of fun. The tech teams are going to have a blast. It'll be well documented, it will be easy to use. But will it bring an roi? And is that ROI the correct one that the business owner or the problem owner, so to speak, should be orienting on?
• 6:25
  Speaker B: Let me make sure I understand you correctly. So basically what you're saying is that it, AKA technology, people love to play with technology all day long and if you give them a project, they'll enjoy putting whatever project together and doing that for you and asking all kinds of questions. But what you're saying is if there's not a business owner of the project, AKA a problem owner, then there may not be a clearly defined scope or pathway forward for what the goal is that we are trying to achieve with the implementation of said technology. And then you've took it even a step further, which I love. And you said is this even the business problem that we should be trying to solve to begin with? And I would say that that is the crux of the major problem that so many organizations have when guiding it to do the right thing.
• 7:23
  Speaker A: We can take that even a step further.
• 7:27
  Speaker B: Let's go please.
• 7:30
  Speaker A: Let's talk about how technology gets funded. So most organizations fund projects. There's a capital approval, a go live and then the project team disbands. Systems can then run for years on an operating budget that never accounted for upkeep, security patching, replacement upgrades. Technical debt is the accumulated cost of that gap and it stays invisible until something fails. So if I love giving advice and one of the I'll get into this a little bit after how I give advice.
• 8:16
  Speaker B: Advise us Jess.
• 8:17
  Speaker A: I would advise every organization to a persistent funding of business capabilities with life cycle and run costs approved at the same time as the build that will make technical debt visible and forces an honest total cost of ownership discussion before anyone signs off and saves my teams and people like me and their teams from the challenges of oh here's another 30 VMs or here's another software solution that you have to run as a service. Good luck, have fun. Maybe the governance or the security the data loss prevention team hopefully people department
• 9:05
  Speaker B: for paying Azure responsible for paying the Azure bill maybe come up somewhere in there.
• 9:10
  Speaker A: There you go.
• 9:12
  Speaker B: Or sprawl spend. I love it. I really love it because one of the complaints that we've heard over the years because sometimes it can become believe it or not, this show can be a gripe session where we just we sit on the couch and I become like the like the shrink for like you know, it leadership. One of you know here's a classic one. We need to get the ERP implemented within three months and you get the ERP up and running and you've done your first day of training or whatever it is and executive management's like okay, we're done and but hold on, we didn't implement this add on or this whatever this other. Why can't I think of the word right now? You know additional module that you guys didn't realize is we need to do that next month and that's going to cost more money. To your point of like, should we have the sprawl? I like to think of it as like a plus or minus percentage contingency factor maybe written into the, written into the beginning of the project. Well, is there like any average that you've seen? Or like, you know, like, like, how do you explain that up front? Guys, I just want to let you know that typically these things always take longer than ever expected. They always cost more than ever expected, and they never quite work exactly the way that the dream has been laid out from the beginning. I just want to let you know that.
• 10:36
  Speaker A: So the first thing that I'd like to ask is, have you ever seen an ERP implementation take three months?
• 10:44
  Speaker B: I've had people say, look, a win is we delivered the ERP on time. Like, if you deliver it on time, it's like you've completed it. You're like at 150.
• 10:55
  Speaker A: Okay, Phil, let's put this in terms of pizza. If you get your pizza within 30 minutes, is that a success? If you open up the box and like the cheese is on one side and the dough is on the other.
• 11:07
  Speaker B: No, no, no. I love your metaphors. If we could make this a show of metaphors, like, let's do another one too. Yes, that's a great metaphor. It is. And it's not a sports metaphor, which works. So, no, I don't know. I do not know if an ERP project has been on three months. We're doing our CRM migration right now and I'll be surprised if that's done in three months. That's just a module.
• 11:35
  Speaker A: So that brings to light one of the huge disconnects between IT and other leaders. So executive teams often decide based on revenue margin or what's happening in a given quarter. IT reports in projects, uptime multi year roadmaps. Both have their own performance indicators and both are accurate, but neither translate automatically. So an executive could hear, we need to replace the ERP as a large cost with an uncertain timeline or a target timeline, when it means our ability to invoice is at risk unless we complete this module in erp. So from the communications perspective, in this particular example, the fix or the solution sits with IT leadership. To close the disconnect, IT need to present every material technology item as a business decision with a cost risk. The options, the recommendations on the same cadence and in the same style that the executive team or leadership team use for everything else.
• 12:59
  Speaker B: Love that. I love how you put that. I didn't think that was going to come out. You're surprising me left and right today. Full of surprises. I love it. Okay, yes. But if we go back to the problem that we started with, it's ability to actually explain reality and project overspend and all these other things which they may fail to do because they might be afraid of getting a no from the executive team. Just a thought. I don't know. Or inability to communicate effectively. Whatever these reasons are, I would love to have your thoughts. They would need to be able to do all that to begin with in order to communicate and do the translation from KPIs to I don't know Business success indicators and measurement terms. I hope you're following me here. In order to get to that in order to be able to put a put together a presentation that speaks to executive management, they need to know first how to do that in the most simplest ways of putting that. And I don't know if the majority of IT leaders know how to do that because the statistics show that something like 86% of it leaders with a C in front of their title are respected as operational managers and not necessarily respected as business partners.
• 14:29
  Speaker A: You've given me about 10 different things to respond to there.
• 14:33
  Speaker B: I'm sorry.
• 14:34
  Speaker A: No, it's all good.
• 14:36
  Speaker B: Lots of coffee.
• 14:38
  Speaker A: We'll probably put this through an AI later and say there's about 50 questions that were asked or topics raised. You answered 25. And here's 25 other things that are on a completely separate train of thought.
• 14:52
  Speaker B: I need you in my life.
• 14:55
  Speaker A: One of the things that I would like to point out that you stated is the and I forget the words you actually used. I'm sorry, but the reality of life is different depending on who you're talking to. So different C level executives have different things that they will hear regardless of what you are actually saying. So the first point that I want to make is technology risk is business risk and the business should own that. It owns controls, architecture and advice. But the decision to accept a risk or defer replacement of an outdated system or skip a control or fail a compliance audit and lie about it belongs to the executive whose revenue, customers or license depends on that system or that audit. When ownership is unclear, risks get accepted by default because nobody made a decision. So if we take technology risk and put it on the enterprise risk register with named business owners and help them with all of the understanding of risk like tolerance, review dates, compensating controls and the like, then we can treat every deferred decision as an explicit Risk acceptance. And ultimately that turns into IT personnel being able to justifiably say it's not my fault that this failed. Well, we did our best. We advised you didn't approve the budget, you didn't approve the prioritization. And prioritization is something we should talk about after you didn't approve whatever it was that needed to be approved, the overtime. Well, that was you, Mr. Business Owner, accepting the risk.
• 17:01
  Speaker B: Yes, I love that. I love it. Because that's the answer to every CISO's gripe about. And it's not even a CISO because if you're a CISO to begin with, they've already approved the budget. It's the companies that don't have CISOs or don't have budget for security and are trying to fight to get money to approve security.
• 17:19
  Speaker A: I disagree with that as we, I
• 17:22
  Speaker B: was just saying we're putting the ownership on them. I was saying. But what I heard, maybe I didn't hear it right. What I heard was that security is really a business ownership issue. Meaning if you're going to own. If you're, if as a business owner you are responsible for not leaking your customers data, if you are responsible for, or we'll just keep it at that one, then the ownership is on you. And then if your IT guy tells you you need to do this security wise because we have a security gap of some sort, we're advising you and you don't approve the budget, whose fault is it?
• 17:58
  Speaker A: Let's look at a scenario as I'm sure your listeners like things that they can relate to. So we have a, let's say we have a web application that's vulnerable to all sorts of horrible stuff. The CISO identifies this brings it to the leadership team's awareness, identifies the cost as. And I'm just going to make something up. $200,000 per year for a web application firewall and detection response service. And then the budget's denied. A month later there's a major incident. Who is responsible and who is accountable?
• 18:41
  Speaker B: I think we probably have to ask like a thousand more questions. That's probably an exaggeration, but I don't know. Was the application even that worthwhile? Could we have just used a different application? That would be the first thing I would have probably thought of.
• 18:52
  Speaker A: See, you're thinking like a technologist and this is a perspective that I actually find very challenging in my role as a cio. I love solutioning. I love expanding the options, the decision matrix into more components and more sub decisions than most people would ever want to know existed. I have fun doing that with my team, but I also tell my team I'm getting into solutioning mode. Pretend that my opinion matters here on the technical side as I've been out of the hands on work for too long, but hopefully it will trigger a light bulb above your head and you'll take away something from me as a late 90s BSD Unix system administrator perspective into something that's applicable today. But coming back to the CISO perspective, there are a lot of CISOs out there that I speak with often enough who view their jobs as the scapegoat. And how often do you see a major incident? The CISO gets replaced within a few months, but there's no major change. There's no adoption of controls of a framework of a standard, no audit, no budget allocated to secure but as far
• 20:21
  Speaker B: as the discussion goes, I really really love the discussion of ownership of business problem ownership. And I think one of the biggest problems with technology misalignment in business is that the IT department becomes a department of like all these projects going on and you could never finish all the projects at one time. And then it's like well which project do we do first? So like people would gravitate probably to the easiest one if there's no ownership. And the second thing is there's who owns the problem. But not only that, who owns the hierarchy of the problems and who really knows what the actual real problem and challenge is in the business that needs to be solved. And you're calling out those people saying look, we can help you. We are the IT department. We can help you solve problems, we can help make a huge difference in the company. But someone has to first own and communicate to us what the biggest business challenges are. And I hoping that rings true with you.
• 21:26
  Speaker A: It does. And that brings another thought to mind. Within most organizations in the past let's call IT decade, IT departments treat the business as their internal customer. Agree or disagree?
• 21:46
  Speaker B: 100% agree. I'm like I'm loving everything that you say today.
• 21:50
  Speaker A: So that sounds service oriented and Service catalogs and SLAs reinforce it. Applied to transformation, it creates a vendor relationship inside your own company.
• 22:05
  Speaker B: Amazing.
• 22:06
  Speaker A: The business specifies it delivers and when results disappoint, each side points to the sla.
• 22:14
  Speaker B: Okay, yes, it was a stupid look.
• 22:17
  Speaker A: You could look at this as fantastic from one perspective, but it also is damaging to an organization.
• 22:25
  Speaker B: Yeah, it's also the reason why I believe mediocrity is king. So many vendors, so many vendors are better because they suck less than the other vendor.
• 22:38
  Speaker A: Let's look at why I've swapped socks every year for the past. Socks, as in security, operations center. I swap my socks at least once a day. And yeah, I'm just guessing, like day
• 22:55
  Speaker B: one was great, but day 100 wasn't as good as day one.
• 22:59
  Speaker A: Well, it's also our own fault from another perspective, in the midst of massive transformation, you can never complete an onboarding and set up the right rule sets, set up the right correlation to allow your vendor to succeed. And that having built up a SOC service business and sold it many, many years ago, I saw that with customers all the time. And now I'm one of those customers that I would have hated like bit more than 15 years ago. So when you are onboarding into a SoC, you have a requirement for consistency in data input. What happens when you have four different centralized logging facilities in different environments? You're constantly migrating a legacy, legacy, legacy environment to a legacy legacy, the legacy legacy to a legacy. And then you hope that you'll get from legacy to sort of kind of modern ish, and then from there to bleeding edge. You want to set yourself up on bleeding edge.
• 24:19
  Speaker B: Yeah.
• 24:19
  Speaker A: But you can't.
• 24:21
  Speaker B: Well, that's reality. Back to that word again.
• 24:25
  Speaker A: And that's where managing expectations and defining how things should have been done from the get go is very important. And I will, I will own that mistake. It was one that I made with the first and second sock and now with the third, things are probably going to go a lot better.
• 24:44
  Speaker B: What changed the. What were the expectations? I guess what were the expectations? What were the expectations that were not made apparent on the first and second shot that we have legacy things moving to legacy things. And we've got an IB, like an AS400 in the back room over here and we've got this over here. And like this is this reality of, of our completely unstable and unpredictable group
• 25:09
  Speaker A: of people and a few different identity and access management systems that have their own synchronization and modernization projects for each of them that did not allow the results of those programs and adjustments to the way that the SOC ingested data, understood data, and was able to correlate that data. Now with AI, it's a lot easier. Thank the powers that be and future AI overlords. I acknowledge your awesomeness. But historically there was a lot more human requirement for standardization of data. And data is a challenge that I'm sure most companies out there are dealing with.
• 25:56
  Speaker B: Everyone wants to talk about it. Everyone knows that data is a challenge. Back to the ownership problem, though. Give me the top three or five things to make any project successful. And how do we even know we should be doing this project to begin with?
• 26:08
  Speaker A: Answer that question first.
• 26:10
  Speaker B: Yeah.
• 26:11
  Speaker A: How do we know we should be doing this project?
• 26:13
  Speaker B: Yeah.
• 26:15
  Speaker A: So what is it going to accomplish? What is the roi? Is the ROI measurable?
• 26:21
  Speaker B: Let's just say we don't know. Let me just play devil's advocate and say we don't know. What would you do first? We think there's a big ROI because there's this gap that we never. That we've known about, but we've ignored it. And there's this. Yeah, let me give you an example. We have 2,000 truckers available, and I'm going to try to use TMS in the industry that they just kind of call in every now and then. We know that there's a good 10% of them that just deliver a lot faster. They don't drink and drive. They don't do these different things. We know they're better, but we've never made an attempt from marketing or customer service point of view. Oh, I forgot. Are you guys internal? You own all the truckers? Like, you employ them all or they're third party? They're third and fourth party. Right. You're hiring them. Okay. But we've never made any attempt to reach out to them or say, hey, come back to us. Or we think you really do a good job or give them some kind of award or something like that. So we have this project we want to put together that is basically a communication project to bring these people into the fold more and prioritize them as the. I can't remember what you guys call drivers. What do you guys call them? What do you call it? Your drivers? Like the official term in the management transportation world. It's not truckers. Like, what is it?
• 27:40
  Speaker A: It's like, I want to say truckers, but I don't know.
• 27:44
  Speaker B: Okay, so whatever drivers, we have this idea of, like, you know, that we're going to bail through this new CRM. We're going to be able to reach out to them more and it's going to be able to, you know, grow revenue by a good 20% because we never. And let's just say their customers, too. It could be other customers. Like, we've never reached out to our old customers and asked them to come book a load with us again. I know it sounds like a crazy example because anyone that doesn't do that's like, kind of ridiculous, but let's just say we didn't do that. What would you do? We think There's a big RNI.
• 28:14
  Speaker A: The salient point there is. You said 20% of revenue increase.
• 28:18
  Speaker B: We think 20%. A potential 20% revenue increase. Yeah.
• 28:22
  Speaker A: With the desire to shape a positive business outcome. We start with the named business executive, the number and the date. So you've defined the number. A target of 20% revenue in whatever the business unit is. You're the owner in the.
• 28:44
  Speaker B: We'll go three months. Perfect. There's your number or your date.
• 28:49
  Speaker A: Three months from the time of implementation. So great. You are now the business executive. You've put your name on that outcome.
• 28:59
  Speaker B: Oh, crap.
• 28:59
  Speaker A: You are funding that initiative or. I'm going to go back with my team and figure out what it'll take to. To build, implement, to support, to maintain, to secure, to govern. I will bring that back to you. I'm just making up a number. It's a $5 million project over nine months. And then after nine months, you can start seeing how close to 20% increase in revenue you can get in the following three.
• 29:27
  Speaker B: That's a wild number. I would totally challenge that. But what would your suggestions be? What would your suggestions be if. When you heard this.
• 29:38
  Speaker A: Well, the first thing that I need to do is go back and look at how we do what we do now. And most failed initiatives will fail on data quality, process discipline, or unclear ownership. And you might not be the owner of every process within the scope of what it'll take to build out this solution. We have concerns about environment stability. While we're changing, we need to identify all of the different stakeholders.
• 30:15
  Speaker B: Yeah.
• 30:16
  Speaker A: And we need to identify how we are going to measure progress and measure the results of the program as if we're spending. I forget the number that I made up. I think it was something like five.
• 30:27
  Speaker B: Okay. Yeah, five million. Five.
• 30:28
  Speaker A: Nine.
• 30:28
  Speaker B: Okay.
• 30:30
  Speaker A: So at what point in the progress of spending that $5 million, do we have enough indicators to assess is the project capable of succeeding or should we stop and shelve it?
• 30:44
  Speaker B: Right. Not only. The other questions that were coming to my mind is as business owner, and this is the gap that I think if IT leaders become also good business leaders, it will be that much more helpful to the C Suite. And the point of the show is getting heard at the roundtable, not just sitting there. Right. Not just the guys. Okay. We need this done. Like, how do we get heard as IT leaders and spoken about and talked about when we're not in the boardroom anymore? You know, it's it's not necessarily like, oh, we, we kind of heard you. And then like, you know, zero trust. Okay, congratulations. Next subject. But what are people saying about you when you're not in the room? That means you're really being heard. So my thoughts here would be as an IT leader, like, well, can we handle the extra 20%? Also, do we even have the staff for it? If I give you 20%. If I give you 20%, can you handle it? That would be a business. See, that would be like something that you would ask as a business thought leader, not as a technology thought leader. And then the second piece would be, I think this might be more of a technology piece, is like, how do we do just kind of like a. Can we do a little test? Can we do like a little subset test or a POC before we invest $5 million?
• 32:04
  Speaker A: Valid. And that actually brings up something that is hotly debated at the CIO level.
• 32:12
  Speaker B: Oh.
• 32:14
  Speaker A: So my question is, does a CIO still need real technical depth? And the prevailing advice is that the CIO should be a pure business executive and leave technology to the CTO and architecture team. And I disagree with that. A CIO who can't challenge an architecture or test a vendor's security claims or recognize an unrealistic estimate is approving decisions that they can't evaluate. And that's how organizations end up locked into platforms and contracts that they regret.
• 32:50
  Speaker B: Yeah. Yep. It's also how they end up with worthless consultants. I don't know. You know, it's kind of like you have to be able to spot one, no one type of thing. It's. You want that, you want the CAO CTO that not necessarily as an MBA has. Like, because an MBA is one thing, it's important. That'll definitely, like, get you to a certain degree, but also actual business experience, like actual business fail forward type of experience, like really in the trenches, like building kind of business experience helps a lot. But to actually know what to do from a command prompt or to know whether someone's snowing you over in a security, in a security meeting, to know whether you've got just another vendor advisor that's on every street corner that used to be an insurance salesman versus someone that actually knows what they're talking about, it's kind of important.
• 33:47
  Speaker A: I present sessions to students, often with the organization of a university or a college. And the topic of one of my recent sessions was saying no with credibility. The roadmap to a technology executive and saying no with credibility is a skill as most executives and leadership type People on the business side don't have the technical background. So the CIO and sometimes the CTO need to be that bridge. So when someone on the business side says we should do X, the CIO or CTO need to be able to and we don't just say no, but we need to be able to assess and advise so that if the reality of the situation is that is a terrible idea from the technology perspective as many of the ideas that people come up with related to AI are these days, we have to be able to explain that and they know with credibility.
• 35:04
  Speaker B: It would be a lot easier if we could just shoot their no. If we could say no with the credibility from a business perspective from the beginning than have to even go into the technology aspect of. Because if we can actually say hey look, forget the technology, forget that in the back of your head this is a ridiculous idea, it's actually a bad business idea and here's why. And then like oh yeah, you're right, our job is to focus on delivering more whatever triplet bars from point A to point B through the TMS system and you're asking for us to I don't know, some other thing that's like this real minor, kind of like minor off league point you want us to to, I don't know, just talk about, you know, truck tire wheels on in across social media using AI to spreads. I don't know who knows what it is. It's just a bad business I idea that's a lot easier sell than you know. The reason why we can't do this AI thing is this and I actually highly a lot of people say it has become the department of no. I don't want to be the department no. I don't want to be the department of no. I totally disagree with that. It's a very, very popular theme that comes up on the show all we don't want to be the department of no. We don't want to be the department. I think you should be the department of no. I think that's a good thing. And the reason why I say that, the only reason why I say that is I mean be the department of no from the business can only focus on so many things at one time and the more things that you' focus on, the less laser focused you are on driving revenue.
• 36:35
  Speaker A: So let's prioritization. I I brought this up earlier and and this is a near and dear topic to my heart, something that I've struggled to implement in my current organization and we've finally gotten to the point where we have a meeting every two weeks. Priorities are presented and we have a few columns on one slide. Okay, the five. Five and other. We have five high priority projects. A high priority project has a specific delivery date. Okay, five medium priority projects which have target dates. And then there's everything else with the up next five.
• 37:23
  Speaker B: See, that's already. That's already. To me, that's already way too much. That's crazy. But you, your team, how big's your team? How's bigger? How big is your team?
• 37:33
  Speaker A: My team began five years ago at just over 20. I grew it to 108.
• 37:41
  Speaker B: Holy crap. Fives. Let's do it. Let's do the five projects. No problem. We got it. That's amazing. That's amazing.
• 37:50
  Speaker A: Now we're a bit less. Through the past couple of years of challenges and the like, team size has dropped a bit. There's a few more consultants and the like, but whatever the number is, I firmly believe that every technology leader should follow that type of style. The high priority has a delivery date. Medium priority has a target. Because people will only work on these items if there's not something high priority for them to work on. And then there's everything else. Oh, can you just do this quickly? We can if you label it a high priority. But then which of the current high priorities moves to medium? Which of the current mediums move to up next and be firm with that.
• 38:38
  Speaker B: How. What's the cutoff for you? What's the cutoff? That's everything else. Is there like a. Is there like a cutoff from a time like this would take a week to do. Does that make the mild priority list? Mild, medium hot. Does that. I'm just thinking Taco Bell or something right now. Mild, medium hot sauce. The. What makes the everything else list, is it any request or is it a project request?
• 39:05
  Speaker A: It is any activity that would take time away from someone that in the project plans and program management system has some of their time allocated to a high priority item. That's it. We can swap something in. That's two hours. But I want the formal change register that takes 30 seconds to do, noting that this person who's on this high priority path was taken off for another higher priority. And thus, when we look at the pretty Gantt chart, because executives love Gantt charts for projects and timelines, we see that the delivery of this other high priority thing is extended out by a day because we took this person off of it, and that's fine. And who makes that decision? Well, that's the business leadership, that's the committee for prioritization, which should have representation from technology. So the CIO and, or the cto, it should have the coo, the operations person, the CFO or a designated finance person. And making an appearance in that committee will be whoever it is that is the authoritative or the sponsor of the project that they want to take time away from an existing high priority. Ultimately, I'm a technologist. I lead a technology team. Do we work on changing this button from baby puke green to teal blue or do we work on changing that button from orange to purple? Doesn't make a difference to me. Let the business decide.
• 40:56
  Speaker B: We have. I would ask you why, why it took so long to get there, but I think it's. It takes, it takes a lot of management and leadership sense to get to where you've gotten right now. So let me just say congratulations on that. On, on some level of prioritization and governance around making changes. We had some, we had some bullet points to talk about today. One of them is blocking for your team. So I. Let's just say block and tackling. Block and tackling for your team. When. When you get unreasonable demands. How do you protect your team from unreasonable demands?
• 41:37
  Speaker A: Well, this is a continuation of the Department of no conversation as I don't want to be the Department of no, I want.
• 41:46
  Speaker B: You wanted to disagree with me there. I could tell you wanted to disagree with me.
• 41:50
  Speaker A: I held it back waiting for this question. I want to be the Department of Risk. So if someone comes up with something that is absolutely, ridiculously unreasonable or even somewhat unreasonable, I'm not going to tell them no. I'm going to tell them. Have you consulted with the GRC team, the Governance Risk Compliance team, to perform a risk assessment? So if we do this, then you have to accept the following things. If you don't fund this other thing, you have to accept the following things. You want us to prioritize your baby puke green button. Well, that's one day of work. Probably like five minutes of work, but let's just say it's one day of work. So the Deliverable for the. How quickly will chocolate melt in the refrigerated trucks if the refrigeration unit goes offline based on the ice pack to chocolate ratio and spacing of the crates. I just made that up, but it sounds pretty cool.
• 43:01
  Speaker B: Well, it's relevant because I don't know if you guys do check calls because I do a lot in logistics and I remember check calls so people have to call truckers just to check the temperature of the load and geographically where it is on the map before it's reached point Z.
• 43:14
  Speaker A: So we have technology, but realistically, if we allocate time to changing your button color, then we might lose two loads of Hershey kisses that have melted and we have to make an insurance claim.
• 43:26
  Speaker B: Yeah. And that button was for placing more orders for chocolate bars, and it now became irrelevant.
• 43:32
  Speaker A: There you go. So the way that I body block, so to speak, for the team, is I ask both questions. I bring the risk approach. Or someone calls the fourth meeting to discuss whether we should use baby puke green or I forget the color. We just painted my bathroom, but it's gorgeous. It's like a deep olive with a hint of brown. Baby puke green or Jeff's new bathroom paint color.
• 44:05
  Speaker B: Amazing. That's amazing.
• 44:06
  Speaker A: I don't want my technology team members to be part of that. I'll send a project management manager who can roll their eyes and then come back to us with, yeah, I just spent a half hour listening to people debate pantone colors. Not quite, but I'm exaggerating, but you get the idea.
• 44:22
  Speaker B: It's amazing that we grow as companies. Sometimes it blows my mind. So we. The department of risk versus the department of no. In other words, it's how you say no.
• 44:34
  Speaker A: Absolutely. You have.
• 44:36
  Speaker B: In other words, you're agreeing with me. We are still the department of no. It's just we need to, like, we need to shine it up a little bit better.
• 44:45
  Speaker A: We have to position our communications strategy based on the worldview and existential knowledge that the person that we are speaking to has adopted.
• 44:59
  Speaker B: Yeah, we need to go back to that. Yeah. Because you mentioned earlier, I'm looking at my notes because when I take notes, it's a good thing. They hear what they know. Like every C level hears what they know, or they hear what they want to think, or they're in their own. Like you said, existential other reality over exaggeration.
• 45:16
  Speaker A: I'm sorry to interrupt, but, like, not everyone is like that, but there is a tendency. There is a little bit of a brain that will always squirrel back to the framing that they are familiar with.
• 45:30
  Speaker B: Yeah, I'm not being sarcastic at all. I think you're absolutely 100% right. 100% right. And the question is, do technology leaders have the skillset to communicate effectively? Again, if I went back to statistics and we looked at the top three skills that most technology leaders would even rate as important or worried that they're not good enough at, Soft skills is one of them.
• 45:59
  Speaker A: Communications is the most important skill that a technology executive can have. And I think back to a few companies past where I believe I was in one of the first meetings with one of the other C levels and she said to me, she interrupted me after my third or fourth point of you lost me a few minutes ago. And we have to change how you're framing things. Otherwise I'm just going to sleep and work on other things while you're talking. And part of me took a little bit of offense, but thankful.
• 46:40
  Speaker B: Yeah, because thank you for being so blunt.
• 46:44
  Speaker A: They were helping me learn how to be a better C level executive when dealing with them and people like them. And I think that was probably 2013, 2014, but that was a key moment in my development as I see it as a C level communicator.
• 47:07
  Speaker B: Yeah, the people that give you true advice or good advice, it usually comes off as harsh. And the people that just kind of like tell you what you want to hear, it's not very useful to you in your life. And then vice versa. The people that are coachable that actually take that advice and then take action upon it are the best employees versus the person that gets all offended and, you know, hurt typically don't grow. So yeah, it's usually those things that people have said to us in a harsh manner that that was in our best interest that we remember. You have this thing called a diagram fatigue. And what AI written content is doing to AI written content is doing to LinkedIn. I guess what can't already be done. It's surprising that I am able to find any human on LinkedIn anymore that actually will respond to another human. But that's where we find people for the podcast. So LinkedIn's like it's still arguably the largest business to business database in the world right now. So that's how we find you. But I do want to know what you mean by diagram fatigue. I'm assuming it's just general the blunting of human emotions and our ability to, I don't know, have any differentiation or artistic expression anymore.
• 48:34
  Speaker A: This morning when I had my coffee, probably it was about 6:36 6:45am But I opened up LinkedIn and I did the quick scroll down of the page and I believe There were about 10 diagrams about AI governance. There were 15 people reposting the same AI RMF article that someone wrote and there were enough flashy lights that I felt at risk of a seizure looking at these animated GIFs of, of diagrams. The value that brought to my life was negative.
• 49:15
  Speaker B: Yeah, Completely.
• 49:17
  Speaker A: The few items with text had so many indicators that they were written by AI that it's a good thing that I hadn't had breakfast yet, because I probably would have felt like vomiting. And LinkedIn has become absolutely useless as a consumption source. From that perspective, there's two projects that I want to bring up. The first one is clean language. And having read way too many reports, documents, and postings in social media that have more N or M dashes than characters of actual text. Over exaggerated.
• 50:04
  Speaker B: I hate it.
• 50:05
  Speaker A: I spent an hour and put together.
• 50:07
  Speaker B: Are you locking in on this? Are you gonna lock in? If I see you lock in on anything again, I know. I'm just like, I get so tired of the words and stuff. And the transitions are all the same. The transitions, it's smooth. When you read it for the first time, you're like, oh, wow, this is really weird. But then it's like you've read one, you've read them all.
• 50:23
  Speaker A: Absolutely. And you can look at one and say, an AI wrote this. The person did not give it more than 30 seconds of review. What the hell is wrong? So clean like you.
• 50:35
  Speaker B: I mean, I have been working for a very long time to try to get it to write like me because I'm a creative writing major and I really, really do like writing articles with a large.
• 50:43
  Speaker A: Love your input. You're. You're exactly my. My target. Tell me what's wrong, person. Clean language AI is a skill took me an hour to write, probably another day or two of effort tuning it since then. But you install it in any AI, tell it to use it, and the output that it will give you will look like something that doesn't make you want to go vomit.
• 51:10
  Speaker B: Yeah. Remove all the EM dashes. Remove this database of a thousand words. Like, we have a lot of it. And if you go on, there's a lot of kind of like skills like Claude skills, like already already written that are like, you know, humanizer, like the humanizer skill and like all these other things, and it gets you some of the way there. But if you really want to have AI right in your personality and everything, you've got to feed it all of your writing. You've got to go through a really, really long prompt and you've got to like, tweak it and tweak it and tweak it and tweak it. And there's something weird about the models that it may work for like a month, and then it somehow breaks itself and goes back to the same craziness. So in My company, we have a rule. You're not allowed to write an email with AI. You're not allowed to. You're not allowed to write or represent the company at all using AI. You're only allowed to use it for like efficiency and gathering data and using it for spreadsheets and things like this. But you're not allowed to use it to express yourself. You can use it for like, like spell check, stuff like that. But M dashes are like a clear giveaway. Like I'm just surprised it's still doing that. Like remove the M dashes, that's like the first thing.
• 52:30
  Speaker A: Or it's not this, it's that. The negative to positive.
• 52:34
  Speaker B: Yes. It gets old.
• 52:36
  Speaker A: If you have the time, I'd appreciate your input on the skill that I wrote. It's. It's free open source. You could look at the source of it with all of the rules in there. You.
• 52:45
  Speaker B: What is it again?
• 52:46
  Speaker A: Humanizer Language AI.
• 52:49
  Speaker B: Okay. Clean language. Clean language A. You've heard it Everybody. Clean language AI. Everyone post about it on LinkedIn. We've been talking for an hour. I could talk forever. I've got to. Let me ask you this one question then.
• 53:04
  Speaker A: Yeah.
• 53:04
  Speaker B: If there was one. You have to give a presentation to TED Talk or something like that. What's the one skill that you would title your presentation that everyone, that you could promise everyone would walk away from this presentation today changed or knowing this, this is the one thing you'll be able to take away after my presentation today. What skill would it be or what takeaway would you offer your best thing?
• 53:34
  Speaker A: Learn to hate the right things.
• 53:38
  Speaker B: Okay. I mean that's great because I'm immediately curious like you have now. You have. I'm locked in. I'm now lock dash in. I'm locked in. What does that mean?
• 53:51
  Speaker A: Well, how often does it occur that a technologist engages in a conversation with someone who does not have the same knowledge or background that they do and they'll walk away from the conversation making a comment about uneducated people, something being stupid or not wanting to waste their time like that. It happens pretty often. I see a lot of people complaining in that. That type of response.
• 54:26
  Speaker B: Are you saying the technology person is saying that or the non technology person?
• 54:30
  Speaker A: The technology person is saying that they.
• 54:34
  Speaker B: If you look the same person that can't talk to people.
• 54:38
  Speaker A: Potentially, yes.
• 54:40
  Speaker B: Okay, gotcha. The soft skill. The soft. The guy with soft skills.
• 54:44
  Speaker A: So the simple 30 second answer to that is don't let the person who is uneducated frustrate you. Let the, the person process that didn't allow them to be educated frustrate you. And if you're not the right person to educate them, that's fine. But point them where they can be or speak to the right person who can put that education program together to help the world or that person in a particular case learn what they need to learn so that you, as a technologist, or potentially, as you said, a not as good communicator to non technologists, can get along with them and help them to understand your position and restate
• 55:42
  Speaker B: the premise of this again at the beginning of the TED Talk.
• 55:45
  Speaker A: Learn to hate the right things.
• 55:49
  Speaker B: Learn to hate the right things. What was hate. What was the right thing there? I just gotta get it. I'm a little bit slow. Okay. I'm a little bit slow. You need to teach me how. What am I
• 56:01
  Speaker A: speaking as fast as I'm thinking here? Rather than having prepared something as I
• 56:07
  Speaker B: usually do, I just want to know what I hate. We never prepare here. We're like all over the place. Add on coffee and stuff like that.
• 56:13
  Speaker A: The lack of education about technology in educational institutions and in early career positioning.
• 56:23
  Speaker B: Gotcha, gotcha. Don't hate the person, hate the process or something like that. Hey. Something like that.
• 56:31
  Speaker A: Yeah.
• 56:32
  Speaker B: Hey. Hey. Well, I mean, at the same time, though, there's this MIT professor that's got this viral video that he teaches, like, for free that he gives all his, like, PhD students, like, or something like this, like every year or something. I can't remember. It's like, it's viral on, like, X right now. He's basically teaching all the MIT nerds, like, how to give a presentation so that people actually, like, listen to them and, you know, basically teaching them how, like, how to communicate effectively. And one of the metaphors that he used was like, it was like Serena Williams. It was like, basically a tennis player or something like that. He's like, I'm, like a really good skier. And like, she happened to be there when I was, right, but she couldn't, like, ski with a damn. But here she is, like, this, like, amazing tennis player, right? Like, would I be able to hit a tennis ball? Like, would I know she'd, like, smash it in my face, basically. So I get. I guess what you're actually calling for is empathy because while you may be very, very good at technology, that other person's really, really good at whatever the heck they do, and your job is to support them. So he's kind of back to the customer service analysis, but really what it is.
• 57:36
  Speaker A: Is.
• 57:36
  Speaker B: Yeah, it's like learning to communicate and have empathy, I think. Does that make any sense?
• 57:41
  Speaker A: It does make sense, and you've put probably a more politically correct spin on the intent of the idea. But I, I believe this should probably be one of my upcoming talks when I'm. When I'm preaching, so to speak, to the. The new technologists in the industry or the up and coming technologists in the industry. So thank you for that framing. I will use it.
• 58:08
  Speaker B: It's your. I think there's things that people will walk away from this episode that you may underestimate because we typically tend to underestimate our talents and things that we do naturally and have done very, very well. And I think that the majority of the people are not holding people accountable to the outcomes of projects. In business ownership, making someone own the project is. That's gold. It's absolute gold. And I don't think people do that. I know people don't do that. So, Jeff and I got to make sure I pronounce your last name right. Pons Oslund.
• 58:44
  Speaker A: Pronounced the S's like Zeds. Pozlan Poslands.
• 58:47
  Speaker B: Jeff Poslins, you've been heard. Thank you so much for being on the show.
• 58:52
  Speaker A: Thank you for having me, Phil.