 And what I'm going to present for you is sort of how I've presented IT for IT to executives over my last three years of working with the standard and since it was even before a standard. And some of the tricks and things that seem to work and some of the scars that I've earned where it doesn't work so well, things that I've learned. And the way I've got this structured is I want to give you a little bit of a background. So I've actually presented IT for IT. I look back at my three years and over 80 times I've presented to executives or teams of folks and tried to convey the value and convey what IT for IT was and get them to sort of subscribe to, this is a great idea. I've had the privilege of actually getting more involved in the open group. I'm certified now as one of the few folks out there is only 160 or 70 of us now. I keep track of it. And I am the adoption work group chair. So I'm highly invested in your ability to convey IT for IT to the folks that you work with or your customer base or what have you. I measure adoption and people taking a hold of this and owning it and moving forward in their own initiatives and everybody here is doing a different job, different companies, different outcomes that you're looking for. But IT for IT is really a common thread and I think that's why you're here in this room. So that's my current experience on IT for IT and really my agenda, the best way I think to kind of show you at least what works and what doesn't work is to kind of go through a scenario. And I'm gonna take about five minutes and do what I would consider my elevator pitch to explaining IT for IT in five minutes. And if you're in the elevator with an executive, here's your five minute chance to get them interested enough to have the next meeting. And what is that successful outcome? We're gonna decompose that a little bit. And then I'll have six tips for successfully presenting IT for IT based on some of the themes and the things that I've learned over the years. And of course Q&A. So with that, I am going to use the Open Group Standard Templates. They have provided some executive communication material and you can download this material and use it on your own. So this is sort of the scenario I'm gonna take you through. The company I work for, of course, being a good adopter use case, I'm gonna show you a little bit about how we have adopted and sort of take you through that scenario. So here we go, five minutes folks. Somebody keep me honest. Okay, so how can CIOs better improve what you're doing today? And you're faced with a lot of challenges. And I've noticed Mr. CIO that you've got a couple of key challenges in your environment. One is linking costs directly to the revenue, understanding the value of IT's contributions in your environment. And also is having a better financial transparency of where your investments are going. So your business basically trusts and continues to invest in your IT organization. So I met with their account team and I understood that these are some key issues that you're having within the organization. Would you agree with that Mr. CIO? Thank you, thank you. I thought so. We have a number of organizations that have actually already adopted the IT for IT framework and have started to realize the benefits from actually using this framework to change the way they manage their IT organizations and also integrate and use the tools that automate what many of these IT functions. And out of those organizations, I mean you would agree that these are the fairly large and fairly complicated organizations. And if they're able to do it, would you agree that this is something that you as a smaller organization could actually tackle? Yes, I thought so. What IT for IT really is, is a language for digital business and being able to have a true service portfolio, a management function in your organization. What we see is a lot of organizations struggling to transform themselves into a service delivery organization and still thinking about everything they do as bespoke projects. Well part of that is being able to have a standards based operating model. How can you interoperate with vendors or have your tool vendors provide different capabilities that cannot interoperate? Standardization allows you to walk around with your cell phone and use it anywhere in the world or any hotel in the wifi networks. Standardization is what fix that problem so we don't have to worry about connecting each other to the broader network. We have to, IT for IT also helps improve the financial controls and provides the end of business IT structure so that you can realize the business outcomes that your business is asking for. So these are the key elements that IT for IT provides and I think that this would be something that you would value. We understand that you have kind of four key areas of the organization, probably three right now but I would consider debt liver as the disruptive area of the value stream. And what each of these values, these areas of your IT organization has evolved to be is to be more of a value stream. You've heard of product idea to product, quote to order, order to cash. These are elements that your business is currently using to identify bottlenecks and to automate and mainstream the current business that you're in. So with strategy to portfolio, we are able to better understand what the strategy of your organization and where you should be investing to maximize the outcome for your business. With build we look at that in more of a requirements to deploy perspective. Once you understand the requirements of what your business is trying to deliver to be able to automate the steps in the processes to be able to deploy and realize those requirements in an environment. Detective correct is really the ability to understand and operate your IT organization and maintain SLAs and make sure that nobody's calling you two in the morning because something failed. And getting in front of that, being able to improve the service availability, service ability and SLAs. Last but not least is delivering standard services. What we've noticed is that there's a lot of organizations that treat every deliverable like a unique project but we know many of those services are repeatable and you should be able to standardize those and be able to automate the fulfillment for those services that are being delivered. This is IT for IT and a nutshell. And here at service now, we understand IT for IT is important. And what we've done is we've been able to map the IT for IT framework to the platform that we sell and the solutions that we provide to our customer base. So Mr. CIO, would you like to come and see my team and find out a little bit more about IT for IT and also the capabilities that we provide to deliver on the end-to-end value streams? Thank you. That's about it. Now that was a little bit of a nervous version of a five minute, but this is kind of how I would use this material if I had a few minutes with the CIO discussing really what IT for IT was, this idea of value stream concepts, right? Identifying what problems they already have and kind of correlating that back to what the value streams in IT for IT standard really represents. And I think that's where you guys all can do a pretty good job and leverage the material that's available. Everybody here has available to you the same basic material, right? These books are out on the shelves. Everybody can read this. What I found is that everybody, not everybody could present this information and contextualize it for each of those customer engagements. And that's the trick. What I've learned is that contextualization is key. Not everybody listens to the same message in the same way. Not everybody interprets it in the same way. So you've got to study, you've got to do some homework. So just a quick question. How did I do? Besides being a little nervous on my feet because I'm like sweating up here, right? Whew. Hopefully your CIO conversations aren't so under heated pressure. And what's a successful outcome? I think there's a couple of key successful outcomes of a presentation, whether you have five minutes or an hour or two hours, right? Make that connection. And part of that is being able to have them understand that you understand their problem. And there's a bit of an emotional drowning here where they have to realize that they're not with the other forks that are actually solving these problems. They're not, the problems aren't unique and that you understand what those problems are and there is a way out of it. There's a sales technique in emotional drowning. Anybody out here in sales? Ah-ha, a few of you. Anybody out here sales people? I mean, salesmen. Everybody here is a sales person and here's why. Even an enterprise architect, you got to sell your ideas, right? They don't just sell themselves. You have to be up there in front and be emotionally invested and convince folks that this is something that's valuable and worth pursuing and are investigating. You need to establish empathy with that individual and there might be a room full of different individuals and there's different objectives and different personalities and different drivers. So on a one-on-one, it's easy. You know, there's nobody, there's no third, fourth party in there to kind of convince that might argue or not really understand what you're saying. You just have to worry about one, but in a room full of people, it's a lot harder. And you have to really peak the interest of that individual based on contextualizing the story to their particular problems. And that is really the key for, I think, an executive presentation. If you don't peak their interest, they don't want to meet with you again. There's no reason to. Interesting, but I don't really need this. You know, everybody sort of experiences that, right? A guy comes to the door and tries to sell you a vacuum cleaner. I really don't need a vacuum cleaner right now. Goodbye. So you're not selling vacuum cleaners. You're solving an industry level problem that a lot of organizations are all invested in, including you being there, presenting IT for IT. And really the key objective is, or in the next meeting, the executives aren't there to make all the decisions. They're there to approve what their folks are saying and believing in and asking them for usually funding. And permission to move forward. They're not gonna do the work. So a lot of times the executive meeting is really the step to the next meeting. And you gotta look at it that way. When you get the opportunity to get up in front of the executives, you just have to get the next meeting. And if you've done that, you've done your job, you've been effective, and you can bring in more detailed information in that presentation, or smarter people than myself to present the details, based on the different interest areas. So the tip one is really preparing your IT for IT presentations to that individual presentation. It's understanding the customer really well, understand the material. If you don't understand those two basic things, you're gonna miss, you're gonna miss. You have to assimilate that information in a way that makes sense for why you're there. I could be out there and just talking about the open group. And I think there's a lot of open group folks in here that's what you do. You're selling the open group and the standard. But you, working for a consultant, or a software vendor, a hardware vendor, doesn't matter. There's another angle. There's another reason that you're there for. And you'd still have to assimilate in your context and adapt it to that audience. And that's the last thing, is really contextualize the story so that the audience understands and it resonates. Some of the examples that I've had in the past, actually, this is a slide that came out of FedEx about a year ago. And what FedEx did was they took the material, right, over the course of a year, digested it, used it, and then tweaked and tailored it to their organization. This looks like a conveyor belt for everybody, right? I mean, would you agree? It's kinda like, you know, this is a FedEx. And you don't see the conveyor belt in FedEx, but that's what's running all of those routing systems in the middle of the night when all the planes go to their distribution hubs, right? And they're trying to reroute packages to the right destinations. And so they've tailored the colors, they've digested this, and they've detailed this in their own way so that it resonates with their own executives. So Jody Jenkins, who I actually presented this with, really surprised me, and it was sort of humbling to see people that you don't even hear about. They just took the information verbatim at conference number one, and one year later came back with a great story. So contextualize and make it your own and make sure that the folks in your organization understand the paradigm in their way. Why IT for IT? Anybody know Simon Sinek by any chance? Yeah, so this changed my life in a little bit. I would recommend you going out there and there's only a few things that Simon Sinek has done, but this is one very profound thing, right? It's you start with why, then you show what, and then you, or how, then you show what. And really, and anybody can say why this is, why this is so profound? What's the meaning of this? And why is this sort of a different way of thinking? Nobody? Any Simon Sinek fans out there? That's right. The people that, and I like his analogy, too, because the people that use Apple products are the ones that get up the night before, standing in line all night long just to get that next version of the freaking iPhone. I'm not that invested or emotionally invested, but that's why people do that. They are emphatic, not only about the products, but why the company exists and what they stand for. And so part of what you gotta get across is why IT for IT is important. It's really why is the standard relevant to me, and this is a bigger problem than you and me in a room. It's an industry problem. We're fixing things that are much bigger and broader than just the things that we're dealing with in this room. And then I like to show how it can help, which is why I contextualize the problem to their problems, and I also show how other folks have solved similar problems using the same standard. So how can it help? And then last but not least, but what is the IT for IT standard? Should you try to teach the IT for IT standard in an executive meeting? Anybody guess? Anybody try it? Yeah, you could try it. And depending on the executive, it's a hit or miss, but 90% of the time it's gonna be a miss. And the reason is, A, they don't have the time to sit in there and listen. There's a lot of material here. It's a 180-page document and there's a lot of detail there. You're not gonna learn it, okay? But your objective is to get the next meeting and to meet with the folks that will read the material, take it away and do something with it. This is one of the things that I've done as well. I've taken this material and I've contextualized it for, in this case, an executive, CIO. And shown we're at a high level, right? They can digest the details, but also executives love these, I call them viscidine charts, get the red out, right? It's really finding out where to improve and what to do about it. And in this case, it's a little understanding the corporate priorities related to the value streams and the value streams you need to break it down and saying, listen, Mr. CIO, or executive team, diagnosis of a problem and detective correct is your biggest problem based on your corporate priorities. And so now you've got some level of detail and the CIO, and when I've done this in the past, we'll put names, budgets, timelines underneath this and use this as a planning template. Now, this isn't too complicated, right? I mean, any CIO would get this in about 10 minutes, right? Or less. And if they're not, you should just go away and start somewhere else. But this is a very high level understanding of an IT shop, right? And if you go through it at a high level and get to this point, now, who do you follow up with? You follow up with John over here that owns this particular step in the value stream and you work from this point of view and work out. And he's gonna get the budget because he's the one where we've identified the corporate priority lies. Props. Have everybody get one of these? Probably have a library of them by now for some of the folks that have been coming for a while. I use props wherever possible because this is kind of nice because you can like hand it out. And what I usually do when I do a presentation to a room full of execs or whatever, I'll hand this around the room and I'll pass it around. And the trick is figuring out who wants it bad enough. Who's gonna open it up, crack it open, thumb through it and find something while they're listening to you, right? This is sort of the background. You're not doing it as a full distraction, but they're able to kind of see that this is real. This isn't some crazy idea that you thought up, right? It's on planet Pluto. This is actually a real standard that has material behind it. And most of the time when I use this technique, the customers ask for the book. And it's usually one of the persons in that room that asked, you know, and one of the last examples that I have of that was the CIO for an insurance company. When I passed it around the room, it came back. It landed on my desk again and I think, okay, apparently it wasn't, you know, nobody found anything of interest. But as I was shutting down the presentation, the CIO asked for the books. And that told me, you know, I've got her attention and this is actually something that I can follow up on. But that identifies the champion. It also gets the information into their hands. And if it's not gonna be for her, she's gonna give it to one of her key folks, right? And then I'll have something to follow up on. But that generates interest beyond just the power points, right, there's a, you know, like when you come here, you get the free pens, you know, you get a free standards book, cool. The next thing is don't panic. Anybody been in a meeting and it went sideways? Through no fault of your own or maybe it was just a personality thing or maybe the folks that you've come into meet you used to work with and you've pissed off one in a previous life, right? You never know what's gonna happen. But don't panic, sometimes it's the wrong audience. I took a trip one time, I lived in, I live in Austin. I took a trip all the way to Houston, two and a half hour drive. Get in there and I'm gonna do my typical IT for IT spiel, right, hour long. I get in there, it's the wrong audience. It took me about two seconds to realize this is not gonna be of any value for them, any value for me. I didn't panic, I just sort of shut down fast. They didn't care and I just moved on. Backup slides, sometimes there are needs to kind of branch into other topics. So have some backup slides. I like to have those interactions, especially with a smaller team of executives, very informal, very interactive. If you don't get any interaction, there's something wrong, right? You should beat their interest or get them to interact and if they don't, you've got a problem. But you need to go to those backup slides because you're gonna have your consolidated deck and everything else that you could talk about that usually comes up, because if you've done it long enough, you'll sort of know, oh, they're gonna have a problem with bimodal, we'll have a bimodal contextual slide ready to go that you can bring forward. Hostiloid and so I've had that before. Believe it or not, I was called into, it was a company that's in Ohio. I was called out to be the bad cop. And really what there was is there was two managers in this organization that couldn't agree on a framework. It goes back to one of the examples, I think that you used during the lunch. Couldn't agree on the framework and I was there as sort of the industry spokesman and it started out hostile, right? This guy did not want to hear from me. He was already invested in something else, but I had to kind of rise above that saying, listen, this is a great thing you're doing, but I'll tell you, don't even deal with my business. Don't deal with my company if you're not gonna subscribe to this because our company's behind it. And so you have to take the high road, which is a big part of going in there and being able to deal with a situation is if you're always take the high road and do things for the right reason, nobody can fault you for it. And I like that. I think nobody, Gandhi, right? Who could ever fault Gandhi for doing what he did, right? And there's a lot of great examples in our lives. Don't give in is what that should be. I don't know what happened to in. It often takes two to three meetings to get through to an audience. There's another energy company in Houston that I dealt with. I met with them three times and no, it's no company that's in this room. Three times before we really started to see some momentum with this company. And it was really as subtle as this, they didn't quite understand what services were. And the fact that this wasn't delivering servers, this was delivering services and there's a different paradigm afoot, right? So sometimes it takes a few times to sink in. You're dealing with older people that have done things the same way for most of their lives. They got there using a paradigm that we've created in the industrial age and it takes a while to change. So two or three meetings don't get frustrated. And again, it goes back to take a different approach because I don't know, I can't remember who to quote here, but doing the same thing and getting the same result, right? That's insanity. You gotta change the approach, right? So take a different approach if saying the same thing over going the same way, it doesn't work. And find a different audience. So if you're really kind of in an organization and you're finding a ceiling, right? You can't go up, go around. Find somebody else in the organization that actually will listen. I was at Dell. This wasn't for this particular environment, but when I was at Dell, I was trying to do something that was organizational wide and I had one individual in the executive staff that wouldn't listen. I just went around him and eventually when all his peers had adopted and moved forward with this initiative, he was sort of the last man, single man standing. Find a different audience and then check back later because even at this conference, there are people here that I've met with and never heard back from, but the people that are actually here is an indicator that we're still moving forward. And so check back later, it could take a year, it could take less. Leverage key opportunities. This is kind of interesting and I'm all about maximizing opportunities. Don't exploit, but at least don't waste your time. Find the soft spot and go there. One of the ones that really works well is when a new executive comes in to play. Those new executives are in and they have to come up with their 30, 60, 90 day plan. This could be part of it. That's if you get in early enough and you can get in front of them and educate them on, hey, there's this bigger thing than just us, called IT for IT. We should rule zero, so you look at this as part of your transformation plan going forward. An event. An event could be an M&A, a divestiture. It could be a big project. The Phoenix project is a good example. It's either save the company or die. But the point is you gotta have these events. I met with a company last week and I was there in my day job providing ServiceNow stuff. I was meeting with the enterprise architect and they were saying, you know what? We're going through this IT transformation at the executive level, the CIO and they're gonna be presenting to the board in March what we're doing. It's not going so well. Do you have anything that can help? Well, out came IT for IT presentation and now we've got a very different conversation and engagement with that customer. So a big event was happening. I found out about it and I moved in to provide a solution. And that's really the transformation story in this case. They were going through a transformation. This particular company had hired a small consulting firm and apparently there wasn't very trustworthy the material that's come out, the framework that was being provided and everybody saw it and it was gonna go down in flames. So we stepped in, brought IT for IT forward and we have some momentum. One of the things that I wanted to also show is that you have to contextualize to whatever's going on. So one of the transformations might be bimodal. Anybody dealing with a company that's doing, trying to take all Gartner's sort of material and saying let's do bimodal, trying to implement this? No, yes, yeah. Well, you gotta break this down because the way Gartner presents it, it's not very easy to really implement. There's a lot of things on the table and what I've been able to do is map the bimodal story to IT for IT in a way that's easier to implement and get behind. And if you're not familiar with bimodal, the idea is there's a core IT organization that delivers standardized services, focuses on delivery, sounds like a repeatable factory or a request to a fill, doesn't it? Then there's a mode two fluid IT which needs to be able to deal with ad hoc demands. The way I map that to IT for IT is okay, well core IT, you're talking about repeatable, focused on efficiencies and costs. That's kind of what this request of a fill is. You can standardize the service delivery and once it's in the catalog, automate the fulfillment. Whether it's infrastructure or storage or some other business service, right, that's necessary. And then requirements deploy is really that fluid organization that develops based on ad hoc demand. Now this could be waterfall, it could be DevOps, it could be agile, it doesn't really matter. But the point is once somebody defines those requirements, you need to get them out there and that's fluidity. So bimodal differently interpreted, but I find organizations loving this interpretation because they can implement it. This is something I can get my head around and it makes perfect sense. And it also, bimodal is kind of turned into multi-mode, right? You can get into some of these arguments, right? It's not just two, there's many ways that we operate. It accommodates that. And I would argue that the standardized services are leverageable here. There's a big automotive manufacturer that I was dealing with that was automating the entire deployment process. So IT didn't have to get involved all the way even through deployment. So they've automated every step here and it allows all of their development organizations to just go crazy and deliver new services. And that new service goes back in the catalog for others to consume. Another good example, Jody Jenkins from FedEx. They did this. They basically were able to take the tools in their standard service catalog, build a new service over here, put it in the catalog for consumption and then get rid of it. They did this in two weeks. They built the service, used it for a week and that was done. So that's fluidity, right? If you can react to a business demand that fast, that's amazing. Anybody's organization could do that other than a single person organization? No, it's amazing. And then when you're funding, of course you have to fund both of these value streams. There's standardization of those services and the delivery options. And then of course these teams need to be able to use those standard services to unblock and facilitate the factory of getting an idea out into market. So that's my bimodal contextual slide just to give you an example. And over the last couple of years, I've developed a lot of these kinds of contextual slides because the executives that I meet with, this could be their thing. And I wanna detour into this because I find out this is their hot topic. If I speak their hot topic, I now have an IT for IT context. I have a path forward to present and get them on board with IT for IT. All right, tactics for overcoming some of the challenges. One of them I call it top up, bottom up, bottom up, bottom up, bottom up, bottom down by lot. What did I get wrong there? Yeah. Yeah, I'm getting hot. I'm not thinking straight. No, so the idea here is that depending on who you're dealing with in an organization, you might be dealing with one individual that has testing functionality ownership. And that's, yeah, they don't care about anything else. So you can't talk about strategy portfolio. You can't talk about debt or requirements to deploy. You have to just deal with testing. That's bottoms up. You're dealing with sort of that lowest level denominator in the framework, and you're showing them now where they fit in the world. When you're looking at Google Earth and you zoom out, you're looking at where you're somewhere is, you zoom out and say, hey, this is an island. You don't even know until you zoom out. So IT for IT is a nice tool to show that bottoms up guy where they fit in the ecosystem, or any one of those functional owners, right? Top down, again, if it's the CIO, excellent. You've got a great opportunity to express the whole value chain and then down. And the middle out is somewhere in between. And that's where I see people that own all of the operations team, they might wanna really understand what Detective Correct is, for example. And that's where you start. Explain the value stream. Use different starting points in each of these points of view. Again, being nimble on your feet, recognizing who you're talking to, you've gotta change your priority. And you may have a CIO and then, you know, their third or fourth level direct report in the same room. But when you're answering questions, use that point of view and they'll understand how they fit and how they work together better. So a lot of times I work with these large organizations that they don't even know what they're doing across the organization. So you're sort of providing roadmaps in some ways on how they interact with each other. And that's really powerful. You gave them a roadmap for their own company and they don't even know it. And then focus on one value stream. A lot of times when people look at this, they get really enamored and they get really excited. And they say, we wanna do this. Well, you got it, let's start small and incrementally get to all the other areas that you really wanna get to. But let's prioritize, right? You can't eat an elephant in one bite. Let's figure this out in one area at a time. So most of the time we tee up a value stream level analysis and we look at one value stream and say, okay, given your situation and priority on this value stream, let's decompose this and then we'll start from there. But in that executive conversation, you can tee that up ahead of time so that that next step is with the right individuals for that value stream. You don't waste your time in another area. Another thing is really stand your ground. And when you're challenged because, so they'll always ask, so what? That's not a priority for me. Stand your ground that this is an industry level standard that's gonna change how we all work. We all work together, right? It's how tool of vendors can be compatible with one another. All these stories are gonna come out and when people start objecting to what you're presenting, right? This is gonna be no value. Wait a minute, it is. It's gonna decrease the cost of ownership. It's gonna decrease the cost of integration, et cetera, right? There's plenty of opportunities to actually rebut the argument. But stand your ground and if you're not comfortable, bring some people that are. I certainly wasn't an expert the first time I went out there to talk about it. I brought some of the folks that worked on the standard into those environments and I was sort of a fly on the wall and learning and then they were there to back me up when I was actually presenting the first time. So get somebody else to back you up and stand your ground. Don't be afraid. People don't like change inherently and you're kind of talking about a pretty big way, a change in the way of thinking in many cases. It's not radically different. It's just organizing a little bit better. So those are the six tips, tips that I've got. There's some tactics for overcoming changes of course. Using those props, these props have always worked and I always tend to take a couple of books when I go and do a briefing and veritably I leave them behind. I've asked Open Group to supply me a small chain of these so usually I stock up a little bit when I'm out here and so I have enough for the couple of next executive meetings, thank you. But it works and that's it. That's pretty much what I have. That's what I've learned. I've got a lot more material that I've developed over the years and you've got a room full of people in the forum that you can just reach out to. As a chair of the adoption work group it's my interest to get you an answer. If you have a question, get you a coach, get you somebody to hold your hand, go into a meeting if you need it, whatever you need. So that's it, yes. Thank you, Mark. You have a question, Gin. Yeah. Yeah. Well you have a question. I'd be interested in hearing what your top objections are, valid or invalid? Top objections, well it's an architecture first of all. So when you say architecture you immediately turn off the attention of executives, right? So I often don't even say architecture, I say operating model or you know what I mean? That gets them over that initial shock, right? If you say reference architecture it's even worse, okay? Because executives don't understand that at all. It's a special kind of architecture. So that would be the top objection that I see. The second thing is usually that they're, one company, I'll just say they're in the airplane manufacturing business. When I presented this they were like, wait a minute, we just got to plan, build, run. You're telling me there's a deliver too? Yeah, well okay, well that means you're gonna go on another journey to figure out deliver. So those are the kind of objectives. If they've already got something in flight, if they've already kind of have a framework that they're using that is similar but not the same, those are the kind of objectives I've seen. Or like the individuals, right? The hostile individuals, they already have a religion and you're not gonna convince a religious person. I've actually had some battles, I'll just say with an analyst firm, people at analyst firms, nobody that's in this room, and it was clearly religious. I till was the religion there and you weren't gonna convince them any other way. So those are the other things. It becomes a religious discussion. Yes. One of your tactics is to focus on one value stream. Yes. Do you find that you've gotta try and keep the bigger game in mind as well? Always. I mean, that's one of the, I think that's one of the traits of enterprise architecture anyway. I found myself in my career, always needing to understand the big picture before I was able to concentrate on the little picture. Yeah, you always keep it in mind, but you don't beat the dead horse to death. Once you understand there's a big picture and all they care about is that, just throw everything else away for a while, right? But it is a challenge, the bigger picture, like typically in a larger IT organization, there's not one person owning the end-to-end process or the end-to-end way of working. So we have people responsible for enterprise architecture, portfolio management, security, risk. There seem to be monitoring operations and that can continue. So what is your idea of how do we then come to the right person and say, you have to think about end-to-end and CIO typically doesn't really directly see that because he has people already covering it. So how would you go into that discussion? Find somebody that feels ownership of the end-to-end way of working within an IT function? Well, one is going up until you find that individual where things come together, right? We're monitoring meets event management, right? For example, that's an easier one. You might find an individual. The caveat to that is they don't care. They're not invested, they don't want to learn. They've got a couple of teams, they seem to be working good. You're not giving me any sort of answer. So you might not be able to get there. You might just have to work with those individual teams and you are their architect. You're the one designing and I guess instilling the need to change and how to interoperate in them, right? Yeah, but still, if the organization is still fragmented, so you can go up to the CIO level and talk about IT-5T and they say, well, still coming back to the question is, how do you then explain to that CIO, say, wait, you have organized around silos, but now we need to think about end-to-end value streams. Think about IT-5T as a model, but still you need to explain how that brings values because he said, well, I already covered that. Well, part of it, this is really interesting because a consultant, anybody in here a consultant, you'll know that a lot of times you're hired to tell them something they don't know already, right? But it's like they have egg on their face, they just don't know yet. Somebody's gonna come in, provide pictures and documentation, talk to enough people to establish the fact that there's egg on your face. Part of that is being a consultant and being able to kind of show the evidence in their own organization, where there's disconnects. I've did this many companies and it works, right? Sometimes, again, you might present this and they don't wanna hear it. I've had that happen before. You present a bad story and then you're never gonna be invited back again, but you did the right thing. And surprisingly, if enough people know that around there, that individual may not be there long enough. What's the 10-year of a CIO? But it's a key challenge we face with IT-5-T reference architecture. You can talk with executives and they know they need to change their operating model, right? They know they need DevOps, agile development, but they don't directly see how then IT-5-T would be that specific solution for them. So we still in that... Part of that's education and marketing. I mean, this is something that we don't do great here. I mean, architects, how many of you guys know how to do marketing? Anybody have a marketing background? Okay, you're the exceptions, okay? But most architects don't know how to market. And why? Because we don't know the mechanisms of doing marketing, right? Or architects, we know design, we know constraints, we know patterns. When I was at Dell, I hired a marketing person that used to sell phones, market cell phones. It's back when Motorola was falling apart and there was people and I needed a marketing person to market what we were doing as an enterprise architecture team. But I think that's an area where even within a company that's adopting, I usually recommend they get some marketing help to market internally what's going on. Being that evangelist and having a marketing flair, but attaching to something that's already happening, an existing transformation, existing event, all the stuff, all those little tips, right? You put it all into a bucket and you pull out what's necessary in that particular situation.