Managing Speed & Risk in the Age of AI Development

In this episode, host Logan Lyles sits down with Justin Billig (CEO & Co-founder, Tensure) and Joe Kerstanoff (Director of Platform Engineering, Tensure), along with special guest Rich Theil (Founder, Product Forge), to unpack one of the biggest shifts in software delivery: the speed of AI-assisted development has outpaced the organizations trying to manage it.

The conversation covers why the engineering bottleneck has disappeared, why user stories are "dead," how specs and context are replacing traditional requirements, why platform engineering is becoming the operating system of the business, and what leaders in regulated industries like financial services need to do to move fast without breaking compliance.

Key topics discussed:

• Why the bottleneck has shifted from engineering to business communication
• The death of user stories and the rise of spec-driven development
• How executives' expectations of engineering speed are changing
• Why the fear of "wasted work" is disappearing
• Platform engineering's role in guarding against AI-driven risk
• The return of "shadow IT" — and why it's not necessarily a bad thing
• What leaders consistently overestimate and underestimate about AI adoption
• Practical advice for financial services leaders navigating this shift

Guest: Rich Theil, Founder of Product Forge

Hosts: Logan Lyles, with Justin Billig and Joe Kerstanoff of Tensure

Transcript

SPEAKER_03 0:00

Welcome to a platform for modern finance where technology leaders in financial services get peer-level insights to help them modernize without losing control. Today's conversation is all about managing speed and risk in the age of AI development. I am joined today by Justin Billig, who's the CEO and co-founder of Tensure, a cloud and platform engineering consultancy, as well as Joe Kersinoff, the director of platform engineering at Tensure, where he and his team help financial services and fintech organizations design and scale internal development platforms. Today, Justin and Joe and I are talking with Rich Thiel, founder of Product Forge, about what happens when the speed of software creation changes faster than the organization around it. Rich, welcome to the show. Thanks so much for joining us, man.

SPEAKER_04 0:49

Yeah, thanks so much for having me. It's a lot of fun to be here.

SPEAKER_03 0:51

We're going to talk about this big shift. Before we get into what to do about it, we're going to talk about what this shift is with the speed in which AI is changing how development gets done. But for some context, give us a little bit of background on yourself, what you are up to these days, especially as it relates to this topic for listeners to give them a little bit of context.

SPEAKER_04 1:13

Yeah, absolutely. So I've been, I the way I've been introducing myself is I've been making software for 30 years or 28 years. It's like a shocking number to me, as uh like, whoa, 28 years. Um the uh in that time I've led like technical projects, uh, I've led uh software teams, I've done a lot of um Scrum and Agile coaching uh through that time. And most recently, I've launched Product Forge, which is a tool to help teams uh take what their customers are saying and turn it into something valuable that they can use to build software, turn it into valuable software input and requirements. And so um, you know, I've watched the industry change tons and tons over those 30 years. And uh it's a lot of fun what's happening right now. For for years and years, um AI has, or excuse me, the software creation has been a bottleneck, and we're eliminating that now. And so it's a really neat time and fun time to be in the space. I love that.

SPEAKER_03 2:08

Well, let's kick it off with the first question to you. I've heard you say that software delivery has changed dramatically, not just in the last two years with AI's impact, but even over just the last six months at the time of this recording, you know, uh late July 2026. What feels most different to you right now? And what do you attribute this really quick acceleration in the last several months, even?

SPEAKER_04 2:31

Yeah, I think um clearly it's speed, right? Like speed is the game changer for what we are doing because that bottleneck has shifted. The bottleneck no longer lives at engineering in the way that it did before. It used to be that like you could go do some work and you could hand it off to engineering, and like, you know, three weeks, six weeks, eight weeks later, you would get something back that's like, okay, cool, now we can react to this. And that's just not it anymore. The teams are taking these huge steps. We give them huge bodies of work, and the teams are able to take huge steps to um move the product forward, whatever it is that you're making. And that's like that's really a fundamental shift in the way that we've thought about making software. There used to be a philosophy make your user stories as small as possible. Like, I'm not sure that's relevant. In fact, I'm sure that's not relevant at the moment. So, why the last six months? Because the, I think the adoption curve, we finally went over some element in the adoption curve where teams were like really, really putting it into practice, really, really getting there. I think the models got to a certain point, and then it took a little while for the actual engineering teams to shift over. And um yeah, so I think that's that's what's driven it. It's like, in one sense, I really want all the organizations to be moving very, very quickly through this curve. But the reality is most of them can't go through the curve fast enough. Um, they don't, uh it's just hard to steer a big ship. That's what's happening.

SPEAKER_03 3:58

Yeah, when you say that teams are able to take, you know, huge steps that they weren't able to before, what does that kind of look like in practice? What's maybe an example of that you've seen recently?

SPEAKER_04 4:08

Yeah, yeah. So we, you know, we used to do user stories, we'd break the user stories down as small as we can. And now we're in a space where bigger is better because the engineer doesn't have to hold all that in their head. Um they're able to take something that looks more like a spec, which I'm sure you've heard about spec-driven development. You take something that looks more like a spec, it could be 10 pages long that describes this entire feature. Um, this is the way we've been doing development on Product Forge, is like you build this feature based on this 10-page document, um, but you start by feeding it into a model and asking the model to do the work, not the um like as a human, it's not that you don't need to understand it, it's that it's so much context that like it doesn't make sense for you to try to understand it. You're better off to like just get it in there, get the thing built, and then allow the business and allow yourself to react, obviously, you first as an engineer, to react to what you've just created and go, does it is this consistent with the kind of thing that we create normally? Is it consistent with the kind of thing that we want to be creating right now? Is it consistent with this document? Is the document wrong in some places? You know, they've got questions like this that they're going to answer. And um, yeah, so I think that's what it looks like is this giant document gets fed in there, and then you like you get a feature out the other side. And it's hours, not weeks. So we've gone from, let's say, three to six to um an afternoon, you know, to crank out something valuable.

SPEAKER_03 5:34

Yeah, and you said one of the key words that I've seen um as it relates to all these AI tools and the LLMs is context, right? The amount of context that they can hold reliably at any given point has just been exponential from this year, right? And in that last six-month window we've been talking about. Well, Jess, I want to come to you with a question from the executive perspective, as usual on the show. How do you think AI is changing expectations that executives have for engineering speed and software delivery? Because we know how it's impacting the developers themselves, as Rich is talking about. Um, what's the other side of that coin, maybe?

SPEAKER_00 6:10

Yeah, I think there's from a from the executive's perspective, the sort of contract between the business and technology is being blown up. You know, we we had this understanding of how the dance was gonna be, right? How long it would take to develop software, how long it would take to define requirements and what the expectation of defining those requirements are gonna be. And now the speed at which engineering is moving, like you said, it's no longer the bottleneck. And so we as executives, we have to understand that we have to move faster. The business has to understand things quicker, they have to be able to express and and articulate what they need faster as well. Also, too, we have to be able to use those AI tools to to take from what's in our head or what we think is good and and get it down on the paper. Yeah, and you've got to source that from somewhere, right?

SPEAKER_04 7:01

Yeah. Like right now, it's really hard. A lot of what we do is source it from our heads. We don't realize that's what we're doing, but you've got to source it from somewhere.

SPEAKER_00 7:07

Well, too, and you know, I think the speed at which we delivered software previously, you you could get by having like the one person who kind of knows everything in the business, that person will become the extreme bottleneck. Yeah, like they're not gonna be able to output fast enough, they're not gonna be able to produce fast enough. And so I think I've said this probably a dozen times over the last two weeks. The the engineer of the future is gonna have so much understanding of the business and and what the customer is doing and sort of the the vertical nature of their business, that is going to be the the most valuable that the sort of what we call like the 10x engineer. Yeah, that is going to be what the profile of them in the future. Yeah.

SPEAKER_02 7:46

I was gonna say the same exact thing, actually. Like it frees developers up to like learn more about what the business actually does instead of just being fed requirements and stories by a project manager. Um now they can be closer to the business and be a part of making the those decisions going forward. The other thing that I think is interesting is like those specs you were talking about, like those become the most important source controlled thing in the code becomes way less important because you can just say, okay, I want to move to Rust now, and it rewrites the whole thing based on those specs. Like the specs are the important part, code not so much.

SPEAKER_04 8:24

Yeah. Yeah. You said something really interesting about the engineers now get to learn about the businesses, the way you said it, something like that, which I think is phenomenal because for so long, the role of the engineer has sort of been, why don't you be quiet over in that corner and like not bother us? Just do what we ask you to do. And the reality is like that is shifting so that you as an engineer, I mean, Justin said it already, but you as an engineer need to know what's happening and why and where does it fit in the framework and like all this. And it's not just from a technical standpoint, it's primarily from a business standpoint.

SPEAKER_02 8:55

I think that's more interesting too from an engineer's perspective to like actually be invested in something um and like get a say in that process. Like, you know, I think back early in my career, it's just like, you know, here's a story. You got to do this story. Cool. Why? Don't worry about it. Do your nerd stuff.

SPEAKER_04 9:12

Yeah, yeah. Yeah, that's exactly what it was. And uh it cannot be do your nerd stuff anymore. It cannot be that way. It won't work. Yeah.

SPEAKER_01 9:21

Yeah.

unknown 9:21

Yeah.

SPEAKER_03 9:22

Joe, you kind of touched on already jumping off of the bottlenecks that Justin was talking about. Are there others now with this changing dynamic and the shift we're talking about with the speed of delivery inside the delivery process that you think engineering teams need to be aware of uh the the new bottlenecks on their side?

SPEAKER_02 9:41

Oh yeah. Like the unclear requirements and unclear handoff approval processes, I think, are the bottlenecks now. It's not the code, it's the communication and the handoffs. Um security reviews, compliance checks, all of those things need to happen. And those are sort of like some of the issues that uh platform engineering teams have been trying to solve for years is you know, let's streamline that process, those handoffs, those those um touch points so that we can move things through faster. So I think you know, platform engineering teams are well equipped to uh make this AI-driven development process faster and more compliant. Um but it's all about context and like knowing what you're building and why, so that when you get a spec by done by Claude or Sol, um you can you can actually you know review that make sure that um it's in line with like all the specs and and um governance that you built into that. Um so you have a good foundation of like, yeah, this is good, let's go ahead and and implement this spec. Um write tests first, and then tell me when I can chip it off to QA.

SPEAKER_00 11:04

So I think I think one of the things too that we'll start seeing is the scope of my job as an engineer is gonna increase. Oh, yeah. I used to I'm a web developer and I only do web dev and I only have to worry about web dev, but that's not true anymore because businesses are gonna see that you're able to output more, and so they're gonna give you more responsibility. And just the sc just the nature of the spec and and how software is being developed now. It's just it's just a wider uh tool set. And so I used to be, I'm gonna throw that to the database team, I'm gonna throw that to the infrastructure team, and they're gonna handle it. But that's not gonna work anymore.

SPEAKER_02 11:41

And that that's been sort of changing over the last 20 years, is like, you know, when I first started, I needed to know HTML, how to talk to a database and a backend language, and that was it. Like I didn't need to know how to deploy anything, just need to know how to do my little features. So, like, as we've shifted things left, the cognitive load for a developer has grown. But with AI, there's a lot less difference from a DevOps engineer and a front-end engineer because they can kind of use AI to fill in those gaps and still deliver.

SPEAKER_04 12:12

Yeah, I mean uh one of the things that's happening with the spectrum and development is there's so much context and detail that has to be communicated. Even the humans who are producing the requirements can't read through that and understand everything that they need to have there. And as an engineer, you're the first one to see what you've made. You're the first one to react to it and go, hmm, not quite good enough and make changes to it. So uh your the business context that you have to have, the business understanding, all that stuff needs to be like uh at the top of the game. So when you're talking about breadth, um, you know, it's it's pretty broad. Um, I need I need engineers now to be thinking about the why and the customer experience from the viewpoint of the customer, like why do they care about this and not get lost in the tech, um, but get lost in the business objective. 100%.

SPEAKER_03 13:02

Yeah, I love what you guys are saying about the changing nature of the roles. We're gonna get into next kind of the changing nature of requirements. I want to keep pulling on this thread that you started earlier, Rich, with kind of one of the first hot takes about user stories in today's conversation. But I just want to echo what Joe said uh a few minutes ago in uh developing and shipping faster while maintaining secure and compliant. If you're this is the first time you're listening to the show and you're not yet subscribed either on YouTube or on Apple or Spotify, I want to encourage you to hit follow, hit subscribe wherever you're listening because it is that balance we want to continue to help you with, both in today's conversation and in regular episodes here on a platform for modern finance. All right, Rich, as promised, let's get back to that your comment about user stories. Um, are they dead? Have they completely changed in what they need to be? What is the gold standard for a user story? Tell us a little bit about where you stand there and let's keep that conversation. Yeah, user stories are dead. Yes.

SPEAKER_04 13:59

Like they're dead. They yeah, they uh they died a little while ago. And it's it's simply because user stories were designed to make the work small enough that you could hand to an engineer and they could spend a day or two or three working on that thing and then hand it off. And in a world where uh maybe this is a good way to describe the change. Uh at the beginning of the AI revolution, I took a few hours and in a back and forth conversation with uh it was OpenAI at the time, um, what I forget what model, I built a little calendar widget thing that would take, would find my free time on my calendar and like put it on my clipboard. I uh most recently went to Claude and said, Hey, make me a version of Trello that I need. And then I walked away from my computer and I walked back to a working version of Trello that I could use for myself. What that means is these small bodies of work that used to be really hard to implement even two years ago with AI, they were like a lot of back and forth work, are not hard now. So if you do the work of creating a user story, you're wasting your time. Like you can literally have the work done by the time the user story uh is written. So you might as well just say, like, go do this thing, or like batch them up into like a larger body of work, uh, which is one of the ways that we see things changing. Uh, you batch more work into a thing, um, call it um a spec, batch more work into that spec and shove that into um the model to get the work done.

SPEAKER_00 15:31

Yeah, but but this this is why, sorry, this is why though the the spec and the platform are so important. Yeah. Because they're the foundation of that fast work being good. Yeah. When I was in when I was in college, I took the design and analysis of algorithms and we did like mathematical proofs on sorting algorithms. That sounds awful. It was the worst thing I ever did in my life. You're such a better engineer for it. But you know, they don't do that anymore, and I don't blame them unless you're taking like super hardcore like computer science. Computer science. Yeah. And so it, you know, it just becomes it becomes sort of the operating system of AI. You have to have those things to so that when it runs off and does its own thing, it's doing it in a way that that matches your standards, matches your compliance, matches your governance, matches your regulatory requirements, matches how you want to position software into the world. So they become the thing that just kind of exists and eventually I don't know how they work. They're just there and they and they they work.

SPEAKER_04 16:34

Yeah, you shouldn't have to slow down to uh spin up environments or to like make sure that you're following the rules and uh building in the way that everybody else builds. None of that should, in today's world, none of that I guess the best way to say it is none of that should stand in the way of business progress. Right. It used to be that we had to go, I mean, look at the progression. We used to have to go buy servers. Now we now we write some code to spin up a server. Now we shouldn't even be doing that, right? It should just be available.

SPEAKER_01 17:01

Yeah.

SPEAKER_00 17:02

I want a server and then I click a button and I I tell Claude or I tell whatever AI model I want a server and then a server exists. Yes, yeah.

SPEAKER_03 17:10

I love that. That's a great before and after. Rich, let's talk a little bit more about uh what you were talking about a minute ago. Richer specs and the word we were using earlier, more complete context. The the importance of both of those when it comes to AI assisted development or AI-driven development, um, why are those so much more important now and the user stories becoming less important?

SPEAKER_04 17:32

The reason those are more important is because the model is going to do what you tell it, and also because the model has its own thoughts about what to build. And so uh not in a way that they're more deterministic approaches like Kiro um is taking, but the um having that context increases the likelihood that you will get what you want. I mean, I think that's probably fairly obvious, but the so it's important to build that into what you're trying to create. And the context exists both as like business context that you're providing, but also environmental context that you're providing for like the local dev environment that you're building within, or uh the cloud-based whatever dev environment that you're building within. Um so I think it's important to have that because it like that is how you define what you're building now. It used to be that you did it at a user story level and you let engineers figure out the how. Now we've sort of combined the how with the what in this spec concept. And um so I think that's it. I think that's why.

SPEAKER_03 18:34

Justin, you were talking about this a little bit earlier when we were talking about the executive and leadership perspective of the importance now of clearly communicating what you want the engineers to build. This is what we want to hand off. Where do you see some of the potential potholes uh or pitfalls there that maybe are bigger based on this speed of development when we're as a leadership, we're not handing off clearly what we want engineering teams to build.

SPEAKER_00 19:01

There used to be the fear of um like I've gone so far down this path and it's not what I needed, it's not what I wanted, it's not what my customers needed. And so I've I've spent all this time and investment and energy, and it's sort of for waste and for not. That's maybe gone. I think I think that's gone. Within reason, yeah. Yeah, within reason. I think what some of the bigger things become your competitors are moving at lightning speed, right? And if you're not getting it right, uh that miss may have a bigger impact than it did before, right? And so um I think too, there's also the uh people's expectations of AI and what it can build, and you know, I don't want to sour people's understanding of, oh well, this thing can't do it right or it can't build it right, or you know, I but I put garbage in and so it it didn't. And so then you don't want your organization sort of revolting and saying, no, I'm just gonna do it the way we've done it before. And there is, there is um from a financial services perspective in the world of fintech, you know, if you build it in correctly, you're still exposing yourself to security, potential security issues, potential customer data loss issues, you uh not meeting your regulatory requirements. And those things, you know, while you know you're great and happy that it ran fast, uh, regulators coming in and auditing you aren't aren't going to care at all. They're gonna be like, well, this is not, this isn't meeting.

SPEAKER_04 20:28

You generated this, didn't you?

SPEAKER_03 20:32

I I love what you're saying there, Justin, because the um there's risk involved, right? But there's also the opportunity cost, both externally, as you mentioned, those competitors moving at lightning speed as well, because they've got just as much access to this AI-assisted development, but the opportunity cost of using AI wrong and losing that political capital capital internally or losing that momentum, that buy-in um to help you move faster.

SPEAKER_01 20:57

Yeah.

SPEAKER_03 20:58

Joe, think as always, kind of looking at the the engineering side of this, let's talk a little bit about where platform engineering fits into this and becomes even more important to create those repeatable patterns and and paths, as we talk about oftentimes, because we can move so much faster from idea to implementation.

SPEAKER_02 21:16

Yeah, especially like in regulate regulated industries, like you need to have those guardrails in place so that the model or the agent has a context of who's making this request, what data do they have access to, what am I what tools am I allowed to use for this user? All of those have to be baked into like your harness. So like I think it's all about like how we how we build this harness around your agents, um, so that you know, maybe non-technical teams can even like ask questions and get charts and data uh about what they do in their day-to-day work, in addition to you know, developers being able to move faster, deliver more code, and you know, meet business objectives. I think you know like platform engineering teams are again well equ equipped to take on that work because that's really what we've been doing for the past 10 years without AI. And it's really important to get right when we throw these non-deterministic agents around. And I think like the kind of the trick for platform teams is like identifying like what needs to be deterministic versus what's okay for the model to churn on uh and be a little bit random.

SPEAKER_04 22:32

Yeah, well some of those problems are even like Kiro has a deterministic strategy to the product that they're building, meaning like a lot of their underlying stuff is deterministic. If you feed it the same spec, you'll get the same thing. Um not all of it, but they're working in that direction. And I didn't get it at first. I was like, that's dumb, just use the LM, but I was wrong. Like the um that deterministic approach lets you use the spec as source code, basically.

SPEAKER_02 22:53

Yeah, exactly. And like I think I might have said this in the last episode, but like recently the harness around uh Opus was like exported on accident from Claude. And 90% of that code was deterministic things around the agentic flows. So it was all platforming harnessing work. Um so there's like a there's a paper somebody wrote about it. I'll I'll try to find it and send it to you. Um but yeah, it's it's it's interest interesting, like you know, as we want to m use these agentic flows outside of technology and like, you know, let's say legal teams generating NDAs or something like that. Um we need to build those deterministic things so that you know it knows this is this is our format, these are our guardrails, these are our evaluators so we know that you're doing it right and that it's good to send back to the user. So all of those harness like platform y things uh are what enables like use of AI outside of just developer teams.

SPEAKER_04 24:01

Let you do it in a safe, reliable, trustworthy, let you get traceability back to like where those requirements come to the same thing. How many tokens did I use?

SPEAKER_02 24:09

Like making sure like you build token economics into the platform so you know exactly like you know, this team used this many tokens. And I know like, you know, early on we had a client that um was very anti-AI. And when they finally got on board and were like, oh yeah, we have to use this, it was like, okay, everybody has to use 25,000 tokens a month. I'm like, oh, that's not the way to do it. Definitely not the way to do it. That's easy.

SPEAKER_04 24:35

I can burn 25,000 tokens a day. Yeah, I think it's easy. Yeah, yeah. Would you you said 25,000? You know what I mean. Yeah, yeah. 25 million.

SPEAKER_03 24:42

That's such a good point about uh, you know, Opus and the example they're harnessing you were talking about, Joe. And the the point about tokens, I think, is important for listeners as well, is especially as we're starting to start to see the glimmer on the horizon of the the AI token cost apocalypse. Some people are talking about it, right? That that those costs are are going to go up at some point. Um, Rich, let's let's talk a little bit more about the bottlenecks um and specifically for the business and product leaders, how they need to change the way they work with engineering teams when developers can move so much faster. We talked a little bit about you know that working relationship and the user stories changing with your hot take from today. What else do they need to have in mind in the way that they change the way they're working with engineering teams?

SPEAKER_04 25:30

Yeah. It certainly the bottleneck shifts left. It shifts left hard. Um and that's a major concern. Like as I look at the way the industry has developed software for the past 30 years, uh, it's a concern because most times, way more than I think any of us who've been doing this for a minute like to see, it comes from some idea or gut feel from a business and leadership standpoint. And that can work sometimes, but it really we have to build the bridges between what users are saying and what customers want and where they're hitting pain points and they're hitting problems back into this. So you can even imagine a loop now that runs from like customer input and customer feedback all the way back through some tooling and down through the engineering team. And you can run that loop really, really quickly. And so uh the thing that has to happen then that I think we're struggling, we've struggled with as an industry for a long time, is we have to get our business strategy right. We have to get our the goals we're trying to achieve right, we have to be able to articulate the um the things that we want to try, like the bets we're going to make in those spaces based on the context that we can see that we've not yet figured out how to build into the models. And so it's our own ability, the leader's own ability to take, and the product leader's own ability, to take what they're what they're seeing happening with all of this loop that's coming back around to massage it on its way into the engineering team to make sure they're getting exactly what they need to build that. And then you iterate on those experiments really quickly. So uh it's the shift left and the like deep, deep tie to what they're seeing happen with their product in the market and with the product itself that that is the bottleneck now. And they they have we have to as an industry figure that part out. Uh it it is figure outable. Um, and um, that's what part of what we're doing at Product Forge, just bluntly. And it's an important part, uh, the in my opinion, the most important part of the process at this point because it's currently it's currently holding up everything.

SPEAKER_02 27:36

Yeah, I think that's really really interesting. And like if you take one step low like level down, like teams that I talk to without a platform running their their agentic flows, you know, they're like, How does my fleet of agents talk to your fleet of agents? Like the C the CTO knows exactly what to do, and it's probably faster for him to just type it in than share the context with the human engineer so they can type it in. Like sort of like I don't think we're we've sort of landed on the best ways on how to work together in this agent space, agent developer developer space. Like, how do we not step in each other's toes and not build the same things like four times trying to get this product launch?

SPEAKER_04 28:20

Yeah, I think there's uh we have an emerging, we don't talk about our relationship with the agents, because I think it's weird, but we have this emerging relationship with the agents. Yeah. Whereas like uh part of the answer to that six-month question from earlier, as like their capabilities uh go up, we we start asking, like, well, what is my role exactly? I've been asked that question so many times in the past two years. What is my role exactly? And as we build more capabilities into that, it becomes this human oversight watching these loops, which is where we're going. Um, so that these loops are going from both customer input and strategy input and business goal input, like all of this, and they circle back down. So um, you know, I think we're trying to sort out those things as part of what you're describing there.

SPEAKER_03 29:04

I think that's well said. Justin, I want to come back to you again from kind of the leadership perspective. Do you think there's a a risk in we've been talking about speed and bottlenecks and kind of how you know both are changing at the same time? If if there's the just the focus on the speed, there might be this assumption from leadership that, hey, faster development automatically means faster business value. Do you think that's a risky assumption? And if so, what are the dangers there?

SPEAKER_00 29:32

I do think it's a risky, super risky. There's this, there's this um this saying, right? Like, given enough toddlers in front of typewriters and enough time, you could output the the collected works of Shakespeare just on random, like toddlers like smashing their fingers on the keyboards. I mean, we effectively have uh obviously not an infinite, but from a cost perspective, you have an army of uh engineers who could build you anything you wanted. I I could decide, hey, I'm I'm gonna start, you know, I'm a bank, I don't generally offer um personal deposits and those types of things. I can I'm gonna do that now. I'm gonna build a system that does deposits and I'm gonna do that. I'm not a payment processor, but I'm gonna start becoming a payment processor. I'm not a I'm not a this type of company. I'm just gonna become that type of company. And so my whole career has been the intersection of technology and business. And again, I go back to if it's not driving revenue, if it's not enhancing customer experience, if it's not, you know, risk management or or speed of market, like those types of things, if it's not aligning to what we're trying to accomplish, then it was the work valuable. Just because you've done the work, is the work aligning to what you want it to do. And I think we're going to we're going to see a lot of work, a lot of well-intended work go out into the market that isn't going to be fruitful. Yeah. I I think it's gonna happen.

SPEAKER_04 31:01

One of the along those lines, one of the things that I've seen has been really fascinating for me to watch, as it became easier to write code, product managers started writing code. And I watched that happen and I thought, this is the most foolish thing that I have seen. Like legitimately, it's the most foolish thing. Product manager, it like makes me angry. The product managers are supposed to be strategic, thinking about business need and business problems that they're trying to solve.

SPEAKER_01 31:25

Yeah.

SPEAKER_04 31:25

And given the opportunity, they dove into the tech. And it's so easy to become enamored with the tech that you forget about the exact point you're making, the um, the business goals and the things that you're trying to achieve. And you have to set that that like enamored thing aside and focus only on what is it that we're trying to achieve. Not only, but like focus on what we're gonna try to achieve.

SPEAKER_02 31:46

Yeah. Yeah. I mean, that's like you have to bake that into your measurements. Like you need to know, like, yes, this initiative measurely affected up or down this business objective.

SPEAKER_00 31:57

Yeah. Oh yeah. It it's I think we're gonna uh organizations that master this are going to be able to to uh be able to accurately track every dollar spent to every business objective. Yeah. Because because that seems reasonable. Because m uh essentially investment is going to be the limiting factor. It used to be time. Time was the limiting factor. I mean, investment is a limiting factor before the world we live in. But in reality, but it was constrained, I think is your point by time. Yeah. And now time is gone.

SPEAKER_04 32:30

Yeah.

SPEAKER_00 32:31

Time time becomes, I mean, not in reality, but like sort of in the same way that cost was constraining us before. Time is kind of constraining us, but not, but not. And so now it becomes is this investment worth it? Because I can make that investment today. Yeah. I don't have to make that investment over 10 years. I can make it today.

SPEAKER_01 32:51

Yeah.

SPEAKER_04 32:52

What is your ROI? That's like the number one question I'm asking people right now. What's the ROI on this work? Or why are we choosing to do this? Right. What benefit does it create for our customers, for our business? Um, and I um I don't always get answers that I love.

SPEAKER_00 33:05

Yeah. I have a a friend who owns a I was just telling this story uh an hour ago. I have a friend who owns a manufacturing business. They they um they package white label food. So for like big retailers, you know, you would buy granola mix and he packaged it for them in their packaging. He had to buy a million-dollar piece of equipment ahead of time. And he had to like wait nine months before he could start see, yeah, start using it. And I said, I would I would die. I don't think I could do that. Um But now, I mean, it becomes this thing where I could spend a million dollars in a month and and have a product and put it in front of customers.

SPEAKER_04 33:46

But think about the weight that went into that decision for him because it was so tangible and it had such a long time frame, he spent an agonizing amount of time. An agonizing amount of time, two months making this choice. Like, is this the right machine? Does it have the right specs? Do I have all the right options and all that? And in a sentence, we can drop a million bucks. Yes. In a sentence, we can drop a million bucks. And we don't realize, like I see business folks, especially the their first time through uh leading a technology project of some kind, they don't realize the things they're saying and the impact downstream, and we're not measuring it. So, like nobody in very rarely do I see it get measured. And so uh, you know, literally, you say one or two things and you've spent six figures, seven figures, and it doesn't matter. Um, it that that has gotten easier, like, but you can still hit problems.

SPEAKER_00 34:38

But I on the flip side of it, the same, you know, the exciting part of it is what would once have cost me a million dollars. Yes, now doesn't, nowhere near. And so the ability for an executive to say, okay, we know what we're doing, we have a uh a supposition, we have an idea, we want to take a risk. Those the the the amount of risk though now becomes less a little bit lessened. And I can I can I can step out and maybe do something because of the time.

SPEAKER_02 35:10

Like it doesn't take time to get it out in front of customers now. Yeah.

SPEAKER_03 35:15

So it's such an important thing, you guys, and I think it comes back to one of the main themes of this show the the balancing of the opportunity and the risk for the technology leaders in financial services and fintech that that we're speaking to. Joe, I wonder if you know, on this topic um of opportunity and risk, Justin was talking about, you know, the the vision of having an infinite number of toddlers on typewriters, how that could create uh operational risk, a bunch of rework, obviously production issues. From a technology perspective, what do you think technically needs to be in place to avoid um some of those risks and a lot of that rework? Um, if we're too quick to jump on the opportunity without it being in a measured way, I think as Rich and Justin were really putting it.

SPEAKER_02 36:07

Yeah, I mean, I think it just goes back to business objectives and tying the platform to those objectives. So, you know, um if we know our primary customer, if it's internal or external, whatever, um, whatever they're trying to do, let's put guardrails around it so you know we know that when they use our system, it's always going to be deterministic when it should be, and you know, be non-deterministic when it doesn't need to be deterministic, right? Um we need to know like that we can observe everything that happens in the system, that we get alerts, there's you know, all the governance is around it so that when things do go wrong, we're we can be alerted and fix it and you know, bake those those loops back in for improvements. Um so I mean it's like the platform is is definitely the thing that everyone wants to build right now. So agent harnesses, agent gateways are conversations that we have essentially daily now. Like how do we how do we govern this? How do we make sure that um we retrain the the the agent and continuously approve it, um improve it? Uh how do we even just observability? So like a lot of what we're doing today is building that small, thin slice, and you know, the easiest like use case for developers is like let's build the harness, build out, build out everything, and our first path is gonna be a PR review. Like easy, and it gives us a small, thin slice for an MVP that will touch every single you know part of the harness and platform so that when we build like features around it, we know that's already been tested, we know how it's gonna work, and we know exactly what to look out for.

SPEAKER_03 37:59

Joe, so you're talking, uh, we've talked a good bit in today's conversation about harnessing the agents, right? Um, and putting them uh using the opportunity to kind of let them loose without letting them too loose, right? Keeping the harnesses on them. The other thing from earlier in the conversation, I think is worth revisiting in the changing dynamic, we've got the relationship with the models, but we still have an actual relationship with the engineers. Rich, um, we we talked about why it's important to for engineers to understand more about the business, the vision, not just go do their nerd stuff, go build it, as as Joe said earlier. How do you think uh that that happens within organizations, especially in fintech and financial services? Um, how do you think that that empowerment of engineers, what what does that look like in practice? What are some of your suggestions for listeners today on that point?

SPEAKER_04 38:54

Yeah, the nerd stuff, it turns out, takes a lot of decisions, like loads and way more decisions get made at the lower level than get made at the higher level in uh technology implementation. Such as it's been that way. Oh my gosh, it's they're making a thousand tiny choices for everything they're doing. Like, how do I structure this thing in a way that it's scalable? What is it? What kind of scalable does it need to be? Like, who is our audience? How does that matter? Should it be on this uh microservice or that one? Like all of these things are choices that are getting made. Like, I mean, they're it's unbelievable the number of decisions that are getting made at that lower level. And getting one, getting as many things off of many decisions off the engineer's plate as possible, like with platform engineering does that, like makes it very easy to take those the right path technology wise, technology-wise, but also from a vision mission standpoint, they're gonna make these decisions um in some business context. They're going to be made. And you, as a product leader, as a business leader, you might have an LLM to help you write stuff down, but you are not going to capture everything that you need to capture. No offense, but you're not that good. Um, like there's way too much stuff. What you have to do instead is empower the engineers. They're making so many choices. If they don't feel empowered, if they don't um, excuse me, the better way to say that is if they don't have the tools that they need or the background information that they need to make the right choices, they will just make mistakes faster. That's what will happen. They will just make things that are outside the context of your goals faster because they don't understand why. And uh engineers are among the smartest people that I know, you know, like they're really smart. So give them a problem like this to solve, they're gladly going to go and solve it. So uh how do you do it? Like leaders have to shift to a leadership and empowerment um stance. And so it's about how much freedom, how much information do I need to provide to my team so that I know that I can trust them? And it's like there's a lot of I in there because I as a leader have to take on the huge responsibility to reproduce the stuff that I'm carrying in me down to the team so that the team can make the decisions the way that I would have made the decisions if I were able to be in the room. If I'm like the product manager, you know, like those things have to be transferred. If I'm the business leader, it's the same kind of thing. But it's like, and I don't mean that to be like centered around the product manager. I just mean like they're the holder of that vision and that direction. They have to transfer it and make sure that it's implanted in everybody else for it to be effective. So uh that's you know, I a vision is a bucket, it drains, um, it's got a hole in the bottom. Uh, and so you have to speak into the vision bucket and keep filling that bucket. Uh, you know, I hear people talk about like once a week, that's not good enough. Like you gotta you gotta be talking about it every day or two uh because the pace and change is so fast that it leaks, it leaks and nobody even notices that it's gone or that they're off vision.

SPEAKER_03 41:51

Absolutely. And I think it's important to talk about both roles here, you know. And so, Joe, maybe switching back over to you from a platform engineering standpoint, what do you think it looks like to empower those engineers without asking every team to become experts in infrastructure, security, compliance, and all of these things at the same time?

SPEAKER_02 42:08

Yeah, that's a good question. I think like the goal of platform engineering is to abstract the complexity away, not to eliminate the control the development teams have to make decisions to uh do what they need to do. Um, and you know, like every good platform uh team knows that like the platform is there for, you know, uh at best 90% of the use cases. And there's always going to be some use cases that you know kind of go off the path. And it's always like a feedback loop of like, okay, this this product went off the path, that's fine, we allow that. Let's get with that team after the fact and see if we should bring that into the platform and put some guardrails around that and and offer that that new architecture inside the platform. So, you know, they they may not like they shouldn't have to know like Terraform or how to talk to the cloud. They should there should be a platform out there that just says what do you need, like what do you need to deploy, what's your operating model? This is what we recommend. Here's a button. Now you have an environment.

SPEAKER_03 43:18

Um here's a button. I love that.

SPEAKER_02 43:20

Yeah.

SPEAKER_03 43:21

I mean, that is that's the goal, right?

SPEAKER_04 43:23

That's it's not not even just like a dream. It's like you have to have that in a world where you've got empowered engineers that are tackling real-world business problems. If not, you're you're bottlenecking your business.

SPEAKER_02 43:35

Yeah, 100%.

SPEAKER_03 43:37

Let's talk a little bit more about you know the platform foundation for for delivery in this AI era. Rich, you were telling that story about, you know, uh basically a Trello lookalike uh working version. And I've heard you say that you know, you can have an idea at noon, functional prototype at 2 p.m., but this works a lot better, maybe only works if you have the right platform existing underneath. It it unpack that a little bit more for us.

SPEAKER_04 44:02

Yeah. I mean, you legitimately can do that now. You couldn't do that a year ago. Could you do it a year ago? I don't know. I think you could do it a year ago. Six, six months ago, maybe is when this started. And I literally we just did this on Product Forge. We were like wrestling with like, oh, could we do this? Could we like could we make this work? Yeah. And I get on a plane. Um, I give some instruction to an engineer, get on a plane and get off the plane, we're ready to roll. You know, like that sort of thing just happened. And um, but it it could only happen because we have established what our uh development platform looks like. There were no decisions, there were no conversations to be had, there was no like shaping of that thing. It was just there and ready for them to use. And we um so, or for him to use, really. So uh what I meant was like you have to have that freedom in place uh to be able to experiment like that. It could mean anything from ephemeral environments to um being it for to be able to test stuff, like to build something up, stand it up, and go like, hey, I just made this in the last two hours. And somebody looks at it and goes, like, that's great, except burn it down because I don't like it at all. Fine, great, it goes away. Uh, but then somebody else is spinning up something else on a different environment. And um, you know, you're taking a look at that thing and you you know how to manage that. And there's just a system and a process in place for being able to evaluate those things, and you can log into them. You can um you can have one of your your business folks out there who might be a real user um log into it and use it and try it and run some experiments on it. Like these are all things that really matter. And then you've got to have a way to go from there to uh uh call it staging environment, production environment, whatever. You've got to get to the point that you can actually start testing it in the real world for real, real. Um, and all of that stuff has to be very, very, very simple. It just needs to be um, what are you saying, on greased skids? Um, like it just needs to roll, you know.

SPEAKER_03 45:52

Justin, maybe kind of continuing to pull on this thread of the importance of the platform, where do you see the importance of internal developer platforms uh becoming more valuable for engineering teams as they're moving faster, as these greased skids are the the track we're running on. We're not running through uh running through putting uh as the opposite would be, right?

SPEAKER_00 46:14

If you are a technology executive and you don't have the mindset that the platform is the product that you own, I think you might be missing the point. Yeah. Because um, you know, before it was your job to manage your environment, to manage the risk of your environment, to manage the the compliance, um the compliance stance, regulatory stance of your environment, right? Uh, but the speed at which we're moving, the amount of innovation that's going to be happening, you as the technology executive, uh giving your business, your executive team, your organization, a platform for them to run on that's safe and secure and and meets your meets your stance as a business is going to be the the single most um productive uh thing that you do uh to your organization.

SPEAKER_02 47:09

The way I describe it is like it's the operating system that runs your business. Uh like that's and a lot of you know non-technical businesses don't understand that like this drives your revenue. This everything flows through this this platform. Yeah. Like you should invest into it. It should be a product that you're aware of and you know about, and you're strategically making decisions about.

SPEAKER_00 47:34

Yeah. I think we're we're we're I'm gonna use a term that has a lot of baggage to it, but I think we're back in the golden age of shadow IT. Oh yeah.

SPEAKER_04 47:42

Oh, for sure. You got product managers creating products all over the place. Yeah. Like not a bad thing.

SPEAKER_00 47:48

But it's not a bad thing anymore.

SPEAKER_04 47:50

Um if it's not. It depends on how you want to slice this. Yeah. Right? Like if you've got the platform in place, then I like I can see where you're going. Um I've I've even thought like there's probably room to build some sort of a um, I don't have the right words yet, but uh some sort of an API layer or something, and then just let whoever build whatever on top of that API layer. Yeah, 100%.

SPEAKER_00 48:14

I have this idea. Uh it's one of the things that it's one of the things we're working on internally, is like um how so we have a put we have a a company that we're having a lot of conversations with, and they're they're all in on AI. Okay. They are in, as a matter of fact, their CEO came down and said, I expect every single one of my leaders to build something that solves a problem in their area of their business like in two weeks, and then demo it to me. And then so they did that, it was great, and then they went and hired like 30 um interns to just bang stuff out. Really? And just and so you know, how do you build uh an ecosystem that uh that my sort of agents can pull down what good looks like from an infrastructure standpoint, from a connectivity standpoint, from a security standpoint, uh just pull it down and then it knows as as these users are building in these requirements or building an application, it also has the specs in the context of what my what my deployment structure looks like. You know, what do I need to do for this? What do I need to do for that? And so I as as you know the the the guy who runs ARAP, who has no context of technology for anything, I built this app, and then it also sucked in all of the really good requirements for a really good piece of software, and it can deploy it somewhere for me and run my little shadow IT thing. I I think that that's an interesting thought.

SPEAKER_02 49:47

I I think it it's a little bit less shadow IT if if it can get those well architecture. Agreed. Like it like it it it doesn't quite meet the dep my definition of shadow IT. Right. But it becomes it becomes sort of the It is, though, like if you know if you don't advertise it outside of your There But I don't know what the term is now.

SPEAKER_00 50:04

Shadow IT is the only thing I can think of because I, you know, I live my whole life thinking of it and thinking how horrible. Shadow IT is evil. Yeah, but it's not anymore.

SPEAKER_04 50:13

What you're talking about is a cultural transformation that is an empowerment culture in a context that you, as the uh technology leader, have created so that you can trust it and allow that to happen.

SPEAKER_00 50:24

And I think that's what I'm hearing. That is going to be the the hallmark of uh CTO. Yeah, CTO mindset. Yeah.

SPEAKER_04 50:34

Yeah, absolutely. And it's a shift from um command and control, uh, which uh like even existing Agile things are feeling a little command and control in this space, to uh to a living breathing mechanism. That that's what it becomes because everybody can go make their own choices and go make their own solutions to these problems. The organism grows like really rapidly.

SPEAKER_02 50:55

A lot of a lot of CISOs are sweating right now.

SPEAKER_00 50:58

I like it it's a building road platform anyway. Yeah, yeah. Yeah. I like it to building roads, right? There, there are different requirements for a road in a neighborhood versus like a state highway versus an interstate, right? And and I've built the system and I've built the road and put your car on it. As long as your car understands the guardrails and what you're supposed to operate, go. I I don't care what your car is, just just run on it, right? And and it almost becomes that as sort of the the future job of the CTO is like let me build you the roads so you can go. Yeah, absolutely. Right. But I think where we're scared is like we're not building highways, we're building sort of F1 tracks and we're building.

SPEAKER_04 51:38

Well, it calls it also calls into question, and I think you'll hit this from a we hit this from a cultural standpoint, is like what what value does the technology you start to feel like you're giving up the technology creation value, which has been part of the identity of the technology organization for such a long time. I'm not saying it's bad, I'm calling it out to say like that's a transformation. It has to come with this in order to make it effective. And um, so I'm I'm more and more in this conversation seeing this as like this is a culture of empowerment transformation that it needs to happen. And like the vehicle is the platform that you're yeah, that you're driving.

SPEAKER_00 52:14

And and but then it becomes even more incumbent upon your executive team because anyone can build anything, anyone can deploy anything, and anyone can run anything, it becomes incumbent upon your executive team to be able to clearly articulate what are the goals of the organization, what are you measuring, what is important, what is good look like, what do we want our customers to think of us as? Those those types of things.

SPEAKER_02 52:36

And if you boil platform engineering down, it's a it's a cultural problem more than a technical problem. Um like how you approach building software, running software, uh guarding against attacks, whatever it is, like it's more culture like culture than technology. Yeah. Like there's a million tools out there that can help you do the thing, and there's a million different decisions you can make, but like you have to have the right culture internally to take advantage of it.

SPEAKER_04 53:06

Yeah, but what doesn't work is to do a culture transformation. What does work is to do a technology transformation that has a culture transformation with it. Like those need to travel together uh because it gives a reason.

SPEAKER_03 53:18

Help unpack that that this not that for listeners a little bit.

SPEAKER_04 53:22

Yeah, you you need to have a reason for the organization to change. And if you don't have that reason, there there's like you're gonna get nothing but like heels digging in and um pushing back and that sort of thing. But what you um you're trying to make it for a reason, make these changes for a reason. And the platform engineering gives you the ability to go like we're doing this from a platform, everybody's like, Yeah, that seems super amazing. And then you're not like Trojan horsing the um the culture transformation in there, but everybody starts to realize, like, oh man, I both like get to change the way that I work and I have to change the way that I work to deliver this thing. We did the exact same thing with cloud. It was like, you know, when we went through cloud transformations, there's a huge mindset shift on um on what it meant to uh at early days of cloud, you couldn't click a button to get a server, but like that was the dream at the time, you know. And um, so it's that sort of that sort of change that has to happen.

SPEAKER_03 54:18

I think the the thing that was rolling around in my head as Rich, you were kind of responding to Justin's comment about the golden age of shadow IT. And and I heard you have two pushbacks. Well, one, maybe it's more the way I would say is maybe IT democratization, um, to put it in more positive terms, but the platform, and as Justin then said, the the IT leaders' job to build those roads becomes even more important. Otherwise, we're just handing people really fast cars, right? With no road, with no highway, with no F1 track, as even uh Justin said there. Um, Rich, um, for leaders who are trying to make sense of their roles, we've talked a little bit about shifting roles from executives to CISOs to CTOs, uh, to engineers. Um, what's one thing that you think that the leaders are maybe overestimating and one thing that they're underestimating when it comes to this whole area of AI assisted development?

SPEAKER_04 55:18

Yeah. Observations so far, I think leaders are overestimating the speed at which their people uh are able to make the shift because they're just like they don't know what to do with it themselves. And they are like sort of shoving it at their people and saying, like, go, go make this thing happen. Um, and it's really it takes a minute for them to learn and get their mind around. So I think the leaders are reading these headlines about the shift being like uh like happening, and they're like, we've got to be there. Uh so they just like shove it at their people and they don't have a vehicle for actually making that change happen. And so, you know, back to the previous conversation, I think that the um platform transformation is uh a really terrific vehicle for driving that sort of cultural change that again, I think they're underestimating. What are they overestimating? Uh probably the um uh the initial, I don't know, maybe this is like a cousin to what I just said, but they're overestimating the initial impacts. Like it takes it's hard work. It you need help to get there. You need help to get to the point that like you know how to implement all this stuff and to make it all go because uh you're you're just not it's like complex and it's an emerging space. And so without the that help and the assistance in getting to the point that you're able to turn things that quickly, you you're just gonna struggle and make up your own stuff um along the way. And the reality is there's a lot of people out there. Um, Tenture is obviously really terrific at this and helping to make these kinds of transitions uh within your organization. So uh I think that's it. Like those, it's almost always for me in these spaces, the technology parts are not the hard parts. The people parts and the um the governance parts and the framework parts, those are the hard parts to get implemented. Uh it's been true for decades and decades in the technology space. And I think it remains true in the AI space.

SPEAKER_03 57:18

For everybody listening, if you missed the last episode with Eddie Sorrell, CIO at UK Credit Union, check that one out. It should be linked uh here for you as well. We talked a good bit about this same thing of the technology transformation and the culture transformation. So continuing on this uh idea of leadership's mindset, Justin, I'll turn it over to you. You mentioned um earlier a story about a CEO kind of giving this mandate to you know go build something and this tendency, or at least the the risk to assume that, hey, if we just move faster with AI, tell my team just move faster with AI, then that will equate to business value. Before leaders start telling their team that, what do you think are one or two of the questions they should be asking themselves before they roll out some of those mandates?

SPEAKER_00 58:08

Man, that's a good question. Um I think I would be asking myself, um, does my does my organization clearly understand what good looks like? Does it understand what like good in terms of um business outcome? Like, do we know what we're trying to accomplish? Do we know what we're trying to move towards? Do we know the pains of our customers? Do we know what what they're feeling? Do we know where they're going? You know, from a business uh business executive perspective, have we clearly communicated the direction of the organization down to the levels of the people who are going to be outputting work at a pace that that we have never seen before? I think that from a executive uh perspective or from a business perspective, you know, someone's uh impact on the business was focused solely in like what are the buttons that I press on a daily basis? How do I make sure that AP happens correctly? How do I make sure that AR happens correctly? Right. But if if that becomes uh inconsequential to what I'm doing to my or for my organization, uh then I'm going to be searching out or I'm gonna be stuck in a rut. And so do I know down to the to the to the lowest rungs of the ladder of my organization how I'm going to impact the the highest levels of business objectives? I think that's a question that that I would be asking for sure.

SPEAKER_03 59:44

That makes a ton of sense. Joe, uh, to you as we kind of uh wrap things here with advice to to leaders, what do you think is one platform engineering principle that organizations should keep in mind as AI continues to change how quickly software is developed and shipped?

SPEAKER_02 1:00:02

Another good question. Um so I mean I think like the easy answer is platform as a product. Like it's gotta be a product that you're aware of. Because like you you you have a platform whether you realize it or not, it just might not be good. Um so if you like shepherd that platform with purpose, tie it to business business objectives, I think you'll you'll see the benefits long term. Um you know the the speed at which AI has like um gotten better is faster than cloud, faster than anything we've ever seen before. Like, you know, there's things that I was doing trying to do in January that I couldn't do that I can do with one sentence today in you know two hours. Um so as at like there's gonna be new things that pop up and your platform needs to be ready for those new things. Um and you you need to be able to implement them quickly. And the only way you can do that is if you have a product that you invest into.

SPEAKER_03 1:01:05

So Rich, maybe we could bring it home with you today uh to give any practical advice, kind of wrap up this conversation, especially to the leaders in financial services and in fintech who are sitting here wanting to take advantage of and seize the opportunity with AI-driven software delivery, but they know that there are all these challenges, right? The organizational changes, the moving bottlenecks, the shift left, the changes in the way we do those things. What's maybe one or two things you would want to leave listeners with today who are sitting in those seats, leading teams and trying to navigate through this fast pace of change?

SPEAKER_04 1:01:42

I've worked with an quite a few actually financial services industry um players. And as I've done that, the thing that I suspect will hold back each of those leaders is the fear and concern um about how do we how do we solve this compliance problem, how do we solve this regulatory problem, how do we solve this? And it the the it's hard to tell the water when you're in it. Um but the water is largely like conservative for a reason, not like not being critical here. It's conservative for a reason. And the reason is because you're dealing with people's money and like there are government rules and they're like all sorts of well-founded reasons why you should have a conservative culture there. And some of it's even born of like these are long, most of them are long-term time organizations. They've been around for a very long time. And so, like, I think the thing that I would offer up is there this space is moving very fast. It is a very good time to put your foot in that water and go learn. It's a very good time to like see what's happening, to engage with some folks and like see what's happening out there and just start learning because you're not going to learn this after the fact. The whole world is learning it in the moment as we experience it. And so it's critical for you to just go do that learning and just start to understand the way that it's impacting engineering right now. And then you can figure out how to fold it into your business. You can figure out how to have all the regulatory stuff in place, you can figure out how to make sure that you're staying in the right spaces. But like, my encouragement is to take the risk of like learning and start to apply it. Because I know that the conservative culture says like we should we should wait until more of this is figured out, or we should wait until like there's more understood about this. And the reality is it's moving so fast that waiting is going to be a very expensive proposition.

SPEAKER_03 1:03:49

That's really well said. And I think it ties into this balance. We're we're trying to help listeners of this show with of seizing the opportunity while it's here in this fast space of change while um uh understanding the the risk-averse nature in the industry, the the guardrails that need to be in place. And hopefully, as a listener, we've given you some of that balance today from talking about harnesses uh for the agents that we're talking about to uh the cultural change that can help you seize this opportunity. If you're a new listener to a platform for modern finance, um hit subscribe on YouTube or hit follow wherever you listen uh to podcasts so you catch more episodes just like this one. Justin, Joe, thanks for joining me on the mic again today.

SPEAKER_00 1:04:31

Yeah, thanks.

SPEAKER_03 1:04:32

Rich, thanks for being our featured guest. This was a fantastic conversation. We really appreciate you being on the show today.

SPEAKER_04 1:04:37

Thanks for having me. I enjoyed being here, enjoyed hanging out with these two guys.