How to Lead in the Wild West of AI with Philip Chew

Welcome to the Lean AI Podcast, where we're flipping the AI conversation on its head by focusing on holistic strategies and tactics that drive AI adoption, rather than focusing solely on overcoming the technical challenges of AI. In every season two episode of the Lean AI Podcast, we talk with corporate AI leaders just like you, who've uncovered the secrets of driving successful adoption with far less wasted time and investment. Our guests challenge established views and offer disruptive perspectives, providing you with new actionable insights. Hi everyone, and welcome back to the Lean AI Podcast. Today I am joined by Philip Chu. Philip, how are you today? I'm doing great, Ben, how are you? Doing well, doing well. So let's just jump right into it and give the audience a little bit of background. Starting all the way back in the 90s, you know, you've been leading the creation and development of kind of small to large platforms at a variety of different, you know, financial companies across the world. Can you give our listeners, you know, a flavor for the types of use cases that you've been working on? Have you been developing AI powered solutions primarily for internal workflows, AI powered products for external customers? Mixture of both, sort of. Ben. You know, I think what's funny is that I started my career in 1996, 1997, and when I was finishing up my grad school at mit, I was really working on parts and pieces of what we now call the field of AI. And it was a lot about optimizations and how you work with large problems and how you solve it in a smaller scale and still get a 90 plus percent answer, a good enough answer. And so when I started at my first job, it was really a matter of survival because you can imagine a supposed rocket scientist landing in Wall street in the 90s. You can imagine that there's lots of tech over in the sell side, but on the buy side, where I landed, there wasn't much. And so it was a matter of really building my way out of a foxhole. And I started with myself and another person who was a C programmer, and in the course of 15 years, we started building what became a platform and started really small in bits and pieces. And what were we tackling? We were tackling more mundane things like strict processing of actually being able to replace faxes and making sure that transaction goes through properly. And we were doing a lot of data cleansing that had to be done so that we could get reliable understanding of our exposures of our risk and also what our bets were on in the asset management side, the portfolio management side of things. And so in Doing all of that. There are bits and pieces of what we now call AI in there, but I had to admit that I had to end up using quite a number of human powered groups of people to help me get to the finish line. It's interesting, when we were talking before the podcast, you'd mentioned some of the things we might do with AI if we had it in the 90s, what would we have done with it? And you'd mentioned data cleansing, maybe tell our audience your thoughts on that if you would. So it's a bit more, you know, at the end of the day when you are trying to make an investment decision, you might literally be looking at 100, 200,000 numbers to get to a decision. And if you wanted to do that and you wanted to have assurance that the numbers were correct, it is not so simple. And you end up doing the most practical thing, which is really understanding what the deltas are. And when you're trying to understand what the deltas are, there's a whole set of things that machines can do if it's boundary based, but if it's more judgment based, you end up having to use machines to prioritize some of the things that people then have to do and humans end up having being in the loop. And what is an example of that? An example of that is, say, for instance, you see the analytics on a bond, its risk exposure drops, so its duration dropped. And when the duration dropped, what is the reason for that? What happened in the market that caused that to happen? Oh, it was the fan action that happened the prior day. And so in the 90s, making that leap is actually extremely difficult on a machine level. For a trained analyst, it's not so hard. So we were literally using analysts, junior people in the department to do the jobs that we would now use an LLM to do. So in a lot of ways, I wish I had LLMs as part of my toolkit back then because my systems would literally be, I would say, 10 to 20 times simpler and the number of people involved would be a thousand times fewer. So you've been using a different approach to developing AI powered products and workflows. Before we get into what that approach is, what's wrong with applying kind of a traditional development approach to in the space of AI? The challenge really is, if I think about is a underestimated shift in programming paradigm. This is not just another technology you can bolt onto your stack. And I would dare say that it is not as simple as the transformation over to the cloud that we had gone through. More than a decade ago, I think the transformation on the cloud side, it was more to do with people who used to run machines and own machines and you knew where the jobs were running and giving up that control and shifting that over. And of course you had to rewrite software also. But it's not a matter of changing the paradigm of your development of your coding. And I think the real shift over here, I think more and more people are starting to talk about it this way, and I fully agree with it. It is literally a shift from one where it is deterministic programming to one where it is a mix of deterministic programming and probabilistic programming. And when you do probabilistic programming, the things that you give up, which is the certainty of being able to arrive a result given some set of input, what you give up over there, the looseness that you, that you inherit over there, gives you the power of closer to closer level of human cognition in that decision making. So to me, it's a very fair trade off to move over to one where as a developer, you know, I've been coding since I was 10 years old. I've always had to crawl and push my brain matter right into the code. And that was the only time I could give it human cognition, which was at the point at which I wrote the code. And that's deterministic programming. And what I found is that in the last few years that I've been doing Genai and probabilistic programming in effect, is I actually don't have to rely on only one point in time where I take my intelligence in my mind and put it into the code. I can literally say I do some of it over there because it's just a better way of doing it. And then for decision making that I have to make at the point of creation, at the point of use case execution, I can literally give it instructions to, to then get more drops of my intelligence into there. Of course, it's a little bit different. I have to articulate that in ways of prompting, prompting of prompting to be able to structure that. So that arrives at very, very reasonable, actually much more effective results. And you know, another way of looking at it is that code that we used to write, which we still have in big, big systems, big systems that we all know and use every day, like SAP Workday, you know, and specialized software like that, that basically, if the DNA was minted in the 90s and the early 2000s, if you, if you had an understanding of the code in your mind, it literally feels and looks like millions of tendrils of very brittle code that goes out there to provide you the millions and millions of use cases that the big software can provide you. Now, if you rethought that, what you would have is you still have the data layer, you would still have the facilities to do calculations really quickly, but the tendrils will all disappear because the tendrils will be created at a point of need in the use case, which means that I like to say you have infinite use cases at that point, and the complexity of the code drops. If you figure out your probabilistic programming correctly, you can actually achieve a much, much better output hosting to, in my mind, an infinite number of use cases and also much more beauty on the programming side of things. And I think the key in doing this is that you really need to figure out, okay, LLM's foundation models are still growing every month, every two months, every three months, definitely every six months. And of course, we all need to be careful about safety, about hallucinations. But I think what is really cool, like, just if I compare a year ago versus where we are right now, what I would say the zone of competence of LLMs, where there's a very, very tiny, negligible chance of hallucination, is getting bigger and bigger and bigger. But that means that in your use of the LLMs, you have to keep it within the zone of competence. It's kind of like making sure that if you are going to have a team of, say, sixth graders doing the work for you, you just make sure that you ask the sixth graders in their zone of competence, don't try to ask them questions about solving quadratic equations at this point in time. You ask them about simple things like arithmetic. But, you know, you and I know that you can do a lot of wonderful calculations with arithmetic. So keep it within the zone of competence and let all those wonderful companies like OpenAI, like Anthropic, like DeepSeq, continue to expand the scope of where all these reasoning, thinking models are really, really good at. And in the meantime, us builders, we keep it within zones of competence, and as we feel more comfortable, we widen it out. Widen out. How do you widen it? You widen it by changing the prompting strategies that you have. I like that it's deliberate management of the strategy of what the team should be working and, you know, working on and building. Um, and I think you'd mentioned a paradigm shift, right? Which means it's. It's not just enough to have a great strategy on what to do and to to have the right people and to have the right tools and the right milestones for teams to know how to make progress. It also takes culture, right? Like what's the. So in a paradigm shift, I guess, what are the cultural elements that you've seen out there that maybe trip up, you know, other executives? Yeah, I think that the biggest hang up I have that I've seen is people like to wear their labels on their chest. I am an XYZ and XYZ can be developer, backend developer, data scientist, data engineer, blah blah and so on, right? And what's interesting is for me, as a veteran of software development, my culture and my DNA was stamped in the 90s. I don't know what a data scientist is, I don't know what a data engineer. And of course I know, but I facetiously say that because it didn't exist when I was there. But we faced the same problems, we looked at it more practically. And so I think actually what I really wish people did was took the labels off their chest. In fact, if you want to wear a label, wear 20 labels on your chest. Because that is literally what you need to do. You need to be able to cross pollinate ideas and learn and understand what the other side is doing to be able to do it correctly. And I think a clear example of this is the artificial delineation between business and development. To me there's no difference between the two. I have to stand in the middle and I have to move everyone on both sides. And I expect people who are working with me in business to be computer literate. If you're not computer literate, you should not be there. And the people who are engineers with me, if you have seen accounting 100,000 times before, I expect you to know accounting. And so in the same way you want to be able to raise the standards on everyone and come together almost back to the old days. In the old days where people had no labels and you're just out there solving problems. So that is the biggest cultural hang up that I see. It's interesting. It's kind of a shift from, you know, the pendulum swinging away from focus on specialists to more of a generalist view, right. And going from labels to maybe tags, right? How many badges, how many tags do I have? So that's a really interesting observation. I think in ruminating over this, the key thing I think is we are in the frontier and we are pioneers, right? If you look at the Old west, when you're pioneers, you don't care what labels you have you're just out there to survive. Right. If you, if you say, well, I'm a businessman, but you're in the middle of the plains, it doesn't matter if you're a businessman. Yeah, it's time to find water. Doesn't matter if you're a businessman. I love it. So I love this thread. Let's keep going on this. So basically, you know, actively managing the strategy of what the team should be working on and being really focused on not going so far, pie in the sky that it's going to take 20 years to develop something. Right. So that's great. And. And it also takes active monitoring of knowing where the frontier of, you know, AI is at any given time. We've talked about some of the cultural aspects. As the leader in charge of kind of coordinating all of these, you know, people and specialists and generalists that are working on developing AI solutions. Are your thoughts on governance? How do you, how do you provide just enough governance, just enough leadership without micromanaging, but also providing the right direction? What are your thoughts on that? I think to be transparent in my current effort, I'm working on my AI program within a big corporate. You know, there are structures within big corporate, which, which is great, which keeps you safe, which gives you govern and so on. And so to me, actually, because I'm not doing this in a startup, open, open environment out there, I've had to carve out a safe space inside. And I have to carve out in the safe space in a way that I've negotiated with cybersecurity, with governance, with our lawyers to make sure that what I'm doing in here is safe. And so it's almost like going back to the pioneering spirit type analogy, it's as if I've been able to find a more wild side of the United States. So, like, for instance, some wide open space in the middle of New Mexico, and there are not that many people in this particular area. I have a lot more freedom. And so I look at myself as the mayor of that patch of land, say it's 300 acres. And within that patch of land, the government has decided to provide me some fencing around it and provide some level of water, some level of electricity, some level of food supplies from the outside. They leave it at the fences outside. And so for the colonists on the inside, and as I've talked to you before we started this, I have a bunch of startups that are inside. And these startups, I ration it out and I make sure that these startups themselves don't fight with each other because they have their own particular missions. And I spend a lot of time with each of these startups because before I brought them in, I had broken out what I believe are the canonical modules that I needed in building up the platform. And so that was a very easy way for me to determine whose roles were what and what their objectives were for each one of them. And so I had to spend a lot of time figuring out what I believe were the right ways to subdivide the overall problem. And the problem is, how do you put together an enterprise wide AI platform given what I know would be all of the capabilities required to do this? And so that was my job as the mayor. I decided what type of shops I needed and then I had to go out and source the pioneers that would be willing to come in and set up these businesses. And I spent a lot of time with each of them to make sure that this is where I behave more like a vc. I make sure that they are well funded in terms of their requirements, the resources that they need, but also in terms of their mission in terms of. And because of who I am, ultimately, I'm the grand architect of the platform. I spend a lot on the technology. And I have a process which I run with each one of them. And we have never talked about this before. I like to race cars when I have the opportunity to. And so one of the most important things to race cars within a controlled track is there's a process that you do. You walk the track on foot before you race around there. Why do you do that? You do that because you get a sense of where the curves are, we get a sense of where the road is. The track is more perfect and less perfect in particular areas. And when you're walking the track, if you find garbage, you find debris, you find little pebbles, you pick it up and put it in your pocket so it doesn't hit you. It doesn't hit your competitors also. And so when you walk the track, you literally feel a lot more comfortable about the space you're going to attack in the mission that you have. And what is really cool is that I can't help myself. Being a black mathematician and a coder, we start to write pseudo code as we are writing walking around the track. What is really cool as I go through this walk the track process is we end up with a bunch of pseudocode. We look at it and we say, are we truly comfortable with this? Does this meet our original objectives? And it does. Then we modify the objectives and Once we agree on it, my contract with the startup, my quote unquote contract with them is I take on the risk of success or failure because all your job is to execute and implement the pseudocode. I'm not going to come back and tell you that I don't agree with the way you did this. It's like, no, I sign up on it. So in that way I gave them certainty, I gave them the ability of freedom, and I walk away from the micromanagement. It's really, we align on the method, we align on what we're going to do, and you go forward at any point in time. If you have to change your pseudocode, I'm always here. So that's how I manage the overall efforts that we have. I like it and I think that the analogies of the racetrack and the plot of land in the Old west, right, I think those are actually quite helpful. I'll use the old west analogy. So when you're out there, you've got that, you've got something fenced off and now it's time to look for water, right? The first time you drill, you're probably not going to find it. And maybe the second and the third, you can use informed decisions and look at land masses and valleys and mountains and get a sense of where it might be. But there's going to be some quote unquote failure, right? And if you minimize the cost of failure, it's just called learning. Right? To the point where we spent $10,000 to find out what not to do. Okay, that's learning, that's not failure. We spent, you know, $100 million to find out what not to do publicly. That's a failure. So how do you, you know, with your startups that you're working with and also your internal team, how do you incentivize people making the right decisions on what to do and what not to do, as opposed to just, you know, anything that you say, hey, we need this. They just feel, feel the pressure to, to make it happen no matter what. Even if it might not be the right thing to build. I can't help but lean on my experience as a portfolio manager. Also. I managed capital before, and to me, this colony is a risk management technique for me. I don't live or die overall on one particular objective. It is really a basket of objectives that we are going after. The thing, of course, like any portfolio, you have to make sure that you have base performance. And if you don't have the base performance, you're screwed anyway. You're done. In normal investment speak, you want to make sure your beta is rock solid. You want your market exposure to be correct and rock solid. And once you've established that, then you have a basket of alphas. Alphas are particular bets that may work out, like drilling full water in one spot. If it doesn't work out, that's okay, it doesn't kill the whole colony, it's not an issue. But if you have only one objective, one big objective, then you know it's usually what big corporate projects turn into. And so as a result, because I took the portfolio approach where there were certain things, of course, that I had to make sure is right by the company, by my objectives, like for instance, the creation of a base layer of the data. So data is non negotiable. We've got to get there. And I have a team that's going after that. This is not part of the pioneering team, but that team is structured in such a way that you'll find that I tend to mix a few things. But to me, in my mind something like that is more similar to the job that the US army might take forward. The US army, they have big equipment, they know what to do. You give them time and they'll get there right? But for the individual pioneers that we have out there, they cannot be structured like an army. They have to be structured more as independent groups that go after the objectives. And so as long as I make sure that the alignment of methods, the alignment of how they put together the pseudocode, and in fact to me a big part of it is evaluating and making, making sure that there's a values alignment between the CEO of that particular startup and my alignment. My, my thinking, I, I let him be because to me, if I vetted him and I'm betting on him, I let him go forward and do what he needs to do. And so in, in that way there are some places where I'll be really draconian. But this is not something that I put forward. I make part of the pressure that I put on the individual startups that's there by nature. The startups need to behave more like startups in the wide open. They need to have freedom and they need to have flexibility and they need to be able to pivot. Hi, this is Jonathan Burtfield, senior director at the Lean Startup Company. If you're a corporate executive looking to drive broad adoption of the AI centric products you're developing with far less wasted time and investment, we invite you to join us for a free 45 minute one on one consultation where we'll help you understand key tactics for validating use cases early in the development journey, to identify the optimal sequence for rapidly driving to scale and to navigate the potholes that have tripped up other leaders in similar roles. Head over to leanstarter co contact AI to reserve your spot. You'll find this link in the show notes, but don't wait. Spaces fill up fast and we don't want you to miss out again. That's LeanStartup Co contact AI. Let's make successful incubation and scaling of AI centric products a reality for your team today. I love the discussion of the beta and the alphas because I think the way the big companies are kind of trained to work and have been working for decades, especially ones that have been around for a while, is to start with any project we have to know what the ROI is before we can start it. And so that works for existing lines of business with a lot of historical data. And you know, we, we all kind of know generally what's going to happen. But to your point, when you've got a portfolio of, of, you know, new things that are uncertain, you can't, it's impossible and it's actually a waste of time to do lots and lots of work evaluating the return on investment of each individual investment or each individual time. We're going to drill for water. What's the ROI in that? I don't know, but our objective is to find water, right? So it's the portfolio that has the ROI in this space, not the individual investment. And that's really hard for a lot of companies to get their head around. That's right. And I think what you need to do, you, you calculate your ROI over time. You got to give the portfolio time to be able to have time in the market. Right. If you measure it every three months it's like, okay, it's kind of boring. But if you, if you watch it over six month period every half year, you're going to see some pretty amazing things. Like for instance, right now I'm coming up to my mid year update and the basket is wonderful. I now have to edit what I'm going to show to my executive committee in that I have to drop some of the really beautiful things that are going to have to be really, really sorry to a lot of folks who work very hard that they don't get showcased this time but they get showcased next time. Let's keep just pulling on this thread a little bit because you'd mentioned the portfolio needs time I've also, I, I've seen in some cases that, that, that goes too far when even, even outside of the space of AI where it's, you know, you've got maybe a corporate innovation team or something like that that says, hey, Trust us, in 7 years this portfolio is going to be gonna, gonna have this amazing return on investment. But due to short term, you know, quarterly results, pressure and, and whatever it is, that seven years never gets here because it's just, it's too long for a company to wait, especially publicly traded one. Balancing those kind of longer term investment goals versus demonstrating some quicker wins. Yeah, you know, I think I lean a lot on my experience as a person who managed capital. Now you and I know that the amount of patience that you get or the amount of rope that you get to hang yourself with is inversely proportional to the amount of money they give you. Right. So you literally have to start tiny, you start small corporates. The problem with corporates is you imagine big and you're measured very tightly. But if you ask for small, then the patience is actually a lot more balanced. That's actually how I started this journey in the AI platform. I didn't start off pitching an AI platform to the board. I started pitching some proof of concepts and the bill was a lot smaller. They had to gain confidence that I could execute. And with the proof of concepts, it executed beautifully in a timeframe that they had never seen before in their lifetimes as corporate. You know, within the span of three months, it went from zero to two really beautiful things in the top of the investment funnel and the bottom of the investment funnel that you can look at it and say, this has radically improved our ability to find deals and to evaluate deals. It's clear, it's out there in the open. And of course I chose the highest value chain we had in the company. And then from there they said, can we get more of this in more places? And I said, patience, of course I want to do that. But if I take this approach and I do this, say 10 across the whole company, I'm going to ask for a big chunk of investment from you. Let's not do that. Let's figure out what we did right as pioneers here and let's figure out how we can build a platform so we can reduce the cost of each of these projects that you want to run. So let's focus on platform first. I love it. And it's the, you know, it's the, it's the concept of metered funding as a, if you're a startup and you went to a venture capitalist and you said, hey, I have an idea for, you know, this new thing. Can I have a hundred million dollars? They'd say, no, get out of here. You're you. We have no proof. We haven't, we haven't seen any evidence that what you're going to, what you're proposing is going to work. And so you could, maybe you'd come back, you know, in three months and say, hey, we interviewed a bunch of customers and we found out this is really a valuable problem to solve and we have a prototype. Okay, well, that's interesting. Maybe you'll get a little bit of money, but you're still not going to get the 100 million. And each time you come back and you demonstrate progress and you earn the right to unlock another round of funding. And so that idea of metered funding works also in a big company as well. That's right, absolutely. And I think to me it's not paradoxical, but if you listen to it at face value, it feels paradoxical. But the ultra tight timeline and the ultra tight budget actually makes us better. It literally makes us better. It makes us a better team. It's actually created a way for me to forge the right people that eventually I know that when, if you integrate the amount of effort we're going to put into this over three years, it's a massive project. It's a massive culture building for the developers because I have to teach deterministic programmers to do hybrid probabilistic and deterministic at the same time. And I have to take teach probabilistic programmers how to do deterministic at the same time. And I have to teach project managers that when I say agile, in this case, I use it in terms of the meaning of English agile, not agile. The methodology. You know, how do you become a project manager in a pioneer is a very different thing than a project manager in a big army. Very, very different. So constraints are really, really good. Yeah, you can use a Gantt chart in the army that goes out for three years. And if you're trying to be a pioneer project manager with a Gantt chart that goes out three years, you're not going to make it until next week. No. You'll lose your sanity very quickly. This is fantastic. So, Philip, let's kind of pick up on an earlier thread. We were talking about strategy and you said that when you were starting small, you picked something that was potentially very high value. Right. You picked maybe the most lucrative part of the business to kind of start applying AI to. Was that a conscious decision, I'm assuming? Yes, it was. I had to orchestrate it. In my heart of hearts I knew it was that. So that organic orchestration sounds a lot like generating buy in, is that what you mean by that? That's right. And in terms of generating buy in, especially if it's supposed to be done in a workshop fashion, you have to do a lot of preparation beforehand and you have to know which. What questions to ask in a wide audience and within the workshop audience. And in some ways there's also keeping me honest to make sure that my instincts were right and if people, if I couldn't convince people that it was probably the wrong thing and so I really shouldn't say it that way. It really is to vet whether my initial instinct was correct or not. Do you recommend using kind of a workshop based approach to generate buy in? I mean any kind of best practices or watch outs you could, you could list for our listeners? It depends on your organization. You. So I guess my advice to, to. To anyone in positions like mine, number one, is really to understand the company's appetite very, very, very well. And not just on a strategy basis and things that are written on paper but really, really getting to know each person first because they, they, they do not reveal to you all of their propensities and they will say things that may be conventional wisdom in the company and you might think that you're buying from that point of view. But these issues relating to AI A lot of us in our day to day have formed particular biases, rightly or wrongly, positively or negatively towards AI and they may not show it at face value. So really understanding your fellow decision makers is fantastically important and spend time there I think for myself I spent the first six months initially when I came to the current corporate I'm at really understanding and feeling and I went on a lot of walking tours, a lot of feeling tours on how people really feel on the ground. Because if you just go to the executive levels, even the minus 1 so minus twos may not be able to articulate to you how the feeling on the ground really is like. And so if you're bringing something transformative like AI to the whole company, it affects everyone and as a result if it affects everyone, you literally have to know to a great degree of confidence how people really feel about it. And then from there you can sort of figure out the acceptance levels and then from there maybe you can find that narrow spot where you can convince people that you know what in this particular area, we want to try it and don't ask for more than what you need. In fact I believe you should constrain it and you should do something that is because this is going to be disruptive, right? So if company, if the company is used to 18 months, 24 month projects, make your project three months even, even if three months is, you feel a little too short, constrain it once again. I think constraints are really, really important. There'll be one, one guy understanding, embrace constraints. I think the other thing that people need to in positions like mine, in other corporates, if they can embrace also being brave in what they are proposing. If you are going to change people's minds and you're going to tell them that this time is different of AI, don't disappoint them with something that is milquetoast. Don't describe to them something that gives an ROI of 23% when people are used to 17% in a PE company, right. You, you obviously need to articulate something that is massively bigger. And if you find that you can't articulate that then I think you have to go back to the drawing board really and ask yourself are you really doing this for the right, for the good reasons and for the good of the company. Because why else would the company transform itself except for really, really big gains? So embrace your inner pioneer and be brave and because otherwise why are you out there in the wild where you have a 80% chance of not going home? You gotta go big. You've been talking about deadlines, right? Constraining, making sure that people feel like maybe they don't have the time or the resources they need in order to accomplish something. And I, I, I very much agree with that. Because if we have too much time and too much investment, there's not a sense of urgency and, and we've certainly seen that with our clients at the lean startup company where there's a few of our clients that say hey, we've got these really smart people who are supposed to be developing AI powered products and you know, they're not really producing anything. Well, what's going on? Well, you know we, we give them an annual budget and we let them know that if they need more money they can get it. And we kind of wait for them to, to develop things. I'm stating that too strongly for effect but what they needed was hey, we need a three month project and if we can't meet these predetermined milestones, it's not a good use case set it Aside, to use our analogy, there's no water here. You know, we went down far enough like next, go to the next hole, don't keep drilling or widening or just let, let's move on to the next thing. I think the other thing that was just super insightful that you mentioned was it's not enough to just read the strategy of your company or look at it and talk to a couple of executives who just tell you what the strategy, they read the strategy to you, that's printed on the website. And then for you to say, as your, as your AI development group, okay, here's what we're going to do. Based on that, I think the, the idea of going in, walking the racetrack, really understanding all the way down to individual contributors in some cases, hey, what's actually going on? What are people excited about? What are they afraid of? That is super helpful because a lot of the strategy of a company isn't written. Everybody knows that we're not going to do that or that we should do this, but it's not written down anywhere. I think that's a really deep insight. Absolutely. And you know, I think that to me, I've been working for 30 years. This is my final, I think, capstone experience. And in this capstone experience that I have, I take a lot of my learnings that I've encountered like that I've built up over time. Like if you ask me when I started my career back in the 90s, would I have this way of thinking? No, of course not. It's like constraints. Who wants constraints, right? You want no constraints, you want infinite budget, you want infinite time and all that. So it is very counter. And the reason why I came to this realization is because if I just look back honestly, the times when I created the best work in my life, it's always been under constraints. So I'll tell you a story. In my first six months in the company, they had a really vexing problem that they couldn't solve for a long time. So this was the guy who was the co founder of this company and he basically ran and he was the smartest guy in the company and he couldn't solve it. And not because he couldn't, but probably because he couldn't invest all of his mind share towards doing so. So he gave me a new entry entrant to the company. He's like, hey, would you like to try to solve this? It's like one of these Fermat's last theorem type of thing. Just go try to do it. He had no expectation of me solving it. But within the space of 36 hours, I didn't sleep, I just ran through the clock because I knew when I had all these complications in my mind, when I dropped it, coming back would be close to impossible to do so. And this was a problem that was very important to the company. It was, how do you determine the performance attribution for a fixed income portfolio? And it wasn't simple to get there because they had an operational side to it as well as a theoretical side to it. But within that space, I did something that he couldn't do himself and his massive team couldn't do. And so it's. If I look at my career, there were probably 15 of these things that have happened, and they all came from constraints. So I. And I would think, well, I'm a smart person. I'm not, you know, not the smartest or dumbest. I can do a lot of things. You know, I know how I like to work. But if I look at it honestly, the times when I was really productive and really created was when I was under pressure and under huge constraints. So creating those artificial constraints in many ways is a method and actually it's a way for me to forge new culture, especially for young people who are coming through this. Man, they are like the young pups that have never hunted before. You take the blood of some of the prey that you just got, you wipe it in their mouths and they're like, man, I love this. I can go out and hunt again. And you make them hunters by doing so. I love it. I'll tell you what, I feel like we could go on forever, but unfortunately we're gonna have to wrap up, I guess, just fantastic discussion. If you could kind of give three key pieces of advice or recommendations to your fellow corporate AI executives, even if we've already talked about them, what would those three things be? Number one, be humble, empathetic to your organization. Really learn and know it before you try to change it. Number two, be the bravest person in the room. Because if you are looking at AI for the company, you have to be the bravest person in the room. Because as you start the journey, they will look upon to you as a prophet to move along. And if you don't have big visions and you're not brave, they will smell fear and that would not be good for anyone. And I think the third thing really is this time really is different in the juncture of computing that we're in right now. It is doing something we've never done before. Generationally or even since the start of computing. This is moving from deterministic programming to a hybrid, probabilistic and deterministic. This time literally is different. And a lot of the insights that you just kind of brought up in this episode are going to be super helpful for the for the leaders that are trying to drive that kind of change. But they have to know that this isn't just another thing. It's not just the cloud, it's not just some other new technology. This is a paradigm shift, not just when it comes to how to develop things, but also in terms of how the users and the customers use the products that are being generated. So it's a totally new ballgame. Well, Philip, thank you so much. This has been an absolute pleasure and so appreciate your time and hope to talk to you soon. Oh, thank you Ben. It was a pleasure. The Lean AI Podcast is brought to you by the Lean Startup Company. To find out more about our Lean AI approach to generating more AI wins with far less wasted time and investment, including our training workshops, pilot programs and full implementation offerings, Visit us at leanstartup.co Search the Lean AI podcast in Apple Podcasts, Spotify or wherever you get your podcasts so you don't miss a future episode. On behalf of behalf of our entire team here at the Lean Startup Company, thank you for listening and sharing with your colleagues and friends. If you found this episode insightful.