CTO Confessions Brought to you by IT Labs · 2026-05-21 · 54 min
Key moments - from our scoring
Substance score
39 / 100
Five dimensions, 20 points each
ABAX Healthcare's Jay Dalke breaks down what the CTO role actually entails - debunking the myth that it requires knowing everything about technology. Instead, he frames it as conducting an orchestra rather than playing every instrument, emphasizing that effective leadership means understanding whether a problem is technological, procedural, or people-related. Dalke's approach centers on asking "what problem are we solving?" repeatedly to reach root causes, recognizing that solutions often involve removing obstacles rather than adding complexity. The conversation touches on his experience with AI and machine learning in healthcare administrative workflows, where systems can discover efficiency patterns humans wouldn't consider. He discusses how cloud-native architecture and containerization have simplified scalability compared to legacy data center approaches, and shares perspective on the hype cycle surrounding AI - comparing it to historical technology disruptions like the assembly line and personal computer that didn't eliminate jobs but evolved them. Throughout, Dalke emphasizes the importance of human oversight in automated systems, using healthcare referral optimization as a concrete example of how technology and process improvement intersect.
People often assume CTOs have all the answers and are experts in everything, when in reality they're more like orchestral conductors who know where to find answers and coordinate expertise across teams rather than playing every instrument themselves.
Ask "what problem are we trying to solve?" repeatedly - often 4-5 times - to drill down to the root cause, which may turn out to be a people problem, process problem, or removal of an obstacle rather than a technology solution.
AI won't displace developers but will make them faster, enabling quicker production of features; however, enterprise-grade qualities like performance and reliability require human oversight to prevent the systems from going off course.
ML can analyze factors and parameters that humans wouldn't normally consider, discovering unexpected correlations that improve processes like patient scheduling and referrals without explicit programming for those relationships.
Cloud-native and containerized architectures eliminated the need to over-provision servers for peak capacity; systems now scale automatically based on demand using cloud provider services and proper design patterns.
Our reviewer’s read on each dimension, with quotes from the episode.
A handful of useful ideas appear (smaller dev teams reduce communication overhead, feature toggles as a non-negotiable, AI in three distinct use-cases at ABAX) but the episode is heavily padded with nostalgic tangents about old computers, Toastmasters, and RF engineering that crowd out usable content. The insights-per-minute ratio is low for a 54-minute episode.
I'd much rather have a smaller development team than a larger development team. The more connection points, the communication points we have within individual. The harder it is to get anything done
feature toggles, um, um, where you can actually push code into production and turn it on and turn it off, uh, without impacting the system
Most ideas are explicitly borrowed (Lencioni's framework, Dunning-Kruger, servant leadership) or standard CTO talking points (cloud scalability, ask why five times). The interview game and the dark-fiber analogy applied to AI data centers are the only genuinely fresh angles.
There's a game called keep talking and nobody explodes
there's such a rush now for building data centers for AI and then the power to, to, to supply those data centers. And I sit there and I wonder what happens when we, we get all these data centers built and then all of a sudden somebody figures out another way to do it
Jay Dalke is a genuine CTO practitioner with an engineering foundation who has clearly run development teams and made real hiring and architecture decisions. He is not a high-profile name and the company is niche, but the experience is authentic and domain-relevant rather than purely theoretical.
I still dabble in coding, and I've been playing with vibe coding here of late
we're using AI in three different areas at ABAC's health
The guest names specific books (Accelerate, The Goal, The Ideal Team Player), real tools (feature toggles, ORMs, ERDs, DevOps pipelines), and a concrete hiring exercise, which lifts the episode above pure abstraction. However, there are zero metrics, no outcome data, no dollar figures, and no named customer or product results from ABAX.
Accelerate by Gene Kim has a fantastic book
the must have is something I don't have yet. So, uh, in the old days, I had it right in the old days where we had a data architect or a data engineer and you put the ERD together
The host consistently hijacks the conversation with personal anecdotes about his own RF career, coding nostalgia, and Toastmasters experience, reducing the guest's airtime significantly. Questions are pre-written softballs with no meaningful pushback, and claims go entirely unchallenged throughout.
In fact, I want to speak to my history. I worked on the RF side of mobile communications.
I must admit, I missed the days of debugging. Even though it was painful, there was this beautiful feeling at the end of it.
Computed from the transcript - who did the talking, and the words that came up most.
Most people think the CTO has all the answers. Jay Dalke would disagree. In this episode of CTO Confessions, TC Gill sits down with Jay Dalke, CTO at AbaxHealth, to explore what the role actually looks like from the inside - the misconceptions that follow it, the hiring instincts that hold up over time, and how to think clearly about AI when the noise around it is louder than ever. Jay brings over 25 years of experience leading technology across startups, enterprises, and private equity transformations, with a people-first approach that has built high-performing global teams delivering real business outcomes. In this episode: → Why CTOs guide - they don't need to have every answer → Why social EQ isn't a hiring requirement for engineers → The three traits that matter most when building a team: humility, hunger, and intellect → Hard work and natural talent - why it's not a binary choice → AI: separating the fear from the hype "Strength overdone is a weakness, and a weakness overcome is a strength."You said: what is the easiest way to extract audio from video on capcut?
Transcribed and scored by The B2B Podcast Index.
Speaker A: So, Jay, welcome to CTO Confessions. It's great to have you on board, sir.
Speaker B: Uh, terrific. Great to be here.
Speaker A: Brilliant. So tell the audience a little bit about yourself. Who are you, what do you do, and who do you work for?
Speaker B: So, Jay Dahlke, CTO of ABAX Healthcare. Our main focus is improving revenue and outcomes for health systems. We streamline the patient access and, um, referral process. So if you think about where you might get referred to, get, uh, an MRI or some sort of procedure, but forget to follow through up on that. We reach out to patients and help them get scheduled for their appointments and get that process completed.
Speaker A: Fantastic. I take it. I can imagine that's a proper choreographing of lots of people's calendars, times, and making sure that you get efficient use out of the resources in hospitals.
Speaker B: Absolutely. Uh, and if you think about the United States as a, you know, a geography. Right. We've got different people in different areas across the country, so coordinating times when, how to reach out to people, who, to reach out to people, making sure that, you know, you don't necessarily want to have somebody from South Georgia calling somebody in Brooklyn, New York. Right. Just like to keep the accents and the cultures similar so everybody connect and can bring the whole process to fruition.
Speaker A: Fantastic. Sounds like a wonderful and interesting kind of the, uh, technological solution to real problems in the space. So I'm kind of curious. We've had some great conversations offline around various things. I've got some questions here lined up. So I'm always. Ctos people have an idea of what a CTO is and sometimes it varies depending on the company. Um, um, and what have you. So what do you think the biggest misconception is about being a cto, being one yourself.
Speaker B: So I think that for me, the thing that I've been had to kind of correct people along the way is they think that I have the answers to everything. It's like, oh, you're the expert. It's like, well, no, I know often where to go get the answers, but I am not the expert on everything. And I think that's probably the biggest misconception I've had to help people understand is that, um, we're more of a conductor of an orchestra than the individual who can play every single instrument.
Speaker A: Yes. Yeah, that's good. That's, that's a nice description, actually, because I think people often think that, you know, if you've got technology in your, in your title, it's all about tech. It's. I'm going to make Some stereotypical comments now, you know, it's about, you know, white socks, sandals, you know, big beard, you know, uh, geeking out in front of a computer. It's not about that at all. I think the leadership position is actually a really important part of organizations now because, you know, as I've mentioned many times on the podcast, is that all companies are technology companies of sorts. They've got a specialization that they focus on. So it's around. It's around, you know, making sure that things are working as they are, the products that you're creating and doing what they're supposed to be doing, and also making sure that there's a business case for what you're doing as well, you know. So I guess it's a mix of needs that get merged in.
Speaker B: Well, and one of the things I always focus on is the first thing I typically ask is, what problem are we trying to solve? Right. So many times somebody will come up and say, oh, we need to do this. It's like, well, why? Right? Why do we need? What problem are we really trying to solve? And you have to usually ask that four or five times to get down to the root problem. And oftentimes that root problem to solve it isn't a technology problem. Sometimes it is. Sometimes it's a people problem, sometimes it's a process problem. But going through that cycle of asking, what problem are we trying to solve? Numerous times usually ends up with a much simpler and elegant solution than if you just take it off it at first glance.
Speaker A: Like, yes. Yeah, I, uh, can. So just as a joke, how many times have you had to ask that? That why I go down that rabbit hole of.
Speaker B: I've lost count. Yeah.
Speaker A: Some of them can go quite deep, can't they? You know?
Speaker B: Yeah. Well, and sometimes you run into situations, right? It's always about personalities and types. There's like, why do you need to know that? It's like, it's, uh. I can't help you if I don't know. Right.
Speaker A: Yes, that's right. On, um, that note, you know, when we are in these kind of leadership positions, it's interesting how people do hold information and question why you're questioning it.
Speaker B: Yeah, yeah. I think it comes from sometimes with, you know, there's a. From a security consciousness, but also from an insecurity framework, Right. Where people are afraid of, if somebody else knows what I know, then no longer my value, the organization, which is, I think, is completely the opposite of my thinking. Right. The more people that know what I know, the more it frees me up to do other things.
Speaker A: And there's something around awareness of what these conversations raise, an awareness in the system so that people can then maybe navigate them, maybe avoid them, maybe go, well that's covered or that's not covered. I think that there is something around that and communication. In fact I was talking to another leader today around this is that communication is always failing in most organizations. I think it fails in all human systems in some extent. But the bigger the organization gets and the more agendas people have, it just starts to kind of get a bit messy.
Speaker B: 100% absolutely. In fact, you know, we have development teams. I always say I'd much rather have a smaller development team than a larger development team. The more connection points, the communication points we have within individual. The harder it is to get anything done, the more complex it becomes, the more problem it becomes. So give me a smaller, more dynamic, more agile team any day of the week to get things done. And it is interesting too, uh, mentioned this earlier. The. It seems like technology has always been about solving communication problems. If you go all the way back to the printing press, right. Your development of the printing press was to help with communication, telephone to help communication, email, word processors, everything we've done in technology is really helping about communication. But yet I'm not sure we're any better at it.
Speaker A: Yeah, it's kind of interesting. We've gone down this rabbit hole of using tech to solve that and actually we've lost, we've lost the, we've lost the plot as they say, you know. So I'd love to come back to that when we kind of speak about our leadership because I think that is part of leadership is to enhance and turn the volume up on, on effective communication. I think there can be too much communication as well, which creates a lot of noise and, and somebody like me who can talk for England, you know, you know, I can fill the space with communication. It's not always what we want. So we'll visit that again in a second. I've got a really funny question here actually around. If you could swap a role in your organization with anyone for a day, what would that be and who would that be with?
Speaker B: Yeah, so this may be non typical. Uh, so I started out as an engineer, was a software engineer, electrical engineer, the software engineer. But it was many, many years ago. So technology's evolved quite a bit. So I still, you know, even though I'm leading technology and development teams, there are times I'd love to go back to being an engineer, being a uh, developer to see things from that perspective again, because writing code now is very different than when I wrote cod. The advent of the. And all sorts of other technology versus doing punch cards and so forth has changed quite a bit. So going back just to being, uh, an engineer and writing code would be great to see what I think about leadership, right? Because I think I have a good understanding of how my people look at me and what they think about my leadership, but I really don't know. So if I could swap roles and actually be back to being an engineer, that would be probably more for a day, for a whole week. Just to see what challenges they face, see what struggles they face, and see how crazy leadership really is.
Speaker A: Yeah, that's a really interesting take. I often have that as well because I come from electronics background and software, and I do kind of point for those days where you just kind of chill out, make a few cups of tea, have a bit of thinking, get around the whiteboard, you know, uh, and write that code. But I do remember the very last time I pushed my keyboard away, I. I was using Clear Case to check in some code. And I checked in for the last time. I've never been back again. But I must admit, there's a voice I can hear, like, uh, a siren, you know, kind of singing to draw me back into that kind of world. But the interesting thing is that I always wondered how different it is to actually code now with all the different tools we have around us. Obviously we've got AI as well to kind of facilitate some of this stuff as well. So I'm kind of curious as to, uh, how much of a difference that makes.
Speaker B: Yeah, well, it's. I still dabble in coding, and I've been playing with vibe coding here of late. Right. Including some just applications and doing some different things. And it is very. Back when I programmed professionally, right, I flowcharted everything. There was a flowchart. You know, I did primarily embedded systems, but everything was thought through. And now it's like I just have an idea and I sit there and talk to the AI and tell us the idea, and all of a sudden something evolves. Now, I don't think what comes out of that is something that I would call enterprise ready, right. There's lots of performance and what I call, uh, the ilities. Right. The qualities of architecture that aren't necessarily in there. But it's amazing how quickly I can create something without going through all of the flowcharting and so forth. Now it's interesting talking to my development team. The developers seem to be falling in one of two camps. Either they're ready to embrace and try that, or they're very obstinate. It's like, nope, nope, uh, they can't do what I could do. So it's ridiculous. They're afraid of it to a certain extent. So it'll be interesting to see how that evolves over time. I don't think it's going to displace. I don't think. I'm going down a tangent. I don't think AI is going to displace developers, but I do think it's going to make developers faster. I think we're going to be able to produce more quicker. But I think we're also running into problems where that enterprise ability. Right. All the attributes of quality are forgotten and if we're not careful, we'll end up with a log.
Speaker A: Yes, I think you're right. I'm aligned with that. I think you're. I think you're absolute right. He's augmenting us. So what types of tech challenges do you personally enjoy the most? Okay, so this is speaking to the techie inside of you from a leadership perspective and from a kind of getting, getting into the weeds with it as well.
Speaker B: It really is going back to that. Finding out the root cause, what problem are we trying to solve? That's the thing I really enjoy the most, is really drilling down and finding out what problem are we really trying to solve and then putting a solution around that. And that solution, like I say, might involve people, might involve process, might involve in technology. It might be that, and this has happened numerous times, that we're solving a problem because there's something in the way, and if we remove something, the problem goes away. So it's like, well, gee, all we have to do is remove this, take this out of the equation, and now we don't have to solve the problem because the problem's gone. So that's probably my favorite part is that sitting down and thinking and conversing with people and really trying to understand the problem.
Speaker A: Yeah, I like it. I like that. I must admit, I missed the days of debugging. Even though it was painful, there was this beautiful feeling at the end of it. I forget it, you know.
Speaker B: Well, uh, if you were to ask me who the core of who I am is. I'm a repairman. I love to fix things.
Speaker A: Yeah, yeah.
Speaker B: I started off fixing things. I've always. I still fix things. I like to repair things. And. And now I just repair things with people. Right. And culture, but still. That debugging, that problem solving. It's like solving a puzzle, right? It's. It's kind of fun.
Speaker A: Yeah, I think so. I think so. I'm, um. I'm just recording back at the. Some of the late nights, trying to figure something out. And even in the electronics days, I remember, you know, when sometimes electrical play, you know, it'd be like a bad pad on. On a chip, you know, and you're thinking, well, everything looks fine, you know, and. And, you know, you'd be doing everything to. To figure it out. But it was a beautiful. It was such a. A fulfilling time, I think, when. When you figured it out, because you always did.
Speaker B: Oh, yeah, we had that Eureka moment, right? That, that's it. I've got it. Right. That, uh, eureka moment is. Is. It's a, uh. It's an adrenaline rush that's hard to be.
Speaker A: Absolutely, absolutely. So has anything speaking to the AI thing. We can't kind of not talk about that the AI revolution is. Anything about it surprised you?
Speaker B: I don't know that it surprised me, but I find it odd that it's the hype, right? The hype and the fear. Right. And I feel like we've seen this over and over again. Right. Way before my time, but the assembly line was going to, you know, revolutionize industry and cost everybody their jobs. Right? The. The personal computer was going to, you know, take everybody's job over and over again. We see these things where we think, oh, this, this new technology is going to take everybody's job and it's going to be the end. And it seems like it's like, okay, well, no, it's going to change, but people are still people. Things still work the way things work. So we'll evolve and we'll change, but it's not like everybody's going to be sitting on the side of the street, you know, with. With nothing to do. Uh, I just recently went to a dental hygienist, and I was sitting there and thinking, yep, this is something that. That AI or a robot is just not going to be able to do. Right. You know, so.
Speaker A: Yes. Yeah. I think it's interesting. So you have a, like a positive side of the hype. We have the. I'm going to use the. The Star Wars Jedi kind of like, analogy here. So you've got the light side, okay. And then we've got the dark side of the hype. And I think it's interesting how they kind of intermingle and mix and, and, and. And I see people trying to kind of show the light side. You know, this is the difference he's going to make and we're going to adapt. It's going to augment us, et cetera, et cetera. So, yeah, I, you know, I'm really curious as to how we get through this hype. Okay. Because it's painful, why we're in it, you know, because it's all very confusing. There's lots of voices. Everybody's trying to make some money out of it as well. Which is, which is interesting.
Speaker B: Well, there's other, another, uh, answer. And I don't know whether I heard this on one of your podcasts or somebody else, but, uh, we're talking about the, uh, advent of fiber, right? And everybody was rushing to put out fiber optic networks for the Internet. And it ended up, uh, how much dark fiber we had around the country, right? Because we put all this fiber optic band in the country for higher bandwidth. But then from the node to the home, it was still dial up, right? It was still dial up or maybe broadband, but. So you didn't, weren't able to use all of that network, um, that we put in there. And I sit there and I think, wow, there's such a rush now for building data centers for AI and then the power to, to, to supply those data centers. And I sit there and I wonder what happens when we, we get all these data centers built and then all of a sudden somebody figures out another way to do it. Or it turns out that, um, well, maybe, maybe we don't need all that, that power because maybe AI isn't as powerful as we thought. And then we have all these data centers sitting there that are cold, but we'll see.
Speaker A: Yeah, that's right. It's a, it's a huge investment going on. I must admit it's kind of eye watering. My eyes actually water when I see the numbers. I'm like, oh, my God. You know, it's like, yeah, it's a huge investment and that has a cost. It reminds me of a little bit like some of the tech bubbles that we had where, especially in telecoms, we had lots of investments in certain technologies. And then it kind of depleted the investment later on because people were tired
Speaker B: and run out and a lot of those, those, you know, companies were belly up, you know, WorldCom and lots of, lots of them just, you know, disappeared overnight because of, of that bubble. So I wonder, you know, how much of how much, how much, how big is this bubble?
Speaker A: Yeah, it'd be interesting to see when, what happens with that, uh, bubble and you know, all bubbles at some point have formed a correction of some sort. So let's see. So on the tech front, back on, still on the AI, as we mentioned, AI is a big hype. How do you balance the use of AI and machine learning with clinical administrative workflows within hospitals? That's your kind of area. So it's got all these kind of like, possibilities, but also we've got some kind of practicalities as well.
Speaker B: Yep. So one of the things we're doing is, you know, you've got a, uh, set of data elements that you understand and you say, okay, based upon these data elements, we can make this, this process more efficient. We can figure out, you know, what patients we need to call at what time or things based upon these data loans. But then there are the, uh, elements that we, that might have an impact on that, but we know nothing about. Right. What other factors might exist that might make a procedure or a process more efficient that were. That just don't make any sense. Right. You would never extrapolate to say that this parameter has any impact whatsoever. But machine learning can, can look at a whole lot more parameters a whole lot faster and draw those inferences than we can. So we sit there and say, oh, wow, we never would have thought about this. Right. That this actually has an impact to the efficiency of getting a patient scheduled for a referral or whatever process it might be. So I think that's, uh, to me, the fascinating thing is being able to discover the things that we wouldn't normally have thought about.
Speaker A: Yeah, I like it. Yeah, that's an interesting one. And I guess, I guess this kind of stuff can be happening in the background without actually, you know, it's just there.
Speaker B: 100, right. 100. And it can make decisions and, and change the algorithms and the process to become, to make more efficient process without us even understanding. Right. Or knowing it happens. And this is nothing from my perspective, new we've been doing it, you know, different areas have been doing it for a long time. It's just now more approachable to everybody. Right.
Speaker A: So, and I imagine, uh, that once it does come up with a way of maybe improving the workflow, I've just got curiosity around. Is it a case of he just goes and does it or, uh, is there a human kind of gateway interaction?
Speaker B: So I think there's both. Right. I think you have to have so equated to social media. Right. To a certain extent where you're using AI to look at pictures and posts to determine whether it's a safe post or, you know, or not. I think you still have to have human supervision over that. Double checking and making sure it doesn't, doesn't go crazy. And all of a sudden it starts, you know, accepting things that it shouldn't be accepting. So I think you have to have, whether it's spot checking or something, but you've got to have some human involvement to make sure it's not going off the deep end, especially when we're processing, uh, faster. It's making decisions on its own. It's looking at factors and parameters. Right. And we know that going from here to the moon, you're off by one degree and you completely miss it. So it's the same thing in those algorithms and calculations. Right. It might make a slight change that's not noticeable now, but over time, if you're not paying attention, it can completely take you off course.
Speaker A: Yes. Yeah, that's a really good analogy. Actually. It's an interesting thing how we allow automation to kind of take to lead and you know, what rabbit hole that might kind of send us down. And uh, on that kind of similar note, you know, imagine you know, the systems that you're creating. You know, there's always a scalability issue there. You know, you want to be able to, for the thing to be able to kind of deal with scale. What in your experience and the time you've been there, maybe in your previous careers, how have you dealt with that, uh, ability to be able to design in scalability?
Speaker B: So there's a, you know, I hate to go down the road, but with the whole aspect of being cloud and cloud native has really provided a tremendous benefit to that. Right. We used to build, you know, build systems and put them on, you know, servers and sat in a data center. Right. You know, designed your service and everything for it to operate at peak capacity and they were operating at peak capacity all the time, whether it was the weekend or whether it was the middle of the night or not. You had to put a server in place with X processing power and memory to work at peak capacity. But now with, with containerization and being cloud native, you have to do that. The system scales as needed, which I don't want to say it's out of the box, but it's pretty close to being out of the box now, where you just follow the right design patterns, put things in place, make use of whichever cloud provider services you're using and for the most part, like I say, it works out of the box.
Speaker A: Uh, doesn't it? It's crazy. I mean, I'M reflecting back at how it used to be and, um, what it is now. It's pretty amazing how you can just add and remove stuff. And I think, you know, when it comes to the. Even the. The companies that provide some of these cloud services, how they're able to kind of like ramp up machines as the demand goes up and switch machines off as the demand goes down, you know, it's pretty fantastic. I just wish. I just wish more people. I mean, obviously we've got a tech leader audience or techie audience here, but I wish more people appreciated, actually, what's going on behind the scenes, the magic that's happening all the time, even on the website.
Speaker B: Well, it's, um, it is magic, right? When you think about it, it was magic. I was on a plane recently, um, uh, traveling and connected to the Internet, um, and, uh, was frustrated because I wasn't able to get a good connection. And then I thought about it. I'm on a freaking plane, for heaven's sakes. You know, flying across the country, able to get on the Internet at all. I mean, that's literally magic, right? There's so much of what you and I deal with every this, right? You're in the uk, I'm in the States. We're talking real time. Um, and it's not costing us a fortune. It's magic. Um, it really is.
Speaker A: It is mad, isn't it? In fact, I want to speak to my history. I worked on the RF side of mobile communications. So, you know, the RF maths, which is real magic.
Speaker B: Once you get into rf, it's crazy magic.
Speaker A: And I was talking to one of the engineers, and he showed me the signal to noise ratio of the signal or how they pull that out of the noise. And the noise was like, like up here and the signal was, like, down here. And. And I was thinking, how does that work? And he looked at me and he goes, it's amazing, isn't it? You know, this is amazing. And we get this stuff into our pockets, you know, so, uh, yeah, it's. I just wish more people appreciate. Maybe, Maybe we can morph the CTO Confessions podcast to be more about celebrating tech and, and teaching people around it to see the beauty behind the you seek, you know, kind of thing. Um, so, um, again, on the tech subject, what is a must have in your technology stack? What's the thing that you cannot do without or things you cannot do without?
Speaker B: I don't know how to equate it to a thing, but the understanding of the data. Right? Um, um, I Think really having a solid understanding of how the data is constructed and put together, um, is a must have and has become a somewhat of a problem sometimes because we can move so fast. With the advent of the orm, right, where you just write code and it magically creates the database behind the scenes and then you've got some business leader that comes to you and wants to know something, uh, about the data and you don't have a schema you can pull up or an ERD to look at and say, I think that becomes a continuing problem. I haven't come up with a good way to solve that yet. But um, but having that understanding of how the data fits together and how the data works and what relates to one thing and maybe AI will help with that a little bit, but that's the um. So, um, I think the must have is something I don't have yet. So, uh, in the old days, I had it right in the old days where we had a data architect or a data engineer and you put the ERD together and you had typically a big diagram up in the wall that showed all the tables and showed all the relationships and you could look at it. And although you can still create that nowadays, oftentimes it doesn't make logical sense, um, to us.
Speaker A: Um, hey, there's something also around because data's so abstract, you don't really know where it came from. You don't know the quality of it, uh, you don't know when it. Sometimes, you know, simple things maybe, you know, you don't even know when it, you know, what time span it was concrete. So there's something around it moving around. Then it kind of gets abstracted. Was it abstracted? Uh, this is data created from data, you know, all this kind of stuff. And um, so yeah, I think it's a really important. Yeah, I think it's not an interest to many people, but I think it has a huge impact on all of us, you know, so it's something around that.
Speaker B: But it's, it's a, so it's a, it's a must have that I don't have yet.
Speaker A: Well, yeah, maybe we can work on that. Um, so are there any non negotiables when it comes to Tech Stack within your team? So this is, so this is around the kind of team level of working.
Speaker B: I think for me this is, you know, the DevOps pipeline, right? And this has only been in the last, you know, five, 10 years. But having a good solid dev pipeline, right, where we can push out code readily, publish it to development, test it, um, and get it through the pipeline, I think is critical, um, um, these days. And I'll tie into that the whole concept of feature toggles, um, um, where you can actually push code into production and turn it on and turn it off, uh, without impacting the system. Um, I think the teams I've worked with, if you were to come along and take that away from them, they would be very upset. It's a protestable thing.
Speaker A: It's like, oh, we're not cause a revolution.
Speaker B: Exactly.
Speaker A: Yeah. It's got an interesting one. I think I've seen some great, um, uh, abilities to kind of release code and bring code together and test it automatically. And so far. And again, that's quite a beautiful way in which, you know, you can just be constantly generating releases and, um, then dishing them out.
Speaker B: If you think back when you and I were writing code, right? It was, you put the code, then you got to compile it, then you kind of load it somewhere and then run it and hope it works. And it doesn't. And then you've got to go back and debug it. And it's like it just took forever, right? So now you can, you can, uh, go through the pipeline a whole lot quicker and get it figured out a lot faster.
Speaker A: Brilliant. Yeah, I think that's a really good one. Um, what more do you think AI can do in your field? Okay, so specifically, um, to kind of the health area, is there an area that you feel still hasn't been touched?
Speaker B: Everybody's doing so much all over the place right now. It's funny, everywhere you go, you know, I don't think you can find a technology or a company website that doesn't have AI on the face of it. So I think lots of people are trying lots of different things. I'm, um, not smart enough to come up with an area that is not yet being investigated and being touched. I question how much of them will actually be truly useful or provide actual real value. Uh, um, we're using AI in three different areas at ABAC's health. Um, one is on the product side. Right. Um, then the other is on the development side. We're reason AI for Vibe coding and developers. The third is, uh, just for company knowledge. The ability to ask a question about. Hey, there was a meeting three weeks ago where we talked about this. Can you summarize that meeting for me? M. Uh, just being able to ask about meetings and transcripts and what's happened from the company knowledge has been a tremendous value to us. Um, to be able to get answers quickly. Um, the AI in the development pipeline, able to develop solutions faster. The idea, from idea to putting in front of the users to say is this what you're really talking about has been incredibly valued. And then of course on the product side we're talking about um, the um, machine learning and looking at all the different data factors we're aware of and aren't aware of to help um, improve the process. So those are the three areas that we're certainly focused on. Um, I think obviously in the medical world there's a lot of AI going on the diagnostics aspect and the health. So I think AI is pretty covered across the board. But like I said, we'll see what actually falls out turns out to be real and sustainable.
Speaker A: Yes. Yeah. I think it's also in part the democratization of it. It's kind of me made readily available. It's not down to a few big players, um, to, to control. Control that which, which I find quite, quite interesting. When you do allow it, it's all the corners that could be thought of get, get Thor, they get filled in some way. It's just about, I think then it's a question of awareness. Where are people taking this and where they haven't they taken this? Um, because I sometimes when I look at these new texts come out, I'm thinking there's no gaps, there's nothing I can, I can think of that I could fill here. You know, everybody's got it covered, you
Speaker B: know, and multiple parties haven't covered. To me it reminds me of the advent of the personal computer. Right back when the IBM PC kind of became open, right? Everybody and their brother was making computers. Everybody, right, the kid down the street was making computers. Everybody was making computers. Every town you went to there was some shop building PCs. Um, um, and eventually that scaled down to now there's only a few large manufacturers, um, and then the occasional individual who's more of a hobbyist, um, and it'll be interesting to see how that plays out with AI. Right, because everywhere you look there's another LLM or, you know.
Speaker A: Yeah, it's interesting. I've got just a random question I want to throw you around that. What was your very first PC? Was it an IBM?
Speaker B: Well, the very first PC was uh, a, uh, Radio Shack TRS 80.
Speaker A: Okay. I don't, I don't recall that.
Speaker B: Yeah, yeah, back, back when I was, um, right out of high school, I worked at Radio Shacks. I don't know if you have Radio Shacks.
Speaker A: I Know of it. I've seen it in there in Sheldon Young Sheldon. You know, they mentioned it in that. The, uh, comedy series.
Speaker B: Yes. Yeah. So it's no longer in existence a long way. But they were, um. They were one of the first home computers that was out there, was the TRS 80. Um, and then it was also the Commodore that was the big competitor at this point.
Speaker A: Commodores were pretty amazing because they had, like, multicolored pixels in a block. I was a ZX81, which was the very early, uh, Spectrum. We called it the computerized Frisbee. You know, literally, it was a good Frisbee as well, and, uh, the ZX Spectrum. So I was more of a Sinclair kind of.
Speaker B: Uh, I had a Sinclair. Um, so, um, it didn't do much with it. Um, but. But I got one because I thought it was really cool.
Speaker A: In fact, I bought one off ebay. It's just as a bit of an historical thing, I thought, you know what? I don't know what happened to mine, but I bought one just to kind of fill that gap.
Speaker B: I wish it might. I went from the. The TRS 80 Model 3 to a Compaq, which had. There was a big box and had the E board as the. The top that you disconnected and came down. There was a little monitor on it. Um, I wish I had both of those right now. I don't know. Don't know what happened to them.
Speaker A: Um, they're probably in some attic somewhere waiting for you to rediscover them. Good stuff. So here we go. We've got to come onto your leadership. This is my. This is my passion. I love leadership. But I think we had a wonderful conversation, uh, beforehand. I, uh, wish we would have recorded some of it, but hopefully, uh, we'll cover some of the points here again. So how do you choose your team members? Oh, this is a good one. I like this one. How do you choose your team members? What matters most when you're hiring?
Speaker B: So I look for three things. Um, they're absolute must haves, non negotiables that I have to have out of everybody. Hire. Uh, humility, hunger, and intellect. Um, um, and I'll be honest, I stole this from the ideal team member for a book from Patrick Lencioni, and he defined it as Humility, hunger, and social eq. I replaced social EQ with actual intellect because from a developer, an engineer, trying to make that a factor limits my audience somewhat. But. But I want somebody who has the desire to learn that curiosity, that sense to explore and try new things. Always Learning, right? Always learning, always growing the humility to understand that they don't know everything and they're not the smartest person in the room, even if they are. And then the intellect to be able to learn to, to fulfill that curiosity. Right. A lot of people have the desire and the, the, the curiosity, but they just, they can't connect the dots. But if I have people with those three things, they may not know the technology stack, they may not know the programming language, but I can get them there.
Speaker A: That's a really good list. So I'm going to ask you a really tough question now. Okay? So with those, how do you spot those in a hour long interview? Maybe even less than that.
Speaker B: So I do some weird things in our interviews. Oftentimes I'll have a team interview and we'll play a game. There's a game called keep talking and nobody explodes. It's essentially, we'd have a situation like, like this, uh, there would be a bomb. You know, somebody's got to disarm and then somebody's got a set of instructions that tells you how to disarm. And then the two people have to communicate back and forth. Often like what we see in movies and TV shows where, you know, somebody's on a phone trying to de. Arm along. Um, and the candidate will play the position of being what we'll call the hero of disarming the bomb or the, or the expert. Often we flip it back and forth, seeing how they behave in that environment. And there's other games we'll play as well, but seeing how they behave in that environment of trying to solve a problem and collaborate with someone over the phone, right. If they'll sit there and the bomb blows up, it's like they blame the other person. Well, you didn't tell me this or you didn't communicate that you're out. So seeing that dynamic helps a lot. I will, uh, will be in the middle of an interview. Maybe I've got you on a whiteboard or something diagramming and explaining the problem and I'll ask some uh, inane question out of the blue, like what's your favorite flavored bowling ball? Which makes no sense whatsoever, but how the candidate reacts to the question. Right. Sometimes they'll just give you an answer. Right. Sometimes they'll completely throw their train of thought off and they're completely lost. So I do a lot of really kind of different things just to see how people react to different situations and that, that, you know, one of the things we often ask is teach me something Teach me something not necessarily about technology, but something that you're passionate about. So I've had people, you know, explain how to make beer, how to, how to build a guitar. Right. All sorts of different things. And then seeing how well they can communicate that and seeing their passion for that tells me a lot.
Speaker A: Nice. That's really good one. I'm trying to think of how I would answer some of your questions, actually, but. Yeah, yeah, that's a really good one. I'm going to take them.
Speaker B: Oftentimes it's not so much about the answer, it's about the response. Right. Uh, how, uh, do they react to the thing? Right. So it's just like often in interviews, often say it's not so much about the answers somebody gives me, it's about the questions they ask me.
Speaker A: That's really good. Yeah. I'm going to read that to Patrick Renci, uh, one of his.
Speaker B: Patrick Lencioni, he's got a series of books.
Speaker A: Yeah. He. The Five Dysfunctions of a Team, didn't he?
Speaker B: Another great book.
Speaker A: Yeah, yeah, yeah. That's one of my. That's one of my kind of, kind of pillars of team dynamics. But yeah, I'll have a look at that. But that's really interesting. In fact, actually, you mentioned that you would place the social eq. EQ is actually a really important part of the human dynamics, the kind of people side of stuff and how that creates a dynamic within teams. And I'm always interested in people that don't have a clue and people that are a bit more clued up, you know, and the impact that has.
Speaker B: Well, it's being somebody who is a former introvert and incredibly shy. Right. One would say now that, you know, gee, you were shy. Right. You were, you know, uh, introverted and I was, I was an extreme introvert. Incredibly shy. You wouldn't get me to look you in the eye or anything. It was just, it was tough. And I fortunately had a phenomenal mentor, a gentleman by the name Nick Clevis, who took me under his wing and he forced me to go to Dale Carnegie, forced me to go to Toastmasters, and just really forced me out of my shell, which took me into leadership. So had some great mentors over life. But as an engineer and maybe this goes against the thing, I'm not sure social EQ matters as much because I do think if you get a group of engineers together in a room who all in public are horrible. Right. But you put them in a room working on a common problem, it's like the room Lights up. Right. You take those people that are introverts and shy and couldn't carry on a conversation, you put them in a room, put a problem in front of them, let them work it out together, and this magic happens. Right. So what other people might see as, I think, uh, high EQ is not necessarily, you know, what you might want in a salesperson. Right. Or in a business leader or a teacher is not the same type of EQ that I think you need to have in an engineer. This is, of course, my perception.
Speaker A: Yeah. Yeah. That's interesting. That's an interesting take to touch on your.
Speaker B: You.
Speaker A: I, uh, guess moving out of your kind of introvertness, a similar kind of story here. I found Toastmasters, that public speaking, absolutely a game changer. In fact, that was a game changer for me. It unblocked a huge part of my. I had a number of shadows around communication in the space for various reasons. I got traumatized by trying to do a talk and it went horribly wrong. And I got laughed at and it just kind of created a whole thing. But Toastmasters was really good for that. And Tael Carnegie's book, How to Make Friends and Influence People. Brilliant. Honestly, if someone hasn't read that, do read it. Because even if you think you're good at it, it's got some great tips.
Speaker B: I've sent so many engineers to his course and give them that book because somebody did it for me. Right. So he pay it forward. But it was a game changer for me as well. Right.
Speaker A: Yeah. So here, here, here to both of those. Okay. I champion those. So do you believe hard work beats talent?
Speaker B: It's a really good question because I consider myself that talented of an individual. Uh, but I certainly feel like I've put in a lot of hard work over the years. I've also probably gotten lucky, I think. You know, I have a saying. I say a strength overdone is weakness, and a weakness overcome is a strength. So you can take somebody who's naturally gifted and naturally talented, but then they can become, and not necessarily the case. They can become that prima domino. They can become that person that's hard to work with or won't get anybody else the time of day because somebody's not as good as they are. So I think having natural talent can be a detracker. But the same thing can be on, um, the hard work. Somebody can put in a lot of hard work and get to a certain, certain point in life. And now they're, they're the, they're the prima donna So I think it's a. I think they're equivalent, but I think that humility is an underlying thing that probably is regardless of where you put in hard work or the talent. If you don't have humility goes out the door.
Speaker A: I think you're right. In fact, it reminds me of something. When I'm working with leaders. I talk about humble confidence. So you can be confident without being a. I, ah, was going to use a really bad word then. But I think you think your humility is really good because it's kind of questioning yourself. You know, we're not. We kind of sure what we're doing, but kind of questioning as well to have that ability to step back and go, you know, what do you think? Uh, there's always a door open. I think it's interesting with this question is that uh, I mean I think I've got to where I've got to by hard work because I don't think I'm naturally talented but. And I'm so. I'm not fast, I'm not the fastest out there. There's people out there that just seem to look at stuff and fix it without even moving a finger. You know, I can make a shot, give a shout out to quite a few people like that and I'm just ignore them. But what, what people that put a lot of hard work in is they bring a bit more of a thoroughness, a little bit more thought out and they see, they see more connections. So I think, yeah, there's uh, I think there's, there's benefits in both and, and what we find is that uh, I wrote down here as you were describing, the kind of talented ones that become kind of bit bullish. I call them intellectual bullies because they were probably bullied for different reasons and they think, well now this is my time, this is my space, you're in my manner, my domain and I'm going to make sure that I'm the top boss. And it's a shame really because it's just, it's just not cool. It's not very nice.
Speaker B: You know, uh, nobody is from my precise. A human is better than anybody else, right? We all start out the same way, we all end up the same way. The journey may be different, but we end up, start out and end up at the same place. So I think that, that when I was. That mutual respect, right, of wherever you fit on the ladder is important.
Speaker A: So, so anybody listening out there that feels that they are a intellectual bully or you know, uh, you're hard you know, we've all got money to bring. Just kind of consider each other, have a bit of kindness, compassion, I think. I don't think we celebrate kindness and compassion and empathy enough these days. Maybe.
Speaker B: Yeah. But I will add to that because there's another factor to that, which is, uh, kindness doesn't necessarily mean you're being a pushover. So I'll go back to a point in my career where I had gotten to that point where I thought I was a little bigger than my britches really were. And the same gentleman I mentioned earlier, who was a great mentor, was still my boss at the time. And he pulled me aside and he fired me. It was one of the best things that ever happened. He cared enough to do something that was incredibly difficult because we worked together for years. It was my mentor. We were friends, and we're still good friends to this day. But he cared enough to pull me aside and fire me. That was tough. So you say, is that kind? Actually, it was because had he not, I would have continued to gone out down a path that was just not a good path. And, uh, you know, it was the, uh, gestalt moment. I needed to shock my world to wake me up. So I think that's the important thing. But although he fired me, he did fire me with kindness. He said, hey, you need to wake up. Take some time to figure it out.
Speaker A: That's really good, actually. I think, yeah, this is kind of, uh, I sometimes refer to as tough love, you know, and it's also seeing it for the wider picture as well, because sometimes people's. Again, I relate to your story because I've been that. Okay, I've been that person that needed to be kind of taken down a few notches. I think what it is, is our egos get fed and they become monsters.
Speaker B: We start to believe ourselves.
Speaker A: We get into our own echo chamber, and people around us start to kind of feed that. And what we actually need is people to meet us, to actually. No, no, no, no, that's not cool. You know, everybody else thinks it's great, but I'm going to tell you something. Out of love or out of compassion, this is what you need to hear. And I think this is where we learn and we turn, uh, turn it down a bit and we could go back into that zone of. Of, you know, the ideal kind of bracket of operating with that, you know, rather than kind of overdoing it. I've, uh, seen people where their egos have got so big they actually destroyed themselves. They. People didn't want to work with them anymore. I was one of those as well, by the way. Kind of a confession. Confession. So yeah, I think that's a really good point actually is, is, is knowing when as leaders we need to kind of call people out on their stuff. Uh, what we're seeing. Okay. And rather than. Yeah. Being overly kind, there's different forms of kindness.
Speaker B: Absolutely. Yeah. Yeah. And it's, and kindness, like I said, doesn't necessarily mean you're a pushover. Right. Doesn't mean you're, you know.
Speaker A: Yeah. And actually this is an uh, interesting topic in terms of leadership. I think we can have, we can have leaders that, uh, taking a step back. So I, I think sometimes that people who are kind and who are, who are good. Okay. You know, they, I don't think they step into that kind of that, that other side of kindness to do the tough stuff, to deal with the tough topics. And we need more of that in the world because somebody's going to fill that void. And often it's usually the people that we don't want to fill that void. You know.
Speaker B: Are you familiar with the, the Dunning Kruger effect? Dunning Kruger curve. It's one of my favorite things of all time. For those who aren't familiar with it, look it up. But on the, the far left hand side of the curve it's, it's, it's confidence versus skill. And oftentimes you've got these people that have incredible amount of confidence but no real knowledge or skill. And as we become more and more knowledgeable, the confidence drops down to go the valley of despair where all of a sudden you start to realize that you don't know nearly as much as you think you do, but yet you're far, far more knowledgeable than you were on the other side. And to me, uh, that one curve explains so much about so many leaders. Right. That they haven't gone through that valley of despair realizing, yeah, I'm not really all that in a bag of chips.
Speaker A: Yeah. It's interesting as human beings are amazing, aren't we? We're just such complex creatures.
Speaker B: Well, I think you and I started off as electronics engineers and things and it was a complex problem, but it was solvable. And I'm not sure the people equation is solvable. Right. There's so many more variables, right?
Speaker A: Yes, that's right. It's a complex, complex system. You know, complex square. And I think we just have to uh, for me, around leadership and we've kind of touched on this is around raising awareness so we can dance with what's here and just learn from. So continuously learning and adapting to it. So, yeah, brilliant topic. You know what? I could have a proper chat about this over a beer or, uh, whatever it is.
Speaker B: We will figure out how to make that happen.
Speaker A: Yeah, we'll have to m. Make that happen. So I've got a final question here around leadership is that if you could go back to the start of your career, okay. What would you warn yourself about?
Speaker B: You know, it's interesting, I want to say I'd warn myself about getting too big for my britches and exactly what we were just talking about. But there's this other side that I feel like if I wouldn't have gone through that, right. I wouldn't be the leader and the person I am today. So, you know, I think there's dozens of things I could sit there and I wish I didn't do or had not made those mistakes. But at the same time, gosh, if I. If I hadn't made those mistakes, I wouldn't be where I am today. Another mentor of mine and gentleman, Jordan Klein. Many years ago, when I was an engineer, was working in designing a pressure vessel for underwater camera. And I was sitting there working all these calculations and trying to figure out the ideal thing. And he comes in the room, big thing, was throwing a phone book across the room, and he says, just go down to the shop, weld something together, put it in the tank and blow it up. You will learn more from blowing it up than you ever will from all the research and all the calculations. And that has held true in my life for just about everything. Unfortunately, sometimes once you blow something up, you can't put it back together, particularly with relationships. But the next one is always better. Right. And everybody said it over. Numerous people say you learn so much more from failure than you ever do from success.
Speaker A: Yeah, I think that's an interesting thing around how unforgiving we are. For example, if I saw somebody getting too big for their britches, you know, wouldn't it be great if we could just say, well, they just need to go through that process, you know, let's encourage them. Let's go for it, you know, see. See how far you can take this and then just come back a little bit from me, you know, kind of come back from the edge?
Speaker B: Well, certainly there were numerous people that warned me. Right. And I just chose not to listen until. Until it blew up. So, yeah.
Speaker A: And it is those moments where, where we do end up hitting that. That kind of wall. We go over the edge, the cliff and we kind of do it. And that does come define who we are. Because, you know, I mean, I, I work with a lot of leaders. I, I, I couldn't be as good at what I do if I hadn't have made the mistakes and complete and utter, you know, utter messes in the space. It's just that the only thing I probably wish for would be probably some form of forgiveness from people to say, all right, that's what you needed to go through. It's all right, we're all done, you know, you're good now, you know, kind of thing.
Speaker B: I've been very fortunate. Like I said, gentlemen, good friends now. So I think I've been very fortunate that everybody's forgiven me and we've come through as far as I know.
Speaker A: Yeah, yeah. And it comes back to our, Hm, humility. Maybe humility is enough for us to come back and say, yeah, I've learned. I've learned. Thank you for teaching me, you know, kind of thing. Or I've learned my lesson now. So that's good. So as we come towards the closing arc of our time together, unfortunately, Jack, are there any books, any, any films, any, any instrumental things that you've experienced in your life that you'd like to share with the leadership audience here?
Speaker B: Oh, gosh, so many. I'm an avid reader, I will say. Several years ago I started writing a book of my own to explain how I felt software engineering and software development should work. And then, uh, a book came out by a gentleman named Gene Kim, who wrote the DevOps Handbook and who wrote Phoenix Project in the Mirror. And he came out with a book called Accelerate. And I read through it and it pissed me off so much because it was like, this is the exact book, book I want to write. This is, he wrote what I wanted to write. And still whenever I start a shop, uh, or uh, uh, go into a new thing, I tell everybody to get the book and read it. But Accelerate by Gene Kim has a fantastic book from a development, software development, life cycle, operation stuff, of course, all the Patrick Lencioni books we talked about. There is a book, the Code, the Goal by Eli Goldthwaite.
Speaker A: Oh, yes, I've read that.
Speaker B: Yeah. Excellent, excellent, excellent book. And then probably another, uh, book more, probably more Spiritual Nature, but the Servant, by, by James Hunter. It's all about servant leadership and about serving. And that's, I would say I try to. Emily, being a servant leader, right? The people don't work for me, I work for them. Right. It's my job to help them Be successful in their job, to help them grow, to get to where they need to be. So.
Speaker A: So I've read some of those and I haven't read some of those, so that's a good selection there. And I'm going to offer you a wish. I'm going to be. Pretend to be the tech genie for a second. I'm going to give you a wish. What would you wish for? For your leadership, for your industry, for tech in general.
Speaker B: So, so this is probably controversial in nature, so, but, but uh, uh, here in the States we focus a lot on offshore development, right? Because of the cost. And we sit there and we look and say, gosh, you know, for what it costs to hire three engineers in the States, I could get a dozen right offshore. And that drives me nuts because again, I'd rather have a much smaller team, more cohesive team, same time zone. Um, nothing against developers in any other country, but time zone matters a whole lot, right? It's tough when you have to people on the opposite side of the world and different time zones and a number of different connection points and stuff. I would love to get over that. Let's try to focus more on having. And of course, you know, now with the distributed workplace and stuff, it, it makes it tough as, as well. It used to be nice when we'd all go into the same office, but I'd like to see more, you know, local centric development. But uh, I, I think the. There's another argument to be made the other way.
Speaker A: But. So one of the things that I miss actually is going into the office and being around a whiteboard, being next to people's desks, having those very, very rich conversations in the whole body language, the way we're sitting, the room, the space, the stuff like that. So I don't know, maybe we'll go back towards that in some way. Maybe we'll have islands of working away from home. You know, the hybrid kind of model kind of thing.
Speaker B: If you get together, you know, on a quarterly basis, we sit around and work out problems and stuff like that and build those relationships, right?
Speaker A: So maybe technology can fix this. I'm just going to have a tiny kind of idea around this.
Speaker B: So either Transporter from Star Trek. Wow.
Speaker A: Anything's possible. We can wish for that.
Speaker B: You know, there we go. That, that would be the wish.
Speaker A: A gateway that kind of connects two offices together that are actually, uh, on the other side of the world. There's a film, I can't remember the name of it, this Bruce Willis, where you actually connect into uh, like an Android. I can't remember the name of the film, but you, you plug into a humanoid type kind of robot thing. It looks like a human being walking around, but it's actually somebody who's asleep lying in a bed in their, in their house. And they're able to then walk around and kind of be and do and
Speaker B: feel, you know, that is that answer, that virtual reality? That might be the answer to that.
Speaker A: Yeah. Yes. I never know.
Speaker B: But again, it always comes back to communication. Right. It's, that's, that's the fundamental problem is the communication.
Speaker A: That's right. And maybe the technology can add a layer onto that to kind of smooth some of that out as well, you know, as a kind of bit of a feedback. Actually, you might want to say, you might not said this, you know, what have you as a reminder. So that's brilliant. Beautiful, beautiful wish. As we come to our, uh, kind of full stop of the podcast, what's your parting comment that you'd like to leave with our tech leader audience out there as a, ah, gift as we
Speaker B: part company, I would say remember, it's not about the technology, it's about the people. Right, the technology. Everything that we do fundamentally is there to serve humankind and serve people. So it's not about the technology. It's not about the zeros and the ones and the bits and the bytes. It's about people. And if we keep that centered in our mind, I think we make better technology solutions.
Speaker A: Beautiful note to finish on. Thank you for that comment, Jay. It's been wonderful having you on CTO Confessions.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.