.png)
Beyond Delivery
Beyond Delivery is a podcast about the changing world of outsourcing and technology services. As companies face increasing pressure to innovate faster, leaders in IT, product, and operations must rethink how they scale, collaborate, and deliver value. Each episode features conversations with industry experts and business leaders who experience these transformations first-hand, unpacking how outsourcing, nearshoring, delivery models, and AI adoption can become powerful catalysts for sustainable growth.
Beyond Delivery
AI-first software delivery: why tools alone are not enough
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Adopting AI in software development can make teams faster. But adding AI tools to existing delivery processes does not automatically make software development more efficient, predictable or secure.
In this episode Sebastian speaks with Sebastian Andruszczak, co-creator of the AI-First Teams framework, about what needs to change when organisations move from traditional software delivery towards an AI-driven development lifecycle.
They discuss why AI adoption often goes wrong when companies start with tools instead of processes, how unclear accountability and unmanaged risk can undermine the benefits of AI, and why producing more code faster can simply move the bottleneck into review, testing and validation.
The conversation also explores how developers’ roles change when AI becomes an active part of delivery, why feedback loops can improve quality and consistency over time, and how well-designed governance can actually enable speed rather than slow teams down. Sebastian also explains why organisations need clear goals and meaningful metrics if they want to understand whether AI is creating real business value.
Key topics:
• Why AI adoption should start with processes, not tools
• How the shift from SDLC to AI-DLC changes software delivery
• Why faster code generation can create new review and testing bottlenecks
• How governance, accountability and feedback loops support safer AI adoption
• What organisations should measure to understand whether AI is creating real value
⏱ Timestamps:
00:00 – Introduction
02:08 – Why AI adoption goes wrong: decisions, risk and delivery
14:13 – What changes when teams move from SDLC to AI-DLC
23:54 – Why governance can actually make AI delivery faster
33:24 – How to measure the impact of AI in software development
40:19 – Structure, documentation and data: the key takeaways
🎙 Guest:
Sebastian Andruszczak
Co-creator of the AI-First Teams framework
LinkedIn: https://www.linkedin.com/in/sebastianandruszczak/
🎙Host:
Sebastian Dzieniak
LinkedIn: https://www.linkedin.com/in/sebastian-dzieniak/
Ready to see how prepared your software delivery model is for AI?
Book an AI-DLC Readiness Assessment with Holisticon Connect to identify gaps in your processes, governance and delivery model, and understand what needs to change before scaling AI adoption.
Introduction
SPEAKER_02Very good keyword array is structure, documentation and the data. The one thing that is truly doable two things actually is to start measuring something and then to be able to compare. Are you sure that your current processes are allowing you to validate and check and test so much more code?
SPEAKER_00Welcome to Beyond Delivery by Holistic and Connect where tech meets true business value. Today's episode uh is about the adoption of AI. There is a version of AI adoption that looks like progress, but it isn't. Teams buy the tools, run some experiments, maybe ship faster for a sprint or two, and then the cracks appear. Reviews are skipped, nobody knows who's accountable for the AI-generated code, the governance isn't afterthought. Today's guest has been thinking hard about what it actually takes to get this right. Not just the tooling, but the whole operation model. Sebastian Andreusak co-created the AI First Teams framework, and we're going to get into the why the way most teams work today simply isn't built for what AI requires. Sebastian, welcome to be on delivery.
SPEAKER_02Thank you so much. Uh I'm happy to be here.
SPEAKER_00Yeah, so let's uh fire off with the first question. It's an exciting uh topic right now. Obviously, AI is everywhere and is being adopted. And today I wanted to look at specifically at the uh software development process and how the adoption looks there and what the challenges are. So you've seen a lot of adoption at close. And what does doing it wrong actually look like in a team that thinks is doing it right, in your opinion?
SPEAKER_02Yeah,
Why AI adoption goes wrong: decisions, risk and delivery
SPEAKER_02it's uh excellent question. Thank you so much uh for asking this. So I would sum it up to three areas. So those are decisions, uh risk, and the delivery model. So when I'm looking on how AI is adopted in organizations, the organizations that are kind of early in this transformation journey, they are not having uh the decisions governed in the right way. Like, long story short, uh adoption is not governed by the organization. It means that the company is buying licenses, some people in some teams are using NAI, but ultimately there is no explicitly accountable person and process for potential outcomes. So, you know, when everything is right, then it's great. But if something will happen, if the quality is not right, if there is some data leakage, if there are some security reasons, if if there are some security concerns, or if there are some some other issues, uh there is basically basically no one to blame. And obviously it's not about blaming by its own, but still, if you want to manage the organization or development process seriously, you also should uh always should have the person that is responsible. So uh when AI is adopted in a wrong way, when it's starting from tooling, not from the processes, then it's just a mess on the decision level and the accountability level. So this is the first layer. Then on the other hand, it's about how risk is managed. So uh we're talking a lot about this shadow AI. So, you know, it's when, as I mentioned before, it's when people are starting using tools, and they are sometimes having great results of this, but uh then uh it's not organizational-wide decision about risk management, who is taking risk, uh, what AI could produce, what AI shouldn't produce, never, when the human in the loop should be involved. So we have the decisions, who is taking the decision, is it informed decision, is it team decision, compound-wide decision? It is about the risk. So if is it uh documented at all, if is it managed and how partially on a team level, for example, or if it's uh really suited to how AI works. So you have this risk-based human in the loop. So some stuff could be done much quicker because human interview supervision is not required, just as an example, for internal products that are not strategic and core and are not touching financial and/or sensitive and/or personal data. And on the other hand, uh you have very well documented um areas where person human is involved each time because of those concerns, for example. And the third layer is just a deliverer, how the delivery process looks like. So uh some companies, I don't want to say lots of companies, but yeah, really, lots of companies are uh introducing a tool to support existing traditional uh traditionally crafted processes, and it is just wrong because processes are changing, the ways of work are changing. So, you know, within the traditional software development process, people are creating the concept and executing the concept. Uh, within AI delivery lifecycle, people should create the concept, AI should execute the concept. So if you take this into account, stages of the software development process are working differently. You have different gates that are allowing you to move between various stages, you have uh different accents put on, for example, validation of the quality, verification, testing, and so on and so forth. So the I I suppose those are the biggest issues. And if you are trying to uh enforce new tools to introduce a new tool to old processes, it just creates a mess. And uh it's it's wrong.
SPEAKER_00If you can think of like the worst case scenario, is there a way you can think of the consequences of implementing the AI in the wrong way in the software developing process?
SPEAKER_02It's an interesting question as well. Um first two things that are coming to my mind are actually about leaking important company data to the public, to the model, to the company that is owning model, basically. Another similar pattern is about uh leaking sensitive data of people, sometimes about you know their health history, so very, very, very sensitive data. And then another kind of consequence is just when you give AI too much autonomy and you are working with AI on something big, and at some point you're just realizing that it is not there anymore that the database has been dropped, for example, and it's uh not very not always very reversible, and it could cost you lots of time, money, and frustration. So those are the the first consequences that are uh coming to my mind. But also, and maybe this is uh also something important to say the one of the biggest consequences is that you actually miss the point of adopting. So, you know, organizations are adopting AI to get uh higher efficiency, lower costs, better quality, predictability, consistency of the code. And uh, if you do it wrong, you can just miss the point totally. So you are ending up with huge investment, some maybe cultural changes, even, and then at the end of the year or some period, the token cost, right? Token costs as well, yeah, of course. Uh especially now when the token costs are increasing, but then you're ending up with uh you know a pessimistic evaluation of the project, and you don't want to do it anymore, or your stakeholders uh don't want to do it anymore, they don't see the value. So that yeah, this is the risk.
SPEAKER_00Yeah, I remember we we talked about it previously. Uh, of course, for the listeners, we we do work together, uh, myself and Sebastian quite closely. And um, yeah, you did mention that some of the organizations they produce the code with AI, which is faster, and it seems like on the top layer, it seems faster, but then eventually the senior members of the development team they have to review the code, which is essentially you know, additional effort, time, cost on the company, um company side. So, yeah, I think that's also important to mention, right?
SPEAKER_02Yeah, I think it's a very good observation. Uh, that uh sometimes when we implement NAI, you know, we are all learning, I I could say. Like we obviously we have the framework, we are working based on this framework with our clients. Uh, they are really interested about it, they really want to see the value, it's great. But at the end of the day, everything in the technology is evolving, and I would say I risk that it's evolving exponentially right now, uh, especially in this area. So, uh, yeah, there is a lot of parts moving at the uh same time. But then what I'm trying to say is that yeah, sometimes it looks like you are getting some uh better efficiency on the speed level, you are producing more code quicker, it's great, but it is true what what you mentioned that uh on the other hand, the time to review and validate this code could take lots of time and effort, and then referring to what I mentioned before, it is especially true when you are operating within the old processes, because you know when you are shifting this weight from executing code, lighting, you know, uh writing letters and numbers on your screen as a developer, for example, and you are shifting this weight to creating the concept, it's it's great, but then are you sure that your current processes are allowing you to validate and check and test so much more code? So, yeah, this is very real risk. But being on this topic, recently I had a meeting with client, and it was super interesting and refreshing for me because uh you know the the pattern that you have uh presented, uh creating faster and then some issues with uh valid like quality validation, it is true. But recently I had a meeting with client uh when clients said that the biggest improvement is actually on a quality level, that everything is slower, but quality is better. So it was super cool. I I I was super uh honestly, I was super excited that some organizations, on the other hand, it's not the optimal scenario, but some organizations are still valuing quality so much that even with AI they they are having some improvements, but it's not the fit, it's not the time, it's just quality. So, here in this case, to be a little more uh accurate, we are talking about quality as a consistency of outcomes and the details, uh, for example, for product requirements, how how great those requirements are actually described. So, yeah, uh I I think you are you are totally right.
SPEAKER_00Yeah, thanks for mentioning that because uh I think you know this definitely refreshing because everyone would expect AI to extremely speed up the the production of code and and features, etc. But at the end, the quality is is what really matters to the clients, to the companies. Yeah, so it is great to hear that it's not being lost in the process, and coming back to the process, because you did mention like the process change, and I was wondering because um I think we are moving more towards the AI DLC, so AI-driven development lifecycle, so it's a big shift, in my opinion. So, from your perspective, like can you like walk us through a little bit what actually changes in the day-to-day compared to the traditional sprints?
What changes when teams move from SDLC to AI-DLC
SPEAKER_02It's it's it's very uh case by case, I would say. It will obviously look differently if you take a company that is having, I don't know, 100 employees and 30 people in a delivery team. And if you have a company that is employing 100,000 employees across 70 countries, and they are having hundreds of people in the delivery team. But to give you just some kind of easy example, uh let's take into consideration discovery and ideation phase of software development process. So, this is especially in the product companies, when people are uh working on how the products should look like, what should be developed, how the how should it translate, what are the requirements, how they should translate eventually to the backlog. And at some point, you have people that are thinking, they are asking questions uh together, they are having having some brainstorm sessions, they are creating ideas, they are putting those ideas to backlog, and they are you know uh thinking about what is must have versus nice to have, what is important, crucial, what is not important, crucial, how to really prioritize it. And you know, to proceed with those tasks, they are relying on their own knowledge, uh on the knowledge of their colleagues, on the knowledge on the internet, on the market knowledge and expertise, and so on and so forth. So now imagine that some parts of this activities are just done automatically or are done much quicker and easier. And just to give you an example, when we are talking about referring to our own knowledge, uh one of let's say issues, it's it's probably not very significant, but some kind of issues, is the consistency. You are naming stuff differently than I am, and if we would have nine other people in the room, then at some point when we talk uh long enough, we are risking that we are not really really on the same page when we are talking about some concepts, some abstracts. And now just imagine that uh we are having the definitions of all those abstracts that we are using somewhere in some internal source, and we don't need to really think about it, we are just asking AI to take them into account. It's so much less words, it's so much more accuracy, and obviously, when you look from some specific perspective, it looks like uh not like it it's not very human. But on the other hand, you know, I I think it's I personally like the structures, and uh from from my perspective, it's it's something right that we could skip all this uh stuff of aligning upon the definitions and abstracts and and so on, we can just say, like, yeah, take this into account, take this into account, take this into account. So, this is you know about the the definitions, what we would like to achieve, just as an example, right? So, one layer, then another layer, market intelligence and external data sources. If we would like to come up with some idea about some hypothetical product today, at some point we would probably take a look on the competition, how it looks like, and uh what is their value proposition and so on. Now just imagine that you are saying, please take into account all existing competition for this potential product within our target markets and segments, and you you can further prompt, obviously. And on the other hand, it could be done automatically. Like you could have an agent that is checking up the market situation for you all the time. Every time something new will come up, it will be gathered, or most of the stuff will be gathered and analyzed, and it will create the further like input for your further stages. So this is how the change could taste like. So the next time you have more bigger, higher chance that this mistake won't happen in the first place. So you don't need to review same and same mistakes again and again, and this is again this is also some uh part of our answer for real market needs. We are having clients that are adopting an AI, and when we were talking with them, uh we have found that they are like yeah, that they are solving the same issues over and over uh within the cooperation with AI. So yeah, those are the changes. Uh, this is about changing the role from assistant to actor for AI, and changing the role from writing the code to creating the uh an excellent concepts in general.
SPEAKER_00We love that, and we touched like a lot of elements here the business aspect, like the day-to-day of the developers, and from my understanding is that the developers they no longer just like creating code, but they are the orchestrators in the whole process, and they oversee and they take the ownership and the responsibility for the code created. Am I right in thinking that?
SPEAKER_02Yeah, with uh one small adjustment, I would say. Yeah, obviously, people are uh taking responsibility and accountability, but in the perfect world scenario, it is really done on an organizational level, to be perfectly honest. So it's you know, you you have uh some hierarchy in organizations, and it's not really about the person that is using NAI is uh owning the results, it's about very informed strategic decision about responsibility, accountability, uh roles. Escalation path and it's done a little higher usually in a deliverer team and then it's just rolled out as a as a process. But yeah, you are right. What I'm trying to emphasize is that it's both people, people, and organization people. Like organizations are built by people, right? But but uh it's also very strategic company slash organization or organization focused decision and change.
SPEAKER_00And you also did mention which I think is a very exciting thing, is the learning loop. And I just want to emphasize it for the listeners. Like from the the AI uh first teams framework, it appears that whenever you produce code and you push it into production, before you do the AI actually or the uh the ML learns from the input from the developers. So the developers tell AI, like, okay, I had to fix that, and each time there is an iteration, it becomes better and better. So essentially, you will see like a graph of the efficiency and speed going upwards, right? Am I am I right in in thinking this way? I I think it's uh like the from my perspective personally, this is the most exciting thing about it. I know it's it's hard to implement and it takes time, but over time, once you implement it, it's just like it seems like an amazing thing to me. But correct me if I'm wrong.
Why governance can actually make AI delivery faster
SPEAKER_02Nah, you're right in general. I I think uh you know it's kind of philosophical stuff, really. It's about chasing uh 100% of accuracy and perfectness forever, each time you are closer to your goal, and yet it's never 100%. But uh the change that we are able to make when we structure the ways how we work is huge, it's huge enough to prove the concept, and this is something that I have referred to before. Like uh you asked what are the biggest risk issues or something like this, and I said, like, uh yeah, one of them is that you won't be able to achieve your goals. So, yeah, with those changes, uh and incremental changes in the quality and predictability, uh yeah, I I totally believe that uh we are able to achieve this goal, but yeah, uh again the philosophical part is that it's never going to be 100%, everything is moving constantly, but uh still from I'm sure 45 up to 75, still good, right?
SPEAKER_00That's right, 100%. And we're talking about speed, and there was another aspect that I want to connect here is the governance and the speed. And sometimes, you know, I obviously took a look uh at the framework, and there's a big aspect of the governance, and in first thought, you might think governance means slow, but from the AFRS things framework, it it appears that the governance can actually speed things up. Maybe you could tell a few words about that, like how do you see it? I'd love to you know share it with with with the listeners and yeah, uh hear your point of view on that.
SPEAKER_02It's kind of simple. The governance within this framework, when you adopt AI seriously, governance is actually the speed enabler because when you start implementing it's the biggest limitation. So, yeah, it sounds you know maybe a little contradictory, but the thing is when you get this ability to produce much, much, much, much, much quicker and much more than the just very naturally your next bottleneck is the governance. Who is going to check it up? Who is going to validate the quality? So then when you don't have governance process, governance stages adjusted in the right way, then it's just a bottleneck. You are doing a lot of here, but then here is you know this bottleneck. If you do the governance in the right way, you can then you can benefit from how much more you have produced in the first stage. So this is how you enable this uh this speed, basically. So you are just removing the bottleneck. Speed was already there, you have produced like lots of code, but you needed to govern it. And and and here maybe there are two components actually. The first is this you know always increasing uh quality, and on the other hand, is just a governance process by its own, so it will be done quicker, in in more structured, process-oriented, process-based way. Does it make sense?
SPEAKER_00Yeah, it does make sense, and the two key words that I'm thinking about is like safety and this sense of confidence and security. But if you if you have the right process in place and you have it governed properly, then you feel secure about releasing those features, you feel that they are safe that you can easily show it to clients. Yeah, I think this is my perspective, of course, but yeah, do you think that way as well?
SPEAKER_02Yeah, I think to be fair, there are two topics uh in this question. The first one is safety/slash security, and another one, if I remember right, is uh kind of consistency. For me, those are I'll call two different things. And if it comes to safety slash security, confidence. Yeah, thank you very much. If you take on uh if you look on uh safety and security, it's super super super important. Like everything is based on the data. If your data is not secure, it's not safe, it's a very huge issue, very huge risk. You never should do it. You you you always should owe your data and keep them secure, you know, regardless on how you define, like depending on how you define the security, but not relevant here. But uh what I'm what I would like to say is if your process architecture and um integration layer is done in the right way, then yeah, your data is basically secure. It's not like someone is forcing you to do something that you don't agree with, you just need to make an informed decision. But abilities to keep your stuff, information, data, architecture, everything basically secured, uh it's there. Then you have confidence, and for me, confidence, yeah, you know what is the confidence for me, confidence is uh related to situations when you can expect to have repeatable similar results in time, and quality is uh well enough to satisfy your needs and goals. So, yeah, obviously, if you have those feedback loops, if you have a well-structured process, you have less moving parts at the same time. So it creates higher predictability of what will be the outcome, and then I suppose this is something that gives us that that that gives you confidence, you know what to expect basically.
SPEAKER_00This is how trust in the in the code that is being produced. If someone is uh listening and yeah, obviously people are listening, but if they want to start uh right now, what does the first um step look like when transitioning to AR first? Could I be Anna? Yes, if please, you can be controversial as well, it's okay.
SPEAKER_02Nah, like I I just think that they should uh like get to contact you, and yeah, basically uh the the first step is to to have a conversation, basically. So like depending on how you look, what what is the you know starting point? Then I could tell you what is the next step. But uh basically the first thing is a decision. Do we want to uh adopt AI? Then you need to ask yourself, what are your goals? I I I have seen companies that are adopting an AI because it's hyped. If this is your goal, yeah, it's very easy to fulfill. I don't really think that it will have significant impact on your business. So I wouldn't advise it personally. So uh the first is is a decision, yeah, or or even assessment, like yeah, this is what we are doing right now. We would like to achieve this and this, we would like to do it quicker, we like to do it differently, we would like to do it with uh I'm not sure, less capacity, maybe you know, times are difficult. Then when you have uh your goals and then you're taking really informed informed decision, then it's probably about how to do it. And you know, obviously, AI First Teams framework by holistic on connect is a commercial offering. So, this is what we are helping our clients to do. Uh, I would strongly advise just to have a chat, uh talk, and uh see how could we really go this path together.
SPEAKER_00One thing that we uh didn't talk about, and I I think it's super important, and I think it's exciting as well, is the measuring part. Do you do you still have the capacity, energy to to talk about this a little bit? Of course, because I think it's amazing, like the fact that you can measure different metrics with the new approach. Maybe you can tell me like what metrics would you measure with the AI uh first uh AI DLC approach.
How to measure the impact of AI in software development
SPEAKER_00I think it's amazing.
SPEAKER_02It's super tricky question. It's a super tricky question because yeah, because uh you know, hmm, it reminds me like uh in general, this AI revolution, I would say, reminds me a lot of uh the situation when BI systems came to the market and has you know has started to be adopted because uh they were so cool and they helped with so many things, but then the outcome of potential of implementations were totally based, very connected to the data, to the basics, to the you know, fundaments, I'd say, and it's very similar here. So, you are asking what would be the metrics? Um, to be fair, I would ask, so yeah, what are you measuring today? So for for but but to be a little more specific, you know, the holy grail would be to be able to measure probably business and environmental impact versus cost, and be able to compare it uh you know, quarter by quarter, let's say, like compare it in time, look on this in time, basically. The thing is that uh lots of companies are not measuring the efficiency of their software development process at all right now. You know, there has been some concepts like line for code or story points, but uh looking from depending on the perspective that you take, some of them could look obsolete, some of them could look uh not relevant, and it's really difficult sometimes to get closer to this uh connection between what you are doing and what is the value, because value is not always coming instantly. When you take uh into consideration product companies, it's usually not really like you know, you are developing a new feature, and in a day one, week one, month month one, you can tell like yeah, it was the value that we were aiming for. Nah, it's it's flowing. You will get you you will have some early adopters, some people that will pay more or start paying because of this feature, you will have people that will adopt further. So, and and again, the definition of impact is is difficult. Uh now I'm talking about the money, but you know, for pharmaceutical companies, impact is uh people number of people that has incurred, or people that has uh felt uh increase in their life quality score, let's let's say so it's it's it's complex, it's totally case by case, but uh I think that the one thing that is truly doable, two things actually, is the first one to agree upon something, to start measuring something, and then to be able to compare. And then you could obviously you know reiterate the KPIs uh or measures that you are tracking, but it's better to have something at least, some baseline that you could, you know, take into account and start thinking really.
SPEAKER_00I love the answer, and it's uh very visionary. And obviously, knowing your your role and and your position, it makes complete sense. And I did prepare, I read the AI first teams uh framework, and going down a little one level below, I saw that there was a mention of measuring um the amount of code that was uh the amount of processes that were automated and the amount of override, as far as I remember correctly. And that got me a little bit excited to be honest. And yeah, I just wanted to mention that that it's completely different metrics switching from SDLC to AI DLC. Is that like how much have you uh automated, how much did you have to tell AI that this was wrong? Um, yeah, and that actually these are the metrics that kind of take you to that level up in terms of speed of producing the code in the future. Yeah, that was my understanding of the documents.
SPEAKER_02Yeah, like it is true, but on the other hand, you know, uh just how to say it, looking on various metrics and having this uh analysis process turned on constantly. This is what you do in business. Basically, this is how we learn the reality from the data. So, usually, uh, yeah, of course, it's something important and interesting to be able to say, like, yeah, this is how much we have automated. At the end of the day, is it very close to the impact? Could be, could not be. It's some kind of supporting metric, it's important, but it's kind of some kind of supportive metric, and then you could probably invent like seven different supportive metrics and some you know ultimate metrics. Probably they would change it's kind of probable scenario, but it allows you to think and base your decision on data, and I think this is the value by itself, it's super important. It it's yeah, so I I'm not sure if I haven't gone too visionary with this answer, but yeah, this is how I feel about the data and about measurement and KPI. So, you know, it could be something totally different today and in two weeks. The thing is that you are having some idea, you are having some thought model in your mind that you are willing to follow and check it up and validate and and so on and so forth. This is how we learn.
SPEAKER_00Yeah, I I completely agree. Uh, business, what I learned so far. It's important to the data to make the conscious decisions and also being able to reflect back. This is what we could improve, or this went good. So I think that's the whole idea behind the data, and we did take quite some time today for this episode.
SPEAKER_02Yeah, I like to talk.
SPEAKER_00Yes, and me too. And this is a very uh interesting conversation. Let's think about some kind of uh a summary, like key takeaways for for the listeners.
Structure, documentation and data: the key takeaways
SPEAKER_02Uh, I I would say the change is imminent. It's uh for for me, for the most of the cases, you know. I I mentioned before that first you set up the goals, then you are taking a decision. To be fair, I think uh it's not about the decision anymore. Uh the decision is made globally, everyone is going there. It's super important to have some plan to understand what you would like to achieve, obviously. But uh at the end of the road, you probably for the most of the cases can't just say, nah, I won't implement AI. It's everywhere, it's like the air. You can't just not use it out of the picture. So this is the first thing. The change is imminent, then it totally depends on you what you will do with this, how you will proceed. You could end up with total disaster, and still looking optimistically, you could learn out from it, you could structure stuff more and avoid some traps and pitfalls. I would strongly advise every time. So, yeah, for me, very huge keyword uh really is structure, documentation and the data. Everything starts there. If you are good with this, the rest, you know, you will you will have to uh uh work on your culture and change management. We are still humans, we are still working with people, but uh it's going to be fun, and you will get nice results, so double fun ready.
SPEAKER_00Nice. Um, yeah, what I wanted to add is the like the mindset shit. You did mention the the culture and change management, and I think that's what it is. The end, we are all humans using this technology, and the way we think about it, it's crucial. Um obviously changed our lives significantly in the way we work and the way we think about it to change as well, and then the processes will follow. Um, Sebastian, thank you so much for giving such elaborate view, and um yeah, I actually really enjoyed the conversation. Uh so thanks so much for joining today.
SPEAKER_01It was super cool. Thank you so much, Sebastian. Have a perfect day and see you soon.
SPEAKER_00You too. Thank you. Thanks for listening. What's one thing from the episode that made you think? Let us know in the comments and subscribe to the show. It really helps more people discover it. See you next time.