Agility and Optimization: Jon Kern

YC:  Well, thank you so much Jon Kern, for being here with me in this podcast today.

JK: Oh, my pleasure, Yadi. 

YC: So I've been very excited to talk with you actually, because you are one of the, co-author of the Agile Manifesto. And, uh, for some of us working in the agile world, uh, it's very exciting to hear, particularly from those who create the manifesto in terms of what are we doing right and what are we doing wrong? But first of all, I wanna, get a little bit more background on you. How did you decide your, your career path?

JK: Oh, whew. How much time do you have? <laugh>?

YC: <laugh>? The short version, I guess. <laugh>.

JK: Yeah. Yeah. What’s funny is, uh, I saw a post on LinkedIn about things to do, you know, like learning soft, you know, learning how to code, and, I thought, oh, yeah, let me see what I did. And I happened to, um, started as an aerospace engineer, so working on cruise missile research and development, you know, jet engine testing in an altitude chamber and saw, there was this crazy thing when I wanted some different information on one of the monitors that somebody came and did some work, and it was like, what's that? Oh, it's called Software <laugh>. You know, wrote something to, you know, to make something appear. So I kind of got exposed to it early on, and as I morphed from, you know, pure engineering to things like flight simulation. 
So I worked, on a centrifuge based flight simulator. So there was a, you know, put actual G-forces on people. So you know, we worked, it was the F 14 flat spin, Top Gun fame, you know, when Goose each, you know, they got into a flat spin and Goose died. Well, I was putting people through flat spin, kind of how to recognize the flat spin and how to get out of it. You know, so it's crazy stuff like that. And, you know, really just kind of my career arc. I did a lot of moonlighting and kind of learning on my own and doing some, uh, software for local clients.
So I really went from FORTRAN to C to C plus plus to Java, and then, you know, Ruby -where were you all my life, uh, <laugh>-  wasn't until 2009. And along the way, I went from 15 years in DoD to creating my own company, uh, like an engineering firm that we did a lot of really fun stuff, like hardcore engineering for like what I would call engineering plus software. And then, Peter Code was one of my object-oriented mentors, and we had an opportunity to found, to get together with some other people and kind of kick off together as an entity, which built UML modeling tools. So yeah, there's a lot. I've been doing a lot of SaaS app for probably 12 years or, or more doing. I still code today for blaze mark.com. It's an app for firefighters and basically trying to save property and lives and things like that for everything from big pharma to small, rural, you know, very rural departments that are all volunteer. 
So to me, as an engineer, software was a means to an end. Right? It was like a great tool. I could do all kinds of crazy things but it was always about providing value and  doing cool, you know, doing stuff simpler than, you know, bending metal or, you know, building, building stuff. I'm very passionate about software. It’s a lot of fun.

YC: It seems like a very interesting career path that you have taken throughout and a lot of learning, and I'm glad you mentioned about the creating value aspect, which is a big thing when it comes to being agile. So how, how did the Agile Manifesto came about? Could you tell us a little bit about that history and how that, uh, particular event and, and the premise of, of that particular, document?

JK: Sure. Yeah. As I mentioned, I had been working with Peter Code. I first met him in like 92. Um, and then we did a lot of work together. Um, he's my object-oriented mentor, and I co-authored some books with him. But he's the more famous person in our relationships, you know, at the time. So I'm kind of working under him, just like he worked under Ed Den early on, uh, to write some of his first books. And I believe Bob Martin, Uncle Bob, he might have been the first one that thought up the idea to get a bunch of people together who were successfully practicing, let's say the non-traditional heavyweight processes of the day. And this is something I find when I talk to organizations around the world and conferences, you know, there's people that don't know what it was like 20 some years ago, <laugh> mm-hmm cause they weren't there. It was like, oh yeah, you're too young to even know.
 But, you know, I came from a, the DoD background, as I mentioned, and just like there's a military standard for making a jet engine. There's a military standard for making software. And it was a heavyweight process, as you might imagine. And the marketing leader at the time, uh, in addition to the, the, the waterfall typical approach was the rational, unified process was big. It had a lot of marketing muscle behind it. Maybe it's a little bit like the United States was a huge economic market, so the European Union was created, right? All right. All these little tiny things. Let's try to band together to be able to combat this large gorilla in the marketplace. So it's similar, I think where, um, all our little tiny ways of, of building software better didn't stand a chance in the marketplace because we weren't united so to speak.
So I believe Uncle Bob might've started the idea, but I think Alistair Coburn was also thinking about it, you know, so it was sort of a, um, coincidence. And they had a Rolodex that invited a bunch of people. They invited Peter Code. Peter told me, Hey, why don't you go, this looks like right up your alley. Um. So it was, um, the way that I like to put it, I, I think of it as, you know, a bunch of folks, many of whom were pretty good at modeling, like object modeling. So already kind of good at trying to distill the gist out of something got together. I always say we, we really left our egos at the door cause as we introduced ourselves to each other, we kind of talked about, I was doing mostly feature driven development and XP kind of a blend. That's where I first learned about Scrum, um, from Ken and Jeff. That's where I never heard of Dsdm, some European thing that you knew about. Um, I was familiar with XP. There was a, certainly the XP contingent was there. And, you know, it was really an opportunity to just begin to talk about, you know, how we practice and what we did. Mm-hmm
And we tried to find some commonalities. I like to think of it as finding the gist. You know, how do you work? And what do we have in common? That's it's not heavyweight, it's, you know, light. It was originally called the lightweight methodologies or something like that. So that was the original name. because we were talking about lightweight processes. I published my first lightweight process in like 95. So it was all about, you know, what's different slash common about our techniques versus the heavyweight process. 
So that's really what started it, I think is just the, the conversations from a bunch of practitioners, um, who yeah, as some people point, some good friends of mine pointed out, well, you were already successful. And that's the four values, right? That's really where that came from. And it was combination of, you know, meet in the morning, go skiing, meet in the evening, drink. <laugh>. It wasn't, it wasn't, you know, publishing it was almost an afterthought. That's the way I like to think of it is, you know, Waring Cunningham, said ‘Hey, you think I should put this on the web?’ Yeah, why not? I mean, we got something, so why not publish it? But <laugh>, nobody thought that this was going to happen.

YC: Interesting. Yeah. And you mentioned that it was called, uh, it was focused on lightweight methodology. How did that came to become agile? And how will you define agile? Because a lot of people and organizations throw that word around. So a lot of us may be doing it incorrectly. So how would you define it and how did that came about?

JK: Yeah, the, the one thing that I like about being asked, you know, all of the originals, you know, 17, um, RIP Mike Beetle, but I don't think anybody has a lock on the pure memory of everything that happened, which is really cool. Because I like to say, not only did we leave our ego at the door, there's a lot of humility even in the, the, the manifesto itself. Um, so my recollection, which might not be correct, was, you know, the word lightweight. Oh, he, you know, she's a lightweight or he's a lightweight. Like that's, nobody wants to be a lightweight <laugh> from that perspective. I remember Alistair saying that may or may not be true, but I, I'm just going on my memory. Um, you know, so like, yeah, I don't think that's a good name. Right. We don't wanna call this the lightweight something. And I had been doing research in enhanced fighter maneuverability, uh, like X 31 aircraft post, it's called postal maneuverability. You see it now in a lot of aircraft that are more advanced today, the ability to just crazy maneuvers super agile because in the combat world, you know, he who puts the weapons, you know, on target's fastest wind typically. Right. And that means n you know, not being able to fly  in a very maneuverable fashion. Um, so at a minimum, someone might have mentioned agility or, you know, agile and I definitely corroborated. So I don't know  if I thought of, that as of what we're talking about, but certainly that's how I felt that our kinds of methodologies allowed us to be more agile. 
You know, not like a giant aircraft carrier or, you know, huge ship that takes forever, you know, 30 miles to turn. Um, but you know, small speed boat that can really move around and more quickly, uh, address, you know, whatever we encounter. So who came up with it first? I don't know and I'm sure Martin Fowler said something like, you know, agile versus agile, you know, like how to even say it. Um, so I’ve always liked the fact that it's not completely clear. Some might say adaptive was addressed, but then Jim Highsmith's methodology might have had adaptive in it. 
The beauty of the word is and I know Josh Kerievsky and his Joy of Agility, he explains it pretty well. But if you look up the dictionary definition or you know, even my fighter pilot type, you know, it really is the ability to maneuver quickly, to be kind of, to have less momentum, you know, so that you can change, change direction. AndJosh points out, you know, there's a sense of elegance, um, you know, like a ballet dancer is agile or elegant. 
In many of my presentations, I have some ending photos, and one of them is  one of our twin girls doing a ballet pose at the end of the earth, you know, after they walked like 500 miles across Spain or something, you know. So as the sun setting, you know into the waters in a, you know, ballet pose. So I think it's important to really hold some of those ideas that, you know, what we're talking about. 
It's not some prescriptive step-by-step process, you know? I mean if that's the way you need to learn a recipe first, that's fine. But the mature agile mindset is, is more about understanding the, that we are talking about not building up momentum. You know, I always like to say reduce the gap in time between taking an action and seeing some results. So having that, um, sense of agility and grace, the ability to you to adapt and move under varying circumstances is that's really what we're after, in my opinion.

YC:  Yeah, absolutely. And then when, like, when you mentioned in terms of reducing the gap between the time of learning or I guess the importance of releasing and when you say not create a lot of momentum, how does that look like as an organization? What are some of the practices that any team or organization can implement to be able to be agile?

JK: Yeah, that's a good question. Yeah. The gap in time between taking an action and getting feedback. Yeah. If, if it's building an entire product and then revealing it, that's a very large, and especially if it fails, that's a very large gap in time between, you know, doing something and getting feedback. So that's a lot of momentum. That's a huge batch. So a lot of it, especially if your audience, you know, members haven't touched on some lean aspects, lean is also really fascinating realm to kind of get into because there's a lot of good lessons around understanding flow. Because for me, I often shock people and say, I don't do estimates. I don't do story points. Now I'll often say, you know,I’ll do an estimate when I have to, but it's a very rare, very rare occasion that you actually have to do an estimate. Um, and I, and the reason that works is because if you do a, a good job at, you know, taking an epic or a feature and turning it into smaller bits of value and even trying to negotiate scope away, and a lot of times people, what I find is do far too much work far too in advance of actually needing it.
Whether it's too much requirements, too much, you know, ux you know, weeks ahead or months ahead, you know, all kinds of large documents. Right? That's what we were combating back, you know, in the late nineties and whatnot, was that kind of mentality of, you know, giant amounts of requirements and then we'll do design. Right? That kind of, um, batch work  is what causes, you know, too large of a momentum. It's too difficult to change. You're too invested in that large requirements document. We drafted and we had 10 people, you know, in the company go through it and we got this, you know, the thumbs up and you know, two weeks into implementing it, you get some really big slap in the face maybe because you, somebody saw it and changed, you know, but there's a lot of momentum already and it's really hard to change.
But we already wrote a hundred page document we have to do, you know, so what I, what I preach instead is, um, it sounds counterintuitive, but be more lazy. Right?  This is the problem of a siloed organization where you have experts in their little, you know, I'm a ux, guess what they do? They do UX all day long. Whether it's the right amount or the wrong amount, I don't know. But if you know, you're gonna get eight hours a day or ux, um, and I see ridiculously silly UX being done because it's a step in a process of a silo. The people, you know, if you pick one value to learn, learn the interaction first type approach, you know, individuals over process and tools, right? Talk to each other. Understand what do you need from, you know, what, what, what does someone expect from you?
And that helps keep things small and that helps improve the flow and that reduces your momentum because you have smaller items going through the system and you make smaller mistakes. So it's really, it's really all about trying to be less sure of yourself. Uh, there's a lot of ego involved when you do a big chunk of work. That's a big hypothesis, assuming it's right. So what's the cheapest way to test what's the, you know, um, smallest thing you can do. And you'd be shocked at how small I can produce, uh, you know, something just to get some feedback. Sometimes almost. I like to say, think of the smallest thing you can do and then do less. But that's easier said than done for a lot of people. You know, those are some of the things that can help an organization because it's recursive, whether you're doing it at a,feature level or an epic or a, you know, a big product, you know, it's the same, same principles apply.

YC: Yeah. That's very interesting, uh, what you mentioned in terms of the approach of not being lazy, but also seeing how minimum steps needed to deliver value to be able to release something. And you mentioned as well a lot about that collaboration aspect. How are some of the good applications of that interaction particularly when it comes to conflict, because there's going to be issues arising about, you know, misunderstandings or trying to collaborate in a big organization where there's a lot of silos. How do you recommend we approach that in terms of facilitate that interaction in an organization that is silos or to deal with conflict, not avoid it but manage it?

JK: it's not like you can flick a switch and suddenly have everybody feel safe and you know, sometimes, in a meeting and somebody asks something, and if you feel yourself getting a little warm or you know, like getting a little nervous. You need to listen to that. And why is that and, and what kinds of small maybe, um, steps we can take as an organization, you know, and that's, again, recursive from the team on up and even the individual of course. So a lot of it begins with how comfortable are we with saying what needs to be said? And my British colleague John Turley, he'll say, yeah, like, if you stick your head above the parapet, which I think is something on a castle wall, <laugh>, right?
<laugh>, does it end, does it get chopped off <laugh>? You know, when you see him, when you say something. So the smallest, I think the, the easiest way to get started, and again, a lot of these things sound really simple. I remember seeing a, Jira issue, I'll paraphrase, but imagine there was an account profile, and you can imagine first name, last name, email, title or whatever. And let's just say the issue was, I add middle initial or whatever, you know, something, something that trivial. Well, in this issue, there was a UX design step because they used a template for how to do features. And they had a 13 step template. And one of them was, you gotta do ux and what did somebody do? They did ux. And that would make my head explode. That's the kind of thing where, all right, instead of just being so dogmatic mm-hmm. <affirmative>, why don't you ask, do you need ux?
Part of me is like, yeah, you could hire me and, and the very first day I could do that task because I'm just gonna follow along and shove another field, right? So the simple answer is, is understand, it's almost like, don't be afraid to ask the downstream or the whoever has to cooperate the UX and the developer. before you just jump to some conclusion about what's needed, why don't you ask what, what would be the best thing I could do for you, Yadi? I see this thing, I wanna say it looks easy, but I don't think I need to do a UX design. What do you need from me? And you might go, nothing. Cool. Um, so a lot of it has to do with trying to understand almost from, I don't wanna say contractual, but think of it more like, you know, we're working together. 
So collaboration is actually having the opportunity not just to I know there might be some, some debate about, I like to say cooperation is just, like a handoff where you don't talk much? Okay. Maybe technically that's a kind of collaboration, but I think it's a very low level. True collaboration is actually having a conversation and you know, the interaction first approach is what I like to call it. So that you have an opportunity to understand what's needed. That's when I also say, well, do less. And if they need more, they'll ask maybe, hopefully, right? So again, there's uh, that lazy mantra comes into play that sometimes see what you can get away with, do the bare minimum. 
And maybe that's enough because the reverse of that is doing more than was needed and you'll never get that time back. Right. So it's, it's little tiny things that again, are super simple, but apparently must be hard to do because I see a lot of people not doing that. They just plug away at doing too much.

YC: Yeah. It could be the sense of like we are showing our own value when it comes to being busy, that mentality that by being busy, the busier we are, we are going to provide more value. 

JK: Yeah, you're right. It's, we’re you know, I often say software would be easy if it weren't for all the people, because yeah, we're creatures of weird habits and odd thinking sometimes. And you're right, mistaking activity for progress is a common thread for companies who seem to be always busy, but not getting a lot out the door. And why is that? 

YC: And in your work and when you help other organizations, as you engage with a lot of people around the world, what are some of the either anti-patterns or bad practices that you see when they're trying to do their own agile practices or transform themselves into becoming more agile?

JK: Well, one of the things that we like to do, it's a bit of a Trojan horse, uh, like a bait and switch, you know, some kind of a technique where if we can talk about how they currently produce value, so like, walk us through it, you know, we'll get, try to get a cross-functional team together who's, who's actually doing the work. You might call it a value stream workshop type thing, but it's really all right, just let's talk about how you work and what that allows us to do is, is kind of, you know, we don't invite the bosses, it's just the people doing the work. So the real folks in the trenches, so to speak. And it allows us to capture how they're currently doing things and lets them spill, I like to say spill their guts, like all the pain, and so what that allows us to see is everything from what I was kind of just describing, the lack of true collaboration and the fact that there's, you know, just handoffs going on.
And sometimes during these sessions, not sometimes <laugh>. Mm-hmm. Like every time there will always be some, like, you know, someone, you know, looking down the table, so to speak. Like, what you do that, you know, like it's apparent to us that they don't talk a lot. They don't, you know, especially across the, you know, the wider, you know, from idea to, you know, cash, so to speak. There's definite lack of interaction, first definite lack of interactions over processes and tools. So that usually comes out and then, you know, it's, it's really common to see unrealistic large batch type work. So sometimes, you know, we uncover all the typical symptoms. You might think, you know, you see people doing, going through the motions of Scrum, for example, but not really having progressed, not having moved towards a more nimble fashion. You see the, the product in one organization, the joke was, it's like a, the product dump truck, you know, backs up to the teams and opens up and just shoves, you know, all right, here's the, you know, a hundred more things you need to do. 
So a lot of kind of unrealistic activities and yet still a surprise that things aren't working. You know, it's kind of, it’s almost hard to, to imagine that when you're so buried into a system that it's hard to pull yourself back and see the big picture. Yeah. Because a lot, a lot of the places are kind of compartmentalized. They're just doing their own thing and cooperating, but not really. They, you know, it's a lack of understanding the value and the business purpose and trying to deliver that at the, you know, as rapidly and as effectively as possible. You know, so there's a lot of excess. I think, to your point, a lot of people doing things that may keep them busy but not truly understand is just the most effective way for me to do my part to get value out the door faster. So I think it's a lack of overall holistic understanding. We turn things into a unit, um, like a complicated approach. Yeah. And treat it, treat it like it's a factory. But if you're doing complex, you know, really hard stuff that requires innovation. Treating it like a factory is death for getting any kind of innovation or any kind of flow, you know?

YC:  Yeah. It's great. And the key of having that holistic view for all the people involved to deliver value. And you've addressed something important too, because you've talked about, uh, frameworks. So if an organization wanting to be a bit more agile, what do you think about frameworks?

JK: If you've got, you know, much like if you wanna learn how to cook something maybe you get a cookbook or you just go online, um, and you try a recipe the first time that, you know, that's fine. Or for some reason, the agile world loves all this martial arts, you know, so there's the shu-ha-ri phrase which is, when you're beginning, you can pick up a framework, it'll have, um, a lot of value and things that you can try and follow along and, work the way that scrum tells you to work. But I often say, you know, scrum is not equal to agile. And if you're still doing the same thing like a year later you probably missed something. And so I think that's the industry like SAFe for example, is a giant prescriptive process.
Like, it reminds me of the rational, unified process back in the day, 20 plus years ago, it was a wonderful knowledge base. Like if I would get, you know, requests from prospects and they would have weird things in it, weird acronyms. I could always find it in the rep, you know, the cd, I could look it up, oh, that's what an SSS means, or an SDD or some goofy thing. Beacuse it was this giant knowledge base. And, you know, SAFE is, you know, you gotta give 'em credit. They built a beautiful website. They took Agile and lean and, you know, other stuff from project management. Um, and you got all kinds of click, templates and dates, you know, information. Um, you know, so that's a fine place like Scrum to start. But what, what's more important is to be a lot more curious and introspective and try to understand sort of the forcing functions and what it is we're trying to do.
Because the customer is not buying sprints. The customer's not buying story points, the customer is not buying parts. Right. These are all just machinations of, to your point, like frameworks, they may or may not be the best thing for how you, in your context can deliver value. So I tend to encourage building a kind of a hybrid approach that now you might start with Scrum, but you might end up going to Kanban or something, you know, where you just get better and better at delivering value, small bits of value, much more frequent, you know, doing something like the ART, you know, multiple ARTs, that's a giant batch. Batch is bad, right? I mean, so, I think it's important that people understand there might be a starting point. You might be able to learn from it, but if you really want to elevate your game, you have to realize a more holistic approach about, you know, we're trying to deliver the, the most valuable thing to our customer.
And that involves, um, trying to do the bare minimum, that process. And I think a lot of it also comes down to, you know, the, some of the foundational things that I practice and, and teach, so to speak. And a lot of it is, is the architecture too. Like how you actually architect a solution can, can either lead to silos or prevent silos, you know, so there's, um, sometimes just the way the system's architected is unscalable. And so, you have to overcome it apparently by just adding more people and adding more process. Well, it's probably because your architecture sucks. But I'm a fan of learning to do your own thing and make it tailored to what you need.

YC: Absolutely. Before we go, since this soft, this podcast is all about specifically soft skills. So I hear you mentioned and address a few, like the humility, communication, getting feedback as well, curiosity that you just mentioned. What are some of the skills that you consider we should cultivate as individuals more in order to be able to deliver value to customers faster?

JK: Well, one of the things that John Turley helped me realize that there might have been teams that I worked with in the past, and some were spectacular and some were kind of like, eh, and yet I'm thinking I'm doing the same sort of approach. And he pointed out that there's something about the way people make their meaning. And there's, you know, like, it's like a vertical development. It's, there's a, you know, different, different, uh, things that we go through as adults and, and how we, how we can kind of grow and be able to go from things like being an expert, an expert mindset where, you know, we kind of, it's very inward. It's all about my expertise and my value is all about, you know, me being the expert versus an achiever, you know, which is like maybe trying to also get something done and then an individualist and a strategy, you know, so there's different levels that, that you can work on yourself to be able to try to help understand not only how you make your meaning, but then how other folks on your team because, um, there's, there's a lot that you can, can accomplish if, like, I think what would happen in, in my own world was I might have pushed people beyond their comfort level.
So you, so the more that I learned about the way people make their meaning and be able to detect, um, like it's okay if we go right to the edge, maybe just a little beyond the edge, that that's where you can grow, you know? So, um, sometimes I, I, I might appear ambiguous because I'm holding two different perspectives and I'm comfortable with that. But not everybody is like, an expert wouldn't be like, pick one, you know, like, well now, like you, I can see it from both sides. And so there's, there's elements of that that you can learn about and be able to take advantage of to help move the team and individuals further along. And there's something else that we would often talk about around motivational orientation, and that is, you know, a boss comes in, says something, some of us like myself, who are very autonomous, um, might take it as a Oh, that's interesting.
Might take it as a suggestion. Might, might take it and, and do something slightly different. Um, a younger person typically, you know, not, not as, as, uh, seasoned as someone like me might take it as an order, you know, a command and a command and control. Um, you know, so understanding where your group is regarding sort of the, the motivational orientation is another, um, these are all like psych psychometric type things that, you know, you can actually test and get some information back, but that also helps get, get a, kind of, get a handle on on how likely, like, especially as a boss, if you know that there's a lot of propensity for more command and control than autonomy. You have to be much more careful about how you waltz into the room. And, you know, I remember a young developer, I was on this treadmill and kind of, I was at the back of the, the development room mm-hmm. <affirmative>, um, and one of the young developers up front, I saw, I saw the big boss come in, good friend of mine, you know, co co-founder. And he went and talked to the guy, you know, and I just go back about my way of working. Then after the boss leaves, he, the guy comes back, he says, John Trick was, uh, just telling me about da da da, da, da, should I stop what I'm doing? Should I, should I start working on that <laugh>? I'm like, no, <laugh>
<laugh>.
Yeah. That's not how it works here. But you know, like luckily, you know, he was, he, he came and asked. Um, but you know, there's a little sign of, you know, my immediate reaction is, you know, whatever he said, I don't even know what he said. It didn't matter, <laugh>. But the answer is no. Like, we're still, we we're working on what we said we're gonna be working on, but it's so easy to take that as a command cuz he's got the power. So the power differentials. And so anyway, there's, there's a lot of crazy things that, that sort of the softer side of how we humans work, um, that you can learn about. And, you know, some of the things that we bring when we consult with companies is, is trying to help them see like their organizational network. And sometimes there's big powers, you know, maybe, um, communication hubs. Wow. That person seems to, you know, everybody has to go through this person. What the heck? Um, you know, what is that? So there's, there's things like that that, that might help surface reasons, certain behaviors exhibited, and then we can have some techniques and, and small actions that we can take to try to, um, you know, like accelerate the good and dampen the not so good.
Yeah, that's absolutely. Thank you so much for all the key information that you've given us in this episode. There's just so much to think about and kind of remember what the end or goal of this, uh, initiatives or practices are, are about. So thank you and, and Arianna for your, for your time. So what is the best way for you, if they wanted to know more about you and about your work, what's the best way for them to contact you?
Oh, thank you. I think, um, yeah, LinkedIn is fine. People hit me up like yourself, uh, and yeah, yeah, you'd be surprised at how approachable I am. And I, I love talking about, I could talk about it for hours. Mm-hmm. <affirmative>, love helping teams and happy to have conversations about things that, that, uh, you know, I think are so important for helping us get back to doing joyous and meaningful work. Cause that's, you know, yeah. That's the point is, you know, let's have fun doing it and let's put smiles on our customer's faces and, and enjoy what we do. It doesn't have to suck at work.
Exactly. <laugh>, I agree with that. Thank you so much, John.

JK: You bet. Yadi. My pleasure.