Jerome Gouvernel:
How do you understand enough about payroll and HR data that you can migrate it and connect systems in a way that is actually useful for end users? So you incorporate in your little bag of tricks all the things that you've seen along the way. So, as an industry, we kind of got better over the years, but why does it still take a year to implement payroll? Why does it take three years to roll out a global HR system?
Steve Smith:
Hey everyone. Welcome back to WorkTech Weekly. I'm really excited about today's episode because we're talking about one of the most important and most painful problems in enterprise work tech. And that's all about getting paid. Global payroll and global HR is certainly at the forefront of the industry conversation right now. And one of the things that we're finding out is that when they go wrong, they really go wrong. My guest today is Jerome Gouvernel, the CEO and co-founder of datascalehr. datascalehr helps companies implement new HR and payroll systems faster. They can cut global delivery timelines down from years to months or even weeks. In this conversation, Jerome breaks down why payroll integrations are really a translation problem. We talk about what AI can and cannot do in enterprise environments. And then we get into why auditability is the real requirement if you want AI you can trust.
If you want to know why global payroll is still so hard, what most vendors won't say out loud and what it takes to build AI that works in the real world, you're going to like this one. Let's get into it.
Jerome, welcome to the podcast. Really excited to have you on. I wanted to bring you into this conversation because back when I met you at HR Tech, that was one of the most interesting hours I have spent talking about technology in quite a while. And I walked away from that thinking about that for quite some time. I was also thinking I wanted to bring you in just to hopefully maybe recapture some of that magic and really kind of share some of the thorny things that we're seeing in the market right now with our audience.
Jerome Gouvernel:
Thanks, Steve. Appreciate it. Very excited about this podcast. It was a fun conversation. I remember it being scheduled for 30 minutes and we ended up doing two hours.
Steve Smith:
Always the hallmark of a good conversation. Well, Jerome, tell me about datascalehr.
Jerome Gouvernel:
We do primarily two major things for our clients. The one is we help anybody that has to implement a new HR HCM system or payroll system or multiple payroll systems. We help them cut the implementation timeline from years to weeks or months. That's a massive use case by itself. And then we also help multinational companies and service providers connect whatever HR system or system of record that they have. So anything from SAP Workday, it doesn't matter, anything. It could be homegrown to all of the local payroll service providers around the world so that the data can reliably transfer from one to the other, but also can be reconciled that they can do global aggregation. And because this is all AI-driven, creating a connector between, let's say your Workday system and your Tanzanian payroll takes two hours. And it's done by a payroll admin. There's no software development involved.
There's no project management. You don't have to do any of the project-related stuff. It's literally just a payroll admin. It's essentially what the payroll admin would probably do on an Excel spreadsheet behind the scenes. Nobody would know about this, but he or she would be taking some data from the central system and then reconfiguring it so that they can feed into the local payroll engine. If they can do that, they can build a permanent automated connector. So that's what we do. And it's fun right now because some of our clients are some of the biggest payroll companies in the world. And well, they're scary beasts. They do a lot of cool things, and we help them, so it's fun. And then multinational companies, there's so many of them.
Steve Smith:
Was there ever a moment where you're like, "Everyone else is thinking about this problem with global payroll the wrong way, and I want to take another crack at it," or a different approach?
Jerome Gouvernel:
Yes. There was a definite period where we felt that my co-founder and I, it's really just the fact that we spent 20 years of our careers trying to solve the same problem from different angles, for different products, for different platforms, different vendors. And each time we kind of iterated, you learn stuff, so you don't repeat the same mistakes. But ultimately, it was always the same kind of solution. It was trying to solve the, how do you understand enough about payroll and HR data that you can migrate it and connect systems in a way that is actually useful for end users. Ultimately, it always required a lot of effort from customers and it never felt elegant. It just felt like this is a brutal approach. We're just taking brute force approach, which is with users and just go through lists of fields and tables and business rules.
And then yeah, you build templates because you want to make sure that you don't make the same mistakes as before. So you incorporate in your little bag of tricks all the things that you've seen along the way. So, as an industry, we got better over the years, but why does it still take a year to implement payroll?
Steve Smith:
Right.
Jerome Gouvernel:
Why does it take three years to roll out a global HR system?
Steve Smith:
And it's funny because a lot of times, especially when you're talking about integrations for payroll, you sort of imagine that it is this technical integration, but really it's more like, oh, we're going to just transfer some files, and we're going to cross our fingers and hope everything turns out for the best. What's the hard problem about global payroll in these integrations that people are avoiding naming that they're just not talking about?
Jerome Gouvernel:
It's a hard problem. It is a hard problem. There's a data loss problem. It's not a lossless process if we take an audio kind of metaphor. What you're trying to do is replicate somebody's reality. So let's say they're running Workday HR and they've spent years setting it up, and you're trying to replicate some of that reality into, let's say, a French payroll. And those two realities don't really overlap much. And so it's a translation exercise similar to a French person trying to speak English, but they don't know how to speak English and an English person trying to speak French and they don't speak French. Where do you start? Do they both learn each other's language? And that's kind of where the industry's been at forever. It's like you have to learn the other person's language and learning a language just so you can have a conversation takes a long time.
And you're learning this new language as a one-off process. You're never going to use it again. All you're trying to do is transact. You're trying to do something together. HR system needs to talk to the payroll system and the payroll system needs to talk to HR system. And for that to happen, both sides have to make an enormous amount of effort to learn something completely new to each other, just so that they can do their normal thing afterwards. So it's not like you can learn it once and then now you know how to speak that language because that language is specific to that vendor and specific to the other vendor and it's specific to a client. So at least when you're learning, let's say you're trying to learn French, okay, it might take you two years to learn it, but then you can speak to every French person in the world.
So you're getting value for that investment. In the world of ERP, you're learning that language. It takes the same amount of time, but next time you need to do it, you're going to have to learn another brand new language. It's crazy. And that's where we came at it from. We're like, we can't keep doing this.
Steve Smith:
Describe briefly what datascalehr's approach to this is and how you're attacking this problem.
Jerome Gouvernel:
So using that same metaphor of two people from different languages trying to speak to one another, what we realize is that maybe you don't need to learn to speak French and the other party doesn't necessarily need to learn to speak English because what you're trying to do is not learn a new language. What you're trying to do is transact. So there's a specific outcome that you're seeking. So maybe let's say you're trying to buy a car from a French person, but you don't actually want to learn French, you just want the car. And so what we started thinking about is there a way that we can do the transaction without either party having to learn the other's language? Can this be done? We started thinking about how would we do that? And then the idea is simple is if you break down the problem into very granular little bits, you can actually transact and you can almost pretend that you speak each other's language without actually doing it.
And so what it means in terms of HR and payroll, it means I can get all of my data from my source system into my target system in a way that is useful for the target system without having to understand the data itself. And that was like the breakthrough moment because up to this point, so let's say you're talking about address, an address field for a US-based system and you're trying to put it into a French payroll system. So in the US, we have the zip code. That doesn't exist in the French system. So you have two ways that you can do this. The traditional way is you learn to speak French and you learn what the equivalent concept in French is and what the name for that is. So you have to learn the language and then you can talk about the zip code and then you can figure out where it needs to go or you can granularly figure out a way to map zip code to a French field and you don't have to know what that field means.
You just have to be sure that it's the correct one. To do that, you need to break the problem down into a field-by-field granular level. And the interesting part is automatically when you start doing that, you're talking about a knowledge model. So you're really talking about being able to map a source and a target at field level and you need a way to remember this. And so for us, because we started pre-GenAI a couple of years before GenAI, when these ideas started to take shape, while we had to build our own machine learning mechanism and a place to store it. And so we started doing that. And so when GenAI arrived, I remember we were like panicked because like, oh my God, this thing is amazing. It seemed like it knows everything. So maybe all the stuff that we built, somebody could just replicate the next day.
Took us a few weeks of experimenting to realize what the limitations of GenAI was. And there are a number of limitations. One is that it's never quite sure about anything, so that's a problem. But the main thing is that it just doesn't have enterprise knowledge because the mapping that I was talking about, what is a zip code map to for a French payroll system? Well, it depends on which payroll system and how it was configured and in which country. And all of that knowledge is not publicly available on the internet. You actually have to do the work to get the information.
Steve Smith:
What are you doing differently that is creating different and better outcomes? Because one of the things that has kind of struck me is a lot of, we saw this when everything went from on-premises into the cloud, it was just sort of like, let's take our existing process and let's just put it in the cloud. I think that right now you're seeing the same thing and just like, great, let's take our existing cloud process and just AIify it instead of fundamentally rethinking how things should be done. And that's one of the things that stood out when we talked in Las Vegas was this is someone who's fundamentally rethinking how things should be done.
Jerome Gouvernel:
I think it's a great analogy. I think that's exactly it. And it's so funny because in retrospect, it's so easy to see where everybody failed when they went to the cloud, but it takes time to learn that. I think from a GenAI perspective for enterprise, and I'm only talking about enterprise uses, enterprise requires auditability of decisions. It requires a fundamentally white-box framework. Every decision along the way that AI participated in has to be explainable, auditable. And you could even say it's okay to be wrong in certain cases, as long as you can figure out where it went wrong and therefore you can fix it. Data models that all the big ERPs were built upon do not offer that level of granularity. You don't have the control and the visibility at field and at value level. So let's say you're talking about an SAP system and there's a value associated with a pay code for a particular individual in a particular month, in a particular country.
That value, if you were to do something with it with AI, you'd basically read the value in, you'd apply some kind of AI magic to it, and then it would give you an outcome. There isn't a place to store the decision-making process that the AI went through on that value. Not in general, right? We're not talking about model explainability here. We're talking about the decision itself. Where does that live? And programmatically, how do you control this? You have this value, you apply something to it. Where do you store this process of applying? And of course, in enterprise context, you probably want to have humans in the loop. So it's not just what the AI decided, but it's also what did the human think of the AI's suggestion or decision? Was it reviewed? Was it accepted? Was it rejected? If it was rejected, for what reason? What would've been a better alternative?
That chain of knowledge doesn't have a natural database infrastructure to live in. And there's a lot of posts that I see more recently where people say things like, "Before you can have an AI strategy, you need a data strategy." Something along with that theme. And that's exactly right. The problem is if you don't understand how you're going to design for AI, it's hard to have a data strategy. You kind of have to make the mistakes first and experiment, make the mistakes and go, "Oh, okay. I see this is the gap. This is everything that we would require for AI to be trustworthy and therefore useful."
And then you have to go back and engineer all of that, which could take years. And I'm going to do a selfish plug here, but this is what we've built is that middleware where you're able to take traditional data structures and bring them into this new data structure, which is our secret sauce so that it can be exposed to AI so that this granular decision can be made and audited and reviewed and that the feedback loop from users can be then reused such that it never makes the same mistake twice. Of course, you can build this, but it's a big investment.
Steve Smith:
And so how does this speed up the process? How are you seeing this play out in the real world? There are myriad horror stories about payroll implementations that went on for a year or two or three and ultimately failed. It's just like there is sort of a level of, I guess, friction in the process that is not really talked about. But what are you seeing in the experience of your customers right now with maybe taking that friction out?
Jerome Gouvernel:
I think what we're doing is bringing the domain of payroll to a similar level of agility as a lot of domains have already achieved. So the traditional process to install payroll or migrate payroll or HR or any of these has always been very waterfall. It's like you do a lot of preparation work and a lot of pre-testing and you have all these quality gates in the project management over time and you get closer and closer to your first parallel run and then you run the parallel and then everything breaks and then you go back and then you repeat it. And theoretically, each time it gets a little bit better until a customer's satisfied that it's good enough and then you go live and you switch over. So it's waterfall. A true agile methodology is let's try something and see what works and then repeat, rinse and repeat.
And this hasn't been even, you couldn't even dream of doing that, doing this in the payroll sphere because you had no way of getting data quickly from one place to another. So you can't iterate fast. There's nothing for you to iterate with. If it takes you eight months of data preparation so you can run your first parallel, you're not agile. And so what we are doing is we're cutting that eight months and you could do it in an hour. So if you can do this in an hour, it means you can literally throw data from one side of the wall to the other side, run payroll. Of course, it's not going to be right, but at least in the same day, you have a full result set of payroll, which you can then reconcile, analyze, find the gaps, find the problems, resolve, and then day two you do the same thing again.
And it's amazing because if you do that within, I don't know, five or six iterations, you're already at 99.9% correct. So this is how you contract time is by allowing this communication to happen much faster in the first place. So that's where we play in this example.
Steve Smith:
Moving into this new world where things that were not previously possible now are possible, what are you seeing as sort of being the secrets that are getting kind of dragged out in the open and maybe things that both on the employer side, they're not ready to address, but then also on the vendor side, what are they maybe not wanting to talk about in terms of what the new reality is and what it's going to mean for them?
Jerome Gouvernel:
When we built GlobalView back in 2000, so 25 years ago, wow, time flies, there was no such thing as a global payroll platform or engine. And we were pretty proud of ourselves that we were able to build this payroll engine across 45 countries and repeat that model so that the technology basically worked. It was a technology proof. We were just proving out that this could be done. And for many years, this was good enough. It's like, yeah, this is cool. And then the economic reality catches up with you eventually because now you're maintaining 45 payroll engines, but you're also maintaining this promise to the market that you can be fully compliant. And when I mean fully compliant, you can't say, "Well, I'm compliant, but only for monthly paid employees or only for white collars or only for this industry in that country." Nobody wants to hear that.
So you have to say you're fully compliant, which means there's an enormous amount of maintenance, localization that you have to, firstly, you got to build it and then you got to maintain it. In our case, it was 45 countries and I don't know if anyone's doing more than that right now, but I'm sure some will eventually claim to do more than that. It can be done. And now that the technology is proven that the model has been shown to work, I mean, technology has improved so much. The tools that are at our disposals to develop these engines and technically create them is much better than it was 25 years ago. It's so tempting to say, "Yeah, we're going to do this." But then the reality, the economic reality hasn't changed, which is you're still going to spend tens of thousands of hours of maintenance.
And when I say maintenance, it's trivial stuff, but that's the stuff that trips you up. So you have a tax return form in this country where when you send tax returns, it has to be on a particular form. And every year they go and change the field somewhere and they move the box that was on the left, they move it to the right. And now suddenly they want a subtotal where there wasn't one before. Somebody has to, A, realize that that's happened, B, understand where the data should come from to populate those fields. Then you have to build the form, release it. You have to have a mechanism in your system that allows you to version control these forms because last year's form is still valid for last year. So you can't replace the old one with the new one. Now you have to have a version control system.
None of it is particularly difficult to do, but this is just one form in one country, and then you just keep adding that. So you end up with a problem space that's huge. Let's say you've got 50 countries, you're maintaining tens of thousands of rules every year just to stay compliant. And if you really want to be compliant, you have to do all of the domains, all of the industries, all of the different types of employments in every country. So far, it hasn't been an economically sustainable model. You don't get the volumes to justify this effort. And so there's a lot of people that are saying, "Well, now you can just use GenAI to read the government website and that's it. That's how you're going to do your maintenance. It'll just extract the rules and write the code for you." Well, if that's your idea of compliance, you're going to be in serious trouble.
Steve Smith:
And what could go wrong with that?
Jerome Gouvernel:
Yeah, exactly. So vibe coding payroll engines, I mean, it's fun. You can go to Claude right now and say, "Hey, simulate a German payslip for me. Pretend that I'm a German employee and I work in this industry and I get paid 2,000 euros a month and blah, blah, blah. Give me a payslip." About a minute and a half, that's how long it takes. Is it accurate? You don't know. Would it ever work in real life? No. Is it production code? Not even close, et cetera, et cetera. So those are great for proof of concept, simulations, learning, understanding the mechanics. If you don't know anything about German payroll, it's cool because in half an hour you can get an idea of how it works. But that's not what providing payroll services is about. That's not what you sell. You sell compliance and you have huge penalties, and we know because we have to negotiate contracts with our clients.
And so we have these discussions all the time, how much is it worth to you if we get it wrong? What penalties are going to be applied? And the insurance level in this industry are the canary in the coal mine. They tell you the reality of things. No one publishes things like data breaches and spectacular failures of payroll providers. Nobody talks about it, of course. But when you look at the insurance premiums, it tells a story.
Steve Smith:
All right. I got two more questions for you. So one, first question, how do you use AI in your daily life, not just your work? I mean, how has AI maybe changed the way that you approach solving problems?
Jerome Gouvernel:
It helps me iterate. And so when you think about a problem, you're kind of constructing a... Well, at least in my brain, it's like this kind of 3D visualization of this problem that you're trying to get your mind around. I find it extremely useful to establish a written form of that picture so that I can then move to the next level of abstraction. You know what I mean? It's like, okay, here's what I'm thinking about. Here's the problem as a solution. I'm thinking about this kind of solution. So you just tell the AI that, and then it plays it back to you in a more structured way. It's really good at that. It's not inventing anything. It's just giving you back your own ideas just in a more structured way. And then once you have, that becomes the new model in your brain.
So then you can iterate to the next level. It's like, okay, so now that I've got this, it's like mathematics. Every time you solve an equation, you don't have to go back and say, "Does one plus one equal two?" No, that's already assumed. So those are building blocks upon building blocks. And when you're trying to solve a business problem, it's incredible the power that this has because you can just keep building so quickly. You have to drive it though. Can't ask for the answers.
Steve Smith:
So my second question is, I'm wondering, what's your take on vibe coding? Is that something that you hop into Cursor and you kind of tool around with that? What's your take on that? Is it just kind of a fun toy or is there maybe an enterprise application to it and maybe even a game-changing enterprise application?
Jerome Gouvernel:
Yes, 100%. I think it is a game-changer. I think it's like everything else we've talked about, it has domain applicability and you just need to know where it's good and where you shouldn't be using it. You can use vibe coding in anything that is low impact because you can expect it to not be 100% correct. I mean, if it is, it's great, but you have to assume that it won't be. And so let's say, well, we use it all the time. So somebody says, "Hey, I need to be able to read this document." And you look at this document and you go, "That's a weird format. I've never seen this before. What is this?" "Oh no, this is something we invented. "So you can vibe code the ability to read that particular format so that you can ingest it, for example. It takes about 20 minutes to build a little module.
If your platform is ready for it, so if you have a place to plug it in, you can do that. Now, if it breaks, what happens? Well, you can't ingest that form anymore. Yeah, it's not good, but the world is not going to stop spinning. So for that kind of stuff, it's perfect. I get really worried when I hear things like, "Oh, I'm using vibe coding to build a payroll engine." That just smells like trouble. Again, you can do it, but that's a prototype or it's a POC, but it's not a production level and you cannot maintain code with vibe coding because you can't control what it's going to change. So I think vibe coding is great for this sort of edge type of solutioning. I use it all the time to build visual representations of ideas. Again, because I'm a visual person, I'll write down a whole list of ideas and interrelated things and I say, create a drawing, draw me something that represents this.
And then suddenly I have this picture of what's inside my head on a screen. It's empowering. And that's vibe coding. So it's actually generating code and it's a model. So you can then modify it and you can even put parameters on it. And another thing is financial planning. You can just say build me an Excel model where you put in your retirement age, how much money you're making now, how much savings you have, all your investment ideas, blah, blah, blah, who's going to inherit your money, all that, and it'll generate an Excel spreadsheet for you with parameters that stuff you can use. This is all vibe coding. So it does change your life.
Steve Smith:
Wow. I feel so inadequate now because I'm using AI to do things like, should I open this bottle of wine or should I leave it on the shelf for another year?
Jerome Gouvernel:
Exactly. I love that use case actually.
Steve Smith:
ChatGPT is not a bad sommelier if you kind of grade it on the curve a little bit.
Jerome Gouvernel:
Any prompt with ChatGPT is that it's a sycophant. So anything you tell it is a great idea.
Steve Smith:
Yeah, that's true. That is very true. Jerome, I really appreciate your time and thank you so much for joining us.
Jerome Gouvernel:
The pleasure's on mine, Steve. Love our conversations. Anytime.
Steve Smith:
All right. That's a wrap on today's episode of WorkTech Weekly. Thanks again to Jerome for this hard-hitting conversation. And as we talked about, global payroll and HR implementations are still slow, painful, and high risk. And Jerome named the real reason why. This is not a simple technical integration problem, it's a translation problem. You're trying to map one system's reality to another system's reality, and that's never lossless. What I found most interesting is how data scale HR approaches it. Instead of forcing everyone to learn a new language, every time they connect with systems, they break the problem down into field-level decisions so teams can transact without learning a whole new language. That's what allows them to move faster and actually iterate. And then there's the AI part. Jerome made the point that in enterprise, AI is only useful if it's auditable. You need to understand what decision was made, why it was made, and what a human did with it.
Otherwise, you're just creating a bigger mess faster. If you enjoyed this episode, make sure to subscribe to WorkTech Weekly on Apple Podcast, Spotify, or YouTube Music. And I'll see you next week.