Code and Conscience: Freedom to Invent

Transcript

Code and Conscience: Freedom to Invent

Seth (00:03):
Our data is our crown jewels, and so we effectively have to draw a bit of a line around the data, but not around the idea. So our teams actually have quite a bit of freedom in what they try, how they approach a problem, being able to be curious, which I think is a truly core competency.

Steve (00:21):
I think there's such a huge opportunity for innovation. Historically, we've been bottlenecked on execution speed of creating these solutions in the engineering capacity that we have. That's becoming less and less the constraint.

Jim (00:34):
When we work with leadership teams, we see that when the C-suite is using AI and demonstrating how they're using AI, they get their teams on board as well, and they can show that there's a practical and useful way to use it where they're applying their own guardrails, when they're applying human judgement.

Tom (00:53):
We're at the start of Q3 2026. Every day that passes, individuals, managers, executives, and boards are crunching their internal numbers. They're working out if the millions of dollars spent on cutting edge agentic AI deployment over the previous two years is showing signs of meaningful ROI. If figures from the first half of 2025 were anything to go on, the juice was not worth the squeeze. MIT's GenAI Divide Report 2025 showed that 95% of generative AI projects in H1 last year failed to deliver demonstrable ROI, 95%. But what happened to that remaining 5%? What secret engine were those elite organisations running that the rest of the market completely missed? Is it really a gap in technical horsepower? Did they structure innovation better, manage risk more competently, or did they grant their teams the power to experiment more freely than the rest? Welcome to the Next five podcast.

(02:04):
This is part two of our special three-part series called Code and Conscience. Today, we're exploring the freedom to invent. We are dissecting how to escape pilot purgatory, why traditional management models need to be re-imagined, and what it truly takes to transform experimentation into industrial scale monetization. Joining me today are three leaders on the front lines of digital transformation. First, we have Steve Tarza, Director of AI and Developer Acceleration for Stores at Amazon. Steve, welcome.

Steve (02:41):
Thanks, Tom. Nice to be here.

Tom (02:43):
Next is Jim Rowan, US Head of AI at Deloitte. Jim, great to have you.

Jim (02:48):
Thanks, Tom, for being here. Appreciate it.

Tom (02:50):
And finally, Seth Fox, chief technology officer at S&P Global. Seth, a pleasure.

Seth (02:56):
Great to join you today, Tom. Well,

Tom (02:58):
Steve, let's start with you. When you look at that statistic from MIT, that 95% of projects fail to find ROI, what's your first thought and what do you think is really driving that statistic? Is it as bad as it looks and what are the companies that make up that 5% of success doing differently?

Steve (03:22):
Let me talk a little bit about what we did in Amazon stores to figure out how we could take this really great new technology and get into that 5% to get into that category of seeing those gains. And you mentioned this in your intro, we ran experiments, frankly, we had to figure out how we could take this really amazing new technology and get that acceleration in a sort of very human-centric way. They would get percentage-wise gains. They would apply them to their existing workflows and they would see improvement, but it would be in the sort of sub 100% gain. That's called AI enhanced, where you apply it to your existing processes. We saw that when we go further and we redesigned the workflows, we redesigned the way work got done, we saw these step change improvements in the outcomes that teams were getting. And so in our experiments, we actually saw a median velocity increase of 4.5 times for teams that redesign their process around AI as a core part of it.

(04:22):
And we typically call that AI native. I would say the nearest parallel to that is the cloud-native transformation. That's something we went through when cloud came around and companies that lifted and shifted their workflows into the cloud would see that percentage-wise efficiency, same thing, same parallel, but those that redesign their applications for cloud actually saw step change improvements. It's the exact same thing we're seeing with AI.

Tom (04:49):
Does that mean that those that aren't having this AI native environment are potentially in that 95% bracket? What's going wrong for them that makes that statistic so stark?

Steve (05:00):
Yeah, I think what ends up happening is folks take the AI tools and they apply them to the exact same workflows that they're doing today. If you have to write a document, you maybe do this dialogue with one of the AIs and say, "I need to write this document and this is the outcome I'm looking for." And the AI will accelerate that, and that will make you a little bit faster on that one activity. If you look at that in the context of the entire workflow and you figure out what is that purpose of writing that document, and you identify if that step is even needed anymore and you question the entire workflow, you can sometimes eliminate many of the steps and then that's when you get the changes. And I think the folks that are in that 95% that are not seeing that, they're sort of bolting AI onto the work that they're already doing, and so they're not seeing those gains.

(05:49):
You really have to change the system of work in order to be able to see these stepwise improvements.

Tom (05:55):
Jim, at Deloitte, you see this execution gap play out across hundreds of enterprise client balance sheets. MIT's figures are a year old. So where are we now? Do we have some more up-to-date numbers? Have we seen improvements? And how have or can leadership teams guide their organisations out of that pilot purgatory?

Jim (06:15):
Yeah, thanks, Tom. And we do have some more updated numbers. I love the survey though because it created a lot of challenge in the market for enterprise leaders to say, "Well, how do we not end up in the 95%?" So in our State of AI report that we launched back in January, we saw a quarter of organisations get more than about 50% of their AI solutions into production. But when you do the math on that, that's still not really that impressive because we'd expect to see a lot more solutions getting into production. And so what we see is a challenge, and Steve is hitting on this a little bit, they're starting with the technology first. And so when you're having those conversations, it's become so much about a model and a technology conversation when in fact it really needs to be about the people and the process side of this.

(06:55):
And we've been doing these transformations for years, digital transformations, cloud transformations, but we know from those transformations that it has to be about how do you do the work differently? How do you help your people understand how the work's going to be done differently? How do you help educate, communicate, share that vision and North Star with them? And so that's some of the things that we're seeing organisations that are successful are re-imagining how their processes are working. They're starting from the ground up and rebuilding the way the enterprise works and using AI as a technology that's helpful to go do that. And they're using both probabilistic solutions and deterministic solutions to get to the right outcomes. So that's kind of what we're seeing in the market right now and why I think the next time we run our survey, we'll see far more solutions into production too.

Tom (07:39):
Yeah. Seth, you manage critical financial data infrastructure at S&P Global where markets demand instant answers and have a zero tolerance for error. How do you balance Wall Street's demand for immediate quarterly ROI with the messy, sometimes unpredictable realities of testing new AI applications? What if pushing for speed ends up breaking core governance?

Seth (08:03):
Well, I think the first thing that I would state is we've seen probably results more akin to what Jim had just noted, that it's not necessarily a 95-5 split. And so I'd like to start there with that premise and also like to highlight that I don't think that there has to be a sort of one or the other when it comes to the critical infrastructure we serve and then the innovation that we also need to put in place. I do believe that we have to run effectively two different paces, two different clocks. Our core financial infrastructure has zero tolerance for error. We effectively provide information and benchmarks that can move the market. So in this case, we have a lot of client trust that we've effectively created here. Alongside that, however, we've got a separate track where we have multiple innovation and evaluation environments. The teams can actually test how an agent behaves or in the introduction of a new skill or a creation of a new connector to a backend data source or application.

(09:10):
That track that the measure of success is not like the quarterly payback that you typically see, it is really in how fast we can learn and how maybe cheaply or economically we can find out when we were wrong. I love the term, not fail fast, but learn fast. And honestly, as we go through this process, one of the things that to me really stands out as we think about what innovation friction looks like is that we see a lot of duplication across the enterprise and a valuable finding from all of the pilots that we're running, and particularly as we start to consolidate and aggregate those, is that we have a lot of overlapping use cases. We have a lot of overlapping capability that the teams were sort of putting in place, and now we can think about how we just disaggregate that a little bit.

Tom (09:57):
Seth said then about not failing fast, but learning fast. So I want to talk about some friction inside large enterprises. And Steve, when we talk about reducing organisational drag, what does that actually look like on the ground? How do you keep the wheels turning without creating chaos?

Steve (10:15):
Yeah. First I'll say AI amplifies everything, the good and the bad. And so one of the things we saw very early is that our engineers spend less than 30% of their time actually writing software. A lot of the time, the other 70% goes to things like status updates and design work and operations maintenance, things that are not what most folks may consider traditional software engineering. And a lot of organisations end up focusing their effort on those areas, which is I think another component of where you struggle getting the gains. But what we see is when you go faster, when you get to these stepwise improvements, the weak processes that were manageable at human speed, the meetings filling your day, they become a media bottlenecks and you end up seeing these things surface in hours instead of days or weeks that you may have traditionally seen with human-centric speed.

(11:07):
The teams that figured out how to go fastest figured out that they have to deploy agents across the entire workflow, but if they only accelerated one of the steps, say in the workflow, or they didn't address the human speed processes, they created new bottlenecks and those remaining steps continued to operate at that slower human speed. And so while you would speed up one part of the activity, you'd end up stopped on something that has been traditionally slower or again, meetings filling your day. So we saw that when we give engineers full autonomy, maybe a single person, the ability to own a project end-to-end and arm them with agents that allow them to work throughout their meetings and skip through the time weight that they typically have for approvals or handoffs, they can go much, much faster. The other thing that we saw very, very clearly is that if you have a good understanding of what you're trying to build and you can explain it clearly to an AI, the AI can run a lot longer and a lot more accurately to accomplish that outcome.

(12:14):
And so we've really leaned into spectrum development and what that allows engineers to do is really focus on what's their intent, what do they want the software to do and create that contract that both humans and AI can reason over. You can have a debate with another person about whether this is the right attributes of the software, and then AI can take that and run with it and execute and create it. And so that helps in a couple areas. It helps reduce hallucination, it gives us a unified source of truth that isn't the code anymore. The code ends up being an artefact created from that. And so that's really powerful for accelerating things like testing, documentation, and so really redesigning all of these pieces at the same time reduce that extra friction that you typically get.

Tom (13:03):
Yeah, Jim, Steve said that the human speed of learning creates bottlenecks, and that's even for engineers. I want to look at the non-technical part of an organisation. How can these non-technical teams still absorb this technology fast enough to turn this learning speed into a competitive advantage?

Jim (13:23):
Yeah, we've seen with a lot of our clients and even internally too, the need to adopt and understand AI is a critical objective and key point people need to understand. And even though organisations have gone after this with the idea of increasing AI fluency, what is AI fluency in the age of all this change that people are happening about? So what we're finding in organisations is a couple of things. One, you need to create a programme that's very adaptable to the change in pace of what people are trying to learn in this market. And so you're relying on a curriculum that's two years old or a curriculum you built last year to train your employees this year, seems like it's going to be out of date. And so you have to create ways to both institute this curiosity around how you learn about AI and create environments where you can create what we call micro learning opportunities, targeted learning programmes to meet the users where they are when they're using these tools or trying to drive specific activities.

(14:15):
And so we're finding that that's really helpful with enterprises. The other thing that we're seeing is that starting top down. And so when we work with leadership teams, we see that when the C-suite is using AI and demonstrating how they're using AI, they get their teams on board as well, and they can show that there's a practical and useful way to use it where they're applying their own guardrails when they're applying human judgement , and that creates a real incentive for the rest of the teams to start to pick up and use AI as well and sort of cascades through the enterprise too. So those are a couple of things that we're seeing. The final thing that I really just encourage everyone to be doing is that if you're not using this every day, you're not building that muscle, you're not testing where the frontier is on these tools and the capabilities, and that's okay.

(14:55):
And you want to have those, as Seth was saying, learnings, right? When some of those things don't work, you want to bring those learnings back into how you're working. And then the next release you try it again, and that's your own internal eval process about how AI is developing and where you can kind of start to apply it to your work and then the rest of the enterprise.

Tom (15:12):
Yeah. Seth, going back to your failing fast, learning fast, where do you draw the line between giving teams the structural permission to fail or even creative freedom to invent while keeping data strictly secure? What happens when an experiment stumbles and how do you ensure guardrails don't end up acting as innovation handcuffs, if you will?

Seth (15:33):
Well, Tom, it's a great call out. I will start by saying that our data is our crown jewels. And so we effectively have to draw a bit of a line around the data, but not around the idea. So our teams actually have quite a bit of freedom in what they try, how they approach a problem, being able to be curious, which I think is a truly core competency, but there are very firm non-negotiable rules about the data that they can touch and that they can't touch. And we put some pretty rigid access controls around that driven by our enterprise data organisation. I will note though, on the speed question to us, the lesson is not necessarily around the access, but how we train and more importantly, how we coach. A lot of what we've done is put these pods in place where we have both AI experts and business experts and data experts in this pod to allow us to move a little bit faster.

(16:29):
It allows us to not effectively be generic in the sessions that we're driving, and we then are able to sort of embed it in the actual work that we do. Steve talked a lot about teams, and so I love this sort of concept because to me, as you start to build these sort of teams where you have this combined understanding knowledge and capability, it really does start to take off. And I will just say I love this notion of collaboration being a force multiplier for innovation, and that's really how we've been able to drive this and move a little bit faster while we put the right controls in place. And I think maybe the last thing that I'll note is obviously we have the learn fast mentality. It is blameless. So when there is failure, which there inevitably will be, there's not sort of this view around, oh my gosh, well this happened or that happened.

(17:23):
We use those events to make sure that we are effectively building on that for the next team and make sure that that knowledge is broadly shared through the community.

Tom (17:33):
Yeah. Jim, Seth said there that it's about reorganising teams into these sort of pods of experts together. I want to look at what happens when we scale AI from these pilots into future industrialised monetization scales. What really changes? Is there going to be traditional organisational charts thrown out the window? Will middle management approvals sort of disappear? And what happens to product development cycles? Do they vanish by 2030?

Jim (18:03):
Yeah, we can have what I wish will happen and maybe what will happen, and maybe there's a line in the probabilities there of the answer, but I think we see a big move from org charts. So what we're referring to as work charts in the sense that these org charts have existed since I think the railway, and that's how we got a lot of our design of these things. And if you go now into how we really should be organised, it should be around the work and the outcomes and the output that we create. And we view this as an opportunity for organisations to start to look at ways they can eliminate some of the relay work that happens in the organisation and eliminate through automation of AI tools or other capabilities, and then use the time for the humans, for the judgement ask, for the harder problems.

(18:45):
And that's kind of how we're thinking about org charts changing. Now, you put a timeline on, I think it was 2030, and so betting in the space of AI is a little dangerous in terms of when that happens. And I think I speak for myself and the clients I'm working with, organisational change is very hard and takes a long period of time. And so where I'm seeing this pop up now is in IT teams where we're changing how the structure of the development team looks and people own more capabilities across their individual purview as Steve was talking about. And so I think we'll start to see that into other functions as well, which will start to challenge how our org and operating models are going to be working in the future. So 2030 might be a bit aggressive, but I think we're already seeing pockets of it now.

Tom (19:23):
Yeah. Steve, you are looking deeply and discussed it already about how developer teams accelerate. If autonomous AI agents are writing code and running tests, what happens to the human role in the retail ecosystem? What is the core value a human employee brings when the machine handles the execution?

Steve (19:45):
Yeah, this is a great question and one I think a lot about. I think as AI is taking on more of the execution, the human role really shifts upstream. It's really focused more on what should we build, helping define exactly what that looks like and getting away from getting stuck on how exactly to build it. To Seth's point about failing fast and identifying these areas where we can experiment and fail quickly, I look for failures that come from maybe we had the wrong idea or we didn't quite have the product market fit right. I don't want them to fail because of how we execute, because of how we build them. And I think having humans focus more on, hey, this is the right product to build, this is where we should focus our attention is the right part of it. I think that also necessarily means developers need to focus more on clear communication.

(20:36):
They have to continue to look at problem solving and problem solving specifically at a systems level, not necessarily at the component level. And then also being an expert at looking at output from AI. Sometimes the engineers might not be the ones producing the output, but they need to be able to review it and quickly understand if it's high quality. And just to really pin down that piece about communication, it's so important to be able to describe what you want built that if you get it wrong or you're not quite clear in what you're describing, you won't get the output. The AI will build exactly what you ask it to and it won't be the thing that you wanted. And so I'm seeing a big increase in the communication skills being critical for success for engineers.

Tom (21:23):
Seth, when an experiment with new technologies like AI fails, how do you define the value of that failure? How can a technology executive defend a budget for bold experimentation when the financial payoff also might be years away?

Seth (21:40):
So I like to think that every failed experiment is going to tell us a little something about what was the right path, wrong path, faster, slower, more economical, more capable. So I think that that feeds into the next test or the next innovation or the next experiment. It usually leaves these components behind that make the next build better. And I think that learning goes across the organisation. We built a series of communities based on personas, whether you're software engineer or an analyst or a data operator so that we can effectively share some of that. That all then feeds back into some of the core teams. And so as we're building new capabilities internally, we may take some of those learnings and effectively improve in an area where we need some common capability. A good example of this is as we build in more of an observability layer so that we've made some understandings of what we can see and what we can't see, and then being able to pivot those capabilities and what we can build to scale for the enterprise.

(22:46):
Look, on the budget question, I don't think that you can ask each individual pilot to justify itself. We look at this more as a portfolio and understanding that these are effectively aggregate sort of expenses and a little bit of just the cost of doing business. Every firm typically has some type of R&D capability, and all we're asking to do now is effectively fund that in a way that allows us to move fast, increase scale, increase the new capability and feed into either our external client-facing products or internally the way that we work being improved. And so I think that's really how we're starting to look at this. And candidly, as we go through these efforts where we're generating more productivity within the workplace, the initial thought is, okay, well look, we can go to cost savings or cost avoidance and start to contract the workforce.

(23:39):
The other way to leverage this productivity is to then actually give more time to innovation. And that's one of the ways that we're looking at this.

Tom (23:47):
Steve and Jim, you were nodding along. Is there any extra comments you wanted to bring in?

Steve (23:51):
I'll just say that last piece I think is so important. The part around how you take the gains that you get from this acceleration and you apply them. I think there's such a huge opportunity for innovation. Historically, we've been bottlenecked on execution speed of creating these solutions in the engineering capacity that we have. That's becoming less and less the constraint. And so that ability to take those biggest ideas and turn those into reality is just such a huge unlock that we can't overlook that. And I think it's really great because it's also something that we federate that ability. It's not just software engineers that can necessarily do this anymore. It could be anyone that has an idea can really turn that into a prototype or potentially even reality.

Jim (24:38):
And one of the things that sort of struck me was I feel like when we started the conversation, we were talking about failures to get to production. And I think some of the failures that we saw early on was an inordinate amount of time spent on ROI calculations that were overly complex about where to drive value versus allowing these experiments to get going, seeing where they could drive value, and then cycling that back in for learning around the next turn to see how to make it better the next time. And so I always try to talk to clients about ROI is important, yes, and making sure you figure out the right path to ROI and having some space to get and find that can be a little bit more challenging than just a quantitative exercise that I think people are used to running from a business case perspective.

Seth (25:19):
That's a great point, Jim. And one of the things that I will say is we've actually moved that ROI calculation to the back end of the workflow. Typically, 10 years ago you'd look at it and say, well, you've got to build the business case and you've got to define all that upfront. Moving it to the back allows us to have that space to be curious and continue to innovate. And then as we deploy something into production that we know is going to drive some type of time savings or quality improvements, we start to factor that in on the back end to effectively just validate that case in arrears.

Tom (25:54):
Well, before we close out this second chapter of code and conscience, we're going to have a quick fire round and ask all of you to answer these final questions. What is the single biggest obstacle organisations face in your opinion when it comes to AI implementation that they need to get over to really succeed? Jim, let's start with you.

Jim (26:14):
My first answer on this one would probably be data. I think we still underestimate the power of accurate, clean, useful data in applying that to AI drives more grounded and accurate results. So we're still back cleaning up our data and getting that right in the enterprise.

Tom (26:28):
And Steve?

Steve (26:30):
Yeah, finding the right balance between quality and speed. I think trust is the currency of AI adoption, and without keeping quality high, you're really just accelerating risk. And so that shift to AI native is as much a cultural and a people transformation as it is a technology one. Seth.

Seth (26:48):
Well, look, I think since Jim and Steve stole my answers, I will say, look, our processes, we've built process to move it at human speed and we need it to start moving at AI speed.

Tom (27:01):
Okay. So then in five years time, will non-technical enterprise teams be building their own business software autonomously or will development remain locked inside IT? Steve, let's go to you.

Steve (27:13):
I don't think so. We're starting to see this already with AI tools. Our product managers and business users can really vibe code a prototype and they can use those to share with development teams and then developers can take those and turn those prototypes into specifications, and then eventually they become a real world production version. And so I think we're already seeing the non-technical enterprise users really see that unlock.

Seth (27:36):
Jim.

Jim (27:37):
Yeah, I love that. I mean, I think IT can help be the platform and help harden the solutions, but allowing the business to build. Vibe coding's not a bad thing. I feel like sometimes it gets a bad rap out there. It's a great way to get a great design spec into the team that can harden and create a thoughtful solution. I think the other narrative on this too, Tom, that's a little bit tricky is this build versus buy conversation in this space too. And there's a lot of challenges out there around enterprise SaaS and whether or not businesses vibe code their own solutions. And I think there's going to be a lot of opportunity for both businesses to create their software around these existing solutions and augment them to make it more tailored to what they're trying to do.

Seth (28:15):
Seth. Yeah, I agree with all points and I think we do end up somewhere in the middle, but really maybe biassed around the business and product side. Look, we kicked off our own agentic software development lifecycle capability. I think we quickly determined that we actually need to bring this into the product development life cycle and start a little bit more upstream and start to create a bit more of an end-to-end capability. I'll just note that to me, the shift though is not like the creation. Building is going to get cheap. When they say the cost of software is going to be near zero, but the constraint is that after you build it, who owns it, who supports it, who's accountable, those are still things that we have to deal with and have to manage. And AI is not going to solve that at least in the next few months.

Tom (29:04):
Well, Seth, I'm going to stay with you so you can steal Jim and Steve's answers for this next one. What's your primary hope for how giving teams the freedom to invent will reshape human work over the next five years?

Seth (29:18):
I mentioned this notion of curiosity, and to me, that becomes a fundamental part of everyone's job. We have to start becoming idea brokers and experts because the AI is going to do a bit of the heavy lifting there. We measure hours to get back to people, but the question that I care more about is what we do with those hours that we get spent on. And so being curious, ideating, continuing to drive innovation, that's where the freedom comes in. I think that then becomes sort of that efficiency lever that we pull because now we're able to do so much more than we have been in the past.

Tom (29:53):
Steve.

Steve (29:54):
Yeah, I agree with Seth on that piece. I think one of the biggest things I'm hopeful for is reducing the friction and the grunt work that folks have to do that really stops them from being able to do what their actual craft is and get to that innovation, get to those primary outputs that they have.

Tom (30:10):
And

Seth (30:10):
Jim?

Jim (30:11):
Yeah, it's always tough to back clean up with this group here. I've got a lot of great ideas. I agree, and I think I would add just the empowerment of our humans to do really cool, interesting work and solve harder problems. If AI takes care of some of the easier stuff and the grunt work around it, now we've got a tool that can help us work on even harder, more challenging things.

Tom (30:30):
That was the tip of the cap to you there, Seth, for all of the cleaning up you had to do over the last few answers. Thank you,

Jim (30:35):
Seth.

Tom (30:36):
Well, this has been a compelling discussion and I thank you all. So many thanks to Steve Tarza.

Steve (30:43):
Thanks, Tom. Thanks for having me.

Tom (30:44):
To Jim Roman.

Jim (30:45):
Yeah, thanks Tom.This has been great.

Tom (30:47):
And to Seth Fox.

Steve (30:48):
Thanks, Tom.

Seth (30:49):
Great experience.

Tom (30:53):
Well, as we wrap up this second episode of Code Unconscience, I'm left with a striking realisation. The AI landscape isn't just a contest of technological access. It's a high stakes test of organisational design. That 95% failure rate reported by MIT isn't an issue with the algorithms. It's a spotlight on organisational risk aversion and legacy management models. The small fraction of organisations winning this game are those willing to dismantle friction, grant their workforce genuine permission to experiment. It's about creating new pods of learning, and it's the speed of learning, which then becomes a core asset. If you don't build an environment where teams have the freedom to invent, you risk standing still while the rest of the market moves past you. But what is invention in today's age? What is that relationship between man and machine? Because in 1919, famed engineer Nicola Tesla wrote in his autobiography, "Invention is the most important product of man's creative brain.

(31:59):
The ultimate purpose is the complete mastery of mind over the material world, the harnessing of human nature to human needs." But we are now in an era where man's creative brain and the product of his invention is rewriting human nature and human needs. Mastery of the material machine may no longer be needed as self-contained and self-improving algorithms render humanity's active creativity into more passive consumerism. So in five years time, will mind over matter even matter? Well, in our third and final episode, we take this conversation global. What happens when internal innovation runs directly into national borders, geopolitical warfare, and strict regulatory walls? Join us for our final episode of Code and Conscience called Intelligence Within and Without Borders, where we dissect the massive $195 billion sovereign cloud market, the rise of regional AI hubs, and the complex balance between borderless tech and local control. I'm Tom Parker, and this has been the next Five Podcast.

(33:12):
Thanks for listening.