Pioneering New Tech Narratives

Wade Erickson (00:00):

Good morning, good afternoon, wherever you are in the world. This is Tech Leaders Unplugged, with our first episode for season two. It is, January. And, we have as our guest, Yohan Moore of Green Ant Solutions. And our topic of the day is called Pioneering New Tech Narratives. And so, welcome everybody. Welcome Johann, appreciate your time today and sharing a little bit of your experience with, our Tech Leaders Unplugged, audience. Tell me a little bit about yourself. Green Ant. I know it's a new company, so, you know, tell us where you're at and, you know, what kind of areas you typically support. And, yeah, then we can just get into the show and talk a little bit about tech.

Yohan Moore (00:57):

No problem. First I'd like to thank you Wade and Carlos, for inviting me to the program. I apologize about my voice. I feel like I'm coming down with something, so I hope I am clear enough to everybody who's listening. So with regards to, you know, Green Ant Technologies it's a company that I founded about two years ago, well, actually about four years ago, but nothing really too much came of it, but within the last couple of years is when I decide to say, Hey, look, you know what? I'd like to really make this something. And then along with one of my co-founders sorry, Rene Castillo we decide to kind of take this a little bit further. And for Green End Solution, we offer seller services. We are basically a web development shop, but primarily is that we have developed our own technology one called Element Jss and J sphe. Element JS is a front end technology, and j Sphe is a web application server. And, you know, I know that that general question that people might have is why, especially for, for JavaScript, right? There's so many frameworks, so many different utilities and libraries out there. Why would you do an another one? And I feel it comes into, really, it's, it's, it's all about using some of the tech that's out there and feeling that. I don't think it's offering the right abstraction. It's not to say that it's, it's wrong in a way, but, you know, I think everybody has their way in which they'd like to use a tool, right? I think having a lot of these things just goes to show you the diverse diversity in people in terms of how they like to work with technology or use it to develop pro products, right? So I'm not one that kind of looks and thinks, oh, wow, there's all these technologies out there, there's something wrong with the ecosystem. No, I actually encourage it. I like the innovation. I like people looking and challenging the status quo and think, okay, you know what, maybe I can do something better. And we leave it up to the market to kind of de determine whether that is better or not, right? But again, I like that. And so this is what we decided to do, and I felt that if it is that you do want to be innovative, if you do want to kind of create your own technology because you think you have a different approach or a better approach, you need really need to kind of start your own company to do that, right? It's hard to kind of do that with inside of, you know, let's say you're working for another software development shop and you have a fantastic idea. It's hard to kind of say, okay, let's develop this, right? This is what's going to help. Rightfully so. The the company's probably going to say, well, you know what? We can't because the focus is on the product, right? And that's very well un very much understandable. And so, which leads me to, I guess, some foundational beliefs that I have when it comes to technology and when it comes to product. And I think I'd like to probably, you know, state these foundational beliefs because I think they're it's a predicate to a lot of the views that I, that I have. And the first one is, is that your end users care absolutely nothing about the technology that is used to develop or deliver your, your product, right? And I really want to emphasize that your end users care absolutely nothing about the technology that's used to deliver or used to develop or deliver your, your, your product. And what I mean by that is that, let's say, for example, a mobile app that we might have on our phone, we don't really care if it is developed using Flutter. We don't care if it's developed using Ionic. We don't care if it's the developed React, using React native. What we care about and what the, the end user cares about is one, does it work? Can they derive utility from it? And how does it make, how does it make it feel? How does it make them feel as they're using your product? And if we were to kind of qualify that in, I guess, more fancy terms, it's really what your end user cares about is the quality of service, the quality of value, and the quality of sentiment, right? And we can even boil this down even further to just the quality of the experience, right? That's what your end users kind of care about. And I think when it comes to the technology side of it, the only people that really care about that is the developers themselves, right? And one of the things when it comes to innovation, and this is what Green Ant is all about, when it comes to innovation, what we feel we have to do in order to innovate a green end, we have to be able to step outside the Echo chamber or the, the technology echo chamber that tells you, well, this is what everybody else is using, so this is what you must do, right? Because as long as you operate with inside of the status quo, that kind to me inhibits you from innovating, right? So if we talk about innovation, we talk about companies innovating, it's in, I think it's imperative to be able to step outside of that echo chamber to be able to then look at the, the status quo and challenge what's there, and, and see that at times, to me, I have the statement that when the status quo becomes disruptive, it's time to disrupt the status quo. It's time to kind of look at new ways of kind of doing things, right? And so that's the general philosophy, I guess, behind, you know, the green and team. We're always wanting to challenge the status quo, not to kind of be, we don't like what's going on. We love what everybody's done at, at, at this point, but we just want to make sure that we can innovate and probably potentially do better. And so we feel that our product Jss sphere and Element jss, I think we're tackling that, right? And we've been working this for about a couple years, and I am hesitant to release it, not because I don't think it's, it's, it's quality. We do have some of our clients who are using it for us, but it's because we're constantly testing it. We want to make sure that, you know, this, these, these products once they go live, can actually benefit our, you know our targeted end users.

Wade Erickson (06:40):

Yeah, that sounds great. I mean, you're go, you're following the, you know, customer experience, lean startup methodologies where you're, you know, you, you did build for a while before you even tried it on the market, try it on yourself, and then you know a lot of testing and adjustments, you know, before you actually, like you said, put it out there in the, the market and see how it does. Yeah. So, you know, there's very, very, you know, it, it is kind of a new trend. You're, you're kind of a product enabled service provider. And so, you know it's the same kind of thing we do over here at LogiGear and with the test automation tools, the open source one Selenium, you know playwright, all those, we build a framework on top of them to expedite the work that we do, and we just license that out, you know, for a dollar for 99 years. So it's not, doesn't become an inhibitor to, to, you know, like if the services should end, then all of a sudden the technology's got to be paid, you know? So it's really a, you know, we do the same thing over here and it, it makes us more efficient as well, you know. So great, great idea. Green Ant, of course, I'm sure a lot of people say, where did that come from? I know it's on the website. Maybe just a little snippet on what made you choose the Green Ant for your company?

Yohan Moore (08:02):

The, the name actually came from a very close and good friend of mine Chandler. He was a, a, along with Western Dyer, a couple of individuals that we were looking to start Green Ant with. And he actually had recommended the, the, the name and the name Green Ant. It's because the Green Ant I think native to Australia out of all the ants species, they actually build their nest in trees wherever all the other ants build it in, in the ground. So it's kind of like, again, that difference, you know, like you're doing something different from what the status quo actually is. And just the way, because they're building it in the trees and the way they weave the le the leaves together to kind of form, you know, their, their, their home. I felt that that's what green ads kind of symbolizes, right? We are going to be high above everybody else. We're thinking differently, we're looking at the broader picture, and we, you know, the way we create our applications is with the same type of intricacy that these particular creatures do themselves, right? So that's where that, that came from.

Wade Erickson (09:04):

Great, great analogy there for that. So I have a handful of questions if you'd like to jump in. We can jump into those and then just kind of, you know, flow on that. So, you know, I went into your, your website and looked at your mission statement, and I, something that stood out says, we recognize that delivery and successful dig digital solutions goes beyond meeting deadlines and budgets. It revolves around providing the right digital experience, kind of like what we're talking about. Customer experience centric fa failing to do so often requires costly reworking, which results in prolonged time to adoption, higher cost of ownership, and more importantly, hinders the delivery of business value. So, you know, within the quality assurance world, you know, cost of ownership and rework is, is something that's often a challenge. And like you said, you've iterated on your base product quite a few times, adding functionality, testing, adding, testing, adding, you know, so can you discuss the role of testing that, you know, both manual and automated took in your product development as well as maybe the, some of the services that you do to help, you know, improve the release times, you know, and overall reduce bugs in the experience for the customer?

Yohan Moore (10:15):

Okay, so I, I think when it comes to, to testing, the general purpose of testing, I think is to ensure the, the, the continued delivery of that quality experience, right? That's why we test. And, and, and that's general. Like, I mean, for example, you might have your customer service team that has to also test their, you, you know, how fast they respond to customer inquiries, how, how fast can they resolve issues, you know, so you're testing their process, right? Because you want to make sure that you're continuing to deliver that experience that your clients or customers, you know, are accustomed to. So I think that the purpose of testing is to ensure the continuous quality delivery of, of quality, right? Or quality experience. Now we have, you know, all sorts of testing. You know, we, you know, if you're going to categorize them, we have your manual test and you know, your automated testing. And I think when we come to testing, it all depends on where you are in your product lifecycle, right? Where you are in terms of the maturity of your, your com, your company or organization. And one of the things that I, I feel is that in the earlier stages, we're looking at manual testing and manual testing tries to not only kind of test the functionality and making sure that everything is, is correct, but why manual testing I feel always ha kind of has to be there in present no matter how much you're, you know, you're automating your technology is that with the manual testing you're having the human experience, you're having a human being using your application, using your product so that you can capture again, the quality of the sentiments, right? Like how they feel using the system. Because, you know, I've worked for companies where, you know, the QA team would actually come back and say, I don't think this is the right user experience or user interface for this. It seems very cumbersome and so forth. And so you have to value that kind of feedback. And I feel that that's something that automated testing can't really tell you because auto automated testing depends on the work that the manual are doing, and then you're just trying to automate it to expedite, you know, the, the actual testing process, right? But there's always going to be a need for, for manual testers with let's say for example, now, you know, automated testing is that automated testing is very important, but again, it depends again, where you are in the lifecycle of your product. And I feel that in the earlier stages, I don't feel that software development companies should really focus on automated testing. And so one of the, the, the, the things that happen, I think in software development is that you hear all these terminologies, you're like, look, we should do this testing, do that testing. And then even in the earlier stages of a product development, you have your development team probably focusing on trying to establish automating testing. But the whole point is, is that your product is in a state of flux at that time. So it's constantly changing. So to even try to implement automated testing or early in that stage, you're doing yourself a disservice because I don't feel that you're, you know, optimizing your, your resources, right? Your manual testers could take care of that. They'll change the scripts if they have to. They'll, they'll test things. And I feel when it comes to automated testing, that's something should probably happen further along the, the process when your product starts to solidify, you know, a little bit. And what those bring, once we do have the automated testing, you're, you know, you're right, is that it does help to expedite the delivery of, you know, features that you might have, right? And that's very important. But more importantly is that it's, when it comes to, to testing and delivery, it's really about your delivery cadence, right? So one of the things is, is that even if you're, your, your testing and you know, your, your, your feature, let's say passes and everything is good it doesn't necessarily mean that, you know, you're, that feature is ready for delivery. It doesn't mean all of a sudden, you know, we put it and put it to the customer, right? What we want to do is include that within our delivery cadence and your delivery cadence, you know, incorporates your sprints. And the delivery cadence is meant to deliver meaningful value at the you know, incremental value to your end users. At the, at that time, you're going to do your release. So if, for example, the testing pass, you might just wanna put it aside and then go on and move on to something else, and then, you know, accumulate a bunch of, you know features and then release them all together. So I, again, I'm not sure if I've, I've answered it correctly, but feel free to, you know, to, to jump in. But again, when it comes to the, the testing and the importance of testing, I really feel, again, it's just a matter of when is the right time to do and implement certain types of testing, right? You know, you wouldn't start, let's say, doing performance testing again, again earlier in the cycle, because you have to have a product, you have to know what you're doing, you have to understand how many users you probably would have on this particular product before you do any type of load and performance testing. So it just really just depends on where you are in the product life cycle, where you are in your company, if you have the resources to, to do that. And I think the narrative that I, even if it's not a narrative, something I really like, you know, developers to know, is that we just don't start implementing things because we hear that this is what other companies are doing. We really just have to understand where we are and what's necessary to be done at that particular time. And in most cases, I feel like within the first year of a software development company, you're probably going to do a lot of manual testing. And there's benefits to that, like I said, just simply because you're going to be able to test the functionality, but you're also going to be able to test the experience too, as well, which is very important.

Wade Erickson (15:53):

Yeah, I agree with you a hundred percent that the automation is really to be testing features that are stable. Which is kind of, you know, counterintuitive. Why am I testing things that are stable? Well, you're testing them because, you know, software is very interconnected, and so you may be adding new features in another area and you could core break core functionality. And so you know, we, we do probably 60% of our work is manual testing for the points you exactly made. When the applications in early, you know, ear really early in a lot of flux, you want to have a lot of manual testers on it because it's so, so changing so much. And then as the product matures, you then start to build up your regression suite against the core applications that absolutely have to work in every release. And so you, you know, you basically do it in chunks of and then most of the time, 80, 85% is the max coverage you even want, you know, you never even want to go to a hundred percent because of the flexibility, the new features, all of that stuff. A lot of times it doesn't make sense to even put automated.

Yohan Moore (16:54):

And this, this is one of the things where if we're talking about changing narratives, what I really would like to just emphasize to your listeners, to anybody who's, you know, working in a, a startup and so forth, is that the focus can't be technology and just using technology for the sake of using technology. We can't hear that, oh, they say that we should be testing. So let's start looking at our, you know what testing software we're going to use. Let's start, you know, automating things just simply because again, you have limited resources and the company is in a position, the company isn't in a position to now hire automated testers or people who now understand this aspect of it. 'cause There might be some coding involved. And so if you're going to start to implement that while you're not ready for it, then you're going to be using your current resources to then try to get that done, which takes away from the manual testing and the testing of the product that needs to be done. And then now you're just really just trying to study about how to implement something that you might not need along the line. Mm-Hmm. And I think this is kind of at times really does an injustice to the delivery of, or the, you know, the delivery of your end product, right? Because we're just focusing too much on the technology aspect of it, as opposed to the product side of and supposed to the product side.

Wade Erickson (18:12):

Excellent. Got another question if you're good for that. How do you approach the, so with all the talk about artificial intelligence, machine learning and all those kind of things, there's a big scramble and most software companies figure out how to apply this, you know, this stuff to your products to make them more feature rich in this area. So, you know, how do you approach choosing different aspects of AI and machine learning to apply them particularly to your SaaS product, you know, to enhance the functionality in the user experience?

Yohan Moore (18:45):

Yeah. The yeah, the AI topic is a, is a, is a pretty interesting one. Just to share a little bit, a story is that I remember, you know, working for a, a company and the owner of the, the, the CEO of the company came into me and said like, why are we not, you know, implementing ai? It's kind of like the new thing that's kind of out there, you know, why are we kind of behind? Right? <laugh>. And, and to be honest, at that time, you know, I was hearing about ai, but I didn't know much about it. Right? But I thought it was just an interesting take that as soon as we kind of hear something, then that means we must apply it or implement it, because that's what it seems like a lot of companies are doing. And then after that, I had a discussion with another the CTO of the, the, the company. And I, you know, was honest with him, say, I, you know, don't know much about AI. How are we going to, you know, start implementing this if I don't know much about it? I don't think my team knows much about it. And the response was a very interesting one. I, I mean, I'm not criticizing any of these individuals whatsoever. I'm more just trying to outline, you know, what this is about. But the response was, it's okay, we have if statements and l statements that's considered AI. So just say we, we've implemented it, right? Because there's some decision logic. And really know what it becomes is just a marketing type of thing, right? Where, again, from the end user's perspective, they don't care anything about the technology. Again, it's about are they deriving utility? Are they having a good experience? You know is that the quality of service good? And you can slap AI on in that, and all it does is makes them feel like, Hey, you know what? This pro, this project is progressing, but the end user themselves might not even understand if, whether if AI was implemented or not. Right? So now for talking about implementing ai, like actually truly implementing ai, and I had the, you know, the good fortune of being hired as head of engineering for a company leading AI that dealt with using machine learning and ai technology to basically calculate the a health score for individuals to help them out with insurance, right? So basically, what they did is they'd have all this, this data that they're trained on, and basically, they'd have access to individual's health records, and they will take those health records, put them into their AI models, and it'll come back and give a score. And the insurance company now could kind of, they could cater the premiums towards the score that's being provided, right? And so I learned what AI actually is and what it's about and what is involved. And the thing is with it is that there's two things now when you're talking about implementing ai, are we going to be an AI company where sorry. Are we going to be an AI company where it is that we are going to invest in what's required to train machines because we require that training in order to implement AI into our, our systems? Or are we just going to use APIs of existing services that are out there? Right? And the question we have to ask ourselves is the existing services that are out there, do we have a need for them with inside of our application? And for the most part, the answer is really no. For most applications. Some applications might, and it's amazing if there's an A API that allows us to then augment our app, the, our current product with ai. But if there isn't, then it's hard to implement it. And if you don't have a use case like Lydia AI had a use case, if you don't have a use case to build your company around AI, where we're training these models and getting all this data, which is very expensive and laborious and tedious, and whatever the case may be, then when it comes to innovation with regards to, to ai, I think at this particular stage, it's really just something that's kind of just said and stated, you know, as opposed to, okay, this is something that we can actually now start to implement now with ChatGPT coming out. That's a lot is, is very useful. Just simply because now we could use AI to kind of augment our application. Like, for example, Microsoft with their co-pilot for, for GitHub, right? You, you know, you're using AI to now help somebody do their, their, their, their work. We might use AI in our product to kind of help, you know, individuals maybe streamline, streamline their processes by, in data that we're collected collecting, and we're able to feed into maybe certain models that it is that we have.

Wade Erickson (23:14):

I agree with you a hundred percent. You know, I think as time progresses, the, you know, we've had all kinds of technology that's come along in the last 20 years that had a lot of hype wrapped around it, and just never quite not to blame the technology, it was just really, you know, how do we wrap our brain, as humans around it? And, you know, you're talking about, you know the decision makers at the top have to appreciate what the technology has and then decide is it something that the, that the, the, the, the end user's even going to want. Because as the end users are getting smart about AI and machine learning, and if you selling that and it does not deliver that, yeah. It's going to actually backfire on you, you know? Exactly. I think people have to be very careful about, just don't jump on the bandwagon and throw AI in there for the sake of AI. Make sure there's a value prop for that specifically. And then like you said, AI enabled, let the value, if I'm an AI developer, let the value of applying AI to me to make myself even more efficient and effective, be the driver instead of just say, I'm using AI to help me. And it's, it's, it has to be loved and desired, you know I think to really be appreciated. So just like anything else. So yep. I got one more question, if you're Okay. You know, like you said earlier, you worked on this idea for about four years, and then you started formally, you know, set up the company a couple years ago. Tell me a little bit about that journey. A lot of our viewers are, you know, middle management and wanting to get into the c-suite. Tell me a little bit about what drove you to finally, you know, take the leap as they say to take on entrepreneurialism and yeah. Do you have any good pointers for the viewers?

Yohan Moore (25:08):

I feel it came from a discussion I had with a mentor of mine who is younger than me, but managed to, you know, establish a very successful software company that he had managed to, to sell. And we were just talking one time, and as a matter of fact, he was a, a, a reference for me getting the job at Lydia as head of engineering, right? And at Lydia, it was probably just about, you know, I think it was there for about six months, seven months. And then you know, got another job at a, another really nice company, sorry, I rectify. And the people there worked with them, and then just stayed there for a short stint too as well. But at the end of that, you know, we're just talking and he goes, you know, Johan, you're no longer employable. And, and what he meant by that what he meant by that is that my skillset sets weren't there. And you know, no one's going to hire me. He just said that you, your past trying to help other companies succeed you I feel that I had a, a pretty, you know, good track record of helping companies. Back in 2000, I developed my own kind of language framework for web development when it is that they had ESP and ColdFusion back at that time. And a company ISI, they had adopted it became highly successful, 17 fastest growing company in can at one point. They branched off into two companies and of us, I think as late as 2018, I think it was, they were still using that technology for their products, right? They're trying to obviously transition out of it to newer tech, which by all means, you know, accept and, and recommend. And then in 2014, hired for another company director of development, and they were a consultant company, and it was just one individual who was a developer. And I was hired to kind of help them turn 'em into, from a consultant to a software company. Within four years period of time, we managed to be bought out and grew the team to about 27. So I felt like very confident in my ability to understand tech, develop tech, to help companies kind of succeed. And so what I found in the later stages was just that, I would desire to really try to take companies to a different place, but it's sometimes hard when they're already at a certain place that maybe they feel comfortable with or they have a pace that they'd like to go to. And I then I just realized like, look, you know what, it's time that I have to do for myself, right? It's time that I have to take that, that that leap. And it's, it's nerve wracking. It is. And, you know, but I have this expression that, you know, it requires courage as we kind of talked about before. And when it comes to courage, courage is not action. In the absence of fear, courage is action. In the presence of fear, you, you have to feel a certain amount of feel fear to be able to have courage to do something. And once it is that you kind of now master that courage once you feel comfortable in uncertainty. Because another, you know, sound advice that I received from one of the ex-CEOs of Xerox was that you have to learn to be comfortable in uncomfortable situations. And I think that that's what I'm trying to now start to master, right? So I'm in some very uncomfortable situations, but I feel comfortable with it, right? And, and so I think that's what's required. I think that's where now in my, my, the stage of my life that I'm at and why I felt that this was the right opportunity. And, you know, the thing is, is that when I was laid off from my last job, you always feel kind of, oh, I got laid off. You feel bad. But then it's like, no, that's an opportunity. And you have to be able to recognize opportunities. And just something kind of opened up in me and said, this, this is the time I'm, I'm ready now. Whatever the challenge is, I'm ready to deal with it and handle it. And I'm just surrounded by some really terrific people, close friends, family, who 100% supported me in what I was doing, whether it was more moral support or financial support. So that's also a factor that's, that's there. But anyways, I, I'm happy with this journey. It allowed me now to spend time developing the technologies. And like I said, hopefully we can release those technologies very soon because it, they are different. They are doing things differently, but from the tests that we've been doing so far the clients that we've kind of developed applications for, we're seeing that it, it's working. And so we're excited about that.

Wade Erickson (29:35):

Sounds great. Now, so we're at the top of the, the show. And, you know, wanted to first of all, thank you for, you know, coming on the show, sharing your knowledge and experience with, with us. You know, is there anything else you'd like to quickly share before we kind of wrap up?

Yohan Moore (29:52):

I think I'd like to just, you know, share maybe just a, a diagram kind of talking about my, my thoughts and or, or, sure. Highlighting my, my thoughts with regards to software, you know, development and what, what's required. And so just give me one moment here. Is this visible?

Wade Erickson (30:26):

Not yet. I think they're flipping the switches to get it to show, not sharing yet. Okay. did you want to click that center button again?

Yohan Moore (30:43):

Sure, no problem. Okay, There we go.

Wade Erickson (30:54):

Oh, I can see it.

Yohan Moore (30:56):

Okay. This diagram here kind of represents, I guess, the culmination of my experience working with software companies. And it's something where we here at Green End Technologies are really trying to take in internalize, because I really feel that this is what will help us, you know, proceed. And so one of the things that I always kind of like to look at is not about sprints, it's not about agile, it's not about any specific thing with regards to the, you know, these terminologies that are kind of used or, you know, methodologies for doing things. What it is, is that really what we are trying to do, and I think what leadership has to do is establish a strong delivery cadence. And the characteristics of a, you know, it's strong delivery cadence is it has to be iterative, optimized, and sustainable. And by being iterative, what we're really saying is that it has to be able to deliver incremental value. It has to be optimized, making best use of resources basically applying the right people to the right work at the right time and sustainable. It, it has to be something that we can maintain over a long period of time. And so that's the objective I feel as for anybody in our audience who's, who's listening, who is, you know, in leadership, I think our goal is always to establish the right delivery cadence and the things that now can impact our delivery cadence are our customers compliance, regulatory compliance technology, and, and government governance. Our customers, for example, what we were just talking about before, customers wanting ai, right? And if we are not, if, if, if we don't know about ai, we might feel this pressure that we have to implement it, and then all of a sudden we're changing up our whole game plan, trying to, you know, implement this and then therefore affecting, potentially affecting our delivery cadence. Compliance is not a one, you know, regulatory compliance. All of a sudden something new might come in, you know, years ago was GDPR and you know, the protection of people's information. Then we had to kind of switch up how it is that we were doing things, what we had to provide to our end users, and they had to agree on and so forth that could affect our, our delivery cadence. Then there's governance. Governance is really about the policies, procedures, and practices of your company. They can affect it, right? If you don't govern the company correctly, then you can impede the delivery cadence. A lot of times governance really has to do with the, the culture and the, and the moods of your employees. And, you know, if they're not happy, this can affect the delivery cadence and technology, technology could affect it. Again, you know, using AI it could be that, you know, there's a newer technology that is out there and your, your development team is putting pressure to say, let's use this. 'cause This is the way everybody's doing it, right? This can affect your, your, your delivery cadence. But that's fine, because these things will always exist. In order to counteract that, I feel that companies have to really focus on agility and continuous innovation, right? There are going to be times when we might have to pivot, we might have to change, and that's okay. But we have to establish a culture of agility and continuous innovation. And for us to be able to do that, we have to have these certain qualities within people, process and product. And when it comes to people, we really have to encourage curiosity, courage, compassion, communication, and community. And when it comes to process, we have to make sure our process are very transparent, traceable, trackable. We have to care about the tooling that we're using, and most importantly, teamwork, right? Everybody has to believe in, in the process. And then when it comes to, you know, the product development and engineering, we, we have to make sure that we're taking this thing through a, a discover, design, defined, developed delivery type of process, right? To assure the delivery of a, a quality product. And if I was just going to s sum up software development, sum up running a software company, this would this would be it. And I remember being in a couple of interviews, just like last year, a couple years ago, where I presented this to, when I was being interviewed by CEOs of two particular companies, they'd actually asked me, said, can we use this? And I said, yeah, sure. Right? I didn't end up getting hired, right? But I, I, you know, it's information that I'm, I'm willing to share because I, I think it's important for people to have a mental model. You have to be able to kind of see the, this from a you know, a thousand feet kind of view. And if I was going to do that, this is what this would look like for me. And this is what I like I said, I've used in not formalized in this particular type of way, but in, in, in my 25 years of software development and working in these companies, this is what I realized I had inside of my head. And then I just wanted to kind of put that down now on, on paper and more than willing to share with anybody.

Wade Erickson (35:54):

Great. Yeah. So the great model by the way. You know, 30 years of experience myself, all of that kind of aligned with my thinking. So I think the viewers out there reach out Johan, get a copy of that thing. You could probably build a whole blog site around that for real. I mean, I can imagine, you know, just seeing that as a mental model, you know, pictures a thousand words, you know, I have pictures worth 10,000 words,

Yohan Moore (36:22):

Exactly. And just one last thing, sorry, just one last thing. And anybody who is interested in the tech that we're developing, please feel to reach out to us through, either through our website or in my email, is there, you know, reach out per you know, personally, and we're more than willing to demo our product for anybody.

Wade Erickson (36:39):

Great. so the next show we have, if that's, if we're wrapping here we have a show next week with Michael Frendo, CTO of Proofpoint security Company. It's on January 31st Proofpoint about a little bit about them. Their motto is, Proofpoint protects people and data and brands against advanced threats and compliance risks, which is you know, a concern today in everything we build. And would love to have you on the, you know visit next week and, and listen to what Michael has to share about the security space. So again, Yohan, appreciate your time.

Yohan Moore (37:24):

Thank you, guys, for having me.

Wade Erickson (37:26):

You know, I think we have some good topic areas for, for folks to do takeaways. And yeah, folks, reach out to Yohan and see what he's got over there at Green Ant.

Yohan Moore (37:37):

Okay. Thank you.