How to Transform a SaaS Company with AI from ELMO CTO

Speaker A: The way that we see it is if we can get 80% right on a first pass, that's a considerable amount of effort that's being saved and a huge head start. And then we focus the human effort on that last sort of 10 or 20%. So effectively, AI just becomes the workhorse that's validated by humans.

Speaker B: Welcome to the Data and AI Chief. I'm your host, Cindy Howzen. Picture, uh, it. You've rolled out the AI tools, you've made the business case, and yet your people are anxious. Management is demanding results, and yet the ROI has yet to materialize. If that sounds familiar, you're not alone. And today's guest has lived AI from both sides. Josh McKenzie is the global CTO of Elmo Software Group, an HR rota and payroll platform serving over 19,000 organizations across Australia, New Zealand and the UK, where he's responsible for building AI into the product and in doing so, has led his own internal AI transformation. In this episode, we'll explore the human cost of AI transformation, what Elmo learned doing it themselves, and how HR teams can close the gap between AI adoption and real results. Josh, welcome to the Data and AI Chief.

Speaker A: Hi, Cindy. I'm glad to be here.

Speaker B: Yeah. And where in the world is here?

Speaker A: Here for me right now is Sydney, Australia. So bright and early 7:42 this morning.

Speaker B: Yes, my evening, your morning the next day. Now, Josh, for listeners who are not familiar with Elmo, tell us a little bit about the company and your role there.

Speaker A: Sure. So Elmo consists of, uh, effectively three different companies. Elmo is a hr, um, system that operates in Australia and New Zealand. And we target mostly the mid market, so companies of sort of 300 to 5000 sort of size. Um, we also own two businesses in the UK which are quite polar opposites. We own a SMB product, Breathe. Breathe focuses in the same space, but, um, down for much smaller companies, I think 5 to 100. And then completely on the other side, we have, um, a company called rotorgeek, which focuses on the enterprise space. They have clients like, uh, for those that are familiar with the uk, Pret A Manger and Cat. Cafe Nero. So some big companies that have high, um, roster time and attendance needs.

Speaker B: Yeah, Pret Amanje. Of course, I know that. And Cafe Nero. Actually, you know, you being in Sydney, I feel like I should have started by asking you who has the better coffee, Sydney or Melbourne?

Speaker A: I live in Sydney and I'm still going to say Melbourne, it's better.

Speaker B: Uh, I know our friend James Belzy will appreciate that answer. But we don't want to get you in trouble there. So you're at an interesting intersection because you're infusing AI into workforce software. You're also at the front line of, uh, seeing the impact of job disruption as companies, especially tech companies, are announcing mass layoffs. It feels like every week. What are you seeing on the ground? How are people reacting to this? How much is this a love versus hate relationship with AI right now?

Speaker A: I think clearly people are very nervous, dare I say, even angry, about the perception that AI is going to take jobs. We've seen similar things in Australia. So some big Australian tech companies have also laid off several thousand staff under very similar conditions. And Elmo runs a survey, we call it the HR IB survey, out to all of our customers. And we found that 86% of organizations are expecting headcount as a result of AI changes.

Speaker B: I feel like within a matter of two months, I went from being popular at dinner parties. Everyone's like, oh, yay, you work in AI. I want to learn more. That's so cool. After 30 years, finally I'm cool to now like, a mom went off on me. I hate AI. My son can't get a job from AI. Humans don't like change. And if we haven't painted a good picture of what's coming next, there will be some panic. It was only seven years ago. I was talking to someone about how appliances were state of the art. Netezza was shipping bare metal boxes. Even SAP had BW accelerated. And that was only seven years ago. And this person, uh, just had no idea. A data engineer, he's like, why would anyone ever do that? Like, he thought cloud was forever. Like, no, that's only in the last six years, five years that it's really mainstream. So what do we say? Time flies when we get over that painful disruption.

Speaker A: I think it does. And I think people adapt to the new normal really quite quickly. I, uh, do think that we're living in that acute period right now where people, and probably the industry, to be frank, doesn't really know where this is headed. I think, like, a lot of things, though, standing still is not really an option. You kind of have to dive head first in and, and see where, see where the chips land.

Speaker B: Yeah, head and head first is how it is. Like, there's no playbook for this. We have hints of it, like with digital, like with cloud, um, even the Internet. But I would say a lot of the workforce does not remember that era of total redesign and reinvention. You alluded to a Number of data points. Josh, based on the data you're seeing, and you're a SaaS company, it doesn't sound terrible. Is a SaaS apocalypse coming, or what's your take?

Speaker A: That has been a really popular narrative, um, over the last, what, 12 months or so. I think that, um, like with a lot of those big blanket statements, there's an element of truth to it, but it is nuanced. Um, and I guess I don't see it as an apocalyptic event, but I do think it will change a few things for me. It feels like. Let's just talk about what a SaaS company actually is and what it brings to the table. I mean, a, uh, SaaS company will bring software to the table, but that's the outcome. That's not necessarily everything that they're bringing. They bring deep expertise on the subject matter. In fact, they've probably spent decades or years investing in that subject area. And they're looking at industry standards. They're looking at what works for everybody, not necessarily what works for particular company. They bring a lot of technical standards that I think are, uh, easily glossed over. But I'll, uh, be really specific on this. They bring security, performance, compliance, integration, governance. And the big one here is they bring accountability to the table. If I put this in my sort of lens, if you're a payroll software SaaS company, you are accountable for ensuring that Josh's salary ends up in Josh's

Speaker B: account, right on time, um, with taxes deducted per every region, state, whatever. Correctly.

Speaker A: Yeah, exactly. And every time. Right. So you have to ask yourself, if you're going to go build payroll software from the ground up as a company, do you really want that level of accountability? The other thing like, is usually a SaaS company brings a level of scale that makes the solution actually cheaper, uh, to run and build for the client, because they're spreading that cost out over thousands of companies. And a SaaS company consistently improves their product, or at least a good SaaS company should be consistently improving their product. So where I think there may be like a grain of truth in the matter is SaaS companies that aren't a record of truth and do not need to meet all of those requirements that I just spoke about may find themselves in a little bit of trouble because a company may choose to go rebuild a similar solution if, especially if they already have technical resources to do that. I would say, though, that, um, if a company chooses to do that, they need to, um, ensure that they have the right level of expertise to support that solution moving forward.

Speaker B: Those are some great points. I do think the, the moat, um, for SAS companies, even for a company like Thoughtspot, it's the depth of expertise in a domain. So in Elmo, it's in the hr, it's in, uh, the payroll. In Thoughtspot, it's in the analytics. Uh, your point about spreading out the cost across multiple providers I think is a really good one. And then I think the last one is people love to build things. I don't know who likes to maintain them. Uh, so it's fun to build, but then maintaining is also why you want a tech company. So I would say build maybe what is your core IP and differentiator, but then buy from a partner, uh, what is not your core ip. So, so as you look at when you were approaching adding AI to Elmo software, how did you start? What was the main problem or opportunity you were trying to tackle?

Speaker A: Yeah, this is a bit of a. Bit of a journey, so bear with me. I'll tell a little bit of a story here. So this sort of all started right back in product discovery. So from a product perspective, we were in a state where we were really trying to challenge ourselves on what we can do now with AI that we couldn't do yesterday with AI and we wanted to help our customers navigate AI, uh, disruption. We've just heard, like, some of the stats that I threw out there. There's a lot of companies that are going through this right now. We knew that AI would bring considerable efficiency gains to staff, but it's unlikely that whole roles would be 100% impacted. So the way we approached this was we decided that we're going to start with building out capability frameworks. This is an exercise that, uh, typically larger organizations would do with management consultants. They go in and review the organization, review all of the roles and responsibilities, and many, many sticky notes later, they will come back with a big, um, deck describing what the capabilities are for that particular organization. We thought that we could, uh, absorb reams of business and, uh, academic literature on the topic into our, uh, own AI models. And because we already have the context of, you know, these people work in these roles, and this is what their description is, and this is what the org hierarchy is, we thought we could build out a capability framework in moments, not months. But this was really the starting line. So from there we can then take that capability framework and then analyze it and look at where AI could impact certain parts of roles, or at least should impact certain parts of roles. So Elmo is in the fortuitous position of using Our own software. I think Microsoft calls it dogfooding.

Speaker B: Um, we call it champagne. You drink your own champagne.

Speaker A: So looking at our own capabilities through that lens, things really started to unravel for the technology department. It was really interesting. It felt like you're sort of pulling the loose thread on a jumper and you just keep pulling and pulling and pulling. And we ended up with a ball of yarn and then had to rebuild the jumper. A consequence of all of that was we fundamentally rethought our, uh, software development life cycle and all of our roles and responsibilities. And so some of the headlines that came out of that was, um, we removed the junior roles from our titles. And that's not to say that we weren't hiring juniors anymore per se. What we found is with AI, particularly junior engineers are far more effective than they would have been coming into. Coming in cold and really leaning on the more senior members of that team, that was unnecessary. And we felt that the junior aspect of the title could be removed. We found that we needed to slim down, uh, the engineering ratio in a team. Typically we'd have like six to eight engineers per team. And now we're looking at three to four engineers per team. And that's as a result of just the rapidly increasing throughput as a result of AI. And what that allowed us to do is it allowed us to increase the number of teams that we had by reallocating resources out. So what all of this means is that engineers are now directing agents to write code. They're not really writing code themselves. They're not using AI to write, like as a coding assistant anymore. But it goes broader than engineering. It's like product using AI to build specs. And specs are really, really important in an AI world. Designer using AI to build the designs. And if we, the way that we see it is if we can get 80% right on a first pass, that's a considerable amount of effort that's being saved and a huge head start. And then we focus the human effort on that last sort of 10 or 20%. So effectively AI just becomes the workhorse. Um, that's validated by humans.

Speaker B: Yeah. So if I think about some of the points that you made and how somebody could misconstrue it, if you say, we have no more junior engineers, then somebody fresh out of college is going to think, I can't get a job there anymore. Whereas the reality is you elevated, you started them at a higher, uh, entry level, let's say. And then reducing the team size is you made the teams More impactful by making AI agents part of the team. So it's fewer people to manage. But you use the term workhorse, so a lot of this sounds like how you position it so that people are not fearful. Did I get that right?

Speaker A: That is a big part of it, yeah.

Speaker B: So how did you ensure, let's say, the psychological safety, uh, of the engineers and the managers as you were rolling this out?

Speaker A: People aren't stupid. Um, we hire really smart people. Engineers are generally really smart people. What we found was being communicative and transparent goes a really long way. We explained what we're going to do or what we wanted to do, why we wanted to do it, and we actually asked for help to define it. Um, we involved, we involved everyone in the process. I think it's really important that we instill a culture where it's okay to fail and it's okay to make a mistake. And even more so, you kind of want to be vocal about your mistakes so others don't repeat the same mistake. It's okay not to know the answer to a question and ask for help. I think to instill that level of psychological safety. What was really important is involving, is creating that culture and involving, um, everyone who wanted to be involved in that, in the decision making process to contribute to it. We've been on this journey for like 12 months. This started out with like a combination of training, brown bags, showcases, demos, pair programming, all of that normal stuff. But it eventually built all the way up to redefining that entire process that we have and specific roles within that process. And that was all done collaboratively?

Speaker B: Yeah. That's great. Is there a particular mistake that you're allowed to share, um, that you want to elaborate on that you would say if I started over again, I wouldn't do this. Or picture a listener who is just beginning on this journey.

Speaker A: There's a temptation and I don't know if it's a good thing or a bad thing. The way that we did it was to be pretty collaborative. But uh, being collaborative and working in that sort of more democratic style of leadership is slower. It is slower. You could take a view to be a lot more authoritarian if you like. Mhm. And be like this is what we're doing. But I felt that if I took that path, I'd probably lose most people's trust very, very quickly. And I didn't think that that was worth it.

Speaker B: I would believe that it might be faster to be authoritarian in the short term, but in the long term, I think people who don't trust you are going to circumvent and undermine you and talk about why everything you're doing is wrong behind your back.

Speaker A: That's exactly what would happen 100%. And ultimately, like, it's a technology change, but it's a lot more than that. It's a change management process and you want to change the people in the process process in particular. And if you have sort of all these dissenting voices and people wanting to go back to the, to the way it was rather than pushing forward into the way that it could be, um, you really want their buy in, in that process.

Speaker B: Hi data and AI friends. We are at a generational shift. Some might even say a, uh, once in a lifetime opportunity. To capitalize on this opportunity, you need more than just great technology. You need a mindset shift. That's why I'm proud to say that ThoughtSpot sponsors this podcast. Go from raw data to trusted insights and action with ThoughtSpot Agentic Analytics, a platform powered by a suite of specialized AI agents. It's why companies like Cisco, Lyft, T Mobile, Sephora and Schneider electric count on ThoughtSpot. See what the future of analytics looks like at thoughtspot.com. Now, some of what you've rebuilt in Elmo you've built from the ground up, and some you've had to decide who to partner with for the data insights. And how did you approach the buy versus build decision as you evaluated Thoughtspot?

Speaker A: Ah, as a business, my, my belief is you want to focus on your secret sauce. So what is the thing that makes your business super successful? And for us, that's not data and analytics. That's where we came to look at ThoughtSpot. We could, or we had a, um, we had a previous, uh, data analytics, homegrown solution. Right. It was quite powerful to be honest, but it required a level of expertise from the users that just wasn't present in most cases. It required them to understand the Elmo domain model. It required them to understand sort of basics of data analytics. And that expectedly led to the kind of feedback of it's hard to use, right? So we started looking around. We found Thoughtspot. Thoughtspot was particularly interesting for us because, yes, it's a really nice, um, visual user interface and allows you to create some great dashboards and whatnot. But the big thing for us was the spotter product that you guys have. Allowing users to bridge that data analyst gap was, um, was really important. Um, so that product has yielded really, really great results for us.

Speaker B: Well, I love hearing that. And to clarify, Spotter is One of our first AI agents that let um, anyone ask questions of their data. Now I often say with the utmost respect that HR teams are historically the most underserved within larger organizations. The data team will focus on supply chain or sales and HR teams have to fend for themselves. How do you feel about that, Josh?

Speaker A: What I've seen from speaking with people in Australia mostly um, is that HR teams are typically not involved um, in the procurement process of software. And particularly for um, SMB and mid market organizations there isn't one piece of software that satisfies all their needs. So what this means is HR teams are getting payroll data from the payroll people. They're getting um, I don't know, salary benchmarking data from salary benchmarking providers and performance data from here and learning data from there. And all of this culminates in uh, spreadsheet hell basically.

Speaker B: Oh yeah. Oh that's even scarier. I don't want that sensitive data in spreadsheets.

Speaker A: No one wants that sensitive data in spreadsheets and especially HR teams don't want to, don't want to live through this. So um, I guess with AI there's like three things that sort of really help bridge that gap. The first one is the ability to do sort of look at data and bring it all together. Right. You could have done this through other mechanisms um, historically like MLOps and various different other data technologies but, or techniques I should say. But that's often cost prohibitive for the SMB and the, in the mid market um, space. So as especially over the Last sort of 18 months, two years as AI has really evolved, it's made that process so much easier. In addition, um, we can start looking at doing anomaly detection, trend analysis again. Things that we could have done before but it was really expensive and now it's a lot more accessible. The thing that we couldn't do before that has just totally bridged that gap is the LLM component and the ability to interact with your, with your data at your level, um, that's really, really powerful.

Speaker B: So give me an example, like what's an insightful question uh, that somebody can ask and get an insight to that would have just been so manual before that a leader or a manager wouldn't

Speaker A: bother with it would be tying a couple of data sets together. Um, so you may have as an organization of say a thousand people, you may have um, salary benchmarking data that you get through. I don't know if you've ever seen salary benchmarking data but

Speaker B: yes, that in

Speaker A: and of Itself requires a bit of massaging. Is this role at this level or is it at that level? That sort of thinking is really super annoying. So you might want to try and like bring in a job description over the top to marry that up. Okay, now, now actually pegged my employees to the right salary level. Okay, now might want to take some of their performance data. So what are their KPIs? Have they achieved them? Do they deserve to be put at the 90th percentile versus the 70th percentile or 50th percentile? Um, so you start slicing in performance data and now you can start having some smart recommendations on, oh, Josh is actually underpaid and should deserve a massive pay rise. That would be amazing. But um, that sort of logic, right, you can defensively produce data based decision making.

Speaker B: Yeah. Being data driven on compensation, um, is we often say a fact driven world is a better world. And that sounds like it could be a more merit based, equitable world. So that sounds amazing. I want to shift a little bit, Josh, to your career arc, um, going from an engineer to a chief technology officer. Tell us a little bit about that.

Speaker A: Gosh, I spent a very long time in my career writing software because I genuinely loved writing software. Um, I think I like coding. Yeah. Um, that world is changing a lot right now. But, um, I spent a long time there. I was pretty broad in my career, um, at the, at the sort of lower levels. I did lots of different things. I did architecture, software engineering. I worked in a variety of different contexts, um, from fintech, um, to media companies and all kinds of things. Uh, and then I was fortunate enough to step, um, into, was hoodwinked into a head of engineering role that very quickly turned into an executive role, um, which pushes you through a number of things and there's a lot of learnings there, um, that sort of came out of that. But, um, I guess that's my brief story arc.

Speaker B: So, um, what advice would you give somebody later in their career? How do they position themselves? What do they most have to focus on? Learning to get to the C Suite.

Speaker A: I think one of the lessons that I learned, um, going through that sort of transformation was as you take on more and more responsibilities, um, you can't be the expert in absolutely everything. So in my example I took on, you know, coming from a pretty deep, uh, engineering background, I took on corporate it, so help desk and procurement of software. So not my sweet spot. Right. Um, I'm not saying that you have to be, you uh, can be ignorant on the facts. You still have to know what good looks like in these disciplines. But I think the important lesson to learn is you don't have to be the expert. You have to create a team that is able to achieve the objective. And you as the leader of that team, your job is to ensure that that team has the right skill sets and the right environment to be able to thrive. So for me that meant surrounding myself with people who complement my skill sets. Okay. That meant I needed someone really strong at corporate IT in this example. And um, by doing that, you create a unit which would be the team that is extremely strong. And I think that this sort of lesson applies all the way down to that team lead level. Like you're stepping out into, you know, managing your first couple of engineers. Right. You might be a front end engineer and um, you know, your team is responsible for writing both front end and back end. So surround yourself with backend engineers compliment you. Right. That's a good lesson I learned.

Speaker B: Yeah. It's almost also like going from um, somebody who's managing the work versus you're their coach, um, you're removing the roadblocks for them. As you think about the. Given that you are an engineer, you have been a developer, a coder, and you think about the amount of AI generated code, um, how do you balance that fear or just the fact that it may not be as efficient code and somebody else has to be checking the AI generated code. How much of that is a, uh, problem that we just have to keep iterating on?

Speaker A: So what we've done at Elmo is we've invested quite a lot of effort into um, building up a bit of a factory internally for co generation. AI is really good at doing exactly what you tell it to do. The problem is in software you need to give it a lot of context. It needs to understand the product discovery set. What's uh, the, what's the data telling us? What do the designs look like? What are our architectural standards, this is our design system, blah, blah, blah, blah, blah. So being able to provide AI a much more holistic view on this is what I expect you to do. And this is how I expect you to do it, um, is really, has been really, really powerful for Elmo. This is when you move out of that sort of phase where you're pair programming with AI, asking it to write unit tests or something like that, to actually getting a little bit more hands off and supervising, I use that word deliberately supervising the agents to build software. And then you're just checking did you actually conform to the standards that we need. I think this is quite different. I'll uh, go on a tangent here for a sec. This is quite different to vibe coding. I think vibe coding is not really understanding those things and just asking AI to make all the decisions for you, which is risky, particularly in a enterprise software environment.

Speaker B: Yeah, risky and more expensive. You said context. The context is important with context and in a way better prompting then you're getting it to behave the actual way you want it to, uh, more efficiently. Uh, Josh, we've covered a lot of ground. I'm going to switch to a short, fun, light hearted, lightning round. What do you most enjoy doing outside of work when you're not immersed in the world of data and AI?

Speaker A: I wish I had more time to do this, but I like uh, racing motorbikes, um, getting out on the track and you know, it's very sort of precision like it's like I want that perfect lap, I want that perfect lap and you don't have time to think about anything else. It's great. It's almost meditative.

Speaker B: Okay, meditative. High speed though, high risk. Do you go, do you go off trail or is it on a racetrack more often?

Speaker A: It's on a racetrack. It's not high risk. It sounds high risk because you're going faster but you've got lovely areas to, when you come off and you go for a nice slide, it's, it's m. Much more dangerous on the road.

Speaker B: A nice slide. I don't know, I, I tried. I, I had the opportunity to experience a nascar, um, trial around the track and the driver told me I was driving too dangerously slow. I just couldn't do it. How about as you're joining us from Australia, what would you most recommend for lunch? A Vegemite sandwich or a Spam sandwich?

Speaker A: Oh, definitely not Spam. Um, Vegemite. Vegemite. And for those players who have not had Vegemite before, I would recommend Vegemite and cheese. It softens a little bit.

Speaker B: Okay, there you go. How about someone famous or not, that has, ah, particularly inspired you?

Speaker A: Look, I don't really do heroes. I try to consume a lot of um, a lot of content quite broadly. One thing that strangely stuck with me, just because I thought it was super elegant the way that, the way that he did it, um, his last name is going to escape me, but the first name is Jason Donfield or something like that. He wrote the um, wireguard application, um, and open sourced it and you have a look at the code and it's just, it's beautifully Simple. It's just beautifully simple. And it solved a real pain in the butt problem of those who've ever dealt with VPNs and IPsec, um, that sort of stuff. So it was. It was a great solution. Stuck with me for some reason.

Speaker B: We'll link to it. How about a book or a podcast that you think everyone must check out?

Speaker A: I think AI is moving at absolute lightning pace. And it is really hard to do your day job and then spend your night job trying to keep up with everything that's going on. And I've found that there's quite a few people out there that sort of summarize, um, the key sort of topics of AI that's sort of emerging. There's one that I watch from a guy called Nate Bay that was talking about coding levels, um, in AI, going from, you know, AI is a fancy code complete all the way through to dark factories. Um, I found that really fascinating because it just put in context the exact shift that we're seeing right now. I'd recommend, um, watching that video, but find someone who you like that I think can sort of help you keep pace with everything that's going on in that world.

Speaker B: Yeah. Somebody said to me recently, anyone who has a day job is not keeping up, that that's just how quickly things are happening. Like, m. Yeah, I feel like, um, I could lock myself in a closet for three months and learn, just learn. But then it would have changed again. So we do the best we can. Josh, you can decide the last question. Either what are you most grateful for, maybe beyond the obvious of health and family, or what is an accomplishment that you're particularly proud of from the last week.

Speaker A: A fun little thing. It was probably about three weeks ago now, but a fun little thing that I did with my daughter, who's just turned six, learning to read. She's going through. There's different methods of learning to read. Um, the method that she's going through is called decoding. The decoding method. And, um, we decided to write a first reader together in Claude, featuring her favorite things, which is her, um, little white doll and some mermaids. And Claude did a really good job even on the illustration. So, um, that was, um, that was pretty fun.

Speaker B: Personalized reading plan. I think that's beautiful. Josh, thank you so much for sharing your insights on the data in AI Chief.

Speaker A: Thank you very much for having me. I appreciate it.

Speaker B: Yeah. So, listeners, you heard it from Josh. Think about that psychological safety. Give room for experimentation. Concentrate on building what is your moat and buy what you can because I don't know who likes to maintain who can innovate as fast and spreading out that cost. So sas uh apocalypse not probably going to happen and be a constant learner. Going from engineer to C suite is really about moving the roadblocks for your team. So if you enjoyed this conversation, please rate it or like it on your favorite podcast platform. If you would like more inspiration and thought leadership, follow me on LinkedIn or visit the hub data and aichi.com.