Creating a culture of innovation
2 Jan 2026 · 51 min
This podcast episode (Practical AI, recorded Mar 8, 2022) features a discussion with Lukas Egger, head of the Innovation Office & Strategic Projects at SAP Business Process Intelligence, about how large organizations create and sustain innovation. Key points: innovation teams should be temporary and act as stewards (not permanent owners), rotate people back into product teams after 1–2 years, and help the broader organization get better at product discovery. Egger emphasizes minimizing the cost of change, balancing desirability/viability/feasibility simultaneously, and involving stakeholders early. For AI/ML work, focus on outcomes (better, faster data-driven decisions) instead of fetishizing models; use a transparent de-risking process (a DoD matrix / four-by-four scorecard across phases and four risk categories) and shared win/fail criteria to keep stakeholders engaged and surface bad news early. The desired future organization is cross-functional, customer-closely aligned, and treats change as an organizational capability rather than a centralized specialty.
Chapters
First of all, I tell everyone who joins the Innovation Office that their job is to work here for one maximum two years. I don't want anyone to be a permanent part of an Innovation Office. I want them to get faster to their next promotion, find a project to fall in love with, and then move it into the organization and be the champion that then helps it to scale it. Right? I want people to change from pioneers to settlers, and I don't want them to ever get stuck.
Hey Jared, here. One of the things we can count on in the software industry is change. The state of the art changes so fast, in fact, that keeping up can feel like a whole other job on top of your actual job. That's why we created Changelog Weekly. It's our totally free newsletter that we drop in your inbox each and every Sunday. We link to the latest news, the best articles, and the most interesting projects that you should be aware of. We also add a little commentary from us saying why something's important, pointing you to other instances of a trend, or just making a dorky joke to keep it lively. So if you haven't yet, I recommend subscribing to Changelog Weekly and help us help you keep up with the Latest. Head to changelog.com weekly and sign up today. Again, it's totally free and we never spam you.
Yuck.
One last time. That's changelaw.com weekly. Welcome to Practical AI, a weekly podcast making artificial intelligence practical, productive and accessible to everyone. This is where conversations around AI, machine learning and data science happen. Join us at PracticalAI FM community and follow the show on Twitter. We're RacticalAI FM. Thank you to our partners at Fastly for shipping our pods super fast all around the world. Check them out@fassy.com.
Welcome to another episode of Practical AI. This is Daniel Whitenack. I am a data scientist with S IL International and I'm joined, as always by my co host Chris Benson, who is a tech strategist at Lockheed Martin. How you doing, Chris?
Doing very well, Sunny Co host here on a sunny day in Atlanta.
Yeah, yeah, it's getting to be that time of year where I can take some walks outside and experience the outdoors a little bit without snow boots.
So that's.
That's exciting. Chris, I'm. I particularly think that you're going to enjoy this conversation because out of the people I know that think really well and have done a lot of thinking about strategy within an organization around AI and advanced technology, you're definitely the person I think of and Our guest Louis Egger is joining us. He, I think, has thought about a lot of those same things. He's head of the Innovation Office and Strategic Projects at SAP Business Process Intelligence. Welcome, Lukas.
Hey, thanks for having me.
Maybe to kick this off, I don't know how familiar some of our audience is with this concept. If you're in a large organization, you may be familiar with this concept. Maybe not at a startup or something, but a lot of large organizations, when they're thinking about adopting something cutting edge like AI or some advanced technology or doing a new process or something, they'll establish something called like an Innovation Lab or kind of separate group that does some sort of innovative thing. And I see you have this title like Innovation Office and Strategic Projects. Maybe you could give us your perspective on what is the purpose. Why do companies create these Innovation Labs or innovation teams? And from your perspective, what are they they good at doing and maybe not good at doing?
Oh, that's an excellent question. And so first of all, I think that most of the times innovation is more of an aspiration, right? You want to do new things and you want to incorporate that. And I see it often as a little bit like running a marathon. People want to say they have run a marathon, but they don't like the training. Innovation is really hard and it is at odds with most of the company. What most of the time we actually want to do is just make sure that we minimize the cost of change. So that is what we say is product discovery. So innovation and product discovery is like in the same realm, but actual innovation really hard. And I think the difference is that you are incentivized to do different things, right? Most companies need to minimize the transaction cost. They need to get really good at product delivery. They incorporate agile methodologies and all of that, right? They want to be close to the market, to their customers, get faster in turning around and, and creating value. And that's, I think what most companies should focus on. But then there is like those problems that are really ill defined where there's a lot of risk attached or things you just simply haven't done. And then what you really want to do is you want to minimize the change costs, right? You want to make sure that you're treating it in a way that if you fail, you fail gracefully and fast. So the first impulse there is, hey, we're building a team that will do innovation because they are structurally doing different things. And I think that makes perfect sense. But it also creates a barrier between the teams that should work together. So I Would say what I've learned in the last couple of years, if you think about it like first response, yes, it makes sense to have an innovation team and once again innovation and product discovery. Like there's a little bit to unpack here, but it makes sense to start with an innovation team. But what you really want to do is not have an innovation team. You just want to have people who are focused on, on willing difficult projects into existence and de risking those projects. And so in an ideal world, what a company personally, what I believe should strive towards is help the bigger organization to get good at product discovery themselves and not lead innovation or be the quote, unquote innovation office, but rather then be the steward who helps to incorporate new methodologies and, and help them to get better at de risking. So makes sense to have those offices, but really their existence is more like we help the rest to get better at this part. We should only bring in the new and take on things that are extremely risky where you want to have like let's say splash zone for risky projects and you know, like need to create a little bit of distance there. So that would be my answer of like how we're currently thinking about innovation offices.
So as you do that, one of the things that you mentioned early on there was how hard innovation is. It's brutally hard. I would argue that the bigger the company is, and I say this as someone who works at a very large company, the harder it is and culturally and getting all that. So it really depends on certain personality types that are good at that, that are creative personalities, people that I would argue that I'm one of them, that struggle to work in a large company organization, a large environment. How can a large company that wants to create an innovation team find the right people and empower them and give them the room and the leeway and the authority to run forward with that. How do you just do it? Because if you just put a bunch of people in the room and say go innovate, it probably isn't going to happen. So how do you find the right people to go do that?
That's an excellent question. And I think most in my experience in the last couple of years, most of the projects don't fail because of technology constraints or because of the people themselves. Because when you work on something that's exciting and new, everyone typically is engaged, right? So when they fail, they fail mostly because of the organizational setup, incentive systems, not like the things would typically think where they or why they should fail. So I don't have the ultimate answer But I can definitely say what are our heuristics and what we're trying to achieve and how we build up systems within our organization to make change easier. Right. There's this quip, don't force your peers or your organization to make hard changes. Make change itself easy, which is extremely hard, and then let them do the easy change. So first of all, unpacking a little bit of the question, I think you should be very vocal and clear about who to attract and that those are different types of work. I think what I like is there is this idea of pioneer settlers and town planners. And pioneers are people who are happy with failure and uncertainty. Whereas opposed to, let's say town planners or settlers, they will be more driven by constant improvement and high volume and scale. And you should make clear, like what you're searching for and what you're comfortable with. That's the first part. The next part is don't try to compartmentalize those parts and don't have them interact with each other. You should make sure that every project that has some sort of innovation aspect from the very get go, search for product owners, product managers or stakeholders in the organization and go in and support them. Don't try to claim ownership and say, like, hey, the pioneers are the ones who should be doing this job. It should be the pioneers helping the settlers to find the right spot. Right. So innovation to me in an innovation office is always a supporting role that helps the organization. We never claim ownership. We just help the people that are on this, you know, voyage to new lands. If I stick with the metaphor, Oregon Trail. Exactly. Like the survival rate wasn't as high as I would want my project to be.
Yeah. Hopefully no one's getting dysentery on your team.
Yeah. The last thing I want to say, I think very often incentive systems are misaligned, and that's a big problem. And so two things that I advocate for and that we're doing in my Innovation Office, for instance, that's our Innovation Office is, first of all, I tell everyone who joins the Innovation Office that their job is to work here for one maximum two years. I don't want anyone to be a permanent part of an innovation Office. I want them to get faster to their next promotion, find a project to fall in love with, and then move it into the organization and be the champion that then helps it to scale it. Right. I want people to change from pioneers to settlers. I don't want them to ever get stuck. Right. So that's, I think, like one of the things that are critical here to do in terms of like how you set up your system and your incentive systems. And also the other thing that I found really important in my last couple of years is to address issues that we often put to the end of the value creation to the front. What do I mean by that? We typically when we think about risks, and I feel like innovation is all about de risking ideas, we think about feasibility, viability and desirability or at least in our part of the world, that's how we would frame it. Very often people like me who are engineers, we really are not so much enthralled with viability or the business model. And I think preponing it, thinking about the business model, getting in touch with the people who ultimately at the end need to make it work is more important than jumping right into the technical feasibility question. So I'd really try to create a balance and not sequentially go through desirability first, then viability or feasibility, but really do those three things at the same time.
It's interesting you said something in there that I want to ask about because your language about kind of the town settlers and the pioneers I very closely associate with that. The language that I know in our own workplace we use are pioneers and builders. And in the context of builders, meaning what you would think of as town settlers and that that is by far the overwhelmin kind of percentage of the folks in the workplace.
I need to use more metaphors on my team.
I know. So what I'm curious about, we're kind of experimenting ourselves and I kind of wanted to throw it by you. I'm in the defense industry and so there's a test going around in DoD circles and related it's innovation thing. And I came out as like an extreme pioneer and like I'm willing to walk into a giant project and just smash it to bits and start over because they're just not really getting out there. So I definitely have that personality type of like I'd rather break it and start over than push a bad position forward. And do you think you were talking about kind of pushing those innovators out into the larger organization? And this is a genuine question I'm asking you because it's something that I've been debating in my head, like how this works. Is someone like me, I'm probably not going to. I'm a rule breaker all over the place. And so does that make sense for me to go out into the larger organization? Is that where I'm most effective or should I stay kind of in the center of innovation and keep driving that process forward and making demands and generally being intractable to any reasonable person that I may be interacting with.
Excellent question. And I want to say something about like where are we heading in general? So first of all, I do believe there will always be specialized roles, let's say head of innovation. And Chris, you might find yourself perpetually stuck in innovation teams, but that for me would mean that in the future this role is less about like owning innovation and more facilitating and bringing the knowledge to the organization. So it would be a different role. Now I want to come back to what I said about the bigger point. I think for 30 years digitalization was in essence from our perspective. I'm talking now bpi, SAP, a big organization that is very much concerned about processes and ERPs and you know, have ironclad compliant really well running processes. First 30 years we're just establishing that. Right. And it's already a big task to achieve. Right. No matter where you're working in the world, global spanning logistics chains and you want the perfectly compliant and super quickly updated P and L or whatever you need. But at this point that's table stakes. We're 2022 now. And I think every company has realized that for better or worse, the only way forward is to get better at change itself. Okay. And so digital digitalization used to be like a pet project. Now it's like the prime directive of every CIO and CEO. And I think in the future people will want to portray themselves as the leaders of change. Now how does that relate to your question? If you want to have an agile company that's good at changing and adapting to circumstances, you need some sort of that mindset throughout the entire organization. And that's why I feel like that every organization wants to have the tools and the ability to quickly react to changing forces in the market or whatever it might be. Right? So we need more of that just disseminated entire organization. Think about just as an analogy like mobile development, we had like 10 years ago we had specialized groups. These days, I think it's almost like a function of the fitness of your company. If you need like a centralized position, it means you're not ahead of the curve. Whereas if you enable everyone to do it, you're good. So my job as the head of innovation is to make the entire organization better at product discovery, not just one group. And I think that's why you, Chris, for instance, will have a playing field in the entire organization that's more akin to what you would say is today the perfume or the innovation outfits per se. At least that's what I hope where we're going, right?
The changelog is deep discussions in and around the world of software and it's been going for over a decade. We interview hackers like Chris Anderson from 3D Robotics.
At the time, drones were like predators and global hawks and military industrial and they were classified and super, you know, $10 billion things. And we had just built a drone with Lego pieces around the dining room table programmed by a nine year old and it's like, okay, that should not be possible. You know, when, when a 9 year old can do something that is classic, that literally export control as munition with Lego with toy pieces. Something important in this world has changed.
Leaders like Devin Zugel from GitHub in.
The like 10 to 15 year range or 20 year range. What I would really like is for if you have like three 12 year olds hanging out and one of them's like, I want to be a firefighter. Another one's like I want to be a lawyer. I want one of them to say, I want to be an open source.
Developer, an innovator like Amel Hussein.
I've yet to kind of see applications at scale that don't use multiple languages, that don't have just arcane stories behind why this weirdo thing exists. You know, like, all right, when you open this file, you're going to have to turn around three times and tap your nose once. Like it's just the most hilarious stories, you know. But applications are living, breathing, they have craft. That's normal. So I want to normalize weirdness because that's just how applications evolve over time.
Welcome to the Changelog. Please listen to an episode from our catalog that interests you and subscribe today. We'd love to have you with us.
So Lucas, kind of following up on where you were headed there with product discovery sort of being infused more organically across an organization. And I want to kind of bring AI and machine learning type of perspective into this where maybe not every team in the organization has like a data scientist living on the team or like an AI researcher in the team that's like doing those things right. How would you maybe infuse the right knowledge in the various teams across your organization to know when a problem they're facing or when an opportunity they're seeing is a good fit for a like AI or machine learning type of solution? So like there's a whole range of expectations here that people have, right? Some think it's going to solve every one of their problems. Some groups are thinking like maybe it's going to solve none of my problems and likely they're somewhere in the middle. Right. It's technical knowledge, not like developing AI models, but it's a sort of like AIML product discovery. Like how do you infuse maybe that type of knowledge or start to infuse that within an organization?
That's a really tough question and I will try to answer as best as I can, but I will be a bit, bit of heresy and blasphemy coming in because my pedigree is machine learning as well. But I think especially when it comes to machine learning or we call it AI these days, I mean when I started we worked on conditional random fields. That's how old I am. Right. So I think there's some sort of, I don't want to say fetish, but like we think that as soon as AI gets applied there's an intrinsic value that makes it more worthwhile. And to me that's the problem behind it is focusing on output versus outcome. So you want an outcome and the outcome, like loosely speaking, is you want well informed, data driven decisions fast in a way where you can adapt and quickly iterate or learn of past behavior. That's what you're striving forward. Right. And the output might be model, but it could be something else as well. Right. So I think if you like, there's a currency in every organization, right? How we make decisions, who gets involved and so forth. I think here there's culture at play and if you establish a culture of where the outcome is, we want to make the right data driven decisions and quickly learn and based on previous behavior data and instill that into the organization, it's more likely that people will gravitate towards, let's say, ML solutions. But at the same time you're not creating like weird incentives where you're saying like I only think of your outcome in a positive way if there is some machine learning thing deployed. Right. And that's what I would like to avoid. And in terms of then how to get the right people involved once again, make it easy for people to talk with each other and set the right incentives. But for me, at the core of this or where I focus my attention most is to make sure that we talk about the right outcomes and not focus on the output so much, if that makes sense.
I think that's very insightful. It does make sense. When you're looking at those business outcomes and you're thinking about trying to propel an organization further along the path that's chosen in the marketplace. But you want to push innovation in that, that new way of thinking, you might say, out into the organization. How do you get it out there where you create kind of a safe space for people to do that? Because innovation often can cannibalize existing lines of business or existing products. It may be that the AI you're introducing can wipe out a whole nother part of a major product line, but yet it pushes it forward with a capability you didn't have before. So it can be quite dangerous. You can have a lot of adversaries in your own organization that don't want to see that realized. And yet in the long run, it's good for the health of the organization. How do you make that possible organizationally so that people can go do that? And I might finish up by the idea of Steve Jobs, famously, and I'm paraphrasing not exactly said something about if you don't cannibalize your product, somebody else will, you know, but that's incredibly hard to get people to go do. How do you do that? How do you create that environment?
So, first of all, I believe that most people who are in our industry, in our business, want to be in the capacity of product discovery. People like to be attuned and connected to the value that is being created. And I think that's really important to me, this entire conversation about creating change and adapting. We're not adapting in random directions, right? We're trying to be closer to the value generation part. And whenever I talk to anyone in our organization, everyone is excited. Whenever there is a clear connection between what we're doing and how we're making something better or solving a problem. So that's the first thing. The second thing is I fully agree that there's tremendous challenges with change management or, you know, when a company has to adapt. And I think there is, like, a couple of things we should tease out here or discuss. So first of all, and you can push back on that, but I believe that most of the value creating change is not monumental. Like I would say 99% of the change that creates value is incremental change. And we're just adopting faster and better ways of doing stuff. We're not changing out like cars that run by, let's say, petroleum and gas with flying cars. That happens only once in a generation or on very slow timescales. However, the incremental adoption, that's something where every company and incumbent can really shine. And that's where I feel like that's maybe not valued enough. Everyone talks about the innovators dilemma, about the big changes, the disruption, disintermediation, but let's be frank. Most companies struggle with just getting good at product discovery, right? And I think there's also a bit here of history because we think of these changes as always run top down. Like we had this and you brought in Steve Jobs, right, Benevolent, like leader at the top, who says, like, this is the way to go. I can show you the way to the perfect product. And okay, fair enough. But I would argue product discovery does not need a messiah or someone who has some privileged divine inspiration. I think what we want is to have 95% of the people to have the ability to innovate, right, and do the step changes faster with lower costs attached to them. Now, I don't want to sneak out and say like, hey, that's the only thing. You mentioned that when there are big changes, it's really hard for an organization. And often they, you know, it creates barriers. Right? The only way like really radical and big change has successfully been implemented, as far as I know, or at least in my experience, is if there's top level support from the very top. And I think that only can happen if you bring up your entire organization in a way where everyone sees themselves as product discoverers, as people who can drive meaningful change. If you say, hey, you guys are relegated to just coding or whatever, then how would you build up the muscle and the audacity to take on really hard projects? So if you want to build an organization that can weather a storm and create a really huge change, I think it's best to build it on top of two generations or three generations of employees that come up with an understanding that change is part of their job and they're good at it and it's celebrated.
Would it be fair to say that if we kind of go back to our lingo about kind of the town settlers, or builders as I call them, versus the pioneers, that we are acknowledging through this, that there is both innovation or kind of radical change. And there's also very important evolutionary change, evolutionary development that's incremental and that it's important for an organization to be able to achieve both, maybe in different ways to where you have the builders that are out there every day in all the product groups pushing the boundaries on their product. But then you also might have different groups that are saying we can do it altogether different and that there's a healthy relationship between the two. If so, how do you get that? Because you're talking about two distinct kind of subcultures within your organization in terms of the way people think, and how do you find the healthiest and most productive way for those folks to come together? One might be pushing the next version of a deep learning model, the next transformer iteratively, and the other one might be out there looking at a whole different algorithmic approach to go do something that might replace a whole bunch of previous work. How do you get that, that coexistence together where all types can work?
You're really asking me the hardest questions. I love it.
I'm having a great conversation because you.
Know this stuff and therefore I'm learning a lot. I just. You guys keep chatting and I'm. I'll keep taking notes.
Daniel told me ahead of time, he's like, you're going to love this conversation. And I am.
They say that compliments don't need to be true, just believe. So thanks for the compliment. But I would say, like, once again, I will try to get closer to a solution because it will be. It wouldn't be right to say that I've figured it out, right? Innovation at its core is failing and iterating fast. And I'm still failing a lot, and I'm proud of it. But I would say there's a couple of things which you can do that make things easier, go in the right direction. So first of all, think about, like, minimizing the costs of change. What does impede people to make meaningful changes, right? How hard is it to do something? If you make something extremely easy, then people will do it, right? So I remember like, even like 10, 15 years ago, like, where companies said, like, what they're optimizing for when they're onboarding a developer is we want the developer to be able to put code into staging on the first day after two to four hours, right? And I think that, for instance, is the right spirit. Not think of innovation first, but think of what is keeping me from just doing things that we would call innovation. It's a moving target. Innovation will always be like an aspirational, like unicorn, far away, beautiful. But, you know, it becomes mundane and easy if we're just ushering in, like the simple things, right? Like, innovation will always be out there, but we can make it easier and more approachable for more people. I think that's definitely one part of doing it. And then the second part is even if you have, let's say, a team denominated as the innovation team, make it sure that there is constant communication and collaboration between Any team that works with new technologies or new methodologies, never make it like a walled garden and just be proud of, oh, we have this one team that can do this stuff. Make it a goal and a measurable metric, whether it's an OKR or whatever you want. Right. But make it a metric for them and an incentive to collaborate and foster collaboration and innovation among the entire organization, not just in one place.
So, Lukas, I'd love to put some of sort of structure around this conversation. Like, let's say this, like you and your innovation lab or your innovation group. Someone comes to you and says, hey, I have this idea. What if we could, you know, what if we could use this AI model to predict this? Then this would happen and it would be a wonderful world. Where do you go from there? How do you think about the first steps in de risking a solution like this and exploring feasibility and these other things that you've talked about? What structure do you put around that and how do you take your first steps?
All right, thanks for the question. Because that's hard, right? So for me, in my role, there have always been like two issues that, well, were complicated or hard to solve. So first of all, what am I working on? You know, there's this group, they get to use like this cool, like machine learning algorithms or whatnot, right? And you never know exactly what they're doing. And you know, from an outsider's perspective, I'm trying to put myself into the position of someone who'd be working with me. Right. And the other question is, you don't really know, like, when will something happen? Right? So what we did in our approach is, so first of all, we make it very clear what we're working on, right? It's desirability, viability, feasibility, and stakeholder management in a sense. Like, have we incorporated like analysis of incentive systems, the organizational parts that need to fall into place and so forth. So, so we have four categories in which we apply ourselves. And then the next part is that we talk clearly about like the scope and, you know, innovation often can be anything from, hey, I have this idea and I want to make sure that we align on the idea, the concept, and we share it like a common language and we understand the concept and that's maybe something you can do in a couple of hours all the way to we have a co innovation customer who's running on a POC or mvp and we have a multi, like month kind of engagement in trying to pushing it over to product delivery. Right? So we call this like phases, right? We Have a couple of phases. We go from identify, discover, explore to pre built. And we have those four risk categories. So what we did is. And it's too bad I can't show it with, you know, like with a slider or something.
With your voice?
Yeah, only with my voice. Yeah. But we have like four categories in terms of like phases and four categories in times of risks. It's almost like a matrix, right? We create this matrix, we call it definition of DOM matrix. And then what we do is we go to the owner of a product, whoever has the need, right, who has a problem that we're trying to solve. And the first thing is we're not taking it away. We're not saying like, oh, we're here to solve your problems, but stay aside. We're doing innovation now, right? No, we're saying like, hey, we're in this together, so this is what you want to achieve. We understand the pain point now. We will assess in terms of the risk, let's say desirability, feasibility, viability, or stakeholder management, how far your idea has already gotten, right? And it's think of it as a scorecard. Literally think of it like four by four scorecard. And you start ticking off like how far you got. When the beginning is like, we understand what we're talking about and the end is pushing it into production and making it part of the product. And then what we're doing is we're saying, you as the owner, you tell us where you want to de risk next. And we often make this conversation a broader conversation with more stakeholders or the senior leadership of the organization. We say, look, if we invest in feasibility, the next thing in terms of an outcome we would create is this. Or let's say viability. And we then ask the stakeholders and the owners, like, we're just helping, do you want us to try to de risk viability or do you want us to try and de risk desirability? And we then upfront tell them, next thing we would do is let's think about it, let's say viability in ROI calculation or define like a first user study or these kind of things. So it's almost like an a la carte menu of de risking activities based on a scorecard. And we say like, hey, this is how far we believe you are. And you tell us where you need help in de risking this project and that's how we do it. And then every time we get feedback from our customers or we do our analysis, we come back, we add or subtract from the Scorecard. We say like, this is the new state of the project now. What is the next thing we want to do? Why are we doing this? A, because we want everyone to have skin in the game and include them. B, we want to be methodical and very clear how we. We work and see, we don't want to be away for months and take something away and then say, ha, we have solved it. But rather we want to have really quick iteration cycles where everyone is excited that we de risk it, or if we find out there's a big impediment that makes it unfeasible or impossible that we communicated not at the end and everyone is, oh, what happened? But they are part of the journey, so we're making them part of the journey. We're very clear in like what phase and what risk we're working on and we're doing it together and not isolated from the rest of the team.
So as you're engaging the groups, whether it be kind of in more of in the innovation team or whether the innovation team is going out to the product group and kind of helping them innovate and helping them make some of those leaps that you're talking about there. And you're talking about the scorecard, which is a way of evaluating the benefit. It's evaluating what is the difference in outcomes from what you would have had versus what you have. How do you approach that? Because if you're not able to show your executive teams the value of what you're doing and stuff, they'll move on, they'll get their next thing. How do you establish the value through the organization so that everyone understands what you're bringing to bear and how you're. You're basically leveling up the teams that you're engaging with. How do you go about doing that so that they see it?
Excellent question. I think there is a trap in which you can easily fall into, which is you can say, like, we have the smart kids, all type A personality, we have like this one innovation office, and now we're just solving all your problems problems. And I'm not sure how it is in other teams, but at least with us, work attracts more work. So no matter how well you do, you would always like, get more work than you can possibly manage. And you cannot guarantee success. If you can guarantee success, you're definitely not working in product discovery or innovation. Right. Because per definition, we're trying to do risky stuff and de risk. It's exactly those things that are hard to will into existence. So I would never stand in front of a senior leadership team and go, like, all right, hand it to me, I got it covered. The team will take care of it and everything will be perfect. What I'm trying to establish is fast feedback loops where everyone feels like they have equity and ownership. And we're very transparent and we make it clear what we're doing. And this means that not the team itself, let's say people who are in the innovation office necessarily get to decide, like, how do you want to approach it? What we do is we say like this. These are the outcomes that we want to create in terms of de risking. Let's say, for instance, like the senior leadership team wants to have like a first running prototype, okay. Then they will tell me in terms of the feasibility, I want you to go to the last stage or the penultimate stage, right? And I make them, like, invest in that. I tell them, like, look, this is what you tell us. We will take care of, like, how we do it. And as soon as we have like a prototype, we will show it to you. Right? So it's about this dance, this back and forth. Like, the leadership team and the owners of the ideas get to decide what they want to de risk. We get to decide, like, how we want to do it and how to best engage with the customers or people who have the pain point.
When you're doing that and you run into a situation where you realize that you're going to have to at some level, deliver bad news and you can, you know, you can position the, you can change the verbiage around, you can make it a positive spin. But at some point, and I say this because I'm, I'm actually currently, I'm indirectly soliciting your guidance on this because I'm in a situation where I have a team where a large team has been working on something for a year and it's not, I know it's not an optimal outcome. And as I sit here talking to you right now, there's a major workshop going on that's going to take them in the wrong direction. And I'm actually mostly sitting out of the workshop because of that, because I'll be so frustrated when you can see that a team is going down an unproductive path. And based on your experience, you know that they need to take some turns on this, they need to make some tweaks, some adjustments if they're going to be successful. How do you get them to do that? How do you turn them and say, you know what, there's a newer model, there's a newer. There's a newer way of doing this. There's a newer way of thinking about the problem. How do you go about?
Once again, tough question, but it's absolutely the right question. So, first of all, in my experience, the most painful conversations I had in terms of quote, unquote, failure is when the time between my last conversation and the bad news was long. Right. The closer you are connected, the more often you speak, the more you make the other, let's say the leadership team or the team who's owning the idea of the product part of the entire journey, the better the outcome is in terms of delivering bad news. I think the next thing that has helped me is to upfront before we invest into, let's say we want to de risk desirability and we want to push the next stage of de risking the desirability part. We're not trying to make it a guessing game where we feel like, hey, we are so invested in this idea, we like it so much, and no matter what, we'll try to spin it and make it positive. So what we're trying to do is with the stakeholders or people who, working with us, collaboratively, defined the win and fail criteria upfront and try to make it as quantifiable as possible. That's tricky. That's not easy. But I think having this conversation at the very beginning relieves the pain if it doesn't work out. And then, yeah, we fail. But very often failure doesn't mean that a project gets shut down. What it means is that we know, like, what part of the project we shouldn't do. Right? And so more often than anything, I feel like we're just resetting and we're going a little bit back, but we're going back with more knowledge and better tools. And if we do this quickly, then nobody feels left out or just feels like, hey, it's just, you know, a big sink of resources. And I don't know, maybe in six months, something bad or something good comes out of it. That's what I want to optimize. I cannot optimize for always getting the right answer, but it can optimize for the people having a good experience, not only the users, but also the people with whom we're collaborating.
So I want to go back to something you were talking about. You mentioned some things about involving stakeholders, how you manage sort of. You don't want to just kind of go off, create a product and like, drop it on people.
Right.
And I definitely resonate with that. But also, like the technical People that I work with. So maybe it's like the data scientists or the software engineer is a very smart person. Right. And so they understand, like, well, I can just go back and build this thing in like a couple of weeks and it can be done. Like, why do I have to go through this like back and forth process all the time? And I think it is, it is important, especially in terms of like AI and things that might be automated or predictive solutions. Like you can't just like build something and then come to the group that you've talked to and say, hey, we've automated like these seven things about how your job works. Like, go ahead and use this.
You're crushing me, Daniel, because I'm right on the verge of doing that.
Yeah. How do you motivate like technical people to have these like multidisciplinary discussions and make it something that like maybe even they look forward to or they see value out of like, rather than just like cranking out tickets on JIRA or you know, whatever.
I mean, there is no panacea, but there's definitely something that I would advocate for. What my experience has been so anecdotal, but it's what, what worked for me is the more I get the people who are trying to solve an issue to be connected or aligned or empathetic to the people who have the problem, the better that process works. And if you put your data scientist in the same room as a user in the beginning, they will go like, why am I here? I could be working on my code or whatever. And I think there's also a little bit of leadership that you set, like what is of value in your teams, in your organization. It needs to be clear. Those are not optional things. It's mandatory that you understand the problem and the people you're working for with. Right. And if you bring those people together, let's say roles, I think that creates more incentives to do the right thing and see the problem holistically. Because also, let's think about it from a completely different angle. As an organization, we are obsessed about efficiency, right? Is every person like churning away like enough tickets and working as fast, as hard as, as they can. And then what you create is at times silos and you have, you know, a smooth running operation in the machine learning team. And then you're, and I'm not trying to throw anyone under the bus, but then the sales team or the continuous delivery team or whatever, infrastructure team, they're just like, they're not, it's not working out. And then in the end, success is not having, like, one silo that performs perfectly. In the end, it's about the team, entire team winning. So think about it as like a relay race. We obsess about each runner, each silo, when we should obsess about, you know, like the baton that is moved. Right. We want the baton to go through the goal as fast and as quickly as possible. We don't want to have just one runner and then on the last, like, relay station, somebody's missing because, like, hey, we didn't feel that role. And in an ideal world, you would have people delivering value and they would just try to get, like, all the people that can solve the problem in a team. You wouldn't even, like, necessarily give them titles in a way. Oh, you are the data scientist. You would tell them you are knowledgeable in this domain, but ultimately you're just delivering value. That's what you're really trying to create and have that way of thinking. If you can establish that at an organization, I think it will make those things that you describe, which are prevalent and happening. Right. Better. I know it's maybe not an ideal solution, but I feel like those are the ways in which you can at least nudge and push an organization in the right direction.
So as we wrap up here, I actually want to get you to extend that just a little bit. And if you are, we've kind of talked through this, this dance of organizational adjustments and different personality types to try to achieve better outcomes in a variety of different ways. If you are committed at your organization and you can get the people around you to be committed, and you're starting to do all these things and you're getting better and better. You have some failures, but you pick yourself up and you keep pushing forward. Could you talk a little bit in conclusion about kind of what does the organization look like a little farther out? Tell us a little bit about what this optimized organization that's embraced change and recognizes the different personalities. How is it operating? What's working? What's the differences in the relationships that you're experiencing in that work stream as they're, as they're pushing those different product lines forward, what does that look like in the future?
Once again, tough question. I think such an organization is very closely working together with their customers. They know exactly on what problems they're working and why. I think such an organization is inefficient in a sense that a lot of people are not specialized. So you bring knowledge and, like, how to work across multiple disciplines and also I believe that such an organization focuses more about customer journeys and experiences and less on individual, like, problems. Right. I think they would see it more holistically. I think such an organization would mean that. And here's maybe one of my pet peeves. The managerial part of the organization and the leadership sees themselves less as people who decide how processes or how the organization runs, and more trying to engineer the best setup. Right. And to help. I'm not sure if that's too abstract, but if you think of it that way, way, like, whatever industry you're in, let's make it simple. Because we talked about flying cars, and I still think I should get a flying car soon. And I'm kind of, like, sad that we don't have them. Like, think of. Think of your organization in a way where you're saying, like, who is creating something valuable for the product, the car. Right. And anybody who's not directly connected to doing that, why are they not helping? And can we get rid of the role? And rather, can we make sure that people who are maybe not directly working in a car, they don't create boundaries and behavioral constraints, but rather they try to help the organization to do better? I think it's both. Every employee needs to see themselves more of an agent of change and attuned to customer problems. And every person who's working on the organization doesn't see it as fix, but rather, like, how can we create more value together? Yeah, it's a tough problem, but I'm really positive about the future in the sense that I believe that because of the market forces and the change in the world, that there is some pressure to innovate in the right direction there. So I'm very excited and I really, really love my job and I love working in that space because there's one last question, maybe that frames it at the end that I always liked. And it's, we have the empathy of cavemen, the institution of the Middle Ages, and the technology of gods. And I, as an inner person who works in an innovation space, I'm really worried about our capacity to innovate technology. It's amazing what we can do. It's so fantastic. I really want us to all get better at empathy and at organizational structures and design. And those are the things where I think we will have the most upside if we incorporate meaningful change.
That's awesome. I'm inspired coming out of this. I've learned a lot because you both are like, luminaries that I want to just, like, soak up all of what you're saying around this, but yeah. Thank you so much for joining us, Lucas. It was a great conversation and hope to keep in touch and look forward to seeing what you do in the innovation space.
Thanks much for having me. It was a pleasure.
All right, that is Practical AI for this week. If this is your first time listening, subscribe now at PracticalAI FM or just search for Practical AI in your favorite podcast app. We're in there. And if you're a longtime listener, please do share the show with your friends. It is the best way you can help Practical AI succeed. Thanks again to Fastly for shipping out our shows super fast all around the world to break Master Cylinder for the Beats. And to you for listening. We appreciate you. That's all for this week. We'll talk to you again next time.
Sa.
More from LARRUZ


Ep 882: Rogue AI Agents: Why Breakouts are Happening More and How Companies Should Prepare (Replay)


Ep 881: Faster AI Agents, Fewer Human Coworkers: The Overly Productive Future of Managing Agents? (Replay)


Ep 879: New: OpenAI Presence. Has The AI Customer Service Takeover Finally Arrived? (Replay)




