 So, a little bit of snafu here, right? So I got a little sort of adrenaline because I thought it was me, and so if I'm manic and I go too fast over something, please, like, hey, could you slow down a little bit? That's totally fine. So this talk is driving technical change. I'm going to get right into it. Oh, I should introduce myself. I'm Terry Ryan. I am a developer advocate for Google Cloud, and I'm happy to talk about that. I won't talk about much in this talk, except where, like, some real life experiences kind of come through. Now, does this sound familiar, right? You go to an event, you go to a conference, and you get really excited about a new tool or technology, and you want to use it, and so you spend time being thoughtful about where would this make sense within our organization. And yeah, like, I could bring this back, and this would really work well. This would be great. And you bring it back, and people, you don't just get no, you get hell no, right? Like, I don't want to adopt this thing. I don't want to do this, and now your nerd dreams are crushed, and you have to look everybody in the eye, and they all know they beat you on it, right? How many people have had this experience? How many people, this sounds familiar, yes, right? Make this really clear, you are not alone. Everybody in this room has experienced it, and when you experience this, one of the pieces of advice you will get is this. Change your organization, or change your organization, which is really a pithy way of saying, like, quit, or, like, fix it. Now there are organizations that this is true for, sorry, there are scenarios in which this is true. Like, I make fun of this, but like someone brought this up in the sense of like a very toxic organization, and that's fine, I'm not knocking that. But for this particular problem, I want to do new things, and people aren't coming along with me, this is really bad advice, and I'm going to talk a little bit about my background and explain why I think this is bad advice for this problem. So my first real job in tech was at a place called the Wharton School of Business. For those of you that may not be familiar with the Wharton School of Business, it is like, inarguably one of the top ten business schools in the world. It's arguably the number one business school in the world. Usually that's an argument you have from somebody who goes to Wharton. And at the time, this is like the mid-90s, they were competing with Harvard and with Stanford, and Harvard is Harvard, right, and Stanford is, well Stanford is Stanford too, it's like gorgeous and beautiful, and it has this pipeline directly in the Silicon Valley, and Wharton isn't Philly. Now I'm from Philly, and I love Philly, but even me, like, that's a tough sell, right? Like, you could be at Harvard, you could be in this beautiful paradise, or Philadelphia, like eat some cheese steaks. So what Wharton decided to do was to compete with technology, to make technology ubiquitous, to make every classroom have, like, instead of having one enhanced classroom, every classroom was our enhanced classroom. Instead of, so we had a portal before Yahoo existed, they had Facebook, before Facebook existed, they were on, they were doing cutting-edge stuff with the technology. In fact, that whole thing about like making technology ubiquitous in the classroom, they actually went to a vendor and worked with them to design the perfect podium that was raiseable and lowerable, had a cup holder, had a screen in it that you could pull apart the top of the screen, and that vendor resells it as it's a Wharton podium. And this actually is a Wharton podium and I was part of the team that designed it, like randomly they sold it and it's here, which is kind of cool. So clearly, we did, like, we won awards, industry awards. We had people coming back from Fortune 500 companies saying, I don't have computing as well as I did when I was a student at Wharton, mission accomplished. I had that problem when I was there, getting people to adopt new things. You'd think they're using technology as competitive advantage, they'd do it. No, I ran into this problem there. So it was like, okay, I know what I'm gonna do, I'm gonna go into industry. And I joined Adobe, which is a great place to work, it's fantastic, but I still ran into this problem. All right, screw this, I'm working for Google, right? And whatever you want to say about Google, it's a company that values technology and doing new things. And I have this problem at Google, specifically, like, come on people, why are you storing in spreadsheets what is clearly relational data, all right? So you are going to run into this problem wherever. So this advice, change your organization or change your organization. You can't, you cannot run away from this problem, you're gonna have it every place you go. So, and that's because it's not a technology problem, is not even a culture problem, it is a people problem. So along the way, I figured out some things. Some attempts to drive technology were more successful than others. And I realized people resist in patterns. I was very much into patterns and anti-patterns when I came up with this, and like, it's perfectly designed pattern language. I'll just come up with patterns and anti-patterns for this. So people resist in patterns and therefore they respond to certain things better. And so I came up with a process, process goes something like this. You identify the type of skeptics, the anti-patterns. You identify how people are resisting. You match them to countering tactics and then you implement tactics in a greater strategy. I will explain all this as I go through. But as you see, it's relatively straightforward and that's the thing about this, it is simple. It is not easy, right? Like rolling a builder up a hill is simple, right? Like just apply force, thusly. But it's not necessarily easy. So, before I continue, I need to bring this up. The first question I always get if I don't put this part here, is how do I know what I'm pushing is the right thing? That's a great question to ask. That is not part of the scope of this. Like this takes something minor, or should you use SQL or no SQL? That is a whole talk within a whole track of talks, within a whole event, which is a whole fleet of events that talk about this problem. I'm going to assume you're all good people and you all are thinking things through and you're making the right decisions with your technology. Make sure it's the right thing for your organization and you're not just wanting to do the new shiny, it's cool. But I'm gonna assume you've all done that and you're pushing the right things. So let's talk about the skeptics. You are going to see yourself in the skeptics. These are characters, not that one. But these are caricatures, right? They are not meant to be, if you see yourself and you start getting like, man, I'm gonna find this guy when he's smoking afterwards and hit him with a chair. No, it's not meant to be personal. It's not meant to be, it is just a way of explaining this. And I'll be honest with you, I will cop to the skeptic type I am. And it's nasty. So I will reveal personally that I am guilty of these things too. So yes, I understand these are characters and that real people are more complex, right? So, first type is the uninformed. It's pretty understandable, right? Like these are people that don't know about your new tool or technology, that's why they're not using it. You can change them over pretty easily. Hey, have you heard about this thing, right? It's relatively easy to move these people off of uninformed. You have to be careful that when you move them off of uninformed, you don't move them to one of the other skeptic types. But as these go, these are relatively low hanging fruit. The next are the herd, right? Yeah, okay, my mother down here is broken, so that's why I'm looking back. The herd, so they're not you guys, right? Because you are at an event trying to learn more. But there's a lot of people who aren't really interested in leading, they come to work, they do their work. They work nine to five, they go home and they do other things. They're not looking to push the envelope. They wanna get their job done and go on and do the things that their job enables the rest of their life. That's totally cool. Most of the work done in the world is done by people who show up, do their job, and go home. But you're here at a conference, you're looking to expand yourself, so you're not these people. So, they aren't looking for the next thing. They aren't looking for what's new. They need somebody to guide them. They need somebody to say, hey, come on in, this is where we should be going. So the good thing is that they will respond to leadership. The bad thing is that you need to lead them, that's effort. So just keep that in mind. Next group are the cynics. So skepticism is good. Devil's advocacy is good. Having to defend your ideas and your tools and technology to people is good. However, sometimes this can go to a pathological extent. There are people who just, they have a reason, no, for everything you wanna do. Now some of this is just skepticism and cynicism and people have been working in the industry too long and it's just the same thing they're doing over and over again, which is not altogether unfair. But there's another source of this and this is where I cop to being this. Certainly in my earlier days, I struggled very hard not to do this today. But there are, one of the reasons why cynics appear is that in this industry that we are driven by intellect, like you want to look smart, right? Because looking smart reveals that you're smart and that's what the capital is here. There are two ways to look smart. One is to prep and prepare and really know what you're doing and really know your technology inside and out and really, really understand what you're talking about. Or you find that guy and when he's talking about his stuff, you ask him a question that makes him look dumb, right? That's a lot easier. This is where I cop. Like this is the type of jackass I was. Not anymore, not anymore. And there's like a co-worker of mine in the room so he can reveal whether or not that's true. But so this is where that group, this is some of the dynamics going on with this group. The next group are sort of like the cynic in that they're saying no to this new thing and they have objections, but their objections are borne out by actually having tried the thing. They're not knee-jerk knowing. They are like, I tried this thing and it blew up in my face. Now, it could have been it was the wrong time, it was the wrong group of people that they tried it with. It was the wrong type of a solution. Maybe they tried a product from one vendor and another vendor would have been better in your work, whatever. Also, it could have been them, right? Like that's a possibility. And even if it wasn't them, they're gonna identify with that failure and anything of like, no, it's actually good is going to be met with existential dread. Cause like that means I screwed up. No, no, you didn't screw up. So you gotta be very careful with these people and dance around an ego. But this is a strong, strong argument to have to come up against. Next is the time crunch. I love these guys. They schedule meetings with you to tell you how busy they are and how many meetings they're in and how they can't possibly do what you need to do. I also like to say about these guys, there's never time to do it right. There's always time to do it wrong twice, right? So these are people that are so busy, so pegged. Like their processor, they're like my MacBook when I'm running Starcraft 2 on it, right? Like it's just, right? So they can't take in any new thing. They can't, the idea of stopping learning something and then reapplying, even if it could get rid of all the rest of their outstanding work, it's just, it's terrifying. Cause it's just gonna build up and build up and they're not gonna be able to get what they have already in queue done, let alone new things. So these people are a challenge. You have to show that whatever you're doing actually can reduce their thrashing and you have to time it for when they have a brief break. Otherwise they won't come over. So I'll talk about strategies and tactics of how to deal with that. Next is the boss. Now the boss isn't necessarily hostile to what you're doing but a lot of times, and for this sake of argument here, boss isn't necessarily the person you report to. It's whoever's the authority over the project or technology area that you're looking at. So it could be a client, it could be executive oversight, it could be your team lead, it could be a project, like whatever, it's not, don't stick with the boss itself. But a lot of times these people are not technical and yet we try to bring them technical problems and solutions and get irritated when they don't buy them. And the trick here is that you have to make your technology, the thing you're trying to do a solution to their problems and not a solution to your problems. If we switch over to this new way of doing things, our code base would shrink by 20%, it'd be fantastic and well, no, that is not their problem. If we switch over to this new code base, it'll be much easier to bring new developers on board and therefore people will be productive much faster and we'll be able to drive down costs of hiring new developers. Drive down costs, love it, right? So make your, whatever you're trying to move, whether it's a language, a product, a technology, a system, a solution to their problems and not talk about in terms of yours. Now this last group is the irrational. These guys are awful. The reason why is because whatever, everyone else like has a legitimate beef, right? Even the cynic is maybe just an overactive devil's advocate, but the irrational, the problem is their argument, the problem they have with your new tool or technology has nothing to do with the tool or technology. It could be that you cause a server outage like your first day at work and they've been pissed at you ever since, so nothing good comes from you. It could be you're a woman and they have a problem with that, right? Like that is a thing. It could be that they see being the expert in this thing as job security and now you're wanting to change it and that's an existential threat, so they have to oppose it so that they can keep their job security or at least in their own minds. Thing is it doesn't really matter what their reason is and like I could go into many, many more reasons because for the most part, with the exception of the sexism one, you really can't say that stuff publicly and like get away with it. I'm sad about the sexism that you can, but you can't say that guy ticked me off my first day so all his ideas are garbage, right? Like that won't fly, so what they do is they hide as another type and that's really the only interaction you need to have with these people is figuring out if they're irrational and then ignoring them afterwards. The way you figure out they're irrational is because they know they can't say the thing they really do, so they come up with rational reasons. I'm gonna tell you a story and it's gonna sound absurd, right? But just bear with me, this is a real dude somewhere. So... So... So... We had, I was a systems guy at Wharton for a while and we had SQL servers, Microsoft SQL servers and one of the guys in the team who was like basically a client of ours, it was sort of the relationship, told me he wasn't gonna use indices. He didn't believe in indices. Right? Like I stayed dumb saying that a lot. This is the guy's real opinion. Well, no, it wasn't, but this is what he really said and his response was, well, you guys spec out the hardware so well that I don't feel any need to like worry about, like cause I don't wanna mess up the right performance by adding indices. Like that's crazy. All right, dude. So that was his argument and then later down the road we were, we had a stored procedure rule because the database, the DBAs were better at DBAing than the developers at the time. So all the stuff had to go through stored procedures. It was fixing a problem that we had, whether or not it was a good rule or not, it worked for us and it was a good thing. But we were looking to figure out ways of easing it. One of the things we said was, well, if you go with an ORM, if you go with a Hibernate, that's usually pretty good SQL and we can manage that and so if you do ORM, you don't have to use stored procedures. The guy comes back and says, no, no, no, no. We go have a stored procedures. We're gonna like, I'm really worried about hardware performance under those cases, right? Like so, indices bad for hardware performance but stored procedures only is the only thing that will save our hardware performance. So it's clear that this guy's not not dealing with us rationally. And it turned out what it was, is that this guy was a manager and he came up with another developer. So they were developers together and management decided we couldn't promote just one of these guys because the other one will get resentful. So they promoted both of them to be co-directors but then left them with development responsibilities and the content of load of being in that scenario of like competing with another manager but also having to develop and like it was just too much in this guy just never want anything to change. He was time crunched to the extreme so he came like crazy, right? But that's what kind of happens with the irrational. You'll ignore them and I'll tell you more about that in a minute but so they were the last type. So we now have the types identified. Let's talk about tactics. Oh, I had this thing. Why am I going all over the way? No, now I'm going backwards. All right, there are two kinds of tactics. There are tactics that you can do all the time. They're universal. One of them is like become an expert. I'm not like spoiling anything, right? You can or I get to use the verb spoil which is the right way of saying that. They're universal. They can be used all the time. Like becoming an expert, you can just do that, right? There's nothing stopping you from doing that. It is moderately impactful meaning that in all cases it will not necessarily yield you results. You have to combine it with other tactics and techniques. There are also circumstantial, what do I call them, situational. They're only, you have to have the right environment for them, like a government regulation says you need to make this massive change. You tie your change to that situation and it gets, you know, you're solving the big business problem with this technical problem. They have very high impact and so when you look into them, they're awesome but you have to make sure, like they have to be present. So let's talk about the universal one. So first one is expertise. So the first thing I'll say is you should know more about the tool or technology they're pushing than the people you're trying to push it to. You should be developing an expertise. Now that doesn't mean you have to be a bona fide expert like industry rated. What it just means is you have to, like because quite frankly, being an expert is not a static thing. You don't become an expert then you're an expert and you're done, right? Because version two of that product comes out or this plugin becomes a big part of the ecosystem and like so expertise is always fading. So you always need to be moving to it not necessarily having reached it. So be pushing to know more than the people that you're trying to bring on board know about the technology so that you can be the helpful hand that they need to learn about the technology when they're struggling in the beginning. Next one is delivery. And it just goes without saying like don't be a jerk about this stuff but I work in technology so I know it does not go without saying don't be a jerk about this, right? And we all, I think we're all guilty of this. Like someone does something and your first response is why the hell would you do that? And that is natural but it is not friend-making, right? So interesting. Tell me about the thought process that led you to do that. It's funny, I've said the same exact thing and yet I've alienated less people with that unless they read through the lines. So like, have you tried this versus you should do this, right? Like soften your language. Make sure if you need to practice with somebody to make sure that you're not being too aggressive. I am from, as I said, from Philadelphia and we are not, there are many things we're known for but politeness is not one of them. So now working in the Bay Area I need to like check myself. Like am I being too blunt, too honest? There's something you may have to do, that's fine. People will help you do it. So make sure you're checking your delivery. Next is demonstrate. I demonstrate the cloud for a living. That's my job to go in and show this stuff working. And I can tell you how awesome our stuff is. I can tell you all these stats numbers and tell you why you should give this a try. But until I show a screen and I show, look, watch this, boom, and I said a whole bunch of load of something and it spins up all these things. People, whoa, wow, that's, I get it. I get what you're saying now. People need to see the stuff. There's a thing in, there's a saying in script writing, show don't tell, right? Show don't tell, show these things working. If you have to build demo apps, if you have to take a small problem you have and show that your solution works for it, do that. If you can demonstrate it, do it. The last universal one is trust. You have a long relationship with your coworkers. They need to trust you. You need to not lie. And I know that sounds obvious, right? But don't say your thing does something it doesn't do because they'll, they will catch it and they will call you on it. And again, if someone who demonstrates stuff for a living they will, even when you're just wrong and not lying. So make sure you maintain trust. Make sure that it's okay to not lead with the negatives. Every solution, everything has downsides, right? It's okay to not lead with them, but make sure you have them so when someone asks them you can give it. The other thing is don't use FUD. This comes up a lot. It's soft lying, right? It's soft like, I'm just gonna make you afraid. Do you guys know what FUD is for your uncertainty and doubt? So it's an acronym that IBM I think either coined or it was named for IBM. And what they would do is you'd go out and you'd have dinner with your IBM rep. This is like the 60s and 70s. So I think very mad men but nerdy here. And you'd be having dinner and they'd be like, hey, you know, I think I'm going with you guys but I've really got to check and I don't know. And the IBM reps would like, they're smoking cigarettes again in 60. They'd get up and they'd, well, that's great. We just want to leave you with one thing. That's this. No one ever got fired for choosing IBM. And then poof, pop a spoke and they're gone, right? Because they're just, like, and they would make you afraid for you, you know, like, okay, like I really need to go with them. Don't do that kind of stuff. It sometimes happens in the workplace, so don't do it. Little random aside, my father worked for IBM and I have a book on this stuff and he read the book and he calls me up and he's like, hey, I got to the chapter about FUD. And I'm like, yeah, and he's like, how do you know all that? And I was like, dad, like there's an internet, like there's this thing that like all this stuff is out there. And I'm like, so did you guys really do that? And he's like, yeah, yeah we did. And he was like oddly wistful for these days where he did that. So I, he wasn't in sales but I think he hung out with them too much. So a little over sharing there. Compromise. So I talked about stored procedures and ORM. That was a great example of compromise. People hated moving to frameworks and frameworks that included ORM. But they hated stored procedures more. Compromise. I would really like you to move to frameworks because that would make all our coding better and more consistent. You hate stored procedures, we will compromise and we'll go to something we both hate less. And that's a really great example. It's something you can do to like just brits get. Again, you have to have that sort of environment where you've got the thing to do. Next is synergy. I mentioned this briefly. Like you have a governmental concern like Sarbanes-Oxley or an impending tech disaster like Y2K or any one of a number of random things that could happen that is becomes a giant business concern. There's not necessarily technical concern but your execs and your management really need to solve. So what you do is you tie your technical solution to it. Oh, we need to log everything we do ever for compliance for this thing. Well, I've been wanting to do aspect oriented programming in a while and if we made that switch over it would be really easy to just add that and it would drive down the cost of adding it. Boom, done. So tie your technical problem to another larger problem. Business problem. Next is pressure. So has anybody here ever worked with lawyers from a technology perspective? Like supporting lawyers? Do they still use WordPerfect? Yes. Why do all lawyers use WordPerfect? Because all other lawyers use WordPerfect. It is the ultimate in peer pressure or if you go to business school it's called network externalities but it's peer pressure. So create a solution that everybody like starts using like Slack is a really good example of this in auto organizations. Why does everyone use Slack? Because that's where the answers are. That's where everyone else is. Among other reasons to use it. So create a solution that other people start using and get like that is where you find the answer. Like oh can I find your code for this thing? Oh well it's here it's on GitHub, right? Like there's another one of those things that became that way of like everyone else is using it so you sort of get pressured into using it if you want to be collaborative and successful. Last one is bridging. So I mentioned I'll go with the story procedure and hibernate thing because it was working for me. So I was trying to push frameworks and this was before we started doing hibernate. People would not come over to frameworks because most of the frameworks didn't support stored procedures which we had to do for the other thing. So I've wrote an ORM that was based on stored procedures. It would analyze the database, write stored procedures and then reread them to write code to generate. So scaffolding off of stored procedures. Don't ever by the way, don't ever go down this rapid hole. It's not a fun trip. Not that you really need to do that anymore these days. But what I did is I wanted them to use frameworks. I built a bridge. I built my own bridge. It wasn't the final destination but it got people on so that when hibernate came by and they didn't have to use my crappy thing, they were really happy about it. So bridge. I think that is the last one. Oh, last one with publicity. This used to be a lot harder. Nowadays as long as your company allows it you can put stuff on open source. You can get attention for it. You can get people using it around the world and then come back and say, hey look, all these people are using it. Are we using it internally? No, that's odd. So you can get publicity for stuff. You can try to put stuff up for industry awards. The other thing you can do is, and this is a dirty trick, but I've done this and it really works well, is every summer Wharton would redo their whole student system and it was, one year was a feature branch, one year it was technical debt because they only had two months so they wouldn't do it at the same year. They'd pay off technical debt every other year and they'd do features because the students rotated every two years. So one year, the team that did re-architected the student portal system used a whole bunch of my stuff and they paid off the technical debt like within the first two weeks of their two month window and so they added features in the rest of the time which was awesome. So what I did is I went to the CIO and I was like, did you care the awesome thing, the spike team did? Like in two months, not only did they re-architect the whole Vagant system but they added a whole bunch of features. We've never done that before, it's great. So of course the CIO investigated, what did they find that they used my thing? I didn't sell me, I sold them and let them sell me. So we cross promoted and sucked a lot of the oxygen out of the room for the people that opposed what we were trying to do. Little dirty, but you know, all's fair. So strategy, so we have these tactics and we have these patterns, how do we match them up? So the first thing is ignore the irrational, right? Other than to figure out their irrational, once you figure out their irrational, you're done with them. You're done, leave them alone. You're never gonna, because any time you spend arguing with them is wasted time, they'll just hop to another type. So ignore them. Next, target the willing. Start with the people that are the easiest to convert as many of those people over in increasingly difficulty. First group, uninformed and heard, obviously. They're pretty easy to bring across. Scythic and berm to the next easiest, time crunch are tough, so start tackling them towards the end. And then finally the boss. Here, this presentation is aligned, so if you're like, you really like this, don't just get it off the line, you don't have to take a picture. But this is the, this is which tactics line up best with which types. You'll notice that irrational have two. Not, there's not really, basically you're not giving them a lot of windows in order to argue with you. Like you're not being untrustworthy and you're not delivering like a jackass. That helps them not have too many things to glom onto to resist you. Next, harness converted. Tell people, I am trying to get more people doing this. There's a hand, I'm gonna get to that in a second. Great question. So it's okay, bring the people over and then tell them, hey, I've got this campaign and hey, you know what, maybe Bob won't listen to you because you caused a server outage on your first day. But he'll listen to Todd and Todd will listen to you. So you convert Todd and then Todd helps bring in Bob. So take the people that you've gotten and try to make this argument that you have this thing that's working. So hopefully this is all you need to do, right? You convert everybody this way. But that seldom, it happens, it's definitely has happened but it seldom is in every case. So the next, the last step is you sometimes have to go with the nuclear step of convincing management and getting a mandate. And the reason why I put bosses last and the reason I put convincing management as last is because you wanna do this organically. You wanna do this without mandates. You wanna do this with everybody agreeing to it but sometimes you can't. And if you go to your boss or management or whatever this figure is and say I wanna do this thing, the first question will be, well, why isn't everyone else doing it? Why is everybody else on board already? And you have to be able to say, well, actually I converted a large number of people over and I'm just waiting on a couple of people. So make sure you have a momentum before you go to management to get a mandate and look at it as an unliked final step if you need it. Okay, so now a couple quick conclusions and I'll pass over things to the ignite sessions. So change takes time. When I left Wharton, I felt like, God, like no one wants to do these things that are better. It was at that point, it was continuous integration and frameworks and code reviews. I had stress and friction with all of these. Two years later, I come back for lunch and they're like, oh, we just got a really tough meeting. Yeah, so we have so many frameworks that we're using now that we need to just whittle it down to one or two. So two years later, now granted, there's other people there that were pushing it, but I feel like I loosened that pickle jar for them. But it took two years, two years later and so it's hard to see when you're on the ground but change takes time, but it does happen. The next is that it does take politics and specifically office politics, which people hate, right? Cause like, nobody, almost, you ever hear someone who's like, I love office politics, I can't wait. No, no, you say like, oh, no, you know what, no, my job's great, I don't have any politics to deal with or yeah, you know, other people do that, but I don't care, I'm not in politics. And that person is lying to themselves or to you. The fact of the matter is, is that if you have more than one person in an office, you have office politics. And here's the thing, if you really want to not have or have to deal with office politics, the way to do it is this, when you start out, you say, oh, politics doesn't exist and so you get burned. So you say, okay, I'm tired of getting burned. What do I have to do? Well, like this is, you know, this guy was pissed off and this group over there, like they were late to it and they had already switched to something else and they weren't, so what you do is, okay, this guy got ticked. So instead of just trying to do it in one step, I'll have a series of conversations with them beforehand before I start bringing in everyone else. And then this team always does what this team does, so I'll start with them first and I'll convert them over and then that brings them over. And so like you have a victory and you're like, okay, this is great. So the next time you're like, okay, I know what to do and you start doing it. And then by the time you go through four or five cycles of this, you get to the point where you're not thinking about it. You're just doing it, right? Like you know, like, all right, I gotta do that and I gotta do that. And so you've gotten office politics to disappear but only through mastery. And it sucks because you gotta put effort in the beginning. But the only way to really, if you want office politics to disappear for you, master it so that it becomes something you don't think about, it's just something you do. And the last point is, you know, back when I first started giving this talk, like a long time ago, longer than I'd like to admit, I, there's this dream environment where like you would submit a, you know, to version control, it would get pulled down for code review, someone would click it, right? It would get pushed to testing servers or, you know, integration test servers. And then it'd get pushed over to staging and production. You're like one click all the way to production. And that always seemed like a pipe drain. And then I started working in like the actual technology industry and like realized like, no, that there are organizations that do that. But even when you have no shot at that, like even if you're a small organization that like, that takes resources that you don't have, but that's becoming like less and less of a deal, we see perfect as the enemy of good, right? But the fact of the matter is, is if you move to where you want to be, move towards it, you will be in a lot better place than you were before you started. So don't, don't say because they can't get there. Yeah, I'll never get there from here that you won't try them to make the move, try to make the push. Because between where you are and where you wanna be, there are a lot of better places. And here's the dirty secret. When you get to the perfect place, guess what? Version two is out. And so it's never gonna be perfect. It's never gonna be pristine. Everything is, depending on the word is changing or rotting depending on your outlook on life. But it's always gonna be different. So focus on getting to that better place between where you are now and where you wanna be. With that I'll say thank you very much. If you wanna heckle me, there I am on Twitter, T.Pryan, feel free to throw comments and questions at me. I have a book, that's really the bare minimum I need to do for my publisher. And thank you guys very much. I'll stick around for questions, but thank you.