Why do software projects still struggle even after hiring good engineers?

Speaker A: Why do you think so many software projects struggle even when the companies hire good engineers? What are your thoughts on that one?

Speaker B: Number one is clarity. Um, if the engineers or the software developers don't have clarity, your engineers will build whatever you're asking for. But without clarity or vision, you have to set the standard sometime. To Osmond, the leaders take a pause and take a step back.

Speaker A: Would it be fair to say that the execution failures are actually decision failures?

Speaker B: Failures is a way to learn things, you know, but not constant failure. Not being unorganized.

Speaker A: What kind of pressure CEOs usually underestimate when they are starting a software project?

Speaker B: The pressure is bottleneck.

Speaker A: Welcome to the very first podcast of value Props. My name is Usman and I'm, um, the social media manager at Cloud PSO.

Speaker B: Hi, and my name is Waleed Elamari. I'm the CEO of Cloud PSO and

Speaker A: this podcast is for founders, CEOs, decision makers who are building software driven businesses and constantly making high stakes decisions around, um, technology teams and executions. So in this series, we're not going to talk about tools or trends, we're going to talk about decisions, the kind that either move businesses forward or slow it down. For our first episode, we are starting with something we see again and again. Most software projects don't fail because of bad developers or weak technology. They fail much earlier at the decision level. So starting us off, why do you think so many software projects struggle even when the companies hire good engineers or the, uh, best developers.

Speaker B: Developers.

Speaker A: So what are your thoughts on that, Waleed?

Speaker B: Number one is clarity. If the engineers or that the software developers don't have clarity when it comes to the project or the vision of the project, then your engineers will build whatever you're asking for. But without clarity or vision, you have to set the standards. When you're building an application, set the requirements from the beginning so your engineers believe in your vision. Have clarity on architecture and design. If you don't have many of these things, then they're just on autopilot and they're just building what they need to build. So some people will always blame the engineers and the programmers for everything. But you as a business leader, you need to define a, uh, clear vision for what you want to build, what kind of value that vision is going to bring to the industry, how you got to monetize it and everybody, every stakeholder needs to be to have a stake where? Into that vision, into that clarity. So it's number one, if you don't have clarity, it's very, very difficult to make sure all the programmers, all the engineers, the DevOps, quality assurance, everybody is moving in the same direction.

Speaker A: That's an important point because from the outside everything looks good, in progress. Teams are like, looks very busy. Updates, um, are happening. But under the need, under the surface, the direction keeps drifting and the leaders usually, uh, feel something is really off before they can, you know, they can clearly name it, you know.

Speaker B: Absolutely. And sometimes to Osman, the leaders, the CEOs, the CxO team, take a pause and take a step back if you feel that your project is not producing the outcome that you wanted. Stop and make sure everybody stops with you and define it, you know, define the clarity, define what you, you know, where things are dropping off and so forth. So there's nothing wrong with stopping and making sure that the, uh, money that you're investing into these engineers, into that project, it brings out value. And it all starts with the vision and a clear direction of how you want to build things.

Speaker A: Right. Right. So Waleed, what kind of pressure do you think CEOs usually underestimate when they are starting a software?

Speaker B: So the pressure, there's so many pressure. But underestimating, um, the pressure is, is, is, is a bottleneck. If you, if you underestimate the, the, the pressure that you're going to have when you're starting out a new company or building a new project, uh, working with vendors, different people, there's always going to be the pressure of, um, cost meeting, timeline, finding the right resources to hire, um, what else, uh, making sure the application is actually working as you expected, proper quality assurance in place. So all these things really create pressure, underestimating that pressure. You always got to know there's always going to be pressure when you're building something, but underestimating it is really, um, you got to keep that in your mind as a, uh, as a CEO, in a company developing a new application.

Speaker A: Yeah. And the pressure doesn't show up on the roadmap. It's uh, showing up in the gap between what leaders are responsible for.

Speaker B: Absolutely. It's like, it's not a predictable thing. You know, pressure is just, it's, it's, it's constant. You gotta acknowledge it, accept it, and make sure that you're aware that there's gonna be some bottlenecks when you're building out applications. You know, like I said, you can't really predict it. It will happen. You just gotta be ready for it. You'll be fooling yourself if you think, oh, everything's gonna be running smooth sailing, but it never is. You know, it never is. Anybody who tells you that is not telling you the truth. There's always going to be bottlenecks, pressure from different departments, even pressure with people not getting along. I mean, everybody's seen that. You know, I've seen, you know, um, innovators and CIOs and, and really high technical people they don't agree on saying. And that really create that pressure. I believe if, if you got to get everybody to believe in the vision, to believe in the uh, in the, in the roadmap and the technology that you're building, um, and so forth. So that pressure, you know, gets better, but it's always going to be there.

Speaker A: Yeah, exactly. Waleed. Um, do you feel like that the founders actually understand what they are signing up for once development has begun, or are they mostly reacting as uh, the thing, things unfold?

Speaker B: I think it's, it's a mixture of both. Um, you know, it's more of a reactional thing. They're always reacting at kickoff, for example. So I would say most are, ah, reacted at kickoff. Most are, you know, focused on, you know, how we're going to deliver this roadmap, how are we going to get everybody in line. They feel that they need to have a lot more control when it comes to, when it comes to these type of scenarios. I would say budget is a huge thing. Um, people are reacting. So for example, some people will, you know, will budget like say $100,000 for a project, um, and all of a sudden they double that. And, and it's all because, um, they're just reacting to the, the different environment that they put themselves in. You know, it's like it, um, I think you gotta have a proper, a proper, proper plan, whether it's a business plan or a technology plan with the right person in mind to make sure that, you know, you got their building number one, the right team, the right budget, the right vision and technology. And how do you get to incorporate that into a timeline? Who's going to do what, how's it going to get delivered, how is it going to be monetized and so forth? If you don't have all that stuff, you're just reacting to whatever, you know, things that are just happening that you don't have any control over. In order to build that control, you got to have a proper plan on paper, big time. I've seen projects that, you know, even, even with control project, like the, the proper, the proper project manager and so forth, there's always going to be hiccups. You know, either you overbidded the, the project or you underbid it. There's always that you have the right engineers, you have the right talent and sometimes you don't. Sometimes I even seen people that, oh, you're overqualified for things. You know, we need someone who's under qualified and it's not because of budget. Just, you know, there's a, there's a team synergies, there's people understanding the vision of the project itself. And, and, and again, if, if you don't have, um, a somewhat controlled environment, um, a decent project management system or a decent project manager and all the necessary skill set on board from the beginning, then things will be more of like you're just chasing at that point. Don't chase, you know, stop and go back.

Speaker A: Yeah. So Walid, in your view, where do you see that software projects actually start, um, going in the wrong direction? Maybe strategically, maybe not technically. We often hear phrases like the developer messed up everything, the tech wasn't the right. So what are your thoughts on that?

Speaker B: So number one, if responsibility are fragmented, um, and there's no accountability, you're going to have issues. So the second thing I would say strategy says one thing, but deliveries to another, there's miscommunication there. That's, that's a big, big problem, you know, and, and again, you need to step back and figure that out. The third thing is there's no one party taking accountability for what's going on, you know, in that fragment. So you have to have that person, you have to have that skill set. And I believe the last thing is just the decision get diluted over time. You know, if you don't have someone who is making the proper decisions and someone who sees your vision, the technology, um, the mission, um, all that just get diluted over time. So again, you're chasing, you're not taking a pause. Um, things are fragmented, your team is all over the place. They don't have clarity on what's going on. You, you, I, I always say to people, hey, stop, you know, let's not chase, let's figure out what's going on step by step, you know, and let's make adjustment. There's nothing wrong with making adjustments that is going to, you know, help you, help you stop, uh, and improve your strategy, you know.

Speaker A: Yeah, that's a really good thing, Walid. Is it usually one bad decision or, um, like a series of small, small decisions that compound over time?

Speaker B: I think it's a mixture of both. But, um, what I have seen is always these small, small Incremental decision that um, that really um, build up over time, you know, and it create chaos within your team, create chaos within your, your plan itself. Um, setting up clarity at the beginning of the project and incrementally making changes as you see progress. Um, that's going to help you a lot. So it's not just like, you know, it's a one big thing. I've seen issues, I see, you know companies build huge projects and they have one big problem and it just takes everything back, you know.

Speaker A: So effort isn't the problem, activity isn't the problem. It's the absence of single point of uh.

Speaker B: One point. Yeah. Absence of one point. Yep.

Speaker A: Ownership that quietly creates like misalignments, right?

Speaker B: Yep, absolutely.

Speaker A: Uh, something I've noticed is how many uh, moving parts are involved like different vendors, different freelancer, internal or the internal teams and consultants. So from a leadership perspective how damaging are these handovers to executions?

Speaker B: So I would say you need to anchor um, a clear definition of your project from, from, from the beginning. Have the right stakeholders from the beginning or the key folks on that team understanding the technology stacks that you're going to use. Any security, um, any security um, framework that you need to meet especially I mean security is so big now you gotta make sure it's included from the beginning. So you need to anchor all these things together so that way you have a smooth project. Not saying that it's gonna be perfect, but anchoring that from day one, even before you start programming is, it's really gonna help you drive things a lot better across the entire project, across different departments, vendors, partners and so forth. And security is key. You always gotta make sure by anchor these components that you're meeting all the different compliance that um, you're going to have. Even if you're building a multi tenant application or ah, a BDC application, make sure that security is embedded and anchored with all these different components.

Speaker A: Yeah, security is very.

Speaker B: Yep, absolutely. Yep. And it's going to save you a lot. It's going to save you a lot a lot of headaches down the road because you know I have seen companies, they build these amazing applications, really, really good application. And um, in the end you know, um, one of their customers like well hey, do you meet HIPAA or do you meet this or do you have this? Um and the, and like well you know we, we didn't think about that, you know. And um, and it sets you back now you got to go back to the drawing board. You got to anchor everything from the get go, you know.

Speaker A: Yeah, exactly. So, Walid, would it be fair to say that the execution failures are actually, um, you know, decision failures?

Speaker B: Yes. No, I mean, um, failures is a way to learn things, you know, but not constant failure. Not being unorganized, not having clarity from the beginning, not having an anchored project plan is considered a failure. What I think success is like stepping back for a little bit and really understanding, you know, what, you know, what problems are we face and how are we going to fix it, you know, do we have the right people and so forth. You know, stepping back is, I think it's a success. It's a great thing to do. It's going to take you into success, you know, taking that step back and a breather to try to understand what the hell is going on.

Speaker A: Yeah. That shifts the focus from execution to clarity of, uh.

Speaker B: Yeah. Yep.

Speaker A: Right.

Speaker B: Absolutely.

Speaker A: So, Will, let's talk about what founders and CEOs can actually do differently. Not to eliminate the risk completely, but to reduce the unnecessary care chaos. So if a CEO is about to start or scale a, uh, software product today, so what are the first decisions that they m. Should slow down and get right?

Speaker B: So for, uh, for a CEO, I think you need to manage the tech closely as possible to try so you don't have these issues. Staying involved with the team or having someone that reports to you to be focused on having a controlled environment is key to your success. So being involved is, I believe it's key. Some people will say, well, some CEOs, they don't want to be involved. Find someone who could be involved. It will hurt you down the road if, if, if you're just, you know, letting people just build everything without clarity or, um, or, you know, very clear defined requirements. So what is it? Some people say, well, what happened? If they're not involved? We go back to that unclarity. Some CEOs, um, they have expectations that the application is going to be built the way they imagine it or the way they thought about how it's going to, it's going to come out and so forth. No, you have to be involved. You have to be, to be part of the team. You have to make sure that you're really investing the right time in the right meeting to make sure things are moving along in the right direction. If you're not, then, um, and this is quite normal. A lot of CEOs are very busy. Make sure you have the right person who understands your vision, um, and the technology or the application that you want to build, you want to monetize and so forth, make sure that person is in tune with you, um, um, and what you want to accomplish, and make sure they relay all that information to the people under that person. If you don't have that, then it's going to be very difficult for you as a CEO to make sure that all these things comes together. Because. So, for example, a cloud pso, we work on so many different projects, we have so many different, you know, product managers and so forth who are focused on specific things. We have this framework that we built internally and there's always, okay, CEO, don't want to be involved. But let's understand the CEO's vision, CFO from a financial perspective and all the different stakeholders, and we take that and we delegate all that to, uh, someone who is very in tune with the product, the company, the vision, the budget and so forth. So you don't have any of these issues. So having the right people from the beginning, having the right, you know, the right product manager from the beginning is very key. But I would say CEO needs to be involved at all times, you know, so you can have that controlled environment and you don't go above or under budget, you know, and everything is being delivered the way you want it to be delivered.

Speaker A: Yeah, exactly. It sounds like clarity, ownership and accountability matters more than, uh, speed. But, um, um, from like. So from your experience, how far should a CEO is actually be involved in a software project before that involvement start

Speaker B: getting, Um, I think you need to be heavily. Yeah, you need to be heavily involved from day one. You know, let's just say you're working on a, um, V1 that is going to take you six months. Be involved in the six months, you know, taper off. Once you feel that the team has matured, they understand, they understand the, uh, technology that you're trying to build. They understand the business side of it as well. You can start tapering off. But, you know, I, me personally, I like to be involved. I like to see what's going on, who is doing what. It's not a micromanagement thing. It's more of like making sure that, you know, the ship is moving along and everybody's doing their part and there's, there's no ambiguity or issues with understanding what we're trying to deliver as a team.

Speaker A: Yeah. So, uh, Waleed, when a CEO looks at a team and things like, hey, I can trust this team, so what signals usually, uh, tell you that the team is like, genuinely mature or accountable for this project?

Speaker B: God, that's a great question. I love to see the Sparkle on all the programmers light up. Once you see that everybody's involved. And I mean project is being delivered on time. All the milestones, all the sprints, all that stuff is being done on time. And my thing is, I like to see creativity. You take a programmer who understand nothing about, you know, the technology or the application you're trying to build, and within like two weeks or a month, you see the sparkle, they understand it, they want to build more features. That's what I love seeing. I just love seeing, you know, it's like uh, it's like seeing a shining star. And that's the way I like to see the programs, um, and the project managers, the designers and the qa. You know, I seen, you know, there was, there was a story where I had to build, I had a project where I had to build a transactional application. It used a lot of data, a lot of transaction, um, and the queue process, the QA process was intensive. And I think like two weeks later, um, that QA person, there was two people, they automated the entire QA process. You know, it was rigorous steps that we had to take to make sure that all these heavy transactions are being tested and so forth. So they created all these beautiful automation that helped make their job easier, but it helped the company, the company move, but the project moved quite fast as well.

Speaker A: Yeah, that's quite interesting. So Waleed, what's the basic, basically the difference between having a multiple vendors, hiring freelancers from across the groove, or hiring DevOps or having a one accountable partner?

Speaker B: Um, the difference is, is I would say multiple vendor will help your progress, having the right help from multiple vendors. But again, that vendor really need to understand your project clearly, like 100% clear. There's no guessing in any of the Sprints or the timeline or, or any of the technology. That's, that's number one. The second thing is that vendor will need to work with someone they can't work with. The CEO all the time CEO have a lot of stuff to do. So that vendor will need to work with uh, the right talent or the right person within your organization and so forth. Same thing with partners. You know, they have to understand exactly your project, what you're trying to accomplish, work with the right people and all this stuff. The other thing I would say is, you know, don't micromanage these vendors or these partners. Let them speak up about how to make the application better, how to innovate. And the reason I say that because they have done this many times over, you know, and they have seen Whether it's a feature or team changes or technology stack improvement or changes, make sure you ask your vendors and your partners, hey, are we doing it the right way? You know, can this be improved? Can this, uh, help monetize? You know, can this speed up? Whatever it may be, don't let them be shy. Let you know, empower your vendors and partners to be involved in the entire process because your process will move tremendously fast once you get vendors and partners involved. Maybe in the beginning it will take some time, but after that, I believe that, you know, having the right partner and vendor online with you, uh, with your project is going to help you a lot.

Speaker A: Yeah, I think that makes total sense because micromanagement usually, you know, comes from unnecessary or a lack of trust.

Speaker B: Yeah.

Speaker A: But ironically that approach, um, often slows things down instead of speeding them up, especially when they are. Isn't clear ownership in place.

Speaker B: Yeah, um, I, like I said, I mean, from the beginning of this podcast we spoke about clarity. Like if you don't have clarity. Clarity is the waterfall of, uh, projects. You know, it's the waterfall of, of decision making. It's like you having clarity on pretty much every aspect of um, um, a project especially that project is going to cost you millions and millions of dollars, time and money. You got to have that set in stone.

Speaker A: Yeah, exactly. Clarity is like, it's like really the backbone of everything.

Speaker B: Yeah, absolutely.

Speaker A: Even the best teams can get stuck or pull in different directions, which is a waste of time and resource.

Speaker B: Again, I'll tell you a funny story, Osman. One time we were building, um, we were building a cloud, um, did the project called OpenStack and I love that project. It's one of my favorite cloud projects, but long time ago we're building um, an orchestration tool, um, and we wanted to integrate it with VMware. Um, um. And the way it was going to work is going to receive orders, these orders will get processed, then it's going to automate the whole process of provisioning all these virtual machines in VMware. We went through the whole process of building it and one of the missing components was some of the APIs were not designed to be agnostic. It was more. It was, it was designed to only support VMware. No, we, we wanted an, an agnostic, um, API so we can support any orchestration system, whether it's like, you know, KVM, hypervisors, VMware, you know, and all that stuff. So not having the right clarity around that time, we ended up building, you know, it wasn't a Big thing. But, you know, we caught it in time. We were, we were building. There was a lack of understanding of how these APIs should the agnostic of any vendor. Um, a lot of the programmers, they just didn't get it. And this was in the early stages of cloud computing, so there wasn't a lot of expertise within the hypervisor orchestration world around that time. But it was a good, it was a good thing to see that and also to catch and for me to explain, hey, you know, you're on the right track, but we need to be vendor agnostic so that way we can support any hypervisor that we want to support in the future or any uh, cloud that we want to manage in the future. You know, not having the clarity from the beginning or set on paper, it makes things a lot challenging for a decision maker.

Speaker A: Yeah, I think, Willie, that's a perfect example of uh, how missing clarity or uh, you know, early on can cost a project big time. You ended up building something that works for you only for a narrow use case when the real goal was, you know, flexibility and make it big.

Speaker B: Yeah, yep.

Speaker A: Yeah. None of that, uh, usually doesn't show up until much later when it gets too expensive to fix.

Speaker B: Yeah, absolutely. Especially with new technology. Like I remember, like when cloud was coming out, you know, everything, everything was brand new. It's like you're moving from a physical world into a virtual world and there's like, how is this going to work, work? You know, we're moving like, you know, these heavy metal machines into a virtual machine and so forth. And, and now it's like, try to understand it and explain to people it's all news. I didn't, I didn't necessarily blame it all on the programmers. Um, I blamed it more on me, you know, because I didn't set, you know, the clarity from the beginning. I wanted, uh, an agnostic orchestration system that support multiple vendors. So my APIs needs to be 100% agnostic. You know, and they just um, they didn't understand that. So we fixed it and we became really, really successful. You know, so I was really happy. Yeah, in the beginning, this is always these issues. You got to understand there's a difference between a programmer and um, a system administrator or and so forth. They think differently. You know, you can't tell a programmer, hey, go build me something and an active directory or for Microsoft, uh, you know, load balance and you can, it's, there's a different way. You know, as an architect, you gotta understand how to build all These technologies. As a programmer, you gotta, you gotta get that knowledge transfer from the architect of how he would build it and take that into a programming language and program it, you know, so it's, it's, it's totally different. So you have to be involved, you know, like, especially if you're, if you're a technical CEO, it's great. You know, you have to be involved and it's fun too. If you're not, then get the right person under, you know, to understand what you're trying to accomplish. But it's totally different. Programmers syncs different than, you know, the systems administrator or architects and so forth. But you know, as long as they're moving in the right direction, everybody understand what they need to, you know, to accomplish and deliver. I think everything will be good.

Speaker A: All right, Walid, so if you could leave CEOs with just one piece of advice before they make their next big projects move around, what it would be?

Speaker B: Yeah, so I would say, I would say if I, if I want to give you advice is number one is like first things like have fun while you're doing this as a CEO, make sure you have a clear vision and a clear mile, you know, a clear vision mission statement of what you want to accomplish. Make sure your team is also having fun. You know, anchor the project from day one. You know, set your, set your requirements from day one. Adjust, don't chase, make sure you stop if you have to stop. It's always great to stop and say, hey, let's take a step back and figure out what we're doing wrong. Um, you know, make sure your vendors and partners are involved as well. If you have any questions about anything, always ask. You know, don't hesitate. Your involvement as a CEO is crucial. If you can't be involved all the time, make sure that you hire the right person to be involved. Whether it's a vendor or partner or a full time product manager who can help you as that. I would say also understand the market that you're going in. You know, if you're building a B2C or B2B application or whatever it may be, or an enterprise level application, understand m the market that you're going in really well. Don't be shy. Ask for help. Even if you need to research data from people that you know or vendors that you know, all these things matter. And the good thing was, you know, there's a lot of people on the Internet that has, have experience, you know, with all these things. I have built companies, um, in the past, sold companies in the past. Um, having the right, you know, the right framework and the right mindset from the beginning is good. It's really, really good. And make sure that, you know, you have good people, um, who are accountable. Um, they see your vision, they're having fun, all that stuff. It's very important. But I would say that the most important thing, make sure you're having fun. If you're not, you're not going to be having fun. You got to have. If you're going to be miserable. You know, I always have fun with my projects. You know, like, I want to make sure that, um, there's passion involved, there's creativity, all that stuff. It really helps the job. It really helps the job environment become, um, immersive, fun people, like, coming to work and all that stuff. So that's. That's my biggest advice.

Speaker A: Yeah, that's really great. Notes to end on. And, uh, this was the first episode of Value Props, where we break down the thinking behind successful software decisions. In future, we'll continue unpacking how leadership choices shape the technology outcomes long before a single line or, uh, writing a single code. So thank you for listening, everyone.