Why Founders and CEOs Delay Asking for Help When an IT Project Goes Wrong – Wojtek Kniżewski, Pragmatic Talks

**Wiktor Żołnowski:** Welcome to the next episode of Pragmatic Talks. Today we’ll try to answer the question why so many founders, decision makers, CEOs, and managers are delaying the decision of asking for help when their project is not going as it should. 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 Kniżewski. Wojtek is usually the first person our clients are meeting when they are approaching us, when they are filling out the form on our website and scheduling the meeting to ask for help or consultation. So Wojtek is the best person to talk about the reasons why clients are not making the decision faster than they may be supposed to do, and why they are usually coming to us when it’s really bad. Because of that, the cost of helping them, the cost of fixing the problem is usually higher than it could be. So Wojtek, I have a first question: who is usually approaching us, and what are the problems they are coming with?

**Wojtek Kniżewski:** There are two profiles of people who contact us to save their project. It’s CEOs or founders of companies, and product managers or interim product managers/consultants. These are two distinct profiles. These two roles are completely different within organizations. They have different goals, different issues, different objections, different fears. One of them is the client that has their own IT department, their own IT team working on their product. Those clients usually have some problems with delivery, some issues with their internal team. The second type of clients are founders of a startup, or CEOs or other people working for companies where software is not their core business. Those companies are hiring external software vendors to support them with their projects, and those vendors, believe me or not, from time to time are failing as well.

**Wiktor:** Wojtek, can you share what are the differences between those two groups of clients?

**Wojtek:** Usually, the client who has an internal team – there’s much more politics involved within the organization. When you have an internal team, 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. You need to find out as a CEO by yourself most of the facts, which is incredibly difficult considering you may not have direct technical experience.

When it comes to companies who use external vendors, usually the realization comes a bit faster. You see the money being burned a bit sooner. It’s easier to spot when someone is sending one big invoice every month and you are paying it, 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 all sending you small invoices, or who you’re just paying salaries.

Plus, when you’re at the office, you have an internal team, you see them working, clicking the keyboards, getting coffee, having meetings. And you expect that things are getting delivered. But when you don’t have the technical expertise, you don’t necessarily identify the issues. With the external vendor it’s a bit easier because either it’s your own money being burned that you see at the end of the month in the invoice, or it’s the money of your own investors, in which case they put the pressure on you.

**Wiktor:** With the external vendors, are these decisions usually made faster than with the internal team?

**Wojtek:** Usually you get dissatisfied with an external vendor sooner and make a decision a bit sooner, but it’s a more difficult decision to quit the external vendor. When you have an internal team, it is easier to ask for help – not necessarily to replace the internal team, because that’s probably not going to happen, but to ask for help from an external partner such as Pragmatic Coders to enter the team and help them simply build a better product. When it’s an external vendor, the story’s a bit different. There are legal issues. There’s the question of how to make the external vendor accountable for the mistakes. There’s the issue of transferring the project from one external vendor to the other, which is incredibly difficult – sometimes even without the external vendor knowing that the project is being transferred, because it’s still an ongoing project. You spot it faster, but the decision to quit one vendor in favor of another is a bit more difficult.

**Wiktor:** When clients invite us to help with their internal team, they usually expect us to help those people who are on board – not to fire them, not to replace them. Our team is working alongside the internal team, and our people are showing them how to work more efficiently in their context. Of course, sometimes our clients, when they see the difference in how our people are working and how their developers are working, make the decision that they hired the wrong people at the beginning, and that’s the reason for the problems they have. And then sometimes they even ask us to help them with the recruitment of new staff.

But in terms of replacing another vendor and situations when we take over the projects from other vendors, they are a different story. Sometimes when clients approach us, there are situations where the vendor who is working for this client is not aware that there is someone else who is already reviewing the code, making an audit, and trying to take over the project from this vendor.

**Wojtek:** This is very often the case. In that case, the transfer of the project is incredibly difficult. What we do at the beginning is we start from an audit of the code and audit of the internal processes of the external vendor. We see the documentation, if it exists. Very often it does not exist, so we need to do a bit of reverse engineering to find out what’s wrong. We check the code, we do an audit, then we propose certain recommendations. It could happen that the code itself is all right. It just requires small fixes, nothing dramatic. Then there are just issues with how the team works, or the priorities, or how the cooperation between the client and the vendor looks like. So it’s not always that we recommend replacing the vendor. There are situations where we just point out: “Okay, dear client, here are a few things that you may try before you’d make a decision to replace the current vendor, because it might not be worth it for you to do this.”

We are always trying to be honest and not to push the clients to always buy our services. This approach requires transparency on our end and trust from the client, and integrity on our end. Very often we do not recommend changing the vendor, just changing some processes and the way the vendor works, because it is simply good for the client. Even if it works against our bank account in the end. Would we like to be 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. By having our integrity, we sometimes recommend not doing so, but simply recommending changes of the process.

**Wiktor:** And to add to this: especially when we see that the problem is not necessarily on the vendor side. Because sometimes it’s on the client side, and even if we took over the project where the problem is not with the vendor, there’s a huge chance that we would fail as well. Recommending only project takeover in such a situation is just shooting ourselves in the feet, because we’ll end up in the same place as the current vendor in a couple of months. 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.” This could be an issue as well, and we’re going to help to identify that too.

**Wiktor:** When those people are coming to us, they are usually CEOs, founders, often some kind of interim product managers, consultants, product consultants who are hired full-time to help this company solve their issues. Not so often those are CTOs. Sometimes they are CTOs, but CTOs who are not engaged in the project that we are talking about. Usually, those are projects that are already outsourced somewhere else, and the CTO is somewhere in the organization, working on the core business or other stuff, but the outsourced project is not going so well, so the CTO is also involved. Who else is in this kind of decision-making committee?

**Wojtek:** It could be the board, the management board, investors. It depends on the company. Definitely founder, CEO, sometimes CTO, interim project manager who just came to the company, hired to fix the problem. That was the simple task: fix our problem. They come and see the chaos inside.

**Wiktor:** Sometimes financial people. People who care about the finances, because they see how much money is spent on a project and that it’s not bringing any value. They are also people who raise their hands and say that something is wrong here and we need to do something about it.

**Wiktor:** What are usually the complaints that clients have? What are their first words when they come to us?

**Wojtek:** The biggest issues, no matter if it’s an external or internal team: the team is not delivering on time, the team is promising things to be delivered, but it doesn’t happen. Or it seems that the team is working fine, the features are being delivered, but in the end, the end users, clients, and partners are complaining about the system, the application itself. So the person who comes to us doesn’t know what’s real anymore. There is misinformation in between the lines in the process. I would say this is the main complaint.

Another one could be that part of the team says one thing, the other part says something else. Could be as well that the team focuses on tech too much, but doesn’t focus on the business purpose. Especially the external vendor – they’re doing a lot of stuff which is not necessarily needed. They don’t even engage in conversations with the end users, with the clients of the company. They only focus on the code itself.

**Wiktor:** On the other hand, I remember a situation where we recommended to a client to change something before they change vendor: the client was blocking communication with the users, with end clients. And that was, in our opinion, the main issue. The client simply fixed that and allowed the vendor to contact the users. It turned out that the vendor was very professional, and when they started talking to the users, they found the real business problems that were there to solve, and they helped the client build a much better product than what was actually ordered at the beginning.

**Wojtek:** That’s correct. But it does happen that the management of the company thinks that the tech department should sit in a basement and not come up to see the sunlight. That’s one of the biggest mistakes in building products.

**Wiktor:** Is the perspective of interim product managers and consultants different from people who are inside the organization, like CEOs or owners? Are they asking different questions or complaining about different things?

**Wojtek:** Yes. They were hired for a purpose, so some issues were already identified by the management. The issue was: something is wrong, something doesn’t work. We spent too much money on it. The system doesn’t work. Our users complain. So we hire an interim CPO, interim tech consultant, however we call that role. This interim manager already knows that something is wrong, but doesn’t know yet what is wrong. It’s quite often the case that this person comes to the team, checks everything, and there is either very bad documentation or lacking documentation. The code maybe seems fine, maybe not, or this person has difficulties identifying issues with the code. So the person sees only chaos. Things are supposed to work, but they don’t, and they don’t know what to do. Then we’re being called for help. We begin from the audit usually. We check what’s wrong. We do interviews with the managers within the organization of the client. We find the issues, and we try slowly to solve the chaos, first by identifying issues.

**Wiktor:** We call those people interim managers, interim product managers, interim tech leads, but very often those people are not called that way. In most situations it’s just a person who is a good old friend from school or from university, a friend of the CEO or COO or one of the founders, who is asking for help. “Okay, you are this tech guy. Please come help us, 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 usually external people who are coming to the organization to diagnose their issues and help to find the solution.

**Wojtek:** Imagine you’re that person. You come to a company. You’ve been asked by your friend for help within a semi-large organization. You come in and you see pure chaos. The documentation is lacking. It’s very bad quality. Users are complaining. Clients are calling the hotline with issues. How can you solve this issue without a specialized team behind your back who’s going to quickly, within week two, start identifying the issues? I personally believe this is an impossible task without another external tech team.

**Wiktor:** Or at least it takes a lot of time – hiring people, then setting up the process, training those people, building everything from scratch. It’s time-consuming, and very often the clients who come to us do not have time at all. They already spent a lot of time dealing with the problem as it is.

**Wiktor:** Why are those founders, managers, and decision-makers asking for help so late?

**Wojtek:** Usually because they’re afraid. There are many fears in the background, but they’re afraid even of touching these issues. Somehow when you don’t touch a topic, sometimes it somehow works. They believe that it will sort itself out.

**Wiktor:** Or better not touch it. We’re fine. We’re having revenue. Maybe it will be better.

**Wojtek:** Exactly. Then there is the fear of mistake, a personal one. “Well, I burnt either my own money, or worst case, my investors’ money. Let’s say I’ve burnt a couple of million on something that doesn’t work.”

**Wiktor:** So it’s actually the fear of admitting that I made a mistake.

**Wojtek:** Exactly. Another one: lack of knowledge. The internal team does not inform the CEO that something is wrong. It’s just the clients and users calling him constantly, saying, “It doesn’t work.” Then they call the company with complaints. But the internal team claims everything is fine. The CEO does not have the expertise to find out what’s going on. So this topic is simply not touched. And lack of time, lack of focus. You focus on the business, not on the tech side. It’s not the core of your activities.

**Wiktor:** Do you think there are other reasons why clients are delaying the decision of asking for help? Maybe there are differences between clients who have their own internal team and clients who are using vendors.

**Wojtek:** Sometimes personal relations. If it’s a mid-sized company, you’re related to the people with whom you work, you have some relationships built. It is mentally difficult to say to them that what they built is not all right, it’s low quality, that they need to change their processes, or that you’re going to replace them with some external team. That’s why often we come and we do not offer a replacement. We rather help this internal team to change their processes and to work correctly.

**Wiktor:** What’s really important here is that most people have a problem distinguishing that when someone says something is done wrong or something is bad quality, it only means that this thing is bad quality. It doesn’t mean that the people who actually built it are wrong. And so many people are taking it very personally. And so many people who are sharing this kind of feedback are afraid that those people will take it personally, and very often the way they are sharing it is personal, so that usually causes the problem.

That’s why when we come on board and we do the audit or the research on what’s wrong, we are never pointing fingers in the direction of anyone. We provide a report that says that the process is wrong, or the quality assurance process is wrong, or the documentation is missing or done in a wrong way, or the product management is done poorly. It doesn’t mean that the product manager is a bad person. Usually there is no product manager, and that’s the reason for many problems.

**Wiktor:** What are the reasons why clients are delaying the decision of changing vendors for so long?

**Wojtek:** Admitting that possibly you have burned a lot of money as a manager of the company on an external team that did not deliver – this is, from my experience, one of the most frequent issues. Another one: the external team very often keeps promising to the CEO that something will be fixed. It gives this false hope that in a month, maybe in two months, the guys finally will fix it. Or they changed something within their organization, in how they work. They hired some senior developer or a different manager, and from this point everything will be fine. But very often it’s not fine. So it’s very difficult to take the decision to simply cut off an external vendor from activities, because there are multiple things involved – the legal issues, you need to break the contract basically.

**Wiktor:** Especially if the contract is written in a way that prevents you from changing the vendor, which is pretty hard to do. Whenever you’re signing a contract, you need to be able to change the vendor if anything goes wrong. What sometimes happens 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 a vendor for the software project – consider hiring their own developers, their own IT department to take over this project. In this situation, we always do the proper transfer of knowledge, transfer of everything – every key, every documentation, everything that is needed.

**Wojtek:** Very often it’s a good decision. Once the product is ready, it’s mature, it’s fixed after the past issues, then maybe it’s actually a great decision to renew activities internally.

**Wiktor:** Or if you didn’t have an internal team, to simply build your internal team. Because relying on an external vendor maybe is not always the best case longer term.

**Wojtek:** If I were making the decision, I would rather get external vendor experts to help me fix the issues, and then after a year or whatever the amount of time, maybe I would hire an internal team.

**Wiktor:** We already know that clients usually delay this decision. One of the reasons we haven’t mentioned yet is that so often they simply do not know or are not sure that something is going wrong. They feel that something is going wrong, but there is need for something really big to explode to push them to the decision that they need to find help. Do you have any ideas how to spot the first signals that something is going wrong?

**Wojtek:** 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 way more than they deliver. And there’s no accountability within the team. There is no proper retrospective within the team. The team does not reflect back on the past time and cannot properly identify their own problems or mistakes – because obviously every team makes mistakes. It is completely normal.

**Wiktor:** And fix them not only internally but also do not repeat them, and also have a plan to improve for the future. I recently spotted in one team that they failed to deliver the scope of the iteration, but they did reflect on what they did wrong, and they already had a plan to improve and how to deliver even more in the next iteration. Then they succeeded with this plan. In such a case, one single failure when the team is not delivering everything they planned for a two-week sprint is not necessarily a problem, especially when it’s not happening sprint after sprint. When it happens just from time to time, and when you see that in the next sprints 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 with.

**Wojtek:** I remember some cases when a member of the internal team goes up to management and says that something is wrong. This is the best indicator, but you need an honest team member, not necessarily a senior one.

**Wiktor:** Just listen to your team. You’re paying a lot of money to these people. Software developers are earning a lot of money. It doesn’t matter if you hire them internally or hire some vendors. You should ask those people about the quality, about what they think, about the issues they see. You should ask them very often, and you should truly consider everything they say about it. When someone is saying that something is wrong – and those are software developers who often are pretty keen to share their opinions – then most probably they are right, or at least they are sharing with you something that you should explore more and dig into. That’s another symptom.

We could spend the whole hour discussing what are the symptoms. We will record another episode on how to spot the problem early so you will not spend a lot of money on fixing it when it’s already too late. If you would like to learn more, or check with your team if everything is done right, we are going to share with you our two checklists that we are using internally. One is the technical health checklist, which we use to monitor technical excellence in our teams. There are a bunch of questions that you and your team should answer yes or no. Depending on the result, you will see how technically good your product is. 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 value, not just deliver next features, next lines of code. You can share these checklists with other decision-makers just to show them how good or how bad your current team is, or you can simply work on the checklist with your team or with your vendor to improve the quality of your work.

**Wojtek:** If you have this tiny itch behind your head that something may not be as good as 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.

**Wiktor:** When clients come to us, what are their concerns and fears? What would they like to avoid?

**Wojtek:** The biggest fear is definitely transferring a project from one external vendor to another. During the transfer, the most important is to pay attention that the current company’s business activities are not obstructed in any way. This is very difficult to lead the transfer project from our perspective as Pragmatic Coders in a way that we do not interfere at all with business activities. It requires a very senior team who’s doing everything aside, but does not interfere with the current code base. They just check it aside, do the audit aside, and offer, first of all, quick wins. So the first quick changes within the project itself in order to fix it and then simply bring it to operations, and identify more long-term goals as well.

That’s one fear. Another one is the legal issues, and checking simply what is wrong with the code itself. We handle that by an audit of experts, but we’re also happy to contact the current vendor and discuss with them what the issues were. Maybe the issue wasn’t the vendor himself. Maybe the issue was something else, maybe lack of communication with the end client. We don’t know that. I would say these are the main fears.

If they ask whether we as another partner are a good partner, if they have chosen wisely, we usually respond with a couple of arguments. One is we describe our processes, how we work, how we help our clients. We present similar cases of when we helped a client with similar issues. We can even put you in contact with our previous clients. They’re usually happy to talk to you, and they will describe similar issues they had and how we helped to solve them.

We’re usually hesitant about a big revolution. We try not to flip the table. We try to come with precise, small changes within the project to help you run your business.

**Wiktor:** That’s both for the situation when we take over the project from another vendor and when we help internal teams. What I think is also important: I recall a few last calls with clients who already have their own department. They are looking for help, and when they ask us, “Okay, so how should we trust you? How should we know that you have the knowledge that you are talking about?” – what I’m usually referring them to is: check our other resources like our blog, our webinars, our podcasts. Check the conferences that our people are speaking at. All that we are sharing is our experience, our knowledge, the way we work, our case studies, stories from our cooperations with clients. Of course, not all of them with the names of the clients, because not every story is something that the clients want to be shared. But we share the stories, we share how we’re helping our clients, how we are developing our organization, how we are developing our people, our teams, just to be the best at taking over projects or stepping in and helping organizations to build better products in a better way.

This is what we recently specialized in at Pragmatic Coders. We calculated that it’s more than 60% of our income from the last five years – projects that we actually stepped in and helped others to fix, to improve, or to take over from other vendors that failed. So I think that’s the best proof that we know what we are talking about, that we know what we are doing. Don’t be afraid of making this first step. If you have some gut feeling that something is not going all right, just contact an external partner such as Pragmatic Coders, and we’re going to help you to see if everything is fine, even without further steps.

**Wiktor:** From what I learned, when I spoke with CEOs or other decision-makers facing this kind of decision, what they usually talked about was that they don’t have anyone around who they could talk to. They have bad feelings about something going wrong, but there is no one they could talk to. So regardless of whether it would be Pragmatic Coders – if you schedule a meeting with Wojtek, or if you reach me out on LinkedIn, for example, or if you reach out to any other company that is specializing in this kind of thing – those are usually the right people to talk to about your problems. And, as I said before, we are never pushing our clients to always buy our services. When we see that the problem could be solved another way, we are always trying to help the client to solve the problem, not necessarily sell our services. We believe that if other people around our clients face similar problems, and they ask the 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 at the end of the day we will win something. We believe in this kind of karma: when we help our clients, it will come back to us.

**Wojtek:** I believe it’s a purely business decision from our end. 85 to 90% of our clients come from recommendations?

**Wiktor:** Around 80% of our clients are coming from recommendations. It’s a pretty good result.

I hope that we answered the question why so many decision-makers are delaying the decision, and I hope that after this conversation you will make this kind of decision faster. Because when you are delaying this decision, the cost of fixing the problem will be higher. The other thing is the money that you will lose on building something that is built in the wrong way. So you are actually losing money twice: once on building something that is not right, and secondly, on fixing it and spending way more money on fixing something which is too late, than something that could be addressed early. So do not delay this kind of decision if you can. If you need any help, if you need any advice, you can always contact us.

And of course, the two checklists that I mentioned before – you will find them in this episode description. Click the link, fill them out alone or with your team, and see the results. You can send the checklists to us as well, and we can discuss them together, and we can figure out what you could improve in your team, or if you need external help from our team. And 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 fixes within your internal or external team that can lead to a big success.

Thank you very much for watching this episode. Don’t forget to subscribe to our channel. If you have any questions, do not hesitate to contact us. I hope to see you in the next episodes.