Hey there! Technomancer is a Jacques Artgraven. And welcome to another episode of Hack the Hologram. I get to sit down today in a little bit of an interview with the CTO, my first in a series of these with Rowan Ziman from Teljoy. He is the Chief Technology Officer as well as the director of a company that’s been with us in South Africa for more than 50 years.

🧠 Key Insights & Takeaways from the Episode

1. Legacy Doesn’t Mean Obsolete—It Means Inherited Responsibility.
   Legacy systems often house critical operational knowledge. Modernizing them isn’t just about tech, it’s about honoring the evolutionary path of the company while carefully refactoring its DNA.
2. You Can’t Build for Everyone—And You Shouldn’t Try.
   Teljoy’s strategic focus was sharpened by understanding they couldn’t cater to every customer. Narrowing the avatar was what enabled better product-market alignment and reduced tech debt.
3. “Fail Fast” Only Works When Failure is Safe.
   Encouraging failure in innovation is powerful—but it requires pre-agreed benchmarks for success and failure. It’s not reckless when it’s intentional, measurable, and reversible.
4. True Innovation Happens in Parallel, Not in Place.
   You can’t stop the train to change the tracks. Rowan’s method of creating parallel systems instead of halting legacy operations demonstrates how transformation can be incremental and low-risk.
5. From Order Takers to Business Partners.
   IT departments are often relegated to “implement what we say.” Rowan’s leadership pivoted the tech team into a strategic force—co-creating solutions instead of passively delivering them.
6. Ego is the Enemy of Progress.
   Developers must unlearn perfectionism and overcome imposter syndrome. The goal is not mastery—it’s momentum. If you’re afraid to be wrong, you’ll never be innovative.
7. Speed to Value Beats Perfection Every Time.
   Whether it’s a spreadsheet, a Google Form, or a basic prototype, showing working value quickly builds buy-in and drives funding for more robust systems later.
8. Remote Work is a Trust Contract, Not a Perk.
   Teams must treat remote work as a privilege with responsibility. Misalignment and broken communication loops erode trust fast and push companies back toward micro-management.
9. Hiring for Learning Agility, Not Language Specifics.
   Giving candidates unfamiliar tasks tests how they learn—not what they know. This approach exposes adaptability, creativity, and resilience—traits essential in dynamic environments.

CHAPTER GUIDE

00:00 – Intro to Hack the Hologram & Guest Introduction
00:40 – The Reality of Technical Debt and Legacy Systems
01:39 – Why Startups Fail to Scope Requirements Properly
03:55 – Is the Customer Always Right? Or Just Misunderstood?
06:10 – Lessons from Trying to Be Everything to Everyone
07:15 – Evolving the Customer Avatar at Teljoy
09:17 – Prioritizing What Matters: Customer Value Over Features
10:23 – Using Customer Complaints to Drive Product Development
12:04 – Data-Driven Decisions that Build Trust Internally
14:17 – Breaking Through Old Paradigms in Legacy Teams
17:38 – Creating a Culture Where It’s Safe to Fail
19:20 – Developer Ego vs. Progress: Encouraging Imperfection
21:30 – The Problem with Developer Hiring Processes
24:15 – The Cost of Chasing Perfection in Tech Projects
25:14 – Two Types of Developers: Operational vs. Architectural
29:15 – What Really Makes a Developer Rise to Leadership
33:16 – Remote Work, Productivity, and Accountability
39:01 – When Sales Promises Don’t Match Developer Reality
39:47 – Making the Case for Cutting Tech and Innovating Anyway
42:01 – Moving Beyond the ‘Order Taker’ Role in IT
44:52 – Building Modular Systems to Modernize Legacy
46:07 – Prioritizing Tech Projects Based on Business Value
49:12 – Evolving Your Leadership Mindset: Speed Over Perfection
51:19 – Why Perceived Value Beats Technical Sophistication
53:11 – The Cowboy Method: Go Ugly Early, Iterate Fast
55:14 – Managing Remote & International Dev Teams Effectively
57:57 – Managing Assumptions and Scope for Long-Term Growth

This is a company that’s moved in from the retail space and is now moving into more areas of merchant and payment gateways, with a whole bunch of other new and interesting things that they are working on and developing behind the scenes. I get to sit down today with Roy and his dear friend, as well as a brilliant CTO, to explore the ins and outs of the technical debt.

How do we take on legacy systems? How do we work with remote teams? How do we translate requirements over from non-technical parties, and how do we get people that have been set in a very specific frame of mind, with best intentions to adopt higher risk profiles, as well as what is the ways to actually demonstrate that, to invoke trust with the team.

So if you are finding yourself in the exploration of growing and expanding, I think you will find a lot of useful insights from Rowan’s years of experience. But without any further ado, sit back, relax, and let’s learn some new techniques for hacking our hologram.

And then I chose the technology to understand the implementation requirements. Yeah, we in the business all even the fundamental requirements of business needs to have prior to an implementation, you know, so I maybe I was a bad example, but an asset solution more often than not requires fundamentals. And the fundamentals may be the way that you access your data or how much data you’ve got or how you’re going to link your data sets together.

Right. So you do even have a centralized data warehouse merging all of different systems together, you know, and that would almost be a precursor to any sort of solution. Yeah, it but that would start at the end, at the end resolved to the wanted now. And I think that’s a that’s a dangerous game to play. The dangerous it’s a dangerous position to be in with the CEO doesn’t necessarily want to listen to his advisors technical point of view.

And more dangerously, when it comes to timelines. Yeah, you know, how you start to manage that. But that sort of value adds the reality to the business, for sure.

And I think that brings up quite a couple of like, I think, important ideas because I mean technical data, something that destroys a lot of startups, but they’re not thinking through that. They don’t even know what the metrics are to measure. I think in the first place, often in those cases. So they, they, they kind of come with this wonderful idea.

Maybe they’ve done a degree of research, but they’re not necessarily clear on what are the existing available solutions. What is the actual fundamental need. And I like that idea of almost deleting things sometimes from the spec because they’re nice to have. And people will say, oh, we need this, we need this, but what’s the actual business case for it?

How do you argue that, though?

So from a startup perspective.

Yeah, let’s start there.

Yeah I you know, I think I think the mindset that startup is is a bit different though, because the market for that startup is get to market quickly Rots. And it depends what type of business it is. You may not even have done any due diligence around those requirements. So how do you now start to send it to remove X, Y, and Z when you’re going to market some brain parts, which may or may not be a great idea, but you want to get to market.

Yes. So I think that discussions are a bit more difficult. You know, for that, CEO Richard Price got some involved. But getting the in the technical side of things at least understands it. But the second you drafted, quote the second draft any line of code technical debt. Is that right. So I think that there would be a bit of a challenge.

How do you how do you mitigate technical debt? What will the magnitude of technical debt, the limiting requirements with the requirements, more often than not haven’t even been vetted or tested in the market. I think the conversation will shift quite differently later on in the business lifecycle. You know, when when potentially you could actually talk to your customers directly.

You’ve got customers who actually, and you can almost test those in sandboxing environment or an AB test as opposed to, you know, just going to market like a startup.

That’s a good idea, a good thought, because, I think there’s that argument. Right. The client’s always right, or the client doesn’t know what they won’t do is right. So, so so which one is it like it’s been I think especially in the South African climate like so. So what’s the what’s the choice there?

I think they’re both right. But at the end that’s okay. You know the client doesn’t know what they want I think can hold true if you understanding the value at for at very least understand the challenge that that that you perceive them to be having. Yes. So they may not know what they want, but they very much do know what they what they want, what the challenges.

Oh yeah. So, you know, that’s be a great example to test. But my assumption when not solving for brought is what I’m solving for solving that. Is it a real challenge. They might have not they want but they know the pain points. Yes. The customer is always right. You know. You know we we are retail effectively a retail business.

You know, one would argue in retail the customer’s always right. But but to what degree where do you draw the line. Because if you start to cater and I think that’s been a great lesson for us is at some points along our journey, we tried to be something to everyone to come, and that was a bit of a problem.

Yeah, we can’t be. We can’t be right. Every single person, you know, in our business, in particular in the, in the rental space and a lot of people turn the nose up too often. I don’t want to rent something if I’m going buy it, and that’s fine. It’s not for you, you know, it’s not for everyone. As as a business, we can’t bring business.

I guess you can’t be everything to everyone. And trying to do that the customers are after, or which customer is the right customer for you. If it’s right, customer for you. Well, it’s interrogate that, you know, and I think that that you can’t look at one in isolation and say, well, they always rot or they don’t. They’re what they both have their merits provided you just diving just a little bit underneath.

So, so in terms of that kind of user avatar, like if you look at a company the size of Telstra, was that when you, when you stepped in the CTO role and you moved into the, you know, with the company, was that user avatar, that customer avatar well defined, or was it an exercise that you kind of had to work before as one that’s consistently evolving?

Right. That kind of like set start?

Listen, I think. For us, and in particular, since I’ve joined my roles, yeah has been around the digitization, optimization and automation of the business. And by virtue of that being the customer avatar has changed significantly over time. Either that or we’ve understood our customer more over the top.

I don’t know which one it is.

Makes sense.

But certainly one can say that we now joined. There was a bit of a hobbit. Okay. Where are we trying to be. Everything to everyone. What does that mean for us. And then, you know, again that leads us off into pitfalls that you’re solving for things for potential customers who actually aren’t customers. And that is a financial cost to the business.

Yes.

So the bottom line. Yeah. So, so, I guess it’s been it’s been a little bit more interesting in my journey just seeing the evolution of that, that requirement come to that, you know, when we are a little bit we were a little bit more observe it and understanding of what that is. And that translates itself back into our marketing.

Okay. Because then the marketing can start to, direct their efforts in the right space as opposed to spray and pray.

I like that it’s a bit more technical and data driven decision like curiosity. There is. How do you argue that? Because, it’s it’s out of that process coming in. You have to kind of define technical requirements. You have to kind of figure out like what’s actually value driven for the real clients and what are the nice to haves, because everyone has that kind of speculative idea of what they think will work in the product versus what actually, it’s all worth the time and effort to do it, even though it’s a nice to have versus, you know, we’ve got to make that decision, cut those and locked down on these specific things.

How did you kind of make those choices? Yeah, it’s very different.

It’s a very interesting it’s a very interesting question. And I think again, our approach, we’ve been quite fortunate and my journey has been quite fortunate in the sense that we’ve been running in the startup mindset with history. All that a corporate vetting said makes it. Yeah. So we’ve got a nice hybrid. And what that is me, what is made for me is I’ve had years of data, to correlate and test against.

And again, was that data true? You know, a customer in the country 20 years ago was not shopping in the same way. Shopping? Yes. E-commerce was not what it was like 20 years ago. But again, we drew a line in the sand at some point. We ignored history and we looked at customers from a certain date. So if it was three years, four years back, but even more so, I think what we did well was we started to interrogate, customer care evidence.

Well, even the customer complaints, even the compliments. So we started to interrogate that a lot more. And we would categorize our tickets. So we would look at our platforms and say, well, those customers coming through our platforms, querying things, complaining about things, whatever it was, that was our first point of code time, because by categorizing those, we could see where the biggest effort would have been and instead correct.

And then we could say, well, based on these, you know, let’s say the top ten complaints, a query is coming through the business because they’d shift that out and say, well, what what’s a quick, you know, what’s the quick ones to do? And you can almost put them into a matrix to say, if it’s us. So we didn’t lodge versus then.

Right. So we want to quickly say small efforts are very those are those are your low hanging fruit. Let’s do those now so that it becomes clear prioritization matrix. So effort versus customer value which to some degree is a little bit of a thumb suck because you’re assuming that based on making a sheet of queries or complaints would be more valuable for us.

So that’s what which I think is.

Common, which I think is a fair assumption to like. And maybe we do need to mark every single time, but it’s a factual decision. You get the numbers, you go to quadrant, you know, and then you can work through from there. And that’s what we started to do. You know, we started to knock out the low hanging fruit, low, low effort, higher value and then start to prove that those initiatives coming in were really lousy results, because now you’re actually number one, you targeting value to customer, real value to customer, and improving productivity in a certain business unit.

And the customer came rough because they fielding of those complaints getting measured that the complaints of dropping, you know, more queries in a certain area. So how we normally approach things I like to approach these projects. It would put our policies down and the hypothesis would be I don’t know. We’ve seen X number of queries coming through per month.

We believe that a project targeting that particular avenue to do X, Y and Z should realize that 50% drop in queries. Okay, that’s measurable or measurable, right? So then in a business case there’s a tangible pivot. There’s a measurable business case. We can say well 50% drop I can I can quantify what that means for productivity point of view.

I can’t quantify a customer experience. That’s always going to be a very difficult number to put down. And now you can go back into business and thereafter it’s going to cost. And this number of you with X amount of men, based on the effort to develop the solution, this is going to be the return. Let’s attempt it. If the business in risk appetite is dead from the business leaders or the CEO or whatever it may be, or the board, you know, you put that measure in three months later, you take, you know, you take a litmus test and see when you are did you hit the mark?

Yes we did with this investment. Beautiful. Let’s carry on. Now it’s time to build trust. We starting to build value add decisions back into the business as a leader in.

Yes it makes it that I mean that’s perfect. Like you’ve got the data. You’ve proven a series of test cases. You’ve got a hit bottom hypothesis, you’ve clarified it. So it’s very measurable in specific goals. You were able to use that as an argument and obviously stay flexible short right. Are you hitting that measurement or you or your assumption incorrect.

And now you’re building up the data. And that becomes a good argument because you can demonstrate in marketing this is the benefit in business productivity. This is the benefit. What if you’re coming into a space and you’ve got a lot of bias of old world view, because you make an interesting point. You came in. There was a lot of data of commerce in the old days, pre Covid, pre online shopping.

So there’s established kind of certainty of we’ve done this for this long. We’ve got these kind of cases. And there’s obviously the knowledge of we need tech. We have to stay relevant to keep updating. How do you make those arguments to I think support and maintain rapport with a team that’s still kind of embedded in those paradigms and then support them going forward with this new idea.

That’s a challenge. So just to clarify, are we saying the paradigms of the past?

Yes.

Yeah. Listen, I think. As well myself experienced that. That’s quite hard because again we’re over 50 years old. Yes. Some of our employees have been here for many, many years. Some of their employees have seen us attempt these changes, these hypothesis. And it didn’t work over the years. So yeah, I come in, you know, fresh bushy tails, you know, try and do these things.

And they and they turn around and there’s resistance because we’ve tried this before. It didn’t work. Wow. Why would this be any different? I think that’s what you this you kind of referring to that the those mentalities and I had I had an individual who came to my team was with almost that exact mentality in and I think one needs to understand where they’re coming from.

So all that individual really wanted number one was to be built, which is fun. They were heard because they were critical to me moving forward, because they had all the domain knowledge and prior understanding of why things were done the way they were done. Yeah. So we couldn’t afford to lose individuals. I mean, they’re very important to the business team, but over time, it took a long time.

It wasn’t a quick fix. This took some time, okay.

To be fair.

But their frustration was really stemming from a sense of they didn’t feel that they were adding value back into the business.

So they wanted to be part of a winning team. And over the years they sort of the part of the losing team, so when a decision was made, their intention wasn’t resistance to be malicious, at least from my experience, was it wasn’t the malicious just blocking you like of blocking you. They were coming from a place of saying, we’ve tried this before.

I don’t think your decision is right because we’re going to fight and other will be part of a fighting team again. And the only way that I could change that was first proof projects outside of that resistance. Yes, that resulted in real wins that they felt comfortable joining the winning team. Okay. Be on board with the winning team.

And then what we did is we enabled the individuals to almost speak or be part of the decision making process with those projects where there was resistance. So yes, ten years ago this didn’t work and maybe it didn’t work because of X, Y, and Z. But you know what? Let’s try now and we’ll try it. And if it fails, you know, we’ve adopted this philosophy and it’s worked very, very well.

Yeah. Fail fast. You know, so let’s don’t be afraid to fail, and that’s okay. Let’s try something. And if it fails, at least it’s no, it fails number one. So we have to have measures in place to understand what is failure mean. We’ve talked about the business case. Right. What is the failure actually mean. And do we have a finger on the pulse in terms of the measurement of that.

If it were to fail, do we have a plan to go back to where before time or to pivot? And that’s quite important because the fear and then maybe I must add that as well. That was also the fear of failure.

High-Impact Quotes from this session

1. “You can’t change the train tracks while the train is still running—but you can build a new track in parallel.”
2. “Every line of code written without clarity is a debt you’ll pay back with interest.”
3. “Innovation isn’t about knowing the answers—it’s about building systems that let you test them fast.”
4. “A prototype that works beats a perfect system that never ships.”
5. “Leadership isn’t about being right. It’s about creating space where failure teaches faster than fear.”
6. “The true transformation happens when IT stops being an order taker and becomes a business partner.”

Which is stemming from this throughout the losing team syndrome. Let’s don’t be afraid to fail. So you can lose your job. I mean, everything you say you’re excited about, but you have to make mistakes in the change space. Yes. Non-operational space. In the change space, we are allowing failure provided we understand what the covering of slack time.

That that opens up a lot. Because firstly, what I’m hearing is the frame of and it’s like in this mature frame of leadership and seniority versus the mid-level kind of experiences, the mid-level is going to immediately feel attacked and try to defend that position instead of understanding the real needs of the other individual. And how do we move forward?

Well, I don’t have the autonomy to, to do that.

Yes, yes. Which is another kind of how is that even argue? But the one I want to just kind of step back into because you mentioned this fail fast idea, and you see that a lot with developers that especially in the mid range, they’ve become very almost, I don’t want to say religious, but they become very wedded to the idea of the technology framework or the knowledge space that they have, and they’re afraid of looking stupid.

And I’ve seen this with a variety of different companies where they don’t want to admit ignorance, and because they’re afraid of failure in science, how do you how do you promote the environment where failure is a given if it’s learned fast? And also so it does not curve the learning process, but in answer.

You know, listening, touching on quite a few issues there, you know, and I think the first issue touching on it is in the developer world, the technical world, there’s this very big mentality of imposter syndrome. And it’s very difficult for developers in this world. You know, the technology is moving at such a rapid pace. One is to keep up, to keep their job.

With all this technology around them, master everything. You know, you can’t just be a domain specialist in one, one certain thing like you could have 50 years ago. Couldn’t know everything all of a sudden. And you got to know everything tomorrow. Yeah. And I feel that even when I was a professional developer, there was always a lingering feeling that you’re comparing yourselves to those that as you, you’re comparing yourselves to maybe international developers all over the internet and telling you things, and you say, I don’t know any of this.

Am I really fit for the job? Yes. And I think playing into that is exactly that, that mask you’re saying, well, imposter syndrome means that there’s also a bit of an ego attached to it to say, well, I have to prove myself always. I’ve always got to. I’ve always got to know my stuff. And unfortunately, that what I see a lot is that results in two things that results in developers.

Maybe not you turning to the business that outside the business fearing saying, I don’t know. Number one getting that egos out of things. Yes. And the other point that you touched on was we the developers that that I work with more often than not crave perfection as opposed to speed. And again, it touches on this, this mindset of ego might be the wrong word, but his ego, you if we want, is good.

It’s a good corrected his ego to that’s a world which is made up of ego all over the place, even by virtue of how you two views take your place at certain companies. Very much old boys club ego make assessments about paper city. Things are being asked for which don’t exactly reflect the job as of today.

Yeah what the what the or the changing.

Environment or the changing environment. So you’re interviewing process more often. It doesn’t reflect actual job. It’s more that you must pass these checks as a rite of passage before we accept you into the business.

And potentially lose great talent as a result.

Of it. Not potentially difficult 100% team and these guys get through that. I’m sure there are a few businesses out there that did interviewing process allowance properly to the work as opposed to it. You know, gateway, the rite of passage to get in the more often. Not. That isn’t really the case seen.

Again, especially in larger groups where the HR is managing IT or other groups. And it’s not usually the technical team that’s actually even making those decisions.

Potentially, but also even the technical team or still the blockers in the way to say, okay, I’ll give you a riddle as an example. You must even Google at some point loves these sort of riddles. Yes. And it’s fine. You know, you to you testing out of the box, thinking you will argue and testing all these things.

But are you really testing the question? Are you really tested person in the job? You know, and again, I think it’s a whole different arguments around how you onboard new developers. They will get to just now. But I think just, just, just, just to take us back a bit to, to do that, that mindset side of things.

And I think again, what, what I would always talk to my developers about in the beginning of any engagement. And in fact, I’ve talked to the potential interviewing process of a third party or of a developer who’s going to be a full time and working with us is, number one, all you willing to make mistakes? Yes. Right.

We need to understand that there’s a passion involved, not just a working through the code. But again, I’m talking to a couple of developers. I’m talking about a developer now in sort of a change space. But so maybe we can talk about that just now. Types of developers that there’s a this set up that I’ve come across is that in that environment, perfection cannot be the end game, because otherwise you get stuck in this perpetual loop of saying, just one more thing, I need to get this done.

I need to get this, I need to get this. And then we stack 12 weeks later. Yeah. And we haven’t really progressed. It’s you know, and one also needs to be cognizant of the fact that the last 20% of your project takes 80% of the top. So at what point are you going to market, at what point are you testing this hypothesis?

Because you’re perfect points more often than not, not going to be what you’re thinking. The most important things are any tech, those most important things for you right now. But again, you throw it out the window in a year’s time. Very true, if not sooner.

Very true. Like you, you can’t have any sacred cows, so to speak. It comes to say 100% because you don’t know, like you can have all the initial internal arguments and if it hits market, then only do you reading a success. How do you I think like the concept of the different type of developers is very interesting. And that leads me also to your own kind of progress in that sense.

But because the mindset from just developer to CTO moving through the stack is very, very different. It’s completely different people almost that you have to be at these different stages. What are the patterns that you’ve seen as mentioning from different developers, both in-house outsourced, and then just in your own experience and then what do you have noticed are the key metrics for someone that’s actually got the potential to move from that into our position versus their life?

They’re going to be there, you know, until the end.

Yeah, that’s a good question. So I think let’s start with the different types of developers. I guess, you know. What I’ve noticed is that very least there’s the developers can swing to do one of two sorts, the one side being, an operational developer, as I would call it. And maybe that’s where the developers start. So, so in the world we’re living in and got access to so much information, I mean, it’s very easy to come into the tech world without a formal education, and there’s no problem with that.

No one says you have to do a formal education. I have to do a PSC to become a developer, not someone who’s not to finish a case. You can go to a couple of Udemy courses and you’ll get hired. That’s not even a requirement anymore.

So those are the portfolios.

As I of these focus. But what it does mean is that it depends where you on your journey. Of course it does mean that depends on how you got there and how you build those skills. That could be a foundation lacking. Yes. Right. Yes. So you might have just come in and said, I’m just going to start doing PHP.

We’ll see. When you start writing code.

No background.

Computers? Nope. That’s not computer science. And you haven’t gone through the fundamentals of how this thing is working under the hood.

You’re missing first.

You’re missing first principles. You’re getting stuff, then you just what you’re doing is you’re a plumber. You’re right. You just have the things together. You go on to or chat GPT Tuesdays. It’s like, how do I todo this and this together and enjoy them together? Yeah, we stack overflow. Yes. Just because back in the day, but when things go wrong, do you know how to fix it?

We throw out and that becomes a challenge. And maybe those developers and maybe this is where the conversation starts, is those people would start an operational role where they’re doing that fixes to come up to system and, and you, you just you just managing the system. You come in with a framework already in place. The code structures already there, you maybe your documentation on conventions, whatever it is, then you come in and you just hack away at fixing things.

You have your story and.

That’s a different point. So it’s you get a change coming, put the change into the system. No problem. You do your thing, you test it, you run, you go. Yes. Fun. On the other side is a developer who has the ability and more, and I guess is closer to an architect. Developer who has the ability to construct an entire framework from scratch.

What does he understand? The choice of technology? Does he understand the choice of frameworks? Does he understand the choice of structure? And why is everything in place. And that’s quite difficult because you’re starting from a blank slate. Think right what you need a myriad of knowledge and comforting yourself. So this thing is going to hold up right.

Yeah. Now these two are fond or very different. They’re very different people. In fact. And even this person who’s a change agent who’s able to speed things up, they may not even have years of experience, but they’re willing to take the risk. And I find that that person and almost to the next point has a bit of a bigger thinking mindset too.

You can see past the individual requirements. Yes. Potentially will not potentially has to be thinking of the future because the technology choice has to be at least future proof to some degree. Right. So you’re thinking outside of that particular paradigm of change. You think some future, you’re thinking bigger picture. You’re looking at the bird’s eye view of what you’re trying to solve for.

And I think that exactly that exact mindset of high level thinking or bird’s eye view or helicopter thinking is what can help a person rise up if they want to. By the way. Yeah, that’s above that. That developed into a management sort of role, which isn’t for everyone. It’s a technical, the technical resource starving dead is the opposite.

They’re diving into technology. They’re becoming a subject domain expert in that certain area, which is fine. But problem means that doing so you’re putting on blinkers into technology and into a route becoming the expert in that. But you can no longer do, you know, top down.

Yeah. Who’s trapped by the education.

Or trapped implies that that it’s a bad thing.

Fair, fair.

So and I don’t think that that’s fair to say to someone who loves this technology so much, doesn’t want to deal with people because, you know, developers, not tourists or introverts. Yes. So I don’t deal with people. Let me just do my thing which is fine. For the, for the other side or for the other side of the equation, the person who is a global thinker who’s can look at things at a high level, enjoys people but gets that right.

Well maybe I do want to go into a management sort of position with the foundational understanding of the whole tech. But I’m thinking I’m thinking bigger than just this particular problem.

The list, I think there’s also like innovation, as always, being in different areas, the overlapping of different disciplines and finding the matching patterns within them. And so you need to have those as clearly the innovators and then you, but you do also need to have the solid specialists that can actually complete that project until it’s full scope and understand the potential risks that the generalists may not be able to perceive because of that position.

So, how do you, when it comes to the hiring process, working with teams, both internal and external, how do you identify those and which you’re going to be the decisions you’re going to make for a team that you’re going to be working with. And you you’ve been through the Gantlet that’s.

So difficult to do that, you know, how do you identify a person who’s who fits into one of those, into one of those, buckets? And you know, this I don’t think is the right answer here. You know, one can talk it through that personal portfolio of projects. What are they done on GitHub, you know, to try and work out.

But I’ve always found even that doing that, even if they were to do assessments, it’s almost impossible. The latest thing we’ve done, we’ve tried to do is we would give a individual a project, okay, completely outside of the understanding or the knowledge base, you know. So if, for example, your C-sharp developer has a PHP project, for example, and vice versa, completely outside, right?

Here’s a project. Go and create a little Microsoft or a little thing that can do this or a calculator. I don’t know, something small, you know, a couple of hours that can do after the current job. But we’re lucky they’re employed. And what are we looking for? They is the ability for them to learn very quickly a new technology and build something, even if it’s just popping, even if it’s the plumber.

You know, how do they adapt?

How do they adapt to that? Because that didn’t talk to the personas. I’m saying, are they even able to escape their own area of comfort? So that’s step one. You have so that that that that filters out very quickly that the others, but even still the ones who are able to do that, that doesn’t necessarily mean when the pressure’s on in the job and in the role that they’re able to expand beyond.

So unfortunately for me, that can only get unpacked on the job.

So is it is it a case of higher fast fire? Faster? Yes, so to speak. So that kind of describes, I think, a lot about identifying the technical ability to a degree and the cognitive ability of the user. How important in today’s world, post-Covid remote work, remote teams is the company culture, behavioral kind of mix. So in terms of working with remote teams and developers, is it a value?

Is value is the value metric the most important? Is time metric the most important? What are the what are the kind of key factors there. Yeah it’s a good question.

And I think a lot of developers would face a similar sort of question. And it’s interesting in the South African context and what a little, what a lot of companies to measure as productivity is time on seat. Yeah, which is a bit of a problem. But it also works both ways. Why me? So I understand why that’s happening in the context of our economy versus internationally.

There’s still this hybrid work, but even there they’re calling back to the office. You know, Elon Musk, you know all these guys, they want you back in office. Wow. In general, it’s an age old question. How do you measure developer productivity? The lines of code, you know, how do you know how well they’re working. And so there’s only one way it has to be value.

It’s at its very least all we doing value is the time that we predict. So now we’re talking about estimations of Tom. Which, which, which every developer hates. You know these companies underlying complexities. Devil is the detail. We don’t quite know. That’s all we know with no business sense. Yes. You know I’ve always used analogy if you want to build a new home right.

And you said I want to build a double storey six bedroom home. Great. What’s it going to cost me? Well, let me go ask an architect or a bulldozer. Give me a price. Not if they turned around and said, listen, John, I need 6 million rand from you, but actually don’t know how long it’s going to take me.

It might be 10 million or 20 million range mark. So you need an exit that. Yeah, you’re going to want to project to say, well, guys, I might pay you a bit more, but you need to give me a deadline and you sell my house, maybe, and you make plans and you be living somewhere else. You’re going to want concrete plans when your house will be complete and even in this little slippage.

But there’s something so. Well, we might hate the concept of estimations. And it’s important to understand those costs.

Especially in a business.

100% in the business. But I mean, if a developer, if somebody is providing value to the business reliably, right, can the business turn around or is a fair for them to turn around and say, we’ll come back to the office? No, you probably all it’s not fair. But they don’t give you I’ll give you an interesting, anecdotal story for this, you know, and this happened quite recently, apparently.

1:00 we’ve got teams of developers, right, working with us, some of which are remote, actually most remote. But we check in occasionally in the office, more of a hybrid approach. We had a we had an issue where, something wasn’t working on one of our platforms. Our remote team was responsible for this particular piece of work, and it needed to be resolved immediately.

Okay. No problem. Now unfortunately it was a series of just unfortunate events that had happened to one developers and leave. There’s only one available. And he decided at that moment without telling me he’s going to the shops for them during working hours, which I’m sure everyone does. You need to go running errands if I please inform me manage.

If you’re going to do that, please. He did that and he said to be better now, no problem. Three hours later this is not resolved and we can’t get hold of him. And the point I’m making is those sort of incidents don’t inspire confidence that we’re able to self manage our own time when working remotely. If you were in the office, you’re not going to just go out and randomly go and run into your personal areas in between those hours.

And so one often needs to be cognizant of the responsibility you have when working remotely and being. Mature enough to understand what your time commitments are, or at very least, what your responsibilities are to business. Yes, and I think a lot of companies have seen that that be taken advantage of. So they’re calling they’re calling it back. Just from a discipline point of view or just having their, I don’t know, it’s not there to be corrected.

Any companies are using that as a source of productivity, real time on set. Because if that’s the case, then I don’t I don’t see the value ever on the chain, you know what I’m saying? Like that’s not going to be accepted regardless.

Is the problem with both.

Is a problem.

Yeah. And I think the argument you’re making is quite a valid one, because I think if you’re if you’re in collaboration with a team where there’s code dependencies, everyone’s working on a portion of work that has a communication requirement with each other, then time on seat or time in office kind of really has a big value pair, because the more you’re out, no communication.

That’s a buffer or a blocker for other team members, which again reduces productivity versus when it’s a more isolated space that doesn’t have the dependency to start up. They still kind of maintain coming up with an idea. There’s one person doing the take, another person doing marketing and design, and it’s a small team of three people may be a little bit less important, still useful, but less important when you’re when you’re scaling that team.

But it maybe you’re not. Maybe to this degree. However, even with a smaller team the codependence is on one another is you hire because there’s no distribution of work. Yeah. So all of a sudden, my responsibility. Let’s talk about the startup as example, you know, as if it’s a single developer, single person marketing a single person in sales.

And the synergy between them has to be extremely tight because of the put the person marketing has to be all the person can, sales can achieve, and then ultimately with what the developer can deliver. And the timing of that has to be very much in sync. If it’s not, you’re selling dreams.

It’s true. We’ve seen the failure in digital agencies with sales teams are promising deadlines, not communicating with the dev team that aren’t realistic. And that causes a number of problems in the draft. Yeah. Speaking of speaking of problems like you stepped in and you inherited quite a code base and quite a structure and everything, and you’ve gone quite innovatively and produced completely new systems, things that are still an innovation, really taking the company to new heights, moving into gateways and other areas like that.

That’s a that’s not a simple decision to make. It’s not a simple argument to make. What made you decide to almost cut portions of those technologies, invest in completely new areas? And what was what was the biggest challenge, not only from a business perspective to shift, but technically in order to adapt.

You also so you know, you’re up to I inherited a system, but the top was 20 years old. I think that could have been worse. I don’t see much resistance. It wasn’t. It’s not as bad. It was an old system, but at least it was just recent. Recently. Okay, technology. Yeah.

Do you need to hire COBOL developers?

Yeah. Not that bad that you mentioned, but find those guys in the grave somewhere. But but you know, the challenge is always going to be how do you how do you optimize or change those train tracks when the train is still going on it. Yeah. So it’s always the developers problem. You know, the train is still running yet.

Now you want me to move this train track, right? That’s the pressure of that industry. Is. And that was probably the single biggest issue I had at this business. It’s running. It’s doing what it wants to do. Yeah. Yet I’m hired to pivot the business a different not a different direction, but a but a direction optimization.

And this training has got me. And not only is the train going, we don’t quite understand every single decision being made and why it was made. Why is this train, why is this train track sitting here. Why is it facing this way. And sometimes one can argue with the legacy system. How does the train even get over the train track?

Yeah, I don’t know. And I keep it throughout.

It’s compile I.

Don’t, I don’t understand that. Yeah. And these are, these are big problems to have. And those problems are going to be to some lesser degree or even larger degree faced by everyone with technical debt. The older gets, the worse it gets. Like I guess the only choice I had. To be honest with you, the choice was made for me because, I had to move quickly.

I had to shock value and that two boats, I had to build something that was going to start moving the business. And again, that talks to this idea of building trust back into the business. The, the idea for a lot of Artie Department zero started here is Artie is often is often an order taker to the business you right so you get told to do something.

George go and build me X1Z. Okay? Right. Tom, we’ve talked about Tom Lyons, all these things. No problem. You get told what to do. That’s normally what happens. The problem with that approach is that business is missing out on the value add that that ask the technical department can give because they’re at the coalface. Yeah. They can see things that can make and they can provide ideas on stuff that the business has even thought about.

The value adds coming out of a massive and often underrated so one needs to leverage themself or should leverage themself outside of an order, take into the business to become what I would term a business partner. Right where you now seen on equal footing to the business in terms of decision making as opposed to the guys in the dark room downstairs until what to do in a shelter if it doesn’t work right.

That’s a paradigm shift. Yes. Right. Especially for the business context. And there’s methods to leverage yourself out of that. So the back to the point one has to short start, short one is to start showing value to the business, proving yourself outside of an order taker to gradually shift that.

Create that trust.

Create that. Trust me to become eventually that business partner. That’s imperative. Yes. So back to your question. I knew how to get I had to get out of that ruts because we were very much at that point in order to go into this. Yeah, business knows better.

And by the way, there’s a deadline.

Of course, there’s always there’s always this and it’s never can disappear in three minutes. Watching how you do it. But, but we have to get out of that. We have to show value. We have to prove ourselves to be innovative and providing innovation back into the business as a process, as opposed to be seeing innovations happening here.

You must implement it. Yeah. Right. So when the when you got to this legacy system running and you need to prevent the only option I had without understanding how to even move this Titanic and even understand what was going on underneath it to was to start creating parallel processes. And parallel systems was the only choice I had. And that’s why we started to we started creating parallel systems which were optimized for the digital world.

They were optimized for technology and optimized for automation. And then all we would do is we would just stop a it once a derailing, we’d just stop popping the train in. So gradually leveraging these new technologies. So train is still running, but we are slowly modularized using the legacy system outside of itself. So it’s a it’s a it’s one approach I guess.

And we took there’s many other approaches, you know, but our sense it’s approach was modular based because allowed us to unpack the in isolation the decisions made and even applicable to others. We couldn’t we just made new decisions on what needs to get done. And then we moved the trade off. This is parallel paths.

When you when you were doing that, was that kind of department based. Was that functionality based? What was the what was the driver of decision there? It was a.

Bit of both. It depends what you wanted to achieve. So, you know, if we wanted to achieve a certain value at and in this instance was going to be a customer experience in the digital e-commerce world. E-commerce journey, cross cut departments in Italian e-commerce with websites with marketing it, the website. You got sales, you know, distribution, good warehousing.

Right. That’s all cross-cutting on any e-commerce website. But the value added functionality is a fully fledged platform. Yes. Right. Which crosscut so we would look at that from again that prioritization of value grab records of department. And once we had start showing something then at least we were given a little bit of breathing. Groups are a tool.

Now let’s start targeting. Maybe it’s a top mental process which ultimately affects the customer or the business, or the bottom line, whatever that return is going to be. But it’s not moving through like that. But I guess that that was just incidental. I guess the approach was always going to be value add every single time.

And do you define value add in terms of this is what everyone in the business believes is the most viable, or is this the hardest problem or the most client demanding problem to solve?

No, so I don’t I don’t think one can take the approach of what everyone in the business believes, because you never going to get consensus on that, because you see that it gets much worse. The businesses and the more people they are, even amongst developers, they get back to the ego story. Yeah, you might not. You would find consensus.

In the hierarchies and right.

At the top. Exactly. So there has to be a framework in place from the business side, at very least on what that looks like. Right. Number one. And the truth is when that happens, that’s going to go in regardless. And then it becomes change management to get to get everyone on board. Yes. But they have to come on board.

And again, the stuff that’s another discussion altogether how to bring that on board and how to make sure the product or the system, whatever its use is utilized and adopted. But I don’t think again, I don’t think the metric is around difficulty, complexity. Because if that’s the approach, again, something hard might not be valuable.

Exactly. Right. Exactly. And again it’s use my example. Hard would have been ripping out the entire system. Right. Shutting it down and building a new one. That would be tough to say.

Yes. And aggressive business and one risk.

Yes. Exactly. So cool. But what am I measuring against? That’s what I’m saying. The choice is always going to be value. Now the question we can ask is value. Way is value to bottom not in the business value to customer value to departments. What do we actually targeting in terms of value. Because it can be any one of those.

Yes. Right. But one has to know what you’re targeting. And there’s no value within the business except it, you know, they’re not going to accept paying a developer or an art department or consulting house or an agency to build something. There’s no overhead. Yeah, exactly. That’s always where the discussion starts. And it’s so that’s what the target that that’s the entry point.

That’s what has to be tracked. And then the decisions is going to be what the number what right. If that’s number one with implementation risk cost and time lands is going to be secondary to that. Do you accept it or not.

Yes. I think this also creates the opportunity as you’re doing that, to set new systems in place that weren’t there to test their systems and evolve their systems. Your own evolution in terms of this development, when we talk about this value, value, add your own values, must have evolved quite a lot from the early days of developer as well as your priorities in terms of mindset, from where it was to where it is today, what are some of the biggest kind of value shifts?

And kind of mindsets that when you’re looking at new change, making those decisions for doing these things, that is critical to you? That’s been the most proven.

Yeah, it’s tough. I think what the success has been and in particular what how am I thinking has evolved over the years particularly has been around the concept of speed. And let’s not use market because market is going to assume as a customer the speed to production kind of. And I think embedded in that comes with, interesting concepts, you know, and there’s been many learnings I’ve had over the years from others around me and some of the examples would be there are certain individuals, business individuals who could argue that, well, you can shut down the whole technical department, shut down every system, and we can run this business on a

spreadsheet, okay. And it’s a great tool to help, because if you can run this business on a spreadsheet, am I really that smart? What am I actually building? You know, I’m just building then. Then once you know the database with the capital of user interfaces, you know, so that almost brings you back down to earth to say, well, if the spreadsheet is my starting point, from a process point of view, you can run the whole business on that.

Then. Then surely I can go to market with that idea that my value must. The value that the perceived value is what is what people can see. You would agree the technical person can’t show perceived value through a database design unfortunately would love to optimize database. It’s scalable and highly available or beautiful, but no one’s going to take that out of that.

Yes. Right. So that’s a front end comes in, not front end is very perceived value. But that’s value because tangible. We can see at the website you can see system. You can see an app on the phone. You can see what happens underneath that hood. Nobody can see. And I think what we’ve done exceptionally well is that it’s adopted.

The approach will at least provide perceived value quickly get that thing into the hands even if it means behind the seats. I’m a story about that. I’m sorry I’m not on a spreadsheet, but a Google form. Some way. Or I’m behind the scenes manually sending emails and pulling strings and doing stuff, right. Yes, we actually don’t want to be there.

It’s say, listen, this is very much a cowboy approach.

You’ve got to make a decision on what time and capacity you have and how you’re getting that.

So listen, what I’m talking about now is not the difference. A cup of tea. Yeah. You know, it’s not everyone’s going to agree with me on this approach. And that’s.

Have that risk tolerance and.

That’s fine. Yeah. And that’s okay. But having that approach and having and having that sort of cowboy attitude, for lack of a better word, allows one to get the product or get the system or the app or whatever it is into hands quickly. And then iterate exceptionally fast. And again that talks to my fundamental principles. Fail fast and you can’t fail fast.

If you spent six months in development. Yep. Get into their hands. You know sleeping for three days okay. It seems to help you know sleep I don’t know distribute the load chart or whatever it may be, but then learn and then you can quickly see where the importance is, is the importance going to be around optimizing your SQL database.

Yeah. Or is import is going to be around making something look good, which is what you’re after. Yeah. And then get the learnings at that pivoting quickly. And ultimately what it allows one to do is actually cheap in the long run, albeit in a shortened shorten. Because you wouldn’t have really committed time and effort to something that you weren’t sure about.

The pivoting time is a lot quicker. The caveat of this whole approach means if it were to scale fast, you’re in trouble because features won’t be. The manual processes made me day and you may be stuck in a position where you’d have to do things that maybe temporarily, just to get yourself out of that hole. So this is definitely a caveat that one is to be aware of.

If you’re making this the sort of, you know, these two markets.

But these are risks on the list, correct? I mean, but the argument is from what I’m interpreting, you could spend all this time in designing a macro micro architecture in AWS using all of its structures and, you know, working across analysis, planning, UX and UI, going through the entire wireframing exercise. And that’s wonderful and technically the right process to go through.

But ultimately, you could do all of that and find no client likes the thing. But I think it was the idea behind notion. Notion. He did all of that work, both the thing. No one wanted to use it. I mean, he spent two years just working on that interface and testing it with people in coffee shops. Yeah. In order to kind of get to that next level.

So I’m going in and I think as we move to kind of like a close to what our conversation today, use obviously in scaling that had to work with a lot of different teams because resources aren’t necessarily immediately available. You’ve got a large demand. Working teams in India working in teams in South Africa across the board. What’s been the biggest learnings?

Because now you’ve you’re in a place where you’re I say pretty stable. You’ve got reliable teams, you’ve got people work where if you’ve got a flow, that wasn’t always the case. What were the key learning factors there that somebody should be considering when they’re starting off in that space?

You know. So I really think there’s two and one is clear communication kind of it actually all boils down to clear communication because the expectation management cannot be set if you yourself are not clear of what you want to achieve. Yes. Right. And the second talked at similar point is that probably should be routing. Right. So we talk about a spec.

You know, maybe you’ve adopted a waterfall approach. That spec is all encompassing than luckily you haven’t. But you that that’s where you can find yourself having a problem because the developer, when you hand over to them and they get they want to read quickly, they want to show a failure. Yeah, they’re going to make assumptions, right. And their assumptions are dangerous because depending on how new they are in your business and as part of your part of the portfolio, those assumptions could be completely incorrect.

Yes. Right. So once you know the Agile Manifesto, you know, regular touch base and check in on the product, but even still, all you are you doing like yourself doing code reviews, are you yourself looking at the quality of that code? Which is another pitfall, but it’s different discussion. But ultimately it’s going to have to boil down to your expectations, have to be set.

Very clear out to if a developer teams of developers, whatever it is exceptionally clear. Right. So when it comes back to you and you look at it, you can’t be upset or angry that something wasn’t done. If you’ve missed the mark. Yeah, I’m leaving the door open to a set to assumptions and uncertainty. Yes. You just you just wrote the story.

I want the messaging system. No qualification, no test criteria, no. This information.

Bad data N equals the bad data out. This has. It’s probably been the best lesson learned. Which is simple, right? It sounds it sounds quite simple.

But the granularity of the thing is that.

Correct? Exactly. That’s. Yeah. So you’re talking blocks and high levels where they get into the detail, they start doing whatever they want. Yes. So again, we could spend hours talking about this, but even architecturally they’re not going to be potentially not thinking about this in the long term. They’re thinking about solving the solution for you right now.

And they’ll probably solve actually. But in six months time, would you to add onto it. Your system doesn’t allow for that because you don’t think of the future. Yes.

Yes, I’ve always taken the paradigm because there’s a common view that that software, it’s like architecture. And I tend to think of it actually more like authoring a book, in the sense of someone’s giving, especially if you’re getting a book. And now somebody’s asking you to change the character profile of one of the characters. You need to go read through everything context dependencies, you may assume, but you didn’t really consider until you’ve read through everything.

And that alone is a big buffer time. And especially when you’re in the early stages, people are quoting on a project or a piece. They don’t know what the rest of the story kind of looks like. How do you I think because obviously you can’t give everyone the time span to do that. You can’t go, here’s the book.

You’ve got six months work through it all. Give me feedback. So you’ve got to break down my new task of managing different teams and different technology stacks. How do you allocate that? How do you manage these different teams on a day to day kind of basis to make sure everyone’s moving the mark forward?

Yeah, this and I think that has to be the primary role of a full time employee in a business. Either it’s going to be the full time architect or the CTO. Somebody has to step up and take that role. And while you may not be able to give them that entire book to read you yourself, you know that book.

Yes. You have to know that book, as you call it, forward. Right? So if that’s the case, then the very least you know how to intermingle whatever it is you’re working on based on history, right, as well as future. And that’s why I’m saying that comes to very clear discussions and not at a high level, clear discussions and regular check ins to make sure that we’re on track and we pivot if we when we have to.

That aligns to what expectations are. If those doors of communication are not open or those doors of communication are challenging because of maybe language or distance, whatever it may be. Yeah, you probably have to find another method to get the points across that side of it. The communication. Yeah. And there’s ways to do that with technology.

Right. Maybe it’s whiteboarding. You know, maybe it’s documentation I don’t know. But that that expectation has to be set and maintained throughout. That’s it’s a full time job.

Closing question in this kind of conversational space, everyone’s leading edge technology has always been a problem. Everyone wants to jump on it, and it’s not fully kind of fleshed out or tested. Legacy. You a lot of it developers that kind of stick to the legacy idea. We know you can’t always do that. You need to innovate.

You need to kind of leverage these different technologies. So two fold. Question one, your position on AI and the utilization of AI tools for coders and to your personal prediction for developers, CTOs, people in the tech space, what they should kind of prioritize, what the landscape may be looking like in the next three years, specifically in the retail and commerce spaces.

Yeah, at this, I’m glad you used the word two, because that’s how I see it as well. You know, it’s become this big buzzword is going to take our jobs away from us. And it’s a silver bullet and it solves world hunger and it does all these magic things for all the.

People removed from the code.

That. Exactly. Yes, but it is a tool. Yeah. And unfortunately, with the shiny new hammer, everything looks like a note. And one and one just needs to be very careful of that. And this is not that we’ve seen this many times over the years with do technology. And it’s a great technology. Yeah. Fit for purpose. Yes. 4040 for now in certain contexts.

But it’s a good technology, right. Just for fun with that is I think I think again back to that points. The, the focus differently is around data. That’s where the world is moving. There’s a very much, a shift there to the utilization of AI, into our general as a tool. So again, are we using Copilot or, or GPT TS or, you know, whatever, whatever is your flavor of the day, use virtually of the day to assist you doing your job better.

But what you finding now is that with platforms where and Google’s quite a good example, you know, if you were to think about how you would search back in the day for problems, even code problems, you know, you have to work out your query, right? It couldn’t be like a plain English query. You could get ways of weighting things that you use vetted commons characters everywhere.

You do things in a way to get you the best results, more often up to query Stack Overflow. But you tap that in a way because you get your results. Yes, the way that you use the technology now to achieve something similar, you just tap it’s an English language, right? So our consumption of the technology and Google’s that example has fundamentally changed.

And I think for me that’s where the utilization of focus should be. In particular in the retail space. You also the commerce space is the consumption of our systems. And we need to find a way utilizing what we’ve got available. And as it progresses to make it easier for, for our users to transact, to go through, to market, to, to whatever it is in a way that, that that, you know, that that’s exactly what Apple did many years ago was in 2006 when the iPhone was launched.

You know, that fundamentally changed the landscape of something as simple as creating the whole thing as touchscreen. Yes. Bearing in mind there wasn’t there wasn’t new technology. We had glass available with screens available and with touch screen things, technology available. But what he did was put together. The tech wasn’t exactly new, it was. It was the merging of the two fields which created this us, and that fundamentally changed how we interact with technology.

Ever since. And I feel that that’s what the focus should be on going forward, is that interaction with the points, whatever those touch points with being for our customers and users across the board, to be honest.

So considering due diligence, full tolerance.

Sure.

If you feel like every developer now also using these tools himself must become, the code reviewer and the reviewer for all of those little challenges and those things. How do you and I was supposed the end of that one, but this was kind of ensued with that one. And then then I’m going to ask you for some self glorifying questions.

When, when leveraging those tools or when working with development teams in the remote space that are leveraging those tools, because again, you may have a mixed set of criteria and you and they want to be value add. And now you have two different developers using or leveraging these tools. And those tools don’t necessarily consider the full scope of the book, the full scope of the code, which can introduce bugs.

And these problems, or at the very least can introduce performance weaknesses in terms of the scale. Do you just, you know, sign those off as technical defects? Do you add that into the code review process? How do you handle that, situation when it comes up?

Listen, I think from a business point of view that’s going to have to be judged on a case by case basis and what the appetite of their businesses, I can speak on behalf of where I’m in, and the position that I’m in, we’re fortunate enough to have that cop launch to play with new technology without fear of failure.

Well, again, one needs to make sure that failure doesn’t bring down the business. Yes, it doesn’t bring down completely. Bring down a customer experience or journey. They may be risks in maybe inherent risks, which you would need to at least understand and unpack and agree upon. Yeah, and have a mechanism to roll back. But ultimately, any time you want to progress with a technology, the best way to learn is going to be on the job, with some sort of use case or test hypothesis or something.

And again, that talks to your point of saying, well, again, cowboy approach, but let me build something in. And even if you know this, this is this is AB testing methodology, which somehow, we haven’t really utilized as much as we could have.

On the tech space in the marketing.

Space. You’re correct. But even then, one can limit those transactions to a certain parallel process and say, well, let me limit my transactions to ten as an example, you know, so I bought a parallel process. But, but my risk appetite isn’t as high as I’d like it to be. In limited exposure. Yes. Right. I can control that through the code.

Right. And I can start releasing as it go on. So it’s almost like it AB that environment.

Yes. I going to take a single API endpoint for the load balancer in front of it, put certain amounts of traffic or even control traffic, correct. For a test. That’s good because you always still sandboxing a component under a segment. And you can you can scale on demand or as, as, as trust is gained inside of it.

And now you can get confidence, your measurements, because your measurements now can be isolated and controlled as opposed to getting millions.