In this episode of Cegeka Podcast, we speak with Cliff Moyce, chief officer with extensive experience of leading financial services and professional services organizations with deep experience in fintech, market data, exchanges, banking, insurance, outsource systems development, and IT consultancy, writer and media commentator on industry trends. Our topic is about the Commoditization of software development services in the outsourcing world and how successful companies can still make a difference and add value to their services, in a market that lower prices tend to be the main driver.
Listen to the podcast:
Mihai: Hello and welcome to a new episode of the Cegeka Podcast. I am Mihai Popa. In the Cegeka Podcast, we have short discussions with people in the IT world on technology topics.
Today we are talking to Cliff Moyce, who is a leader of transformation and innovation in financial services and capital markets, based in the UK. Cliff is a known writer and media commentator on the IT industry trends, especially Fintech, and has worked with software engineers from more countries than an average person probably visits in a lifetime. So, hi Cliff, welcome.
Cliff: Thank you for inviting me on. I’m sure your podcasts are very interesting. You’ve also got a lot of experience that’s of interest to many people. Of course, you and I have worked together in different organisations over the years, very successfully, so it’s nice to be speaking to you again on one of my favourite subjects - which I’m sure you’ll want to introduce.
Mihai: Our topic for today is the commoditisation of software development services, especially in the outsourcing world, but not only. What that means in itself, and how successful companies can still make a difference and add value to their commoditised services given that in a commodity market, lower prices tend to be the main driver. Cliff, you know a lot about commodities. You were a director with a couple of commodity exchanges in London.
Cliff: It doesn’t mean I recommend commoditisation, as you know, but yes. I certainly know the difference between a commodity and a high value-add product, and you know where my strengths are meant to lie with software engineering.
Mihai: Yes, I do. I’ve been following your articles, and yes I did enjoy that part where you said that software development right now is basically gathering feedback from unhappy users and making it into a list of new features rather than designing software that’s, let’s say, more future-proof or better written. So, yes.
My first question is, what’s your view, how do you see the software development services world in its evolution - since you’ve been in this game for 30-odd years?
Cliff: Yes, 30-odd years. Amazing, isn’t it? I was a chemical engineer, then an industrial engineer, and like many people of my age, my IT story is that I read articles about these new things called PCs in maybe 1983/84. I got my manufacturing company to buy a PC because I saw the power that it could bring. For example, at that point, production management was done on huge charts across lots of walls in big rooms using string and pins and things, colour-coding, and the first thing I did with a PC was put that onto spreadsheets, and it was like magic. It was like being a witch, and of course here we are today many years later with much better technology, and much better tools. Technology... the difference between the business and IT has blurred enormously.
Now, for many organisations, the business is technology. You know Uber etc, etc.
So I’ve seen this fantastic evolution and we must acknowledge that. I don’t think any of us could have seen how well it was going to go, in terms of information technology. On the other hand, there are things that trouble me. Because, I sit in both camps.
If you were to say to me ‘what do you do?’ - that terrible question at a party, I say simply now ‘I run companies.’ That’s true, that’s my main thing now. You know, I’m a board-level director CEO, COO, so I have an interest in every aspect of the company in its commercial success. Of course, I run companies which either do IT, or where IT is critically important, and many things trouble me.
I see far too many companies failing. I see far too many product developments failing, and I read a lot on that subject, and the failure rates are, depending on who you listen to, between 40% and 85%. I still see an enormous number of IT projects failing as well, and I feel that reflects badly on the IT industry even though it’s perhaps not the engineers’ fault.
I want to solve that problem, and there’s a lot of misunderstanding about software development especially, and I think that feeds into product development failure rates and project failure rates. I just feel that if everyone understood the topic a bit better, and changed some of their fundamental assumptions about the topic, then things would go better.
One of the things I’ve seen is, you know, there is an argument now that software development coding is commoditised, that the tools that we have now have allowed us to commoditise it, and that that’s not where the value-add is. The value-add is elsewhere in the software development life-cycle.
I will challenge that because it is fundamentally untrue because, when something becomes commoditised, it becomes homogenised.
So, soya beans, for example, the usual example - and they are all the same - actually there is a huge benefit to them all being the same. There is a huge benefit to the consumers, to the producers, and so on. It suits everyone for it to all be the same.
Software coding and software design, which is an important thing that I want to talk about, has become less homogenised, more heterogeneous than it was in the 1980s.
Mihai: That’s a good point
Cliff: In the 1980s, people who wrote code on mainframes, pretty much, well they were specialists, they were experts and they all had the same background. Let’s face it, there weren’t many mainframes and there weren't many development languages and they all went on the same courses; there was a very high ethos of engineering, and it was very much regarded as a knowledge job, a specialist job.
If you look at their code, going back, and even things that followed like Cobol and so on, you see more similarities with homogenisation then than there is now. Is that a natural evolution? I will say no it’s not. I will say that the reducing homogenisation of coding is actually because the bottom, the low-quality work has gotten lower and lower, worse and worse, and there’s more and more of it.
And, please forgive me because you work in the outsourcing / nearshore IT industry, I would say that the outsourcing of systems development is largely to blame. I will say that the people who provide those services are only partly to blame, and actually it’s the client assumptions that are perhaps the biggest issue.
It is them that assumes that coding is all the same, and one of the assumptions that I always challenge with people, and these people aren’t stupid, they’re cleverer than me, but they don’t know enough for business people. They don’t know enough about systems development. I think everyone should know a bit more than they do.
One of the easy assumptions that people make, but it’s fundamentally wrong, is that there’s something called design architecture and there’s something called coding.
Mihai: That they’re separate.
Cliff: Yeah. As long as they employ the architect and the architect is a pretty good guy or girl, then everything will be okay because the developers, the coders will then do tasks, which is another fundamental wrong assumption, and the accumulation of all those tasks will deliver that design and everything will be okay.
Now, the huge failure rate, if you read the McKinsey 2012 report on IT failure rates, it’s shocking. You know, there are 70% of companies whose projects failed so badly as to threaten the future of the company. There is still 80-something% failure rates in projects, and I will say it comes down to some of these assumptions.
Because, you know I would never software engineer a systems developer. I was always the guy who had the vision as to what IT could do, I was building IT departments, I was doing the logical design of systems, what they had to do from a business perspective, what problems they had to solve, and I never really got down to the nitty-gritty of coding myself very much at all.
But, I know enough about it to know that developers are not just writing code in the same way that doctors are not just writing prescriptions. Developers, they all look like they’re doing the same thing, they’re looking at the screen, but they’re thinking, and they’re thinking about how best to deliver this function, how best to solve this problem.
Every single one of those decisions is actually a design decision. It’s not just about writing the code.
So, when we talk about the terrible impact of poor-quality code, and I’m not going to name any company names, but I could sit here and name large corporations with massive problems, which manifest mainly in the cost of support, because poor systems cost 100 times more to support than good systems. I could name those companies, but I’m not going to do that.
You know, it’s this idea that someone can use power point to design a system and other guys write code, and if the code is poor it’s because they make syntax errors and so on. Of course, poor developers will do things like syntax errors, but really poor developers generally are out of their depth, and I will name India.
I don’t feel bad about this because India is my favourite country in the world from a personal perspective and I love the place, I love the people, but it is becoming rapidly a victim of its own success.
When Edward Riordan, the American, went over and started working with TATA in the 70s and 80s, he found that the guys were highly educated, highly qualified, all had masters degrees in mathematics and computer science, and were really good, tremendously motivated and committed, and saw that this country could really raise the bar. Riordan was all about raising the bar, it was his obsession, and of course it became so successful and now I go over there and anyone who has any degree...
The last time I went to India an IT company turned up in a small city I was in, of only 1 million people - I won’t say which one - and hired every single leaver from every single college in the town. These people had degrees in finance, and history, geography, geology, and maths, engineering... It didn’t matter, they hired them all, sent them on a short coding course. At the end they could pass a simple coding test.
Mihai: Sounds like the German soldier recruitment at the end of the Second World War.
Cliff: Yeah, exactly. Then, the next step is these people are being billed to clients. Now, you know, this is where it all falls apart because you cannot expect these people to be making the right decisions.
You can say that they’ve got people looking over their shoulder and helping them, and so on.
That’s true.
But, you know, these projects - and I get called in to audit these projects and rescue these projects and rescue these companies that are doing these projects - and it’s the same thing over and over again. It’s the fundamental assumption that you can just buy coding and development on price.
It doesn’t matter if you say to me ‘I will sell you senior developers for 500€/day’ and someone else says ‘I will sell you developers for 100€/day’, then this assumption that I’m going to take the 100€ because it doesn’t matter... It’s so fundamentally wrong and that’s why software development has not been commoditised, because if it was commoditised, it would be okay to buy on price.
It is not okay to buy on price; your project will fail, your product will fail, your company will fail, and it may not close down tomorrow, but you will spend 10 times more supporting that product.
‘Supporting’
Because as we all know, “support” really just means fixing it, spending most of your life fixing it, and then you’re fixing the fixing, all the guys who built it have left, and no one really understands the design, and the design is very opaque anyway, and every fix you make creates another problem, and that’s how people fail.
Mihai: Yeah, but some might argue that right now the development frameworks that are currently used are so well-written and so fool-proof that you cannot go that wrong. Even with a less skilled process stack, or with a less skilled engineer.
Cliff: Well, first of all, I would agree with you. The tool set is so much better now, and it’s there to help the process of systems development, software development, and that’s absolutely true. I will go back and address your point directly, but slightly indirectly, what I would say is I’ve seen those much better tools being used to enable relatively small teams of very high-quality engineers to build amazing products really quickly. The example I always use is WhatsApp.
WhatsApp was built by a small team using those software as services, using Cloud-AWS I think, and so on, and you know, their ability to build something amazing really quickly was enabled by those tools.
But, I go back to this point, that was a team of incredibly high-quality people, knowledge workers who had a vision for a product who actually, now this is important, they understood what problem they were trying to solve, for whom.
They all understood it so they were all coming from the same place, so whenever they had to make a decision, which is all the time when you’re doing software development, that decision was informed by this knowledge of what they were trying to do and what they were trying to achieve. Those tools made it so much easier, so I’m a massive fan of those tools.
And, actually, don’t think I’m against commoditisation in general because I think there’s a weird thing that’s happened in infrastructure and service delivery, which is that we now have commoditised hardware, hardware services, service delivery operations, infrastructure, through cloud, and actually the quality has gone up massively as a result of that commoditisation.
The bar has gone up massively. You know, when I look at where we were in terms of the quality of service delivery and ops, and data centres and all that stuff 15/20 years ago, and where we are now because of Amazon etc...
It’s like difference between night and day.
But it doesn’t seem to apply on software development. The tools are just tools, but they have to be used by craftsmen. So, if I Google the word ‘painters’ right now it knows where I live, it knows where everyone lives.
Mihai: Of course. And much more!
Cliff: Yeah, it’s like the STASI (n.r. Staatssicherheitsdienst, East German Secret Service). It will come up with two things, and everything in between. At one end of the spectrum it will come up with people who can come and decorate my house, who can come and paint my ceiling and my walls, and it will come up with Picasso, okay? And, they both use brushes, and the brushes are the tools.
In systems development and software development, that absolutely seems to apply. If someone says that doesn’t sound very logical etc, etc, all I can do is to defend this is say the proof of the pudding is in the eating. I see first-hand all the time, unfortunately, the products of low-skilled, low-experienced commoditised developers, and I see the products of highly-skilled, highly-experienced developers, and even if they’re both using the same tools, the outputs are, the difference is enormous. That’s what I mean by it’s still heterogeneous, not homogenised.
That’s just a fact.
Can the tools ever take us to a place where, you know, anyone given the right training can do a good job of systems development? So far the answer seems to be ‘no.’ I’ve been thinking about ‘Why is it no?’ and I think it’s got something to do with the fact that systems development is actually a creative job. It is a creative job. It’s like music.
You cannot commoditise music. People try, of course. They try all the time, but it doesn’t work, and it seems to be the same with systems development.
There is so much creativity in software development, and of course it’s hidden by this sitting at a desk looking at a screen. Everyone is sitting at a desk, looking at a screen, and you can’t see the creativity, and then the creativity itself is somewhat hidden from the business community in a way that music or fine art isn’t hidden.
Now, it manifests in the cost of support, it manifests in what it’s like to be a user in the system, but you know, it’s not them staring you in the face.
If you understand architecture and if you understand coding, you know, I’ve seen some architecture designs... I’ve thought about telling you one, but I’ve decided against it. If any of the people involved hear it, they’ll know it’s them and they’ll feel embarrassed so I won’t say.
But, I saw a Microsoft tool, I almost said what it did, being used inside an application once, and it should never be used inside of applications. It’s a tool designed to facilitate communication between systems, or even between entities. And that was being used inside an application. It was a mindbogglingly bad decision, and it had a high impact because it was in capital markets. And, when we discovered this eventually, because again it’s not staring you in the face, and we did a support call to Microsoft, they burst out laughing. Then, they apologised that they burst out laughing. But they just said how could anyone even think to do that, and we just said we’ll never know.
You can give people all the tools in the world, but that creativity, that decision-making, it’s like chess; it’s fairly easy to learn, but it’s almost impossible to play at grand-master level. It’s the same with music, same with art, and systems development. I don’t want to mythologise it too much, but I think it’s been de-mythologised far too much.
The commoditisation thing is completely missing the point.
They don’t just write code. They’re doing design every minute of the day, and you can only do design if you’ve got great skills, great intellect, well, a certain type of intellect, and experience. You can’t just be trained to write code and then be a great developer. I was thinking this morning about great developers, I don’t know if people listening to your podcast will know the names. I wrote some down, let me have a look at my notes here.
So, I was thinking about who were some people who actually, almost single-handedly, and they would hate me saying that because it’s not true, they had small teams with them of course.
But, you know, these guys are developers. They may have been perceived to be gurus or business leaders or something ultimately, but they were developers when they did this:
- Jim Kent, the human genome project
- Jeff Dean, one of the two biggest contributors to big data
- Daniel Bernstein, he did, I think it was called qmail, you know, how to deliver email. That was one guy.
These are developers and, of course, Linus Torvalds.
It’s suiting them writing code to do something, and the design coming from the bottom up. That’s how powerful great developers can be. If you just say ‘we've got Michael in the corner, he’s our architect, we’re just going to off-shore the coding to the cheapest country we can find and everything will be okay’, everything won’t be okay. When we get to the point, Mihai, 10 years from now, 15 years from now, where you can do that, maybe. Personally, I have a lot of doubts because it’s never been done with music. Maybe it’ll be done with music one day. At the moment, it just doesn’t apply, it absolutely doesn’t apply and these product failure rates, these project failure rates, and these company failure rates directly correlate, not perfectly obviously, there are lots of factors coming into play, but there is a direct correlation between these failure rates and the use of so-called commoditised development.
Mihai: Right. Of which I think the APEX is the most far though-out vision: the citizen developer. I think you’re familiar with the term, it means that anyone off the street can just sit down and write code. All they need to do is express what they want any application to do.
Cliff: Yeah, and that’s an interesting point because I try and get people to do bluesky thinking and I say, ‘what would be the ultimate realisation of this process?’ The ultimate realisation would be you just think about it and it happens.
Mihai: Okay, right, that’s even more far-stretched.
Cliff: That’s at one end of the spectrum. Well, we can’t do that yet, so what’s the minimum we have to do to get there? And, this also relates to product development rates, and the lean product development method, and agile software development methodologies, which is... That thing of thinking about what what it is you’re trying to do, the citizen developer, that’s a thing people get wrong massively.
Because, a number of start-ups, let’s say, are going to build X, and then they stick to it, and then they build X... If you analyse the failure rates of those sorts of companies, they’re massive.
The success rates are highest for companies that use the lean product development method which says‘I think people need something that can do X. I’m now going to go and speak to people. I’ll think of a way of saying it to them.’ Then, you go and see a few people, they ask you some hard questions and you think ‘right, okay.’ They seem generally interested, but not quite in the way I imagined. You go away and you think about what your description of X would be and you come back with version two to slightly larger group of people, and you propose it again...
They might just be friends, business associates, colleagues, and then you come back and think ‘this might have legs’ and then you build a prototype. Here’s one thing by the way, you know, what’s one way to separate, commoditised weak developers from good developers? If someone can’t build a prototype, don’t hire them. Simple.
Then you go back and you build a prototype. Now, it’s the funny thing about requirements. I’ve completely taken against the waterfall method. The waterfall method is almost deigned to fail because it stores up risk, misunderstanding, gaps etc, contradictions for you know, six months, 1 year, 2 years, and they only become manifest when somebody eventually sees the system.
Of course, lean and agile methods, you build a prototype and you show it to people. It’s the psychology method. People see it and immediately they come up with 10 things they never said before because what we’re showing them is stimulating thinking in their brain.
So, your prototype generates enormous amounts of feedback and you go away, and you change your product, and then you show it to a wider group of people and get some more feedback. Of course, it’s called ‘pivot’ in the lean method.
You keep changing, changing, changing and that method has an 80% success rate as opposed to an 80% failure rate. The guys who guys who sell X, who are going to build X, they have an 80% failure rate because they’re just basing everything on their opinions of the world, not reality.
Why do so many projects fail? Why would citizen developer fail? He/she would fail for that reason. So, we can’t lump it all onto the developers at all. There is something quite fundamental going on.
Now, why do I say all that in a conversation about commoditised systems development? I think that it’s really important that developers understand that as well.
Developers who think my job is just to sit and write code, they’re missing the point. Their job is to facilitate success for their client or their employer. If they don’t understand what success is, and they don’t have a view on the product and its utility for people, and why it has a great deal of utility for people or might have.
Then, again they’re going to make the wrong decisions, so I think they really need to be plugged in to that bit. That bit is going massively wrong as well, not just with the commodity developers, but there is an overlap. There is an overlap as well.
Mihai: You’ve worked with, or let’s say, been exposed to several companies led by obviously, extremely brilliant people, who started out small, some of them. Some of them are already big. Let’s say, who a while ago turned to skilled developers for whom they were ready to pay premium, however, once they got massive and actually had access to more resources, then switched on to much much cheaper development models. Why would you think that happened?
Cliff: Well, sometimes people don’t realise what it is that made them a success. As you know, I started with one company that was 35 people and it became 13,000 people. You know, it was a fantastic success. There is something about, and I do say this to people doing start-ups, and I said it to this particular team as well, which is: they were determined to keep it as a relatively small number, you know, hundreds not thousands. Very high-quality people who can more or less do anything, and that would be a very pleasurable place to work, and I said it won’t happen because this group of highly talented people, including highly talented IT people, will build products and services that are so successful that will grow much more than you were expecting.
Then you’ll become a victim of your own success. One of the examples they used was, the biggest beast in their particular domain had thousands, tens of thousands of people, and a very low margin, let’s say 7%.
Whereas, the margin at this start-up was 50%, and there was talk of ‘we’ll always keep the margin at 50%.’ We’d rather be 400 people and 50% margin than 10,000 people and a 7% margin, and I said it doesn’t work like that either. I actually know the chairman, the son of the founder of that much larger company and they said that as well.
They became very successful, and then you become a victim of your own success. Then what happens in any company that grows and is successful is that you have to employ the sorts of people you said you’d never employ. You know, being slightly facetious here, the people who write emails and go to meetings and so on, so on. You know, lots of people who create business processes and bureaucratic processes, you know there’s a lot of budgeting, HR processes etc. You know, all those things that people instinctively go to... Start-ups perhaps, to get away from the corporate processes.
I also said to them, these things are there for a reason. It’s inevitable. They’re not just spurious they’re there for a reason, and then you get into cost-based accounting, then into why we’re spending so much money on IT, Mihai. So a very long-winded answer to your question.
So eventually, you get down do ‘can we do this for less?’ Then the poor old CTO who, for years, was able to go and hire people for 1500€/day who were brilliant, and you and I know some brilliant people that you’ve supplied to me. People who’ve won world hacking championships and so on, and the value...
Let me introduce the concept of value here, I think everything that you do should be measured in terms of its ultimate value. You know, some of the projects you and I worked on brought in many many millions of dollars in revenue, many millions. So, it didn’t matter that we were paying somebody 1500€/day when another off-shore provider could do it for half that, or less.
It didn’t matter because if we’d gone for the cheaper person we would never have gotten the highly successful product, we’d never have gotten the millions of dollars of revenue. So, those CTOs who were my peers at that particular company that you and I both know, they had a free hand to hire the best people and they did understand the quality difference.
But then, when it became 10,000 people and more, then they had to answer to not only the Chief Financial Officer, but budgeting committees and everything else. And it was all focused on making sure they address the margin, because if the margin goes down, and then the share price goes down, and of course by then, you’ve floated. It’s a whole different ball game, Mihai.
That is the harsh reality of how it happens.
What can we do to help the CTOs? Well, the CTOs and the CIOs, I feel, need to make a stronger case for quality, about the value of the output, about the difference between people who cost 1500€ and people who cost 200€ a day.
But I also think that the nearshore suppliers, particularly, should be making that case as well and shouldn’t just say ‘yes, I can give you people for 200€/day.’ I think you should at least launch into the Cliff Moyce long speech about why it’s not a good idea.
The cause, and how can you mitigate those problems? You know, give the CTO the words and of course, these days, in very recent years, we now have some nice case studies, going back to the WhatsApp example, it’s not the only example, but when you look at other stuff that’s been built with small teams, and I think things like Trello and so on... And just say you can generate tens of millions of revenue from a small team as long as you hire the right team and pay them two or three times what you think the market rate is.
And this thing about the market rate, it’s horrible, it’s not true. It’s just not true.
Mihai: Do you think there is no real market rate?
Cliff: No, I think, what there is, and this is the thing that non-IT people are not doing... I can find almost no one who can do this well these days, and it’s producing business cases. I think, any company, whether it’s a start-up or a large corporation, going to build something new, or re-engineer something, should produce a business case which really, you know, analyses and validates what the value to this organisation of the new product of this service is going to be.
When I say validate I mean going out and speaking to real customers. Which, for some reason, people are terrified to do. It’s the number one thing they should do, it’s where you get al you best ideas. But, you should validate it. Once you come back and you say look, you know, with the best will in the world, this project could be done by 20 people in six months.
It doesn’t matter what you pay them when the revenue is going to be so high, and if the revenue isn’t going to be so high should you be doing it at all? I really think that, you know, I’ve spent 7/8 years now working with the financial services, capital markets aspects of a relatively larger-growing professional services company in capital markets. And, you know, we found ourselves having to help our clients with that a lot.
Giving them the tools to go to their peers and say this is what you’re going to get from doing this. But, it can only be with people of a certain quality, and one of the other things I hate is job titles. There’s junior developer, senior developer, architect, ‘how much do you charge for an architect?’ ‘how much do you charge for a business analyst?’ ‘how much do you charge for a project manager?’ It’s the kiss of death.
Mihai: Okay. Can you delve a bit further into that, because I think it’s very interesting?
Cliff: Yeah, because, again it’s about commoditisation. What you want is to fully understand what your proposed product or service is going to do for whom, and what problems it solves for them, how you could market it, what you could expect to earn from it, and then with a high-quality team, what you would take to build.
That high-quality team should just be referred to as engineers. I think job titles, they reinforce the commoditisation. Also, they massively reinforce the division of labour, the waterfall method. Waterfall, as we all know, is some version of analysis that is design, build, test, release, you know. And you can call it discovery and, you know, requirements gathering, requirements definition, all that sort of stuff. Those job titles, if you think about it, match a model of world which has been proven to be the highest-risk way of building any system. It stores up mysteriously... Everyone’s building a requirements document, and the requirements document has never been seen by a client and so on, and so on.
So, I just think you need a group of people who, together, can build the service, and just call them engineers. You know, I’ve seen slightly radical articles saying you don’t need business managers, you don’t need project managers, you don’t need this, you don’t need that, you just need engineers who are so good that they can envisage the product, speak to their customers, make decisions and build it, and in the process of building it, they’re designing it.
Mihai: Sort of the stem-cell engineer.
Cliff: Yes. Correct, and this article is both right and wrong. What I would say is, it’s great to have people with business analysis skills, it’s great to have people with project management skills, you know, there’s a list of skills... This is the agile method,
I implemented agile in another market data company, not the one we’ve been referring to so far, but another market data company, and by implementing agile I didn’t meet developers mumbling at their shoes every morning. You know, I met multi-functional teams who were focused on building working software in relatively short time periods, sprints, which they then showed to the client, and got their feedback, and so on, and so on. And, you know, I didn’t want people referred to as developers and testers, because then they sat there, and this is what happens initially, and somebody would say ‘I’m not doing that, I’m a developer, I’m not doing testing. If you make me do testing then I’m going to leave.’ And we would just say ‘goodbye’ because we actually want people who would enjoy doing anything.
You know, it’s just like, how are we going to get this product out the door, and make our customers a success and make our clients a success, and make ourselves a success? So, that’s why I don’t like job titles or daily rates and that sort of stuff. I need somebody to say ‘this is going to generate millions for us, but also for our customers. It’s going to generate millions for them. Let’s think about the skills we need and the people we need, and how long we need them for. Let’s estimate the cost of doing this project, at least up to the minimum viable product level, and then go from there.’
Mihai: Yeah, I think it’s also a matter of people being very apt at estimating costs, but not so good at estimating revenues or lack thereof.
Cliff: Absolutely. I’ve been shocked recently. I just can’t find anyone who can do it. For the people who know me and are thinking I can do it, well, I apologise to them. Part of that disappointment is because when I started off in manufacturing and engineering, it felt like it was a more commonly understood way of working. You know, it was almost the culture that whatever you were proposing to build would have to repay itself three times within three years. It was kind of that level of... It seemed a more common way of doing work, but now it’s been lost and it’s fundamentally important because it should drive everything. Now, we’ve become very focused on cost. That’s a commoditisation trick of course. We should focus on value because again, it’s hard for me to go into and explain on a call, but maybe I could write and article for you or something on this one day, but, what is the difference between the value generated by a really good developer and a commoditised standard developer? Probably a wonderful human being, but really with very little training and experience and exposure, and so on. What’s the difference?
You know, is it ten times more value generated by that...?
Mihai: Yeah, well the 10X...
Cliff: It’s a hundred times higher, and I could write an article about ‘how it is a hundred times higher’ and well how can I prove it? And then there’s, you know, again, this thing, I wrote that article, ‘The Dirty Secret of Financial Technology’ and you know, the way the whole financial services industry has accepted than any system that is built needs to be supported, but support is just really fixing it over years, and it costs a fortune. Yet, developers were trained and educated in the former Soviet Union are typically, certainly in your city, Mihai, they are typically trained for the first two years on embedded systems development where bugs are just not an option. Bugs are not an option because it’s going into the field, whether it’s a washing machine or nuclear bomb--
Mihai: Yeah, you can’t go into the field and fix the washing machine if it’s faulty.
Cliff: Exactly. There’s no terrible thing of bugs going into production and people spending years fixing it and you know, I was hoping that nearshoreoutsourcing would bring that culture to the West, the UK, to Western Europe, to the US. I actually worry that we’re polluting the minds of the Eastern European engineers with our sloppy ways of working. That’s another podcast call, isn’t it?
Mihai: Hopefully, I’d love to!
Cliff: What’s the increased cost from using weak developers compared to super strong developers? Again, it’s not that it costs ten times more to support, it costs a hundred times more to support. You know, the ‘business people’ including myself in that cadre, they don’t understand that. They don’t. Fundamentally they don’t, and I think there’s a big education process needed. I’m trying to do it myself. You know what I’m like, writing articles and banging on about it to everyone. You know, I can only scratch the surface, so...
Mihai: So, what do you think any company like Cegeka, or let’s say, another company that really wants to preserve its reputation in the market as a provider of good solutions which are not legacy code from the moment they are written? And I’m quoting you on this, I like that expression. What do you think they could or should do in order to push the message forward? Or, what else could they do to really prove their worth in front of prospects and customers?
Cliff: I think that they can do what I’ve been doing for the last few years, because obviously I’ve been a buyer in professional services for years and then for the last 7-8 years I’ve been a provider of them which is to say these things, and to educate, and explain. I always say to people, ‘you might say well, you would say that, Cliff, because it’s an advantage to say that to charge us more’ but I think there is...
I’d like to think there’s an aspect where people realise that I’m really genuine about it because I can talk about it from both sides. I can give examples, I don’t want to give examples on a podcast, but in private I can give examples of organisations that have made what I feel is the wrong decision and the impact it has had. Even ones where me and my guys have had to go in and rescue the project, or even the company, because I did work in company rescue for a few years.
So, I’m not saying walk away from it and we’re not doing that. One of the things I say is: we’re not a body shop. We don’t just provide people, it’s not what we do. We’re a massively value-add, we partner with our clients long-term, not just single projects. But, if you wanted to do a single project and we like the idea of it, we’ll do a single project.
Generally, our clients, who are some of the biggest names in the industry, are clients for years and we do multiple projects. But, more importantly than that, we help them decide what projects they should do, and why and how. There’s a massive value-add in all of those things, including the how. Then we do it because of the massive failure rate in the industry. What we don’t want is for you to fail. Not because it’s monetary to us, it’s because it’s not why we come to work.
We come to work to do a great job for your and to share in your success and have that amazing feeling. There’s one exchange where we built a blockchain enabled settlement process. The first one in the industry and it stripped out 99% of the cost of doing private market settlements, and it stripped out an enormous amount of the time. Probably close to 99% again.
Mihai: Impressive.
Cliff: I can’t remember how much money we made from that project and I don’t care because we’re so proud of doing it, and it wasn’t our idea, it was their idea. But we’re so proud of having been involved in that, and that’s why we actually come to work. We would hate to just work on our project where we think the client is doing the wrong thing. There’s an element of, well if we go in we can help and coach and advise and so on, but...
So that’s what I think all nearshore or all Western onshore... IT professional services companies can do is, you know, they’ve got so much knowledge and experience; share it, apologise maybe for the fact you’re going on about it again and you might think it’s not of interest to them, but do explain how you operate to avoid errors. It will cost more in the short-term and save them perhaps everything in the long-term. You can use case studies, there are case studies. You can use your own case studies.
Mihai: Yeah, those we have.
Cliff: Exactly. We all have them.
Mihai: Right, well, this has been extremely useful and pleasant. Cliff, I want to thank you for taking the time to talk to us.
Cliff: My pleasure. Thanks for inviting me on.
Mihai: This won’t be the last time.
Cliff: Okay. That’s a deal.
Mihai: Okay, alright. Thank you so much, Cliff, again, and all the best.
Cliff: Thank you, bye bye.