Build vs. Buy. It's So Easy To Build HR Software Now! Or Is It?

Hey guys, I have an update on some things to share with you in the middle of a lot of announcements from a lot of companies about a Gentick this and a Gentick that and that is the explosion of excitement to build things in Claude or another tool. There's been I just went to the user conference for eightfold this week and I'm going to a whole bunch of them next week. There's a lot of announcements coming the next week and I'll definitely cover all of them, including a big one by SAP today. But there's a perception growing in every HR department we talk to that if you get your hands on Claude or Chachabt or Microsoft Copilot, you can just build what you need and you won't need to buy all this vendor software anymore. What eightfold announced is something called talent forge, which is some tools to build applications on the eightfold platform. And you obviously know or you probably saw that OpenAI just allocated four billion dollars I believe to building a consulting business to help companies build agents of their own and not just in HR in all different areas and Throbbig did the same thing. So there's a lot of wannabe gurus out there helping you build stuff and you know we have done this and you can build some pretty cool stuff. And if you're a software engineer and you get your hands on one of these agent code generation tools or if you're not a software engineer, you can literally prototype something describe what you want it to be. And the more detailed you are in this spec, the better it will build and when it runs it and builds it, you can deploy it and if it breaks, you can send a screenshot of what broke and it'll fix it. And the agents, the off the shelf agents from Anthropic and the others can read the APIs of the systems you want to connect to and build integrations reasonably well, which means then an corporate application setting, you could build a lot of your own applications now. Now there's a lot of considerations that don't seem obvious when you start doing this. We've had a lot of clients told us they have dozens and dozens of HR agents already for interviewing scheduling or for building interviews themselves questions, assessing candidates. I mean, we have 450 workflows in Galileo that are all little applications basically of things that you could have done by hand that you know you can do in Galileo. Galileo knows a lot about HR and skills and jobs that the native LLMS don't so this is a lot easier than it than everybody thought, but let me just mention something that maybe people haven't thought about two things. Number one, you have existing systems, you have payroll systems, you have hiring systems, you have ATSs, you have transactional systems and the transactional systems are systems of record for a reason because you need that data for other things. And that data has to be accurate and it needs to be stored in a place that where we know where it is and we know how to find it and we know how to make sense of it. There needs to be metadata and integration around it and we need business rules so anybody in the company can't randomly go pull data out of some internal application and do something with it without necessarily understanding that they pulled the wrong data or they pulled the old data or they're drawing the wrong conclusions for a whole bunch of reasons. This is why we have analysts and analytics people. So while we're all building our own toys, we also need to be careful and I was kind of joking around today with somebody even talking about this whole topic because this is all part of HR 2030. You know, it's like when you buy a car some people want the car to just run and they don't want to have to deal with it. Other people want to change the wheels and they want to tint the windows and they want to customize the seats and maybe they want to tune the engine and then there's people that want to take the engine out and put their hot rod engine in it. There's not as much of that anymore because it's hard to do but it used to be a lot of that. And so we're going to suddenly be in this world where there are where every single piece of software you have and buy you're going to say to yourself, well, wow, that looks like something we could have built ourselves. Maybe we shouldn't spend all this money. Let me give you some considerations in that equation. I'm not going to tell you what's good or bad or right or wrong. And this goes back to my experience being in the technology industry for a long time. In some sense, the most expensive software you will ever buy is the software that's free because if it's free and you aren't holding somebody else responsible for maintaining it and it breaks or it's incorrect or causes trouble. You're going to be spending the time fixing it and as the IBM guys used to teach me long ago software is hard hardware is soft software is very complex and there's always features missing and there's always new things to add and once you start building something you own it. You have to maintain it. You need to update it. You need to do with the new use cases. The changes that take place in the company and you are now not only a software engineer. You are a software tester. You are a software maintenance person. You're going to do product management for your software and you're going to do release management and performance enhancements and performance optimization and integration. You're going to do all that. So just because you could get it working on your PC and you like it as a personal productivity tool. If you're starting to deploy it as an enterprise application in some fashion, there's a lot of other things to consider. Including the fact that the infrastructure in your company could be changing and the connections or interfaces that it talks to that worked on January might not work in May because the IT department changed something that you didn't know about. So I'm a big fan of this build your own application world. That's the world I came from in the mainframe. All the mainframes in the past were all custom. Everything was custom, but there were large development teams that built things. They had a lot of change management and rigor and process around what they built. They had very mature data practices and data management practices so that the data didn't get messed up. They had tools like CICS and others. They were very sophisticated transaction management tools. So you wouldn't deal with things like the system updated a piece of data but inadvertently computer went down while I was updating it so the database is now out of sync with some other database that it's connected to. It had software for that and many other things like that. So I think we have to be wary of the reality that in a company, if you're going to build something, make sure you're getting the right level of support to maintain it and really scale it. You know that all said there's going to be thousands of things that you're going to want to build. And there are things that maybe are unique to your company, unique to your role, unique to your department. That the system you have just doesn't do very well and maybe was never designed to do. And of course it's threatening to the software vendors but they know this is going on and they're going to be giving you more and more tools to do this built on their platforms. So everybody that's in the pack and software business is now in the application enabling business because they want you to build those applications around their system. For example, we use QuickBooks to run our company and it's very good at what it does and all the financial data is very carefully and meticulously stored in there and we can analyze it. But I don't like downloading things under spreadsheets and building pivot tables. So they're building a tool right in QuickBooks that allows you to move the data into an LLM and create your own little agents to analyze whatever you want to analyze without having to do it by hand. And I'm not going to replace QuickBooks. There's no way I want to build an accounting system. I have no interest in that. But I can extend it. So you know all of the HR systems you have, workday, eightfold, SAP, whatever are going to become more and more extensible. Now for those of you that have never built a piece of software, I have, I didn't like it. I didn't enjoy it. It was fun for a while and then it was a headache because once it was deployed, all the problems came up, all the bug fixes, all the new features. And I just got tired of it. I got tired of maintaining it. I would have preferred somebody else to do it because my skills are in a different area and it's not a good use of my time to maintain this thing. That might have been useful when we started building it when in reality, I just want to get utility out of it and move on. So we're going to all learn a lot of lessons about building things in these tools. The funny thing at the eightfold meeting, somebody stood up there. I mean, it was actually sort of comical to me. There were two people on stage. I won't give you their names. And they were one of, you know, supposedly very sophisticated technology people. And one of them asked the other one, what is the number one thing you would recommend people do to learn about AI and agents. And the answer was use clawed for everything, put everything into clawed and let clawed do all your work. And I suppose there's a, you know, a lot of goodness in that answer, but I think in the world that we live in in the business world of applications, we just have to be careful. And the announcements from work day that I wrote about a couple of weeks ago, the announcements from service now that I wrote about last week, the announcements from SAP this week are basically examples of where very sophisticated software companies are opening up their systems to be more agentic and to give you more tools to build what you need. Now that said, they're not necessarily yet ready to redesign everything they have. So the reason that most of us like to build things from scratch is there's workflows or screens. or clunky process steps built into the old software that are just too hard to use. So we whip up co-work and we like co-work do all the mucking around in the system and finding data and we just tell co-work what we're trying to accomplish and co-work will go get the data and give us the answer. That's a almost like a walk me RPA type of tool used to be called RPA. I'm not sure whether it's still there. Digital enablement type of tool that sits on top of a system and shields you from the complexity of the user experience and allows you to get answers. That kind of technology has been around a long time and it was always sort of AI anyway but it was Denver call dayi because we never had these general purpose how it all sounds like we do today. Now, I guess the second thing I want to talk about is the culture of your company. There are a lot of companies and I talk to a lot of companies. There are a lot of companies that are just engineering oriented companies and they just like to build things. Google built a lot of their own human resources software. Many of the big tech firms, they may have bought work day or something like work day early and then they just sort of built stuff around it and more and more and more and pretty soon they have a very, very customized system. And then there are big companies like Bank of America or JP Morgan Chase that have massive IT departments and they've been building applications forever and it's not intimidating to them to build something new. They love it. They have all sorts of technology stacks and a process for doing that. But they're going to focus on the applications that are really corporate wide, very high ROI, including Amazon by the way, it builds a lot of their own HR stuff too. So they're going to build things and those kinds of companies, if you're an HR person, you're probably very involved in building things, which is great. And the tool sets from ServiceNow and Workday and SAP and the others are getting really, really easier to use. So you don't have to hire a PhD or a very high expensive consulting firm to do this because it's much more approachable than ever was before. And those companies, the reason they customize things is because they're either very engineering oriented and so they're perfectionists and they don't like buying something that wasn't built to their standards. Or they have unique business needs that they just believe are competitive advantages. And this is the way Amazon works. So they can't buy an off the shelf tool because it won't give them the integrated experience that they wanted to deliver. That's by the way, the way websites work, right? I mean, in the early days of websites, nobody built their own website, but now everybody does it because they're very, very, very customized and the tools are very sophisticated and easy to use. So there are lots of companies that are going to lean toward build versus buy and they're going to have to make decisions about, is this thing we're building a really high ROI value add competitive advantage or are we just playing around with something that we think would be kind of fun to build when actually a vendor product would be a much better business decision because we want to spend our time on the value added components not on the things that are commodities. Then there are another, there are another class of companies that don't want to touch this stuff. And there's a lot of them too. And these might be companies that are not in the technology industry. They may have very small IT budgets because they're, you know, they might be a mining company or consumer goods company or a healthcare company and they haven't invested in technology for a right for some reason or many reasons. And it's not easy for them to get into the application development business quickly so they would rather buy it. And they're going to want an off the shelf agent and they're probably going to be okay with off the shelf agents that are better than the old way of doing things. And that's fine. The reason I mention this is you need to decide as a business, as a team, where you are on that continuum. And every application you run into, every tool that you want to build is a little bit hard to position. Is it a competitive advantage? Is it a nice to have? Is it a must have that we could buy off the shelf? Is it a small project? Is it a big project? Do we need to build it in one of the core stacks of technology? Or can we build it in the RPA technology or something that's a little bit simpler? And these are very complicated decisions. You know, when you're building software as a software company, a lot of decisions are being made under the covers as you don't know about. What stack to use, what tools to use, what database to use, what middleware layers to use, what models to use. These are very important architectural decisions that software vendors make that we as amateurs don't even know about. So, you know, if the application turns out to be complicated, it may turn out that you built something that sort of works. And now you've got to move it and re-engineer it to do some things that you never really thought it needed to do. So those are things that software engineering and software firms think about all the time. But when you're doing it yourself, you're not aware of them. So I thought it was a really interesting week talking about this. And we'll talk more about it as we get further along with HR2030. We're launching the big HR2030 blueprint at the Irresistible Conference in about three weeks. And you're going to see a lot of new things coming from us along those lines to help you think this through. For now, let me stop here. And if you've got your hands on Claude or Co-Pilot or Cheshire BT and you're whipping up some application that you really love, just think about some of the issues that I just mentioned and you'll stay out of trouble. That's it for now. Bye.