Latest / You've Been Heard / 412- Nuclear Bombs, F-35s, and Herding Cats w/Stephen Salaka

Transcript

412- Nuclear Bombs, F-35s, and Herding Cats w/Stephen Salaka · You've Been Heard

• 0:09
  Speaker A: Welcome to another episode of you'd been Hurt. Today we've got Dr. Steven Salaka, and he's coming to us with an interesting take on not only AI, but just technology and the utilization of technology within the organizations. Stina, if you'd like to introduce yourself, please, sir.
• 0:28
  Speaker B: Yeah, thanks for having me, Mike. So my name is Stina Spaka. A long time ago, in a galaxy far, far away, I wanted to build nuclear bombs. But unfortunately, that really didn't pan out. There's a little bit of an accident and a couple injuries along the way. So I pivoted to computer science. I've always wanted to do stuff with computers. I found myself in Japan, and that's when I learned my real superpower. It's herding cats. I learned that I'm really good with technology, but I'm even better making sure that people know exactly where they need to do. So I went out there, got my MBA and then a little thing, a PhD in industrial organizational Psychology. This is where it gets interesting, because when you're in the technology world, everybody thinks of technology problems and software and hardware, but the real trouble that most organizations face is the people. And so with that degree in IO psychology, now all of a sudden we're looking at ways of how can we create those better requirements, how can we better engage with teams? And so that's where my career has led me, across multiple continents, leading global organizations, recently working on projects like the Tesla Supercharger network and the F35. So lots of interesting things over my years, for sure. Yeah.
• 1:37
  Speaker A: I noticed those things on LinkedIn on Tesla and the F35. And then that post that you put out there a little bit earlier around Genie Smith. Interesting fact. I was born and raised in Los Alamos, the home of the atomic bomb, not the nuclear. But I mean, it began that whole journey. Yeah. So when my original interview, when I was talking to Phil, I was telling him about railguns, and he had no idea what a rail gun was, so it was kind of fun. I also noticed that you like to do. Was it science fiction? You're a science fiction writer, too?
• 2:10
  Speaker B: Yeah, I do. Last year, I was able to put out my first trilogy. I'm in the process of writing another book now. Right on.
• 2:17
  Speaker A: Very interesting. And I must say that you're the first one that I've come across with psychology, too. Which one was chicken? Which one was the egg?
• 2:28
  Speaker B: So I've always been into studying and learning things. And so after I completed my mba, the question was, what do I do next? Well, you could do a DBA and understand the business at a more technical level or you could do like a PhD in computer science. Well, a lot of the computer science stuff was really like research oriented and looking at the hard math behind it. And that's interesting stuff. But I wanted something more practical. So DBA really was broad my mind. But then I also saw that the university was offering a PhD in IO psychology. I'm like, hey, that's kind of interesting. It's the industrial organizational psychology, the psychology of the workplace. What do we do as managers? How can we better lead our people? And that's where the psychology piece really sort of appealed to me. I was like, oh, how, how can I take this and now leverage that to, to help my teams become even better?
• 3:15
  Speaker A: So, and I'm interested how you ended up as CTO with that because that seems more like, I don't know, it almost seems like it would lead you towards HR or a different C suite role than technology.
• 3:35
  Speaker B: Most IT leaders don't have an Internet problem, they have a management problem. Multiple locations, multiple providers, multiple bills, different contracts. We help IT leaders make Internet boring again by consolidating visibility, billing support and monitoring without changing providers or forcing upgrades. If nothing needs fixing, we'll tell you that's vendor neutral advisory. Just go to you've been heard.com and answer the seven questions to simplify, streamline and save. Oh yeah, of course. But the big thing with IO psychology, it's all about the change management. And so what this has allowed me to do is all of my projects that I've run, everything that I've done have been extremely successful because I've been managing those people because I've been taking care of that psychological orientation. So as an example, we had a contract with UPS to roll out their new maintenance system and they had failed for years trying to get these things out there. But one of the approaches I took in there with my team was not just putting the technology and not just doing the migrations and all the data pieces, but we built a really robust change management piece where we're training the people, we're creating contests for them to go through the process. So they're really encouraged about the new platform. So when it went live, now everybody's using it and everybody's out there jumping on and getting in there. And so it was a successful implementation because we employed the change management piece. And at the end of the day they're like, hey, you're great at what you do. Let's have you re lead the Whole division. And you know, I've got raving fans for everybody who's worked for me because it's different than just being technical.
• 5:02
  Speaker A: Yeah. And that's one of the largest challenges that I've run into in my career throughout the years. That training piece of it, that rollout piece of it. But I've also found, and I wonder what your thoughts are on this, that the revisiting of that training, the training seems to be something that needs to be redone every six months, three to six months, depending on what it is. To be able to keep it in force, to keep that top of mind and keep everybody utilizing whatever you created or whatever you delivered optimally. Thoughts on that retraining? And because I, I know a lot of technical teams would say, okay, we got it up, but light to blink in, it does what it does, we'll make sure it continues to run. Training, somebody else, training, it's just like web content, you know? Well, we're great at standing up websites, but crafting the content within the web page, not always our forte.
• 5:59
  Speaker B: Yeah, for sure. Think about it like CPR certification. You've got to redo those every two years. Even if you're a paramedic, you're on the box, you're doing compressions on a regular basis. You still have to recertify every two years. And a lot of times that stuff doesn't change. It's just a skills refreshment, pressure. It's like, oh, I gotta get my BLS and ALS renewed. But at the end of the day, you're, you're practicing those skills. And as the medical advice changes, that's gonna change how we deal with our patient care. Well, it's the same thing in the tech world. We may put out a platform and everybody's using it on a daily basis, but if you don't have that refresher in there, it really does become stale. Now, instead of forcing people to sit through huge amounts of retraining, we found tools like WalkMe are extremely helpful in this regard. You'll have a tool that will do initial training. You create all these form packages, you'll create all this material, the simulations, all this great stuff. But then after you go through that, maybe they forgot how to reset an aircraft or attach this component to a new bomb. Whatever you're trying to do there, WalkMe will help guide you through that. So it's really that refresher that constantly does that. But the cool thing about technologies like WalkMe is it also captures what you're doing and Sort of guides you in that direction. So if people have discovered a workaround or there's a better way of doing something, it'll adapt as you go through the process. So you don't necessarily have to worry about constantly refreshing all that training. And it's just really baked into the end user experience. So it's not just, hey, here's an interface and then some pointers and guidance on how to continue using it. Yeah, I think from a technologies perspective, if the technologist is doing this, they've usually got a lot of those process pieces already in place. So like, hey, I do my code, I pass it through penetration testing, I do some vulnerability scanning, I do all of these things as part of an actual process. So I'm not too concerned about that pathway. It's these folks who are out outside of that, who don't know that those pieces exist, where those problems come up. We understand package injection, we understand NPN poisoning and things along those lines. So we're very aware of what packages and libraries we use. In fact, we probably have tools out there that say, hey, you got a CVE on this package, need to update it X, Y, Z. But when you're talking about everyone else, they're just like, hey, I'm so happy I got this widget now that I've always been looking for. It's doing what I needed to do. They don't really looking at the architecture, they're not looking at those things underneath it. And those things underneath it may be vectors for infection. Like the example I put in the post. Klein was a package a lot of people were using. Somehow the, it had been poisoned and it allowed the person to install Claude code on about 4,000 machines out in the wild, just because the, the package was there. So if you were using Klein and didn't understand any of that, you know you're going to have an infected computer on your thing. And the whole way of getting there, especially now with AI, it's kind of crazy AI. We're moving out of the time of search engine optimization where you had to get those page ranks and now it's just looking at relevant articles, relevant things. So if you get a pr, a press release going out, it's going to look at that. It's something really high. So if you put a PR saying, hey, I got a new package out, that package might actually start getting recommended inside the build process. When Claude is out there saying, I need a package for something, it'll pull that particular package in. Then all of a sudden your MPN Stats start going up and all of a sudden it starts building in and of itself. And it's great for you as a, you're getting that stuff out there. But think of that as a nefarious actor, something that looks innocuous. It looks like it does what it needs to do. It's out there, everybody's using it. And then all of a sudden you get some injection when with the latest update and now you've got a botnet suddenly sitting out there because it's not vetted, it's not verified and validated. I mean even though it's open source. Sure. I mean the great thing is it does provide them with a lot of flexibility. It's going to pull a lot of those low hanging fruit off our plate like hey, I need this report updated or I need this tool to do xyz and it's going to allow them to dip their toes. The problem isn't so much the individual using it, it's the issue of like oh look, Frank over in finance has done something and now Sam goes over there and uses it too. And now all of a sudden you got so many people using it. So this one micro tool becomes spread out through the organization, so the problem shadow it becomes compounded exponentially. Because now it's not just Frank over here. You've got somebody over there in ops, you've got somebody over there in shipping and receiving. And they all got these little tools that are now making their way throughout the organization environment, no control over it There' you know, understanding of what actually is out there. And then if one of those things breaks that they built a process around, they're not going back to Frank who built it, they're coming over to it say hey, our thing is completely broken, or worse, it creates this vector for an attack surface and all of a sudden you've got a cybersecurity incident. Because they weren't abreast of the cybersecurity policies or procedures. No shame on them because that's not really their job. But at the end of the day these tools are making it. So it sort of has to be. We have to have some framework or some tooling or some sort of security assurances like a sandbox or something that we can make sure that these things aren't becoming those surfaces.
• 11:03
  Speaker A: And I haven't seen those tools or those best practices yet. I, you know, we know some of these innately, just like you and I are talking about of trying to stop that injection and the supply chain injection kind of things and it's the way you've presented it is a very obvious way of getting a hold of some of these nefarious packages. But I'm not seeing, and nor am I hearing from any of the research groups, ways of stopping that, let alone ways of empowering Frank and Steve to take care of the low hanging fruit for themselves without having to have a group of 50 IT people drop into all of the different parts of the organization to try to increase the speed or the volume or do more with less, all of those things. And then the thought while you were talking about it, of how easily it's going to be for Frank to hand that off to Steve without anybody ever knowing about it until Steve starts bragging about it. And it's going to have hit five to 10 other people or many more than that before the guys in the back corner finally hear about it.
• 12:17
  Speaker B: Yeah, you know the big issue with email when it first came out is like, oh, people are going to be able to send anything to anybody and they're like, oh, we're going to have company secrets exposed. And then we got training on it, people had some common sense around it and yet we still have people falling for phishing attacks every day. It's like, you got to do the phishing training, people fall for it and that's just plain easy social engineering. Well now it's not just email, it's all these other things. I mean, when AI first came out a couple years ago, when ChatGPT became the hot thing, people were loading their corporate documents into ChatGPT saying, Synthesize this for me, do this for me. And so many passwords and keys and corporate secrets got out there in the public Internet as a result of that. So a lot of folks just said, yep, we're going to shut down access to those things, not let anybody get out there and do that. And since then we've put in some training in place and hopefully people are a little bit more cognizant of what they're leveraging the public models for. But it's still happening. People are turning this stuff out, it's getting out there. You can query Claude and those are places and you'll find out probably some active keys as you go through it. So it's going to need to take a deeper level of training for folks. I mean, when we rolled out Power BI at smtc, one of the issues is we wanted to have a self service model where people could go out and do things on their own so they wouldn't have to involve a lot of it. The problem with that is they can corrupt data, they can make reports all wonky and all of that stuff. So it was a matter of if you want to be able to do this, you've got to go through and pass all of this training. We're going to certify you as a Power BI super user and things along those lines. So we never got the access until they actually committed to going through, taking all that material and making sure that they at least had the awareness and understanding to do that. And that set off a lot of people in terms of like, hey, I'm not or put off a lot of people. We don't necessarily want to do this anymore because it's too much work. But you had a couple people that bubbled through and now they became the SMEs for Power BI throughout the organization. They're doing really well in terms of what they do and there's that connection with that it that was established. So now, hey, I'm trying to do this and I want to check to make sure it's secure and safe. So there's been that local control, but what we really need to prevent is that wild west mentality which we sort of have now of everyone just randomly doing stuff and winding up with a mess that's going to be too hard to clean up down the line.
• 14:33
  Speaker A: Yeah. Hearing this and thinking about one of my last interviews and their leveraging of
• 14:39
  Speaker B: it, there's been a huge shift in how we've leveraged AI. So at Meal Match we're building out a meal planning software for low income folks so that they can go out there and find available meals, recipes that they can use that are within their budget based on access based on the local grocery stores. And it gets rid of the burden of meal planning. So initially we had coded this all by hand because this was back in 2004 timeframe really wasn't any agents out there at the time and they really weren't up to par. So we were doing a lot of the coding by hand and we were integrating AI as part of the rag model as part of that. Well, as we've gone through, we've actually shifted away from a lot of the hand coding. We're now using agentic programming to actually do a lot of the work. And so we had to shift all the models we had to go through use AI to help create some of that spec driven development pieces and now it's able to produce the code and work through the pieces that we're doing. So we're Able to accelerate with a lot fewer folks. I mean we're startup as it is. And then we actually took a lot of what we did inside of the rag model and we converted that back into standard queries on side of the database. So once we figured out what those parameters were and how that match was occurring, we converted that right into regular statistical formula so that they could pull that out. And now the AI piece is more of the interface, like natural language. Hey, I want to plan this, I want to do this. And then converting that into something that they can use in the back end. So that's helpful help bring down the cost of the tokens across the operation. So instead of tokens for the query, tokens for the processing, tokens for this, it's tokens for translate this into something that we can fetch and now do the fetching in the back end. And it's not only sped things up not having with response, it's made the end user experience a lot better. So it's that AI of where it was then querying was what it was with the rags to where it is now being able to use it to build and have AIs where it needs to be as opposed to just AI everywhere.
• 16:30
  Speaker A: Okay, so it almost sounds like radically different approaches. So internally the team is using it to generate the code and to add and augment the application and present and build. But then you're also taking and what you're providing to the consumer, the user of the application, you're optimizing your token usage and allowing them to not hit as many portions of it, but just taking that, converting it and then allowing for the optimized queries or the optimized response generation.
• 17:06
  Speaker B: Yeah, and this is where that vibe coding, if you want to call it that, really comes into play because it gets you to the point of seeing the problem space a lot more clearly. Because a lot of times you don't know what you need to put together and you don't know all those different pieces and moving parts that are there. So AI lets you get to get there quickly. You can use AI for those boxes that like, hey, I need you to do this. Hey, I need to do that. Once you've got those pieces figured out, the next step is taking it from that prototype or that MVP and saying, well now how can I do that with just database queries? How can I convert that into a Kafka queue? How can I take AI as the processor and now split that out and actually build regular components at the backend to handle those things. And what I'm seeing with a lot of the vibe coding coming out of Lovable Replit and folks out there is they just leave it at their prototype stage. And so they're churning out a million credits a day because everybody's just sticking with that AI piece rather than saying, hey, AI needs to be here. AI needs to be here because that's what the intelligence is. The rest of it is just functions and querying and pulling data in and out. And so when you do that, the next step, that's where that software engineering, I think, has, has evolved into. No, I, I don't think so at all. I mean, you think of this analogy. Excel came out, what, in 1983 or 84, whenever that was. Well, at the same time you had Visual Basic. And so people could code their own version of Excel. They could. Instead of paying the licensing fee for Microsoft, it's pretty easy to create your own sort of spreadsheet. But nobody did. Why? Because there's a maintenance cost associated, there's a support cost associated with it. If you don't get the coding right, you're, you're, you got all these bugs you've got to work through. So there's a huge cost in terms of maintaining it. So companies didn't hire developers because of Excel. Excel is just a thing and there never was that replacement. Well, it's the same thing with these, these big SaaS programs. They're complicated, they're huge. There's a lot of different connections that happen. And trying to replicate and recreate all of those pieces, it's going to be nearly impossible for an AI agent to do it. I mean, it collapses under a weight of a couple thousand lines of code and it starts hallucinating. Now you've got millions and millions of lines across thousands of different modules. It's way too convoluted for an AI to properly manage now, being able to dive in and do bits and pieces and focus targeted things there. Yeah, no problem. I think what's going to happen from the SaaS perspective is now that we've got AI agents, you're not going to have to have 300 seats of the SaaS model for somebody to use it. They're just going to spin up an agent, which is going to be doing all the querying from the SaaS model. So you're still going to have the integrations on your end, but instead of having John and Sam and Stephanie, all of them over there with their own licenses to Salesforce, you're going to have one license that goes to the agent and the agent's going to be doing all these queries and things and things for them. So I think what's going to change is the per seat model that has been baked into these applications for a long time is going to go away and it's going to be on a per use basis. So based on worker throughput and things along those lines. So I don't think vibe coding is going to replace the applications. I think it's just going to cause a shift in the way that those licenses are going to have to be handled from an enterprise perspective going forward.
• 20:10
  Speaker A: Yeah, and in one sense that's kind of scary and invigorating at the same time. To go from 300 licenses down to one and have that agent handling all of that work and that integration piece of it, the integration in between the data, well, the data flow and the workflow and handling all of that and optimizing that piece of it, making it that much faster and then switching to a per transaction basically to a token model almost within them. And so it's going to be interesting how they're going to recognize when it's an agent versus a human doing stuff and, or just API calls from regularly written programs.
• 20:54
  Speaker B: Yeah, a perfect example. This is one of the startup we're using Jira on there, but we're using their $10 a month 10 user type of thing. But we've got way more than 10 devs who are in there and a lot of organizations have been doing this for a while where they're sharing credential if it's not supposed to, but it's happening. And so we actually built an interface that will actually help spit out and truncate the pieces so we can actually have that multiple user experience with only a few licenses. So there'll be tags inside of the tasks themselves that'll indicate users and assignments and things along those lines. Those get maintained and then that way we can say, hey, this is the actual assignments versus what we're seeing inside of Jira. So now we can get by with the, the $10 for 10, even though we've got 18 developers all using it and still have the flexibility of the regular assignments that you see with the Jira pieces there. And it was pretty quick to put that layer on top to allow us to do that. Chrome plugin, Chrome extension, and now we're able to do that. That's the type of things that are going to happen now. It works for us. I don't think that's going to work for a massive organization because there's going to be too many requests in terms of all the different users and this and keeping track and whatnot. But for us, it's the chrome extension. It works fine. The collapse of the AI bubble and how we're trying to replicate a lot of what AI did for a lot less expensive pieces, things like Deep SEQ and some of these other bigger models that are coming out. There's some of the open source will be some of that replacement that come out.
• 22:29
  Speaker A: Okay, any thoughts on what we will be doing or what that collapse is going to look like?
• 22:35
  Speaker B: So I think OpenAI is going to be the linchpin here. OpenAI has been the main GPT that a lot of the consumers are using. You've got technologists and people on the technology side where we're dealing with all this other stuff, but your regular everyday consumers, you know, they've mainly been using ChatGPT. Well, now people are leaving that. There's issues with future financing for the Nvidia and the Oracle pieces. So I think those pieces are coming down to the point where they're going to have to start raising prices in order to maintain their revenue. I mean, they're already losing money. And I think that pressure there is going to cause a cycle just like Uber. When Uber first came out, it was heavily subsidized. It was like, oh, I can get cheap rides everywhere. Everybody's loving. Put a lot of taxi businesses and small operators out of business and then they started raising the prices, they started taking those subsidies out so they could get to that profitability piece. And I think just the cost of processing, the cost of electricity, just where we are today. And in the next five year horizon, we can't just turn on a new power plant. It takes years for those things to get out there. So we're going to be limited on that fresh water supply limitation. And then just see the chip and hardware limitation is going to be to the point where they're not going to be able to subsidize that anymore. The investors aren't going to be continuing to pump money into it. And then all of a sudden they're going to start raising prices. And so companies that have baked in AI as part of their core business model are going to have to raise prices. So if they're not able to compete at that level, they're going to have to end up having to pull that out and replace it. Now, AI is not going to disappear. The processes and technology is still going to be there. We're still going to have text processes, chatbots, all of that stuff that we have, just maybe not access to all of these frontier models and having AI as a service like we do now, it'll probably be folks having to spin their own up, building their own server parts or re leveraging parts of their server infrastructure to spin up some of these things. Or even more beefier workstations to handle some of the local AI processing.
• 24:27
  Speaker A: Yeah, I've seen multiple instances or tutorials on how to build your own contained infrastructure using some containers and the like, and setting up the database on the back end so that you can run everything locally on a single PC and continue to use that PC for everyday usage at the same time.
• 24:50
  Speaker B: Yeah, I think there'll definitely be a lot more of that. A lot of. Maybe there'll be a new market for AI PCs. Like, I know intel is trying to put out an NPU and their AI, but that really didn't take off because we were like, oh, I just, I just ping cloud, I just ping stuff in the cloud. Well, if that collapses and that becomes too expensive now, the local hardware becomes the bigger piece and Intel's already working on pieces and AMD is following up with that as well. And so I think instead of all the memory and all the chips going out to the data centers, there's going to be a hard reset and now all of a sudden it's going to be baked back into devices. So they're going to get more powerful laptops, more powerful workstations, et cetera, so people can roll their own at home using the models they find on Hugging Face or Deepseek and stuff. The biggest thing is how can we leverage AI to make this as optimal as possible in terms of our developer and our developer processes? Because when you're at a larger organization, you've got more resources. You have the ability to go out and get visual studio licenses and access to tooling and things. So up here in the startup world, it's like, what can we do? Free open source, using a lot of the Google stuff, using a lot of free credit time and cloud, run AWS and in Azure and be able to shift those things around as the credits run out and just really the focus on deliverable versus scaling. When you're at these bigger organizations, it's all about scaling your stability. You've got process pieces, but at a startup you're starting from zero. So you've got to come up with that process framework, you've got to come up with that tooling. We've got to come up with all of these things that you usually take for granted already there. And unless you build that in as you do that startup, you're going to be floundering around. At the very beginning, we had a bunch of developers. This person did this thing over here, another one's doing this over here. It's like, no, we need to be in a repository. So we put in a git. Okay, now that we have Git, now we've got to have a pipeline to actually build that stuff out. So setting up the CICD pipelines, putting in a process where we've got a JIRA board, we've got task tracking, so that way we're keeping track of what we're doing. And all of these little tiny things really play a huge impact on getting the organization. It takes a while to get that set up, and until it does, everybody's just like going crazy.
• 26:55
  Speaker A: So, well, this sounds, this sounds perfectly within your wheelhouse because again, we're right back to the change management and the psychology of how to do things more optimally and repeatable. And because the startups, they're just doing, or I imagine a lot of those guys are out there, those developers, like you said, once Steve and Frank are off in their corners doing their little thing, and they're not thinking about checking all of that in or making it so that it can be. I always called it the beer truck test. When somebody gets hit by the beer truck, what now? And that repository and the CICD and the pipelines and all of those pieces so that you can continue on if somebody just said, I'm done.
• 27:40
  Speaker B: Yep. And. And it's funny, because a lot of large organizations that I've gone into don't have any of that stuff to start with there. It's wild West. It's cowboys. They had grown, gotten there. There's been a lot of mergers and acquisitions over time. They've never integrated stuff. And so that's where I come in and say, all right, what are you doing today? And just make sure that you've got an understanding. Like, this is how development's happening here. Development's happening here. Then you say, okay, well, instead of tracking it in your Excel sheet in your axis over here, and you're this, now I want you to put it over here in JIRA or whatever that tool is. So now all of a sudden, they're still doing what they're doing, but now they're using a centralized tool. Okay, cool. Now that you're doing that, now, instead of putting your code and Saving it here, let's also save it over here into Git or whatever, the version control we're doing. So now they're doing that. So it's that process of leading them through, doing what they're doing today, and then migrating into a central piece. And once you get enough of that piece is there, that's when you can start looking at the economy of scale, saying, okay, now, Mark, I want you to teach Jen about this. Jen, I want you to teach Jose about this. So now they can start swapping pieces and you can get that distribution of knowledge. And that also takes care of the documentation piece. Because Mark's been over there for 30 years. He's been doing his own thing. He's been awesome at what he does, but it's all in his head. Well, now he's training Jen over here, doing a piece over there. She doesn't know anything. So now she's taking her notes, he's comparing notes. And now out of that, you've got this document. So when the next hire comes in, you say, hey, go through the documentation and set up guys that we now have that we didn't have before. And then they go out and start building that. And so you're building the same process as you're still able to deliver stuff, as things are still happening. And then one day it's just like this switch. You know, it's six months later and all of a sudden you're in this process piece. The people are doing these things. And now you've got metrics, you've got tracking, and things are going faster because it's not this chaos anymore. Everybody's marching along in the same direction. It's amazing shift. And AI is just going to accelerate. Documentation is going to be quicker. Being able to migrate stuff to central places is going to be quicker. So that whole process is going to be accelerated. But the concern is the pace of change for an individual from a psychological perspective. You know, some folks have an issue of too much change. Too much issue can cause them to burn out. It can cause them to spice cycle. They can be heavily resistant against it. Not because they know it's not right, they know they need to do it. It's just overwhelming.
• 29:58
  Speaker A: All right, radical shift in questions. What's something in it or in technology that you hear CIOs, CTOs talking about that you think it's just fundamentally wrong, that you want to just kind of reach out. Mike, what are you thinking?
• 30:13
  Speaker B: Well, I think the biggest fundamental misconception is AI is going to be a Panacea for everything. It's going to be able to do everything. It's going to be AGI. I think there's this mythology that out there that AI is super powerful. As long as you have enough tokens, you can get it to do everything. And I think that misconception is really feeding a lot of pain in just everywhere we go, because the speed that they're expecting from the payments that they're making is nowhere near where the pieces you think of software development. For decades now, we've optimized things to the point where we've already automated most of it and now we're seeing it's not AI and the speed of the code that's the issue. It's these upstream requirements. And those have always been the issue up to now. Now we're being able to focus on those pieces. But because the CTOs and the CEOs are out there saying, oh, we're going to throw AI and it's going to work, work, they're assuming the whole process, including this requirement piece, including all of these human in the mix pieces that, you know, AI is not replacing. I think their confusion is AI could just replace everything. And it's like, no, it's sped up coding a bit. We've got some improvements here, especially in GREENFIELD and focused development. But for all those other pieces, we still need to have those things there because it's messy. It's not something that AI can just drop in and do.
• 31:28
  Speaker A: I'm. I'm seeing kind of a disparity in the thoughts around what it can do and what's going to happen with it in that the C suite and the, the leadership is thinking that it's going to be solving everything just like you were just talking about. And then the rank and file are thinking, oh, it's taking my job and I don't want that in there. And then there's some of us in the middle of it trying to figure out how best to make both sides have.
• 31:55
  Speaker B: And this is really where that People in IELTS psychology piece comes in deeply because from the rank and file, like, oh, it's going to take my job. Well, no, it's not. You're still going to be doing your job. You're just going to be doing it differently now. You're going to have new tools for it because the backlot of work that everyone has to do is not slowing down. I mean, if anything, the backlog continues to grow. So there are going to have to be more people to do that work. Well, now you're going to be able to get through it faster, but. But the backlog's just going to increase as a result of it going faster. So maybe you're not over there monitoring and writing 50 different reports a week now. You're able to do that reporting in 15 minutes a week because you've got agents being able to take care of it. But there's still all those other pieces that you didn't do or you put on the side or you neglected because you're focusing so much on the reporting now you're shifting from just doing reporting to doing those other pieces, the analysis, the discussions, all the other pieces, or
• 32:50
  Speaker A: just the work that comes from the reporting. Because if you're generating enough information out of the report now, the new activities that need to be done to achieve the goal that you're trying for and. Or you can focus in on specific things. So now that amount of work needs to come out. A lot of the discussion that we've been having in the last 5, 10 minutes has also made me really think about the Phoenix project and the goal and how there's one close that I grabbed out of that that I latch onto a lot and think of optimization anywhere. But the constraint is an illusion. And really what you're talking about, of all of the different places we'll just throw AI at it. Well, we may speed up the front half of the process, but the back half is still as slow, if not slower, than it was. So now all we're doing is creating more of that backlog. Like we're about talking.
• 33:42
  Speaker B: Talking about. Yeah, it goes back to a post I did a couple days ago we were talking about when I was at Virginia Tech, we were marching around and we were just trying to get everything done and doing it. So Colonel Wesley Fox came out and he said, hey, slow down. Get it right. Because when you think about it, slow is smooth and smooth is fast. And I think it's also a Navy SEAL quote along the lines there. Well, by the end of the day, it's that smoothness that we need to be shooting for. Removing the friction, the processes, the automation, the speed, all of that is going to come as a result of it being smooth. So if you get it smooth, all those other things come into play. So when we're throwing automation over here and saving 15 seconds over here, the goal isn't speed. The goal is an automation. That's what too many people are focusing on. The goal is where is the bumps and the friction in the process. And if we smooth that out now all of a sudden, everything is working faster. It's just happening a lot more effectively. There's no stops along the line. Refactoring and doing things and so slowing down, making it smooth, like you said, focusing in on those pain points, that's what we need to do. Not just make something faster for the sake of making it faster. So if you're interested in this whole psychology and how that plays out in the real time and the impacts of the world, that's where my first trilogy comes into play. It's actually about a tech manager who suddenly invents a way with infinite energy, infinite computer processing power, and Star Trek type replicators. But it doesn't solve things. There are problems that come in. It's that thought experiment of what would happen if we had that magic wand. Well, it doesn't solve things because there's problems on the edge. And then you solve those problems and more problems pop up.
• 35:26
  Speaker A: All right, well, truly enjoyed the conversation. Dr. Sulaca, thank you very much for joining us on. You've been heard.
• 35:34
  Speaker B: Yeah, thanks, Mike.