Part 2: People
The success of any project relies heavily on an intricate interplay of various elements, ranging from the clarity of communication to meticulous planning. However, an often overlooked aspect that can anchor a project’s fate is the human dimension—people, their attitudes, and their approaches to work. The complexities brought forth by human interactions within a project’s lifecycle can make or break its progress and ultimate success.
This episode is the second in a series on why projects fail and in this episode we explore how people can cause projects to go awry through their inaction, ego and lack of ability to listen and take sound advice.
A full transcript of the podcast can be found here:
Bhairav Patel:
[00:00:32 – 00:01:07]
Welcome to the Atom CTO podcast. My name is Patel, managing director, Atom CTO, and this is part two in a series of why projects fail. So in part one, I talked about communication, so inconsistent communication, lack of communication, people not explaining themselves, etc, etc. And in the second episode, we’re going to explore the second letter of the acronym CPOP, which is people. So, for those who haven’t yet listened to the first episode of this series, this whole series around why projects fail.
Bhairav Patel:
[00:01:07 – 00:01:52]
So why have we seen Atom CTO companies come to us with projects that have been failing? And so this acronym CPOP stands for communication people, oversight and planning. And these are the four main areas that I have seen and the team has seen that have caused projects to fail and have created frustration for business owners and for software development houses alike. So, moving on to people now, I personally feel that this is the main reason why a lot of the projects have failed that we’ve come across. And there are a number of different examples I can give, but knowing that I’ll probably be sued by quite a few people if I name names, I’ll have to keep them fairly generic.
Bhairav Patel:
[00:01:53 – 00:02:20]
But there are four main areas, really, when it comes to people and why projects fail, in my and our opinion. The first one is egos. The second is something that was revealed to me by Adeb Bamir, who is one of the podcast guests that we’ve had, and it’s a very good podcast, and I strongly urge you to listen to that, where he talks about the one to ten rule. The third reason. Well, the third reasons are fear and inaction.
Bhairav Patel:
[00:02:20 – 00:02:57]
And the last one that I have, and these will all be put onto a slide, which you can see as part of the podcast on our website, is the fact that most people don’t use two ears and one mouth in that proportion. So, let me start with egos. Now, what do I mean by egos? Well, I think everyone understands what the term means, but what do I mean in this context? Well, a number of the larger projects I’ve worked on over the years, and I started my career at IBM and PwC, were very large implementations which were driven and were led by obviously some very high powered people.
Bhairav Patel:
[00:02:57 – 00:03:59]
And within those projects, certain decisions were made where you feel that actually better decisions could have been made, or better design or approaches could have been made towards implementation, but they weren’t taken simply because people wanted to show off. And maybe there was an element of vanity around some of the decisions that were being made. Now, I’ve seen this in similar ways in smaller companies, in startups where people have chosen approaches, they’ve chosen languages that are a little bit esoteric. So they are ones where there are not many developers out there who can create it, and they’ve gone for approaches where it doesn’t make sense for the company and the size of the company that software is being developed for. So we’ve seen a lot of overarchitecting, we’ve seen a lot of issues where people have tried to build something that is too big or too complex for the current needs of the business.
Bhairav Patel:
[00:03:59 – 00:04:53]
So oftentimes what you’ll see is people. And what I mean by over engineering is people are actually using far too many resources or building too many, creating quite complex architectures, because they feel that they feel they need to actually scale that business from day one. Now, if you’re a new startup only just finding product market fit, scaling is not really your issue unless you have actually tested the market and know that there are millions of millions of people who are going to want your product as soon as you launch. Most startups, and this is a 99% of them, will struggle to get the first set of customers in the first few months. And as you are there going out to market, what is more important than building a big, scalable, robust platform is to build an architecture platform in a way that is adaptive to change, that can adapt to changes in the market.
Bhairav Patel:
[00:04:53 – 00:05:51]
So you look at areas within the business that you think may change, because you may build a business that has a set of ten features, and it may well be that the market actually only really likes three of them. But if you spent lots and lots of money developing the other seven, you often feel that that money is sunk cost. And this is where you move into the sunk cost fallacy, where you feel that actually I need to push on with those other seven features because I feel as a business owner that they are more valuable, whereas the market is actually telling you something else. And from a technology point of view, you want your team to build technology in such a way that if, for example, those seven features are not very much used, dropping them and focusing on those other features is not going to cause a huge problem within the overall platform and architecture, so that your platform can move in a different direction without having to re architect absolutely everything. So the key here is agility and being able to respond to the market quickly.
Bhairav Patel:
[00:05:52 – 00:06:32]
So to illustrate all of this, let me tell you a story. And this is regarding a company that came to us some years back that had raised significant amounts of money in the millions and for six years had not delivered anything. Now, there are a couple of reasons for this, and one of them actually fits nicely into the next piece that I’ll talk about. But for the purposes of egos, what I’d say here is that when we took a look at what had been built, it was impressive, but it had been massively overarchitected. And what had happened was that the software development team was essentially building for perfection.
Bhairav Patel:
[00:06:32 – 00:07:14]
What they were doing was they were creating this massive platform which could do a lot of different things. But when the founder had already gone to the companies, their potential clients, the clients had said, yes, we’d like all of these things. But the software house editors or the internal tech team, sorry, had basically said, no, no, it’s not ready, it’s not ready, it’s not ready, because they were building for perfection. And what they were trying to do was build this beautiful, ornate system for future, to meet future needs, which they didn’t really know, because who knows how the market will react over a certain time. What they did know was that they had clients who were very interested in what they were doing at the moment and wanted that implemented.
Bhairav Patel:
[00:07:14 – 00:07:41]
But the team itself was preventing implementation because they wanted to complete the feature set. So that in itself was, again, egos on the part of the CTO in that organisation. Not to recognise that you don’t need to build the most perfect solution in order to go live. You need to build what the customers want. And if the customers like what they see, then put it in front of them, regardless of where you feel the quality is at.
Bhairav Patel:
[00:07:41 – 00:08:35]
The other side effect of what this company had done, or what this tech team had done, was that because it had taken them six years to come up with their finalised product, which wasn’t actually finalised after six years, was that technology had moved on greatly and the techniques that they were using six years ago were not the most up to date and not the most efficient techniques. So in fact, if they had delivered the project, or, sorry, the product at the very beginning and gone to market, they would have been able to have leveraged the new technologies or new methods that came out afterwards. But actually, the issue that they had was, because they were wedded to the path they were taking, they couldn’t then rearchitect and rebuild based on what was out there in the market. Now, this leads me on nicely to the one and ten rule that I mentioned. And again, I’d like to stress that anyone who wants to hear a little bit more about this should listen to the podcast with Adib.
Bhairav Patel:
[00:08:35 – 00:09:11]
Bamier, which is on the Atom CTO podcast. Just search for Adib and you’ll find it. And this is the one to ten rule. And the one to ten rule is all about who you should employ within an organisation, depending on the stage you’re at. So what Adib says is that if you take a startup, which is a number one to a meta, which would be a number nine, and General Electric, or a BP, which would be ten, and the reason that they’re a ten, because they’ve been around longer than obviously the metas and Airbnbs and the Netflix, et cetera, so they’ll have a different set of rules and ways of working.
Bhairav Patel:
[00:09:11 – 00:10:02]
Now, if you are a startup that is just launched and you’re in, let’s say, a number two or number three phase, you want to ensure that whoever you hire or bring on your team is within one or two numbers of where you’re at. So, for example, if you’re an early stage startup and you’re a founder who’s looking to bring on someone who is at a number seven or eight, you’ve got to recognise that that person has a lot of support structures around them. So they’ll have teams with highly paid and motivated people, they will have a lot of resources around them, they’ll have time because there’ll be many teams working, so they’ll not necessarily be under massive time pressure. And these things are fairly opposite to the issues and challenges you’ll face at an early stage company. So you’ve got to be very aware that the person that you hire has to understand the predicament that they’re going into.
Bhairav Patel:
[00:10:02 – 00:10:49]
And I’ll give you a good example of when I was working at a company, aztec exchange, and I was the CTO there, and we were looking to hire a COO, and we were again, an early stage business, well funded, and we were interviewing people from the likes of PayPal, just eat, et cetera. And the expectations of those people was far, far beyond what we could give them. So people were demanding things like 15%, 20% equity, which for anyone who’s a startup founder out there understands that that is insane. Giving 20% to a single person doesn’t make any sense. You would have no equity left after the different rounds and different other hires would come on board.
Bhairav Patel:
[00:10:49 – 00:11:37]
So this is where someone who’s working in these large organisations doesn’t have a basic understanding of what it’s like to be at a startup. And in the previous example that I mentioned where this company hadn’t delivered for six years. Their CTO was someone, again, who came from a very large organisation, who had a lot large r and D budget and had the time in that organisation to spend perfecting things, whereas in a startup you don’t. So again, this is where you as a founder, and actually you as a CTO, or you as a tech person within a new company, have to understand that there are different ways of working, depending on the size of business that you’re in. And you really do need to ensure that you are in line with the business that you’re going to work in.
Bhairav Patel:
[00:11:37 – 00:12:10]
So that’s another reason that people cause problems, then fear and inaction. So again, going back to that example, there is an obvious question as to why the business owner, the CEO of that company, didn’t just fire the CTO or the tech team. And this is something that we see a lot. It’s the fear and inaction. There was another company that came to us a while back who had a working business, doing very well, but their CTO left and a new CTO came in.
Bhairav Patel:
[00:12:10 – 00:13:09]
And for any of those listening, who’s part of tech, who works in technology, the first thing the CTO said was, well, I’m going to have to get rid of everything and rewrite the entire thing. Now, for us at Atom CTO, but also for most other experienced technologists, you’ll know that if you’ve got a running business, it’s very unlikely that, a, you’ll need to rip everything apart and start again, and B, it generally makes no sense to sit, stop and rewrite everything. Why would you take a running business offline, wait two months to rewrite it and then push it back online again, rather than trying to find ways to bolster the current technology to a point where it can run well enough for a few months while you go off and do the rewrites and upgrades that you need. So this founder came to us and said, well, this is what our CTO said. And surprise, surprise, the CTO wasn’t able to deliver within those two months.
Bhairav Patel:
[00:13:09 – 00:13:30]
In fact, it took eight months for that person to deliver. And that was when we came in and they still hadn’t delivered. They were still trying to finish off the last couple of features that were needed. So my immediate question was, why go down this path? And from a business owner’s perspective, they were taking advice from their CTO.
Bhairav Patel:
[00:13:30 – 00:13:45]
But from a real business perspective, this was in action. This was something where you really needed to take action and say, look, the business is losing credibility, it’s losing money, it’s offline. We had revenue. We don’t. We’re burning through cash.
Bhairav Patel:
[00:13:46 – 00:14:28]
We need to take action to find a company that can take over the current platform and do the maintenance needed in order to keep it running whilst we wait for the new version to come. And funnily enough, in this instance, we were brought in by the investors because the investors saw, well, they were quite shocked as to why someone would essentially take their own entire business offline on the behest of a CTO who was new to the business, who said that they could rewrite everything in two months. And still eight months later, the business was offline. So there’s a lot of fear of action, fear of inaction, fear in general, right. When you’re looking at tech projects, especially for nontechnical founders who don’t really understand technology and don’t understand the complexities behind it.
Bhairav Patel:
[00:14:28 – 00:15:05]
And so I think for the advice for the business owners is if it doesn’t smell right or doesn’t sound right, and you don’t think that it makes sense, then it probably doesn’t make sense. You should bring someone in who’s independent, who can tell you whether what that tech team is doing is correct and whether that’s the right approach to your current situation. The last thing is two ears, one mouth. Now this is something that, again, for listeners of the podcast, you’ll have heard this from a number of different interviewees that we’ve had, where they said the best advice that they’ve received is you’ve got two ears, one mouth. Use them in that proportion.
Bhairav Patel:
[00:15:06 – 00:15:54]
And again, from what I have come across across projects, and this is on both sides, where either founders don’t like to listen or tech individuals don’t like to listen, there have been a number of cases where we’ve walked into a company and the tech team have said, well, I don’t really care about the business. I don’t really understand the business. We don’t listen to the business, which is very shocking, given that the business is what pays their salaries. Similarly, we have the situations where business owners, well, won’t listen to technologists because they’ll essentially think that they’re wanting to generate their own work and generate their own revenue, which can be the case, but is generally not the case when it comes to situations where you’re looking to help the business get more efficient, enter new markets, et cetera, et cetera. Building tech.
Bhairav Patel:
[00:15:54 – 00:17:09]
Building tech is a complex, complex thing. So just to recap, the four main areas, when it comes to people that we see that cause the problems are egos where people are employed in a business where they don’t really fit in because their past has shown or their past experiences are very, very different from the business that they’re in at the moment. Fear and inaction, where people are too slow to take action or don’t take action because they fear maybe the wrath of their CTO or their tick team, or maybe even fear that they’ve already made a poor choice and they don’t want to exacerbate that poor choice by doing something else, but by not doing anything, they’re causing even more problems and then by not listening where you have technologists and founders who don’t really listen to those around them, all the advice that they receive. So that’s my take on people, the second letter in the acronym CPOP, and in the last episode, we’ll be talking about oversight, planning, and actually the things that you can do to mitigate the risks that we’ve highlighted in the last two podcasts, which have been communication and people. So thanks for staying tuned, and the next podcast will be released very soon.