Jeff Gothelf on Designing for Users, Enterprise Agility, and the AI Conundrum

And so I went into web design. And the nice part about, you know, 1999 at least was that if you could spell HTML in 1999, you could get a job. You know, it was, it was, they were heady times. And so I could do a little bit more than spell it. So I got, I got a job actually in Richmond, VA at IXL at one of the big consulting companies as, as a web designer. And so I was doing graphic design and, and markup and just basic, you know, brochureware type of websites. And that eventually evolved into a bit more, well, first initially information architecture and then interaction design as the web became more interactive. I ended up moving to Boston for grad school. And while I was there, one boss I had there moved to Virginia to become AVP of something at AOL.

And he was like, hey, why don't you come back here? And we were so cold in Boston. I was late, brother. Yeah. And so we were like, yes, yes, we'll go back to Virginia where it's not so cold. And so we went back to Virginia and at AOL I was doing UI design, working on the flagship software that went out on the CDs, which was really interesting because it, it was a, it's AB. It was AB to C product and we were using it, We were dogfooding the product at work everyday. We used the e-mail client, we used the, the AOL Messenger client.

We used all of the file management tools that came with that client, which gave us a real sense of what it was like to use those products. But they were completely under qualified for a, a business environment. But that's, that's what we did. We built that, we built the products on there and we would ship those CDs to everybody's house and then we'd wait for you to use it. And we see how that went. But look, it was nice. Like to your point about it being kind of a, an artifact of that time at that time. And, and look, in 1999 sort of by the time I was at AOL, it was, it was early 2000, so 2003, 2002 that that they had peaked at that point.

I think that peaked at that point and broadband was becoming more prevalent. And so, but still there were still 25 million, 30 million users of that product on a daily basis. And that's not a bad place to be when you're figuring out how to design software. Right, but that the long time frame of that feedback loop that you just described, Jeff, where you you build something, put it on a physical piece of media, mail it out or drop it from a helicopter. You know, we used to see those things on sidewalks in Virginia all the time.

And but then you have to wait for people to say, you know, obviously you do all the in house testing and you said you were dogfooding and all that, but then you have to wait for the consumer response be like, well, why is the e-mail over here? Why can't I do I am inside of this or all that kind of stuff? Was that it probably taught you a lot in in terms of like writing for a customer and trying to figure out the customer's requirements and how they use things. It look, ultimately it was frustrating, right? Because that learning loop, right? That's what that is. It's a learning loop. You make some assumptions about what you're going to make and then you get your, your VPS to approve it, which is always fun. And then you work on it for six months or eight or nine months or whatever it is, and then you stop and then you print 15,000,000 CDs, like you said, literally we would print 15,000,000 CDs, right?

And then, yeah, everybody gets, everybody gets seven of them. That's what it ended up being. And then you have to wait, right? Will anybody even install the software? Let's start there, right? And then if they install it, are they using it? What are they using? How are they using it? And analytics were tough to get, even over dial up, it was hard to get. And so we did a lot of usability studies, a lot of qualitative research just to get a sense of how things were going to work and then how things were actually working in the real space. But that learning loop, right? Say if you're working on something for six months and then you're learning, by the time you get a, a next iteration out, it's a minimum of 12 months, you're really making any kind of meaningful, meaningful difference because it takes that long for the feedback to come in and then get integrated into the next version of the product and then printed 15,000,000 more times and then sent out, right.

And, and that was, it was just frustrating because ultimately what what ended up happening was the leaders of the organization were impatient and they were highly opinionated. And so we just kind of did what they told us at that point, right and then and hoped that it would work. This was after the Time Warner merger. This was like during the like it was it at the kind of the peak of that, that transformation, yeah. OK, yeah, it's that didn't go well. It's not hard to, it's not hard to understand.

So from there, how did you, how did you sort of move into the, the coaching and and training and and teaching world? So I'm doing so I was doing UI design at the individual contributor level. And as as the web became more more interactive, the, the work became more interesting, more interaction design, kind of user experience design rather than sort of just placing boxes like organizing information on a screen only, right, That was right being of the web now it was like, how do we get folks through a workflow?

And so I bounced around a lot, certainly duringthe.com days. And then I, I worked a bit out in the West Coast. And when I came back to New York in 2000 and 7, I believe 2007, 2008, I ended up in a leadership role. Fine, I said. About 10 years into my career, I ended up in a leadership role leading a design team at a company called The Ladders in New York City. Oh yeah. Which was a job board at the time that catered to people who made $100,000 or more and the people looking to hire them. And that period in time was sort of like the heyday of agile transformation.

It was like, it was like the wave was really picking up steam. Every organization was adopting agile ways of working and trying to figure it out and investing heavily in that. And the latter's was no exception. It was a high growth startup with about 400 folks there and the engineering organization was using Agile exclusively and then the rest of us had to figure out how to collaborate with them. And at the time, this is kind of mid to late 2000s, there wasn't a good answer for how to do design, good user experience design, visual design, copywriting, etcetera, in an agile software environment.

The the the authors of the Agile Manifesto were 17 software engineers. The focus was always about sort of producing better, more predictable code, but the conversation about design and designers wasn't happening. And if it was happening, it was a really sad conversation. There was if if you went out there, it was really like in, in the late 2000s, if, if you kind of searched for how to do design in agile, it was the responses were really, it was really sad. I was like, oh, Agile sucks. There's no room for design in there, right? Design shouldn't have any role in agile. Let's, let's, let's fight against it. You know, there's a lot of US versus them. Yeah.

So I didn't have, I didn't have the time for that. I didn't have the, I didn't have the, the patience for it. And honestly, I didn't have the, the, the bandwidth to not solve this because I, I was leading a team of 10 or 12 folks. There was a large engineering organization that needed us to work with them and we had to figure it out. So the nice thing about that is my boss gave us an opportunity to experiment with different ways of working while at the same time collaborating with folks outside of the ladders who were dealing with the same problem.

And so all of that work LED us to a solution that worked for us. And I began to write about that solution on online, on blog posts, initially on some guest posts on some websites, but really focusing on what it meant to be an agile designer, if you will. And what's interesting is that that caught on because I was providing, and ultimately we were providing an answer to this question, not necessarily the only answer, but answer to this question. And it's a question that literally every single software development team in the world had and probably still has today to some extent.

And so that turned into a conversation called Lean UX. And I began speaking at conferences about this idea called Lean UX and, and my company was all too happy the latter's was, was all too happy to have me out there talking about this because it was really good for their hiring brand. Right here's head of UX talking about this method that that was developed within the the confines of the company. And don't you come, don't you want to come work here on these ideal conditions? And it turns out that book publishers go to, especially tech book publishers, they go to tech conferences and they look to see who's talking about what and who's the, the, you know, the, the leading voice on specific new topics. And I got offered a book deal.

In fact, I had Wiley and O'Reilly competing for the Lean UX book. And I ended up going with O'Reilly because Eric Reese was associated with them. So the Lean start up was just coming. This is 2010 at this point start up wave is is really picking up. The book was six months away from coming out and O'Reilly was building a, a series of lean books with Eric Reese's name attached to it, basically. So I ended up signing a book deal. It took a few iterations and and with the help of my now long term co-author and business partner, Josh Seiden, published Lean UX and that changed everything. So that was kind of the long, the long answer to your question that changed everything, right?

All of a sudden the book, the book did really well, right, continues to do really well. It's I think it's O'reilly's best selling design book, UX design book. No kidding. I. Think so. That's amazing. Yeah, it's like well over 100,000 copies sold over over 3 iteration, 3 editions, you know, and literally last night I spoke in a meet up and a woman came up with the second edition of Lean UX for me to sign it and the book's in its third edition now. And she's like, this book changed my life, right?

And it's, it's amazing to still hear that, you know, 10/12/13 years later about this particular topic. And so people started asking me to come teach this stuff in the book. And I was like, but I want to design stuff and lead design teams. But the teaching work was tempting. It paid a lot better to help. And it was really interesting to me because it was not a path that I'd considered. And so I chose to follow it. Do you?

I know you're a very thoughtful guy. When you look back on this now, do you think had you stayed in the design field, you would have had the same sort of not success, but would you have been, as, you know, fulfilled and happy as you are doing the stuff that you are now? I know that's kind of a A. Yeah, it's a tough one. It's hard to look. I, I was reaching, I, I was reaching a, a, a decision point or a crossroads. Let's just say when we began to write lean UX and, and that up until that point, even with agile being so popular, I was still in what, what I was, what I've called for years, the deliverables business, right? Like I wasn't necessarily designing stuff. I was making documents that described the design of something.

And even even then, 10 years into my career, eleven years in my career, on a good day, 50% of what I put in those documents never got built right. Which means. Which meant that on a good day, half of my work, that's a good day, half my work was being thrown away. Yeah, that's tough. Yeah, it's tough, right? And and I've been doing that for a decade. And so I was reaching, I was reaching a, a threshold there where something had to give. And I think that had I stayed on the design track, I would have continued to build these leaner, more cross functional, more collaborative product development organizations. And depending on where I would have ended up and, and the level of success in doing that, I, I think so. I think, I think we, I could have definitely, you know, done a lot of good work that way as well. But, but it's still look, it's still really difficult. Like I'm, I'm busy today solving those same problems with, you know, just a different set of

companies. So the the issues haven't been completely taken care of. Oh, no, not at all. And it's funny the way that you describe that, Jeff. I have AI worked at a big company for a few years and I had a good friend who's a very creative guy who worked there as well. And he ended up leaving because he wasn't doing the creative work that he wanted to do. And he essentially said I was getting good at things. I don't want to be good at, you know, like leading meetings and doing that kind of shit. And he was just like, that's not what that's not what I want to do. I want to go make stuff, you know, and that's for creative folks like you and me and and him.

It's it's difficult. And you know, I could, you know, you mentioned your music background. You can make music whenever you want to and you can just put it out now, you know, nobody has to approve it. But with something that you were describing before in terms of, you know, building processes and documents, yeah, there's other people above you. They're going to be like, sorry, we only need this portion of it. That's it. Yeah, and because of, because of the nature of how there's still like it is baffles me that, you know, I've been, I've been feels like I've been saying the same things for like 20 years, you know, but it, there's so much historical inertia from manufacturing when it comes to leading organizations today, right. And, and when we were making physical products, if if you're making physical products, OK, some of that actually still makes sense today.

But all of our organizations are software based businesses today. Yeah. And there's not, but they're, they're the, the idea of optimizing the manufacturing process doesn't make sense in a continuous software world. And getting that through to leadership, financial leadership inside organizations is still mind numbingly difficult, right? It's a lot easier for those folks, and I get it right, to have a conversation about what are you guys making.

Right. What is it that you do here well? I make I make Sharpies right there it is, right? It's binary, right? So you did it or you didn't do it. So the measurement is easy, right? I can I can measure it like you, you made the app or you did not make the app, the app works or the app does not work, right? That's, that's easy. But nobody, like very few organizations are talking about does anybody need an app, right? Is anybody looking for an app? Did they find the app right?

And and look when I was at AOL that that manufacturing approach to product development kind of still made sense because the software was static. Yes, right. Yeah. We had to print it literally. Yep. And, you know, today, right, software is, is, is continuous. There's no end to software today, right? These are just systems that we optimize and, and ideally, you know, deprecate and, and, and improve. And so this sense of like we're done with something doesn't make sense anymore.

Like, what does it look like? Well, I can tell you what it looks like today, but what's it going to look like in a month or six months or a year? I, I have no idea, right? And so getting this this this concept, this mindset shift into leadership teams is it's still still mind numbingly difficult. Oh, yeah. You know, in the security world where I've lived for 25 years, one of the big biggest challenges, and I don't know how much work you've done with security teams or folks in that in that world, but one of the biggest challenges is collaboration.

You know, a lot of the folks in the security industry came up as and still are individual contributors. You know, they got into security because they like doing things on their own. They like seeing how things work. You know, same way I think, Jeff, in music, music, a lot of musicians, you know, you sat in your room and played guitar or piano or whatever it was or wrote lyrics because that's what you wanted to do. But if you want to be in a band, you have to collaborate. You know, for security teams, there's a lot of collaboration that's required now because they're facing, you know, large scale threats. Even, you know, you don't have to be a large enterprise to have large scale threats on the outside. How big of a challenge is it for the folks that you're working with just to get the collaboration part of it to work?

It's still frustratingly difficult and and and look. And to be fair, I work primarily with large organizations. So large, usually legacy enterprise style organizations, so big banks, financial services, insurance, pharma, right. That's that's my world most of the time. Very ingrained to processes and. Yeah, and and and outsourced IT. Sure. Yeah, right. And that's, that's the killer, right. The killer is, you know, when I teach a class, if I, if I'm teaching a product management course at a financial services organization, there are no engineers in those classes. I'll have product managers, I may have some business analysts, maybe some project managers, a couple of designers, right? There are no engineers.

Why? Because that's a different department, right? And so like we have to, you know, the, the, the, the phrase that gets set all the time is we, we have to bring our engineering partners in on this. Why aren't there here from step one, right, right. And look, I'm not the first person to, to say this or to promote this, right? There are, there's mountains of material that talk about what good cross functional collaboration looks like, but it's still really difficult because I'll tell you a story. I, I was working with a, with a big German telco. So telco's another industry that I seem to find myself in a lot. And I was sitting in their office in Munich. I was teaching modern product management and, and sort of organizational agility to their leaders, right, how to, how to lead a, a software based organization, which is something that they weren't used to.

And I was sitting in the number three person, This is a 810 thousand person organization, the number three person's office with him and his two lieutenants on either side of him. And I'm explaining this collaboration thing, right? And they, they have, they have an, an like a, what do you call it? It's, it's not outsourcing. It's like an insourced IT, right? They have an IT department, but it's, it's over there. And I was like, look, you guys have to build these cross functional teams where you got product design and engineering working together on the same thing. And, and his two lieutenants shaking their head.

They're like never going to happen. And, and I, I knew and I understood their, their organizational structure. And I said, why? They're like, well, because we've got the separate organization. It's a separate PNL. It's a separate, you know, management structure. And how do we build this together? And the leader, the the number three guy, look at them and both and he goes, if not us right then who like if we can't make this change in this organization, who can do it? Nobody can if it's not like this team here that's in this room. And still, there's just so much resistance to it that when you do come across it, it's so refreshing and and fun to meet those teams because those teams generally are doing better work.

How much of that resistance do you think Jeff is? Because a lot of organizations, especially in the US have short to medium term goals. Like they have things that they have to hit every quarter, every half, every year. Otherwise they have big problems. And what you're describing and changing those processes is more of a medium to long term thing where you're going to see, you know, you're going to see results and you're going to see advantages. But it it's not going to be maybe this month. So I, I do think that short term thinking is, is an issue in this.

I, I think that there's, there's a, an extreme focus on revenue in the next quarter type of thing. But but here's the thing, short, medium or long term, the, the revenue goals are always going to be there, right? It's not going away. It's how, it's how we how we keep, it's how we stay in business, right? What I think leaders in those organizations usually fail to account for is or are the, the levers that drive revenue and the assumptions that go into whether or not we were successfully pulling those levers.

So that was very meta. So let me get specific, right? In my experience, leaders, leaders often talk about two things, right? They talk about the stuff that we're making and money, right? Revenue and features, sure. Basically. Right. In between revenue and features, there is a thing that we call outcomes. Outcomes are meaningful, measurable changes in customer behavior that drive business results. In other words, what are people doing in the systems that we're building, right?

So if we build a feature, what do we expect people to do, right? Those conversations are few and far between. And most organizations, most of the conversations are around, Hey, build me this thing and then make money, right? And So what we try to do when we go into these organizations is to is we literally connect those dots. We're like, OK, let's and, and put into perspective that, hey, go build me. This thing is an assumption. It's a hypothesis.

It's a guess, right? It's not often verbalized as a guess, right? It's often verbalized as a requirement, right? But requirement or not, it's usually an educated guess about what we should make, right? Let's go build a chat bot. OK, great, let's talk that out for a second. Let's say we build a chat bot. It's best chat bot that's ever been, and it's going to do all the things that we hope to do. What will people be doing with it? Well, they're, they'll interact with it, OK, What does interact mean?

Right? They'll, they'll use it. What does use mean, Right. It means that they'll ask it a question, OK, How often are they asking you a question? Like in other words, and you talk them through that and you literally put each one of those activities into a, a board, a digital whiteboard, whatever it is to connect it, to show them all of the various, those are the levers that you can pull, right? The, the customer behaviors, right? What do we actually want people doing, right? And then the question becomes, well, OK, how do we get people to do that? Maybe it's chatbot and there's an infinite way, infinite number of ways to implement chatbot, right?

And so for me, this is where the conversation gets interesting. If an organization is willing to, to put in the effort to, to do this right, it's OK, you've got a short term revenue goal. Terrific. What customer behaviours do we want to focus on in the next three months that will help us achieve that revenue goal? Yeah. And that's often not the conversation that happens. Often the conversation is what are we going to build in the next three months that's going to help us achieve those revenue goals. To me, that's the actual I, I, I do believe that short term thinking is an issue, right.

But even more than that, I think it's that folks fixate on the production of a thing rather than how do we serve our customers more effectively and what does that look like? And then let's figure out the best way to do it. Yeah. Oh my God, that's so true. I mean, it's extremely relevant in the security world where, you know, the outcomes a lot of times are almost like a negative pattern. Like if you're a successful security team, the outcome is that you're not having negative events. You know, the, the, the best end state is that bad things are not happening.

So you have to you, you know, it's tough to go to the board and say nothing bad happened this quarter. So we were successful. You know, it's, it's, it's not the same as look, I built ACD and mailed it to 15,000,000 people. Completely different world it. Reminds me, actually, there was a brief point in my in my life where I was a sound engineer in in between yeah, college and and actually getting a real job and sound engineering is the exact same way, right? It's been a good day. If no one says anything to you, right?

The only time anybody ever says anything to you is when something's broken or something back or. Whatever. Yeah, It's, it's a really weird place to live. And you know, a lot of my friends that are in that, in that world, it's, it's, it's a weird way to get your brain around things, you know, like, you know, it's a, it's a tough thing, But you mentioned chat bots and obviously AI is like a massive initiative all over the all over the industry in the security world. It's it's kind of weird. There's two different ways that people are using it for the most part now.

One is trying to automate simple kind of mind numbing, you know, repetitive tasks for security engineers or people doing security incident response so that they can then go do things that actually matter, can increase in efficiency, productivity, all that kind of stuff. Another way is kind of inefficient. They're just plopping it into security products and being like, we have AI now. We don't really know what it does, but it does some AI shit. How much of that?

Where are you seeing people succeed with, you know, rational thinking about implementing AI, if at all? There is no rational thinking about AII. Mean by definition? Kind of. Yeah, I mean, there isn't, right? It's it's, it's an arms race and it's an arms race to the to the bottom at the moment, right. It's like, oh, you have to, we have to say we have it. So put it in the product, right? And, and I think that for the most part, it makes most of the products worse, not actually better.

It makes it, it makes it messier, you know, and, and, and this default user interaction model of chatbot doesn't necessarily always make sense. I'll give you an example, OK. And this is not, this is, this is a, a personal use example. It's not a client example because my clients are all just like we're building AI. Are you solving a real customer need? I use AI, use an e-mail client that I really like. It's called Spark. Spark Mail. It's made by a team in Ukraine. I like paying, I'm a paying customer. Pay the money for it every year. My whole team uses it.

It's got some cool features, right? Been using it for a while. Recently, in the last few months, they've added AI into the product and the AI is either a e-mail composition assistant, right? Or it takes the form of a well, ask me some questions about your emails and I'll go find some answers to it. So let's take take those two use cases. The first one is e-mail composition. Look, you be the Josh, but more or less I, I speak good English.

I, I speak English pretty well, right? And, and the garbage that this thing spews as a response, as, as, as a response to the emails that I get is something that I would never send to a, a client, a potential client to, to a teammate to, to a vendor, whatever it is it, it would take me a tenth of the time to write an answer, then to edit something that this thing actually created. It's absolutely useless and solves zero of my problems.

So that's garbage. This new implementation they have, it's where you can kind of like talk to your e-mail that's potentially interesting if I'm looking for a theme or a thread across a couple of of different notes from somebody. But I still haven't found a good use for it. But again, both of those interfaces are, are type based interfaces, if you think about it, right, if they implemented AI into the tool, which said, Jeff, I noticed that you always respond to these emails first. I noticed that you always ignore these emails. I noticed that you've got, you know, 80% of your emails have answers that are less than 4 words, right? Things like that.

And then help me optimize those tasks, right? That becomes to me at least a a bot that understands my usage, sees specific patterns that it can help with and it offers to improve those. Yeah. And you certainly doesn't exist in this product. And, and you rarely see that, right. And So what we've done is we've, we, we're forcing AI into all these products and then we're forcing the users of these products to kind of know what to do with it.

Right. Yeah, that's, that's a big issue. I think, you know, the chatbot is the simplest example. Everybody uses those or is forced to use them with your, you know, doctor's office or some other dumb shit that you don't like. Isn't, is completely unhelpful, but so many tech companies, you know, software companies, everybody else is forcing AI in, in a way that really doesn't make any sense. A lot of these these things are just not ready for human consumption, you know, for, for everyday use. They're just not, you know, the, the e-mail use case that you just described. I have the same thing.

You know, Gmail has a version of that. It's OK. You know, it'll suggest some responses and things like that that are easy enough to say, yeah, that's fine. Just say no problem, I'm on it or whatever. But a lot of the other AI tools that I've used are just, they're trash. They're garbage. And putting those things into enterprise tech products is not doing anyone any favors. You know, it's maybe you're meeting your OK R or whatever, but you know your customers aren't going to be happy.

No. And, and again, all of this comes back. This, this is a thing. So, so you know, I have, I own a training company and we, we train product management and that type of thing. And we've got to incorporate AI into our curriculum. And I've been doing, I've been doing a ton of research, listening and synthesizing a bunch of podcasts and newsletters and things like that from AI experts and folks who have been building AI products for a while to understand sort of what we need to incorporate into our training to make it relevant. And without fail, without fail, across a pretty broad variety of sort of super techie to very, very sort of product and design type of spectrum of, of content.

Without fail, the people who've been building AI products for a long time say you still you can't abandoned the fundamentals And the fundamentals are you've got to have a strategy. You got to solve real business problems for real customers in a meaningful way, right? If you've got those things and AI, I can measurably improve the user experience. Terrific, right? Just remember right that it's not, it's not fit for everything. It's expensive. Yes.

Right. Extremely expensive, yeah. And folks are relying on it in such a way they think it's going to solve all these problems. And it's not. In a lot of cases, it's creating other problems and you know, if it's not, as you said, Jeff, if it's not solving anything tangible for your customers, then why are you doing it? What is the point? You know it's. It's well these days. The point is to tick the box right. Absolutely. Say like like I was on my my little past time and and is to go on the Apple App store, the iPhone App Store and and look for new apps. I feel like I I've got the same 15 or 20 apps I've had on my phone for 15 years, you know, and every single app now is like AI, this AI, note taker, AI, app, AI, mental health app, AI, whatever.

It's like why like why, why do I care? Why do I need to know that right? If the app solves my problem in a better way than the other app and it has AI, OK, terrific, right? But again, it's like tick ticking the box there, there's there's this FOMO, right? Like if we don't take the box then we won't even be considered. It's very true. That's, that's 100% it. There's, you know, it reminds me a little bit of, I don't know if you've ever run up against this, but in the large enterprise tech world of, oh, we can't consider your product or service because you're not, not in say the Gartner Magic Quadrant or something like that. You know, it's like it's, it's a table stakes type thing, you know?

Yeah, we have AI in this. OK, cool. Then we can, we can let you in the door, right? Like. Exactly. Yeah, Yeah, you have to, you have to be able to say it. But yeah, I, I, I've yet look, like I said, I work with a lot of enterprise clients and I've yet to really come across a product team that is meaningfully improving the customer experience. And these are B to B to C organizations with AI. Not, not, not yet. Maybe maybe, you know, and, and actually there's a terrifying, actually this is something I've come across recently too, reaction to this because of what I just said, because organizations are not seeing the ROI on these AI efforts.

Some organizations are now saying the only way we're green lighting AI initiatives, like we've given up on revenue ROI on this. The only way we're green lighting AI initiatives is cost cutting return on investment, right? That's what I was going to, yeah. Yes. So you're seeing that in the companies you're working with? Yep. Yeah, yeah. I'm like, OK, we're not going to make money on this, so it needs to cut costs. It's crazy. It's happening in a lot of places like as I mentioned before, companies trying to automate security tasks with AI.

And in a lot of cases, those are entry level jobs in a security operation center or incidents response team that are no longer available because they think that AI is fixing that, you know, and then you're eliminating the next generation of folks that have that baseline experience. You know, I. Such a real issue like the onion. You keep peeling the onion back here and it's like. Yeah, it's bullshit all the way down. Yeah, none of it makes sense.

And I don't, I don't know if you're seeing this, but it it sounds like you probably are. Jeff. Some one of my friends described as AI veganism like organizations that are just like, no, no, no, we're not. We are literally not doing that. It's not getting us anywhere. We have to sort of go back to the to what we know works. Yeah, You know, and and it's, it is terrifying, right. I mean, like this idea of it, if, if we think that the cost cutting here is going to help us get rid of entry level folks at some point, who's left to run the company, right.

You know, folks are going to age out. And then what? It's just the bots. Right. That's exactly it. Yeah. And it's it's not that far. I mean, it sounds absurd, but it's really not. If you sort of take the way that things are going to their illogical conclusion, that's where you end up, you know, in a bad sci-fi movie, unfortunately. So, yeah. All right. Well, I know you're running short on time, Jeff, but it was great catching up with you, brother. And it's it's I'm really happy for all your success. It's it's great to see you and what's next? You got any any other books?

I know writing a book is a pain in the ass. Providing 1 is a lot easier, but. Look, our, our most recent book is called Who Does What by how much? And it's a book about objectives and key results. And it's, it's a real, it's a really practical, tactical look at implementing OK Rs in an organization's at scale. And we did that, that came out about a year, a year and a few months ago. And we are doing a lot of work around that and using that as the backbone. So at the moment, we don't have another book planned. We'll see.

We'll see how this again, how this AI sort of shifts this I think shifts the landscape for a bit. I think there's, there's a lot of volatility. I'd like to see it level out a little bit and then get a sense of sort of where we might want to plant, plant our next flag. But like I said before a second ago, right, the foundation still matter. And that's where we've been, you know, working for 20 years, right? So, so I I'm not, I'm not moving off of that anytime soon. That's also, I mean, just as the last thing very true in the security world where you're seeing a lot of people, you know, throwing AI things or trying to implement it in, in lots of weird ways that aren't working.

And what people are finding is it's the basics that still work and still save you in the end, You know, the the foundational skills that are what actually stops bad things from happening. It's not some fancy robot. Yeah, exactly. All right, man. Well, Jeff, thanks so much for your time. It was great catching up with you and hopefully I'll it won't be another 30 years before we. What are we going to talk about then? We'll be robots by then. Amazing. Nice to see you. Thanks for asking great questions. Thanks man, good to see you.