Why Companies Ask for Help Too Late When Software Projects Go Wrong?

Speaker A: Welcome. Um, in the next episode of Pragmatic Talks, today we'll try to answer the question why so many founders, decision makers, CEOs, managers, are delaying the decision of asking for help when their project is not going as it should be. In this podcast, we talk to founders and experts to share real stories and lessons from building and scaling digital products and companies. Pragmatic Talks is for those who want to understand how digital products are really built and grown. No fluff, no buzzwords, just honest conversations. For today's discussion, I invited Wojtek Kniesevsky. Wojtek is usually the first person our clients are meeting m when they are approaching us, when they are filling out the form on our website and scheduling the meeting, uh, to ask for help for consultation. So Wojtek is the best person to talk about the, the reasons why clients are not making uh, decision faster ah, than they may be supposed to do, why they are usually coming to us when it's really bad. And uh, because of that, the cost of helping them, the cost of fixing the problem is uh, usually higher than it could be. So Foley, I have a first question. Uh, who is usually approaching us and uh, what are the problems they are coming with?

Speaker B: There's two profiles of people who contact us to save their project. It's CEOs of companies or founders of companies, and product managers or interim product managers, consultants. It's two distinct profiles. These two roles are completely different within organizations. They have different goals, different issues, different objections, different fears.

Speaker A: What one of them is uh, the client that uh, have their own IT department, their own IT team that's working on their product. And uh, those clients usually have some problems with delivery. They have some issues with their internal team. And the second type of the clients are clients who are, let's say founders or who are uh, founders of a startup or they are like a CEOs or, or other people who are working for a company where the software is not their core business. So usually those kind of companies are uh, hiring external software, uh, vendors to support them to work on their projects. And those vendors, believe me or not from time to time are failing as well. Maybe Vojta, you can share like what are the differences or if there are any differences between those two groups of clients.

Speaker B: Yeah, usually uh, the client who's having internal team, it's much more politics involved within the organization. I mean uh, um, it's a completely different story. So usually when you have an internal team as a founder or CEO of a company, they're afraid to say that something is wrong. They inform you or do not inform you at all, or inform you a bit too late about that. You need to find out as a CEO by yourself, uh, most of the facts, which is incredibly difficult considering you may not have the uh, direct technical experience. Uh, if it comes to m, the companies who use external vendors, um, usually the realization comes a bit faster. I believe the issue is you uh, see the money being burned a bit sooner than internally.

Speaker A: It's easier to spot when someone is sending one big invoice every month and you are paying that and you see that there is no progress or the progress is way slower than you expected for this amount of money. Instead of paying a bunch of people who are uh, all of them sending you small invoices or you're just paying them salaries.

Speaker B: Plus when you're at the office you have an internal team. You see them working, clicking the keyboards, you see them doing stuff, busy getting coffee, you know, having a meetings and you expect that things are getting delivered. But well once you, when you don't have the technical expertise, not necessarily you identify the issues with the external vendor it's a bit easier because either it's your own money being burned that you see uh, at the end of the month the invoice either it's money of your own investors, well then they put the pressure on you. So uh, it's a bit different uh

Speaker A: story with the external vendors. This kind of decision are usually made faster than uh, in case of the internal team.

Speaker B: Usually you get dissatisfied with external vendors sooner. Usually uh make a decision a bit sooner. But it's more difficult decision uh to quit the external vendor. Let's say when you have internal team it is easier to ask for help, uh, not necessarily replace the internal team because that's probably not going to happen, but ask for help for external partner, let's say such as pragmatic coders to come to enter the team and help them to uh, simply build better product. When it's an external vendor, uh story is a bit different. There's legal issues of course. So how to make the external vendor accountable for the mistakes. There is obviously the issue of transferring the project from one external vendor to the other, which is incredibly difficult. Uh, sometimes even without the external vendor obviously knowing that the project is being transferred because it's still an ongoing project, you spot it faster. But the decision to quit the one vendor on behalf of another, it's a bit more difficult.

Speaker A: Different consequences here. For example, when clients invite us to help with your internal team, uh, they usually like expecting us to Help those people who are on board, like do not fire them, do not replace uh, them. It's greater that our team is working aside of uh, the internal team and our people are simply showing them how to work more efficiently in their context, in their environment, instead of just, you know, being there to replace those people. Of course that sometimes happen. Like, sometimes uh, like we are not enforcing that or we are not uh, asking our clients to fire their own departments. But sometimes our clients, when they see the difference how our people are working, how their developers are working, sometimes they are making decision that okay, they hired wrong people at the beginning and that's the reason of the problems that they have. And then sometimes they are even asking us to help them with the recruitment of new staff. But in terms of another vendor and uh, replacing another vendors and situations when we take over the projects from other vendors, there are like a different story. Sometimes even as you said, uh, when client approach us, there are situations that the vendor who is working for this client is not aware that there is someone else who is already reviewing the code, making some audit and you know, trying to take over the project from, from, from this, this vendor. There are various situations that could happen in this.

Speaker B: Very often in that case, well the transfer of the project is incredibly difficult. Um, what we do at the beginning is definitely we start from audit of the code and audit of the internal processes as well of external vendor. So we see the documentation. If it exists. Very often it does not exist. So we need to do a bit of reverse engineering to finding out what's wrong with that. We do check the code, we do audit, uh, then we propose certain recommendations what to do. It could happen that the code itself is all right, it just requires small fixes, nothing that dramatic. Then there's just the issues uh, with how the team works, the external vendor, or how the priorities or how the

Speaker A: cooperation between the client and the vendor looks like. So it's not always that we always recommend to replace the vendor. Yeah, there are situations where, when we just point out that okay, do client, here are a few things that you may try before you make a decision to replace the current vendor. Because it might not be worth for you to do this. Uh, and we are always trying to be honest and not uh, to push the clients to always uh, buy our services and buy our software development.

Speaker B: Yeah, uh, this type of approach requires definitely transparency on our end and trust from the client and a, uh, small integrity on our end. Meaning that very often we do not uh, recommend changing the vendor, just changing some processes and the way how vendor works because it is simply good for the client. So sometimes, well, even if it works against our bank account in the end because. Well, would we like to be uh, the one who builds the product for a client? Yes. Would we like to replace the external vendor that currently builds the application? Obviously, but not necessarily. It's going to be the best decision for the client himself. So we, by having uh, our integrity, we sometimes recommend not doing so. We recommend simply changes of the process.

Speaker A: And just to add to this, like, especially when we see that the problem is not necessary on the vendor side. Exactly. Because it's sometimes on the client side. And even if we took over the project layer where the problem is not with a vendor, there's a huge chance that we would fail as well as the other vendors. Uh, so in such situation, recommending only Project Takeover is just shooting ourselves in the field because we'll end up in the same place as the current vendor in a couple of months.

Speaker B: Yeah, Think about it. Maybe it's you. Maybe you change your mind every two weeks. Maybe you change your scope every two weeks. Maybe every time you talk to your end client or your partners, you come back to the tech team and say, hey, listen, you need to change everything now. So this could be an issue as well. We're going to help to identify that as well.

Speaker A: Yeah. So uh, we have those two types of clients. So what like when those people are coming to us, those are as you said, usually CEOs, founders, uh, often some kind of interim product managers, consultants. Product consultants who are hired full time to help this company to solve their issues. Not, uh, so often those are CTOs as far as I remember. Sometimes those are CTOs, sometimes. But CTOs who are not uh, involved engaged into the project that we are talking about. Usually those are some projects that are uh, already outsourced somewhere else. And the CTO is somewhere in the organization, is working on some core business or some other stuff. But the project that was outsourced, ah, is not going so well. So the CTO is also involved. Uh, who else is in this kind of programming? This like decision making committee could be

Speaker B: the board, the management board, uh, investors, uh, it depends on the company. Definitely. Founder, CEO, um, sometimes cto, interim project manager as well who just came to the company, uh, was hired to fix the problem. That was a simple task, fix our problem coming and sees that chaos inside supplies financial guys.

Speaker A: Yeah, like people who are taking care about the finance because they see like m. How much money is spent on some project and that it's not bringing any value. So usually they are also people who are rising their hands and telling that something is wrong here and we need to do something about it.

Speaker B: Correct.

Speaker A: Okay. So those people are coming to us. You are the first person who usually they are meeting you, your Conrad. And what usually are the complaints that they have like what they are complaining about, what are their first words when they came to us, uh, or what you are asking them about.

Speaker B: The biggest issues they have is if it's. Well it doesn't matter if it's external or internal. Team that simply team is not delivering uh, on time and the team is promising things to be delivered but it doesn't happen. Or it seems that the team is working fine, seems that the features are being delivered. But in the end the end users, the clients, the partners are complaining about the system, the application itself. So usually the person who comes to us doesn't know what's real anymore. There is some misinformation between the lines in a process uh, that exists there. I would say this is the main complaint. Another one uh, could be a spell that the part of uh, the team says one thing, the other part says something else. Could be a spell that um, the team focuses on tech too much but doesn't especially the external vendor but doesn't focus on the business purpose very often. I've seen it.

Speaker A: So they are doing like a lot of stuff which is not necessarily needed.

Speaker B: Exactly. So they do not even m. Do not engage in the conversations with the end users, with the clients uh, uh, of a company. They only focus on the code itself.

Speaker A: From the other hand I remember the situation, especially those when we recommended to clients to change something before they change vendor. Was the situation that the client was blocking this communication with the users with end clients. And that was in our opinion main issue. And I remember the situation with the client. Simply fix that and allow the vendor to contact the users. And it occurs that the vendor was very uh, professional and uh, actually when they started talking to the users they found out the real business problems that was there to solve and they helped the clients to actually build much better product than they actually uh, ordered at the beginning.

Speaker B: That's correct. Well it does happen that the management of the company thinks that the tech department should sit in a basement and do not uh, come up and see the sunlight. But that's one of the biggest mistakes right. In building products.

Speaker A: You mentioned that there are also some kind of interim product managers, interim consultants who are coming. Is their perspective different from people who are inside of the organization who are CEOs or owners, uh, are they asking another question or complaining about other things?

Speaker B: Uh yes, they were hired for a purpose, so already some issues were identified by the management. So the issue was well something is wrong, something doesn't work, we spent too much money on it. Uh, the system doesn't work, our users complain. So we hire interim cpo, interim tech consultant, however we call that role.

Speaker A: Mhm.

Speaker B: And this interim manager already knows that something is wrong, but doesn't know yet what is wrong. And it's quite an often case that simply that person comes to the team, checks everything. Uh, there is either very bad documentation or lacking documentation. The code maybe seems fine, maybe not. Or this person has difficulties, uh, uh, in identifying issues with the code. So the person sees only chaos, thinks supposed to work, but they don't and doesn't know what to do. So then we're being called for help. We begin from the audit. Usually we check what's wrong. We do some interviews as well, uh, with the managers within the organization as well with a client. We find out the issues and we try slowly to solve the chaos. Uh, first by identifying issues.

Speaker A: Of course, of course we are calling those people interim managers, interim product managers, interim tech leads or whatever. But very often those people are not called that way. Like I can imagine that in most of the situation it's just a person who is like a good old friend from school, from some study, from university, uh, of the friend of CTO or sorry a friend of CEO or CEO or one of the founders who just asking for help, the old friends. And they're asking hey, oh you are this tech guy, please come help us with analyze what's wrong with my IT department because it is not our core business but we see that they're doing something wrong. So it's not necessarily called that way. But you I use there's external people who are coming to the organization to diagnose their uh, issues and help to find the solution. Uh, so this is how does it work.

Speaker B: Imagine you're that person. You come to a company, let's say you've been asked by your friend for help within them semi large organization, you come in and you see pure chaos. So documentation is lacking, it's very bad quality. Uh, users are complaining, clients are calling the hotline with the issues. And how can you solve this issue without a specialized team behind your back who's going to quickly, within week two maybe start to identify uh, the issues. I personally believe this is impossible task without another external tech team or at

Speaker A: least it takes A lot of time like hiring people, uh, then setting up the process, training those people in those processes and uh, building everything from scratch. Again, it's time consuming and very often the clients who came to us, they do not have time at all. They already spend a lot of time on dealing with the problem as it is. Which actually brings me to my next uh, question and the question that I asked at the very beginning. Why those founders, managers, uh, decision makers are asking for help so late?

Speaker B: Usually because they're afraid and oh, there's many fears uh, in the background, but they're afraid of uh, they're afraid of even touching these uh, issues. Well somehow when you don't touch a topic, sometimes it somehow works. Right.

Speaker A: So they believe that it will sort it out itself.

Speaker B: Exactly, exactly. Or better not touch it. We're fine, we're having a revenue, maybe

Speaker A: it will be better.

Speaker B: Exactly. Then there was a fear of mistake, personal one. Well, I burned either my own money, either, worst case my investor's money. Let's say I've burned a couple of million on um, something that doesn't work.

Speaker A: So it's actually the fear of admitting that I made.

Speaker B: Exactly. Yeah, exactly. Ah, so that's one, uh, another one lack m of knowledge. So the internal team does not inform the CEO that something is wrong. It's just the clients and users are calling him constantly and saying oh, it doesn't work and they call the company with complaints. But internal team claims everything is fine. The CEO does not have the expertise to find out uh, what's going on. So this topic is simply not touched, uh, and well, lack of time, lack of focus. Well you focus on the business, not on the tech side. It's not the core of your activities.

Speaker A: Do you think there are other reasons why clients are delaying the decision of uh, asking for help? Maybe especially in, or maybe there are some differences between the clients who have their own uh, internal team or the clients uh, who are using some vendors

Speaker B: for software development, sometimes personal relations. If it's a mid sized company, well you're related to the people with whom you work. You have some relationships built. It is mentally difficult to say to them sometimes that uh, what they built is not all right, it's low quality, that they need to change their processes, how to build it, or that you're going to replace them with some external team. But that's why often we come and we do not offer replacement. We rather help this team, the internal team, to change their processes and to work correctly.

Speaker A: And what is really important here is that uh, Most of the people, I would say they have a problem with distinguishing that when someone is telling that something uh, is done wrong or something is bad quality or something like this, it only means that this is a bad quality or this is done wrong. It doesn't mean that the people who actually build uh, it are wrong. And so many people are taking it very personal. And also, uh, so many people who are sharing this kind of feedback are afraid that those people will take it personal. And very often the way they are sharing it is personal. So uh, that usually caused the problem. So that when you lose the team

Speaker B: and feelings of your feedback.

Speaker A: Yeah. So that's why when we usually came on board and we do like the audit or we do the research, what's wrong? We are never pointing the fingers, uh, in the direction of anyone, but we usually are providing a report that says that the process is wrong or that the uh, quality assurance process is wrong or the documentation is missing or is done in a wrong way or uh, you know, like the product management is done poorly. It doesn't mean that product manager is a bad person or something like this. Usually there is no product manager and that's the reason for many problems. Okay, so that's in the case when there is a team that is in house. Uh, what about the vendors and uh, what are the reasons why clients uh, are delaying uh, the decision of changing the vendors for so long?

Speaker B: I mentioned before, um, it's admitting that possibly you have burned a lot of money, uh, as a manager of the company for external team that did not deliver. And this is from my experience, one of the uh, most frequent issue. Another could be as well, the external team very often keeps promising to the CEO that something will be fixed, it will be fixed. It gives this false hope to a person that in a month, maybe in two months, the guys finally will fix it. Uh, oh, they changed something within their organization, they changed something in how they work. They hired maybe some senior developer or different manager. And right now from this point everything will be fine. But very often it's not fine. So uh, it's very difficult to take this decision to simply cut off an external vendor from activities because there's multiple things involved. I suppose the legal issues that uh, you need to break the contract basically, or.

Speaker A: Yes, especially if the contract is written in a way that is actually preventing you from changing the vendor or which is pretty hard to change the vendor, uh, because of the contract. So whenever you're signing contract, you need to be able to change the vendor if you, if anything goes Wrong. What sometimes happen is that with the growth of the product, with the growth of the organization, and often with our help, our clients are deciding to instead of using vendor for this software project, they are considering hiring their own developers, their own IT department to take over this project. And in this situation we always do the proper transfer of knowledge, transfer of uh, everything like every keys, every documentation and everything.

Speaker B: And very often it's a good decision. Uh, once m the product or project is ready, it's mature, uh, it's fixed, let's say after the past issues, maybe it's actually a great decision to again renew um, activities internally or if you didn't have internal team to simply build your internal tier. Because while relying on external vendor, maybe it's not always uh, the best case. Uh, exactly. If I would be making this decision, I would rather get external vendor expert to help me to fix the issues. And then after a year or whatever the amount of time maybe I would hire internal team.

Speaker A: We already know that the clients usually delay this decision. I think the, one of the reasons that we haven't mentioned yet is that uh, so often they simply do not know or they are not sure that something is going wrong. Like they, they feel that something is going wrong or, but actually there's need to something really big to explode to push them to decision that they need to find for health or fight for another solution. So do you have any ideas how to spot the first signals that uh, something is going wrong and that you need to uh, take care of the project or start searching for help?

Speaker B: Yeah, the most obvious is when your client calls you and says something doesn't work. That's the most obvious one. But it's already too late. The team promises uh, way more than they deliver. There's no accountability within a team as well. So um, there is no proper retrospective within a team as well. So the team does not reflect back on, let's say the pastime and cannot properly identify their own problems or uh, mistakes that they did. Because obviously every team does mistakes that

Speaker A: is completely normal and fix them not only but also I do not repeat them and also have a plan to improve for the future. Like this is something that is really important. I recently spotted in one team that they failed to deliver the scope of the iteration. Uh, but they did reflect on what they did wrong and they already had a plan what to improve and how to deliver even more in the next duration and then they succeed with this plan. So in such cases, one single failure. Once upon a time when the team is not Delivering everything what they planned for a two weeks long sprint is not necessarily a problem, uh, especially when it's not happening one after another sprint. But uh, when it's happening just from time to time and when you see that the next sprints or they learn from the mistakes and they improve all the time, it actually means that they are most probably one of the top teams that you can work uh, on the market, not necessarily the team, uh, that you don't want to work on the market.

Speaker B: Yeah, correct. A member of small cases when a member of internal team goes up to the management and then says that something is wrong as well, it did happen a couple of times. Uh, and well, it could be an. Well this is the best indicator. But you need uh, one honest team member, not necessarily senior one.

Speaker A: Mhm.

Speaker B: So it does happen as well.

Speaker A: Yeah. So just listen to your team. I uh, think I've uh, told it in one podcast before that uh, you are paying a lot of, a lot of money to those people. Like software developers. Software engineers are earning a lot of money. It doesn't matter if you hire them internally or hire some vendors. Uh, you should ask those people uh, about the quality, about what do they think, about the issues that they see. You should ask them very often and you should truly consider everything, what they are saying about it. When someone is saying that something is wrong, and those are software developers that often are pretty keen to share their opinions, then most of the right, or at least they are sharing with you something that you should explore more and dig it and see if uh, there is an issue behind what they are saying. So that's another symptom. Of course we could spend the whole hour on discussing what are the symptoms. And I think that we will record another episode on how to spot the problem, uh, early. So you will not spend a lot of money on fixing it when it's already too late. But uh, if you are interested in that topic and if you would like to uh, learn more or actually check with your team if everything is uh, done right, if everything is going well, or maybe there are some issues that you can spot early and maybe focus on those issues before it will be too late, uh, we are going to share with you our two checklists that we are using internally. One is Technical Health Checklist, which is the checklist that we are used to actually monitor technical excellence in our teams. There are like a bunch of questions that you with your team should answer yes or no. Depending on the result. You will see how technically good is your product. And the second Checklist is the product health checklist which is more about the product management processes in your team that will allow you to check if your process is made to actually deliver the value, not just deliver next features, next line uh, of codes. So we will share those two checklists. You can share it with your another decision makers just to show them how good or how bad is your current team and what you should do. Or you can simply work on the checklist with your team or with your vendor to improve the quality of your work.

Speaker B: If you have this tiny itch behind your head that something may not be as good as uh, it could be, you can go to our website pragmaticcoders.com you can find my contact details there and just reach out. I'll be happy to grab a virtual coffee.

Speaker A: Getting back to the clients who are coming to us, uh, maybe that will be used later. Hopefully not. But when the clients came to us, what are their concerns and fears like what they would like to avoid.

Speaker B: The biggest fear is definitely transferring a project uh if it's from one external vendor to another during the transfer. Uh the most important is to pay attention to that the current company activities, business activities are not obstructed in any way uh by the transfer. This is very difficult actually to lead the transfer project let's say from our perspective as uh pragmatic coders in a way that we do not interfere at all with business activities. It requires a um, very senior team who's doing everything aside but does uh, not interfere with the current code base, just checks it aside, does the audit uh aside. And ASPO offers first of all quick wins. So the first quick uh changes within the project itself in order to fix it and well simply bring it to operations. Identify more long term goals as well. So this is one fear, another one. We mentioned that uh previously the legal issues and well checking simply what is wrong with the code itself. We handle that uh again by an audit of experts. But as well we're happy to uh contact the current vendor uh and simply discuss it with them. What were the issues? Maybe the issue wasn't uh the vendor uh himself. Maybe the issue was something else. Maybe lack of communication uh with the end client. We don't know that. I would say this is the uh main fears uh so as well if we as another partner uh are this time uh, if we're a good partner, if they have chose wisely m pragmatic others to help them to that we usually respond with couple of arguments. One is definitely uh we describe our processes how we work how we help our clients. We present the very similar cases of when we help the client with very similar issues. We can even contact you with our previous clients. They're usually happy to talk to you and they will describe similar issues they had and how we help to solve it. We're usually hesitant from a big revolution. We try not to flip the table. We try to come with m precise, small, uh, and precise changes within the project to help you run your business.

Speaker A: Yeah. And that's uh, both for the uh, situation when we take over the project from another vendor and when we help internal teams. But what I think is also important, I just recall a few last calls that I have with the clients who already have their own IT department. They're looking for help. Like when they are asking us, like, okay, so how should we trust you? How should we know that you have the knowledge that you are talking about? And what I'm usually referring them to is that check our other resources like our blog or our webinars, our uh, podcast, like this one or another podcast that we are running. Uh, check the conferences that our people are speaking at. All what we are sharing is our experience, our knowledge, uh, the way we work, our case studies, like stories from our corporations, uh, with clients. Of course, not all of them with the names of the clients because not every story, uh, is something that the clients want to be shared. But, uh, we share the stories we share. How we helping our clients, how we are developing our organization, how we are developing our people, our teams just to be the best in uh, taking over, uh, the projects or in uh, stepping in and helping organization to build better products, uh, in a better way. Uh, and this is what we actually recently specialized in, Pragmatic colors. And this is something that we recently calculated that it's more than 60% of our income from the last five years. That was the project that we actually step in and helped others to uh, to fix, to improve or just take over from other vendors that failed. So I think that's the best proof, uh, that uh, we know what we are talking about and we know what we are doing.

Speaker B: Don't be afraid of making this first step. Uh, if you have some gut feeling that something is not going all right, just contact external partner such as Pragmatic Coders and we're going to help you to m, see if everything is fine even without the further steps.

Speaker A: Yeah, and I think this is very important, uh, from what I learned when I spoke with CEOs or other decision makers who were facing this kind of Decision. What they usually talk about was that they do not have anyone around who they talk to and they have bad feelings about that something is going wrong, but there is no one they could talk to. So regardless if it will be pragmatic goes if you schedule the meeting with Wojtek or if uh, you will reach me out, uh, at LinkedIn, for example, uh, or if you reach out any other company that is specializing in this kind of things, those are usually the right people to talk about your problems. And uh, as I said before, we are never pushing our clients to actually always buy our services when we see that the problem could be solved other ways. We are always trying to help the client to solve the problem, not necessarily sell our services because we believe that if other people around our clients will face similar problems and they are asked the client or the potential client, how did you make it? How did you help it? This client will refer us as the point of contact. And maybe in the second case there will be no other option than just taking over the project and that will actually end at the end of the day, uh, win something. And uh, we believe in this kind of karma, m that when we'll have our clients, it will come back to us.

Speaker B: No, I believe it's a purely, uh, business decision from our end. What is it, 85, 90% of our clients come from recommendations.

Speaker A: Yeah, maybe not as this. Around 80% of our clients are coming from recommendations. So here you go.

Speaker B: It's a pretty good result.

Speaker A: Yeah. Uh, so, yeah, I think that I hope that we answered the question why so many decision, uh, makers are delaying their decision. And I hope, hope that after this conversation you will make this kind of decision faster. Because when you are delaying this kind of decision, the cost of fixing the problem will be higher. This is one thing. Other thing is the money that you will lose on building something that is built in a wrong way. This is another thing. So you are actually losing money twice. Once on um, building something that is not right, and secondly on um, fixing it and spending way more money on things, something which is too late, uh, than something that could be addressed early. So do not delay this kind of decision. If you can, as we mentioned, if you need any help, if you need any advice, you can always contact us. Uh, and of course the two checklists that I mentioned before, uh, you will find them in this episode description, uh, click the link, fill them out alone or with your team and uh, see the results. Uh, and of course you can send this checklist to us as well. And uh, we can discuss it together and we can figure out what could you improve in your team. Or if, uh, you need an external help from our team and aspo.

Speaker B: Don't be afraid that we're going to cause some revolution and chaos. This is not the goal. We're going to come and start slowly finding out the issues that you might have. It could be very small, uh, fixes within your internal or external team that can lead to a big success.

Speaker A: Okay? So thank you very much for watching this episode. Don't forget to subscribe to our channel. If you have any questions, don't hesitate to contact us. I hope to see you in the next episodes.