AI In HR
Click "Add post" to start the conversation.
Sign up or log in to enable.
AI saved time. Now what?
That might be the more interesting question coming out of our latest conversation on Making AI Work for People with Dr. Kenneth Matos. ⌛ Because automating a task doesn't automatically create a better job. AI can draft the response faster...but someone still has to check the exception. It can eliminate repetitive work...but leave employees with a day made up entirely of the hardest, most cognitively demanding tasks. It can create capacity...but if the immediate response is simply "great, now do more," did we actually improve work? The data suggests we're still figuring this out: 🔹 Only 26% of organizations surveyed say they're realizing more value from AI than the resources they're investing. 🔹 Just 15% of US HR executives say workflows are consistently being redesigned around the capabilities of people + AI. 🔹 Meanwhile, 37% name employee wellbeing and career insecurity as a priority AI workforce challenge. One idea from the session has really stuck with us: AI should make us as fast as humans can be. It shouldn't create pressure for humans to be as fast as AI. So let's keep the webinar conversation going here. Vote here, then tell us why in the comments. And if your organization has actually redesigned a role or workflow around AI, we'd especially love to hear what changed. 21Before we ask AI to find the right candidate, have we defined what “right” means?
Last week, while walking back from work, I caught up with someone from my network for a walk-and-talk. She has extensive Talent Acquisition experience across the Nordics and APAC, so I asked her: “Based on your experience, what defines a good hire?” Her answer- It depends on the seniority of the role. For senior-level positions, relevant experience and demonstrated skills tend to carry more weight, although personal attributes still matter. For entry- and mid-level roles, skills and education are important, but so are the qualities that help someone learn quickly, adapt to change, and collaborate with others. As an HR professional, I find this an interesting question, especially as AI becomes more involved in recruitment. How do we define the criteria for a good hire — and, if we use AI, do we know what it is prioritising? I'd love to hear from TA professionals, recruiters, and hiring managers about how you approach this in practice. And if you're in TA, recruitment, or HR and enjoy exchanging perspectives beyond the usual work conversations, let's connect for a walk-and-talk! 😊 #AIinRecruitment #AIinHR #FutureofWork 10Future of Work
Hi all, I am going to host a Fire Side chat for fundraising purposes. (please delete this message if it is not allowed here). If you are looking for listening discussion how AI may impact our way of working and future work force, please join us 🙂 You can find the link here : https://www.eventbrite.ca/e/2001080982085?aff=oddtdtcreator 00How are you measuring whether AI is actually creating value at work?
In our conversation, Stop Chasing AI ROI: Start Measuring Business Impact, Dr. Kenneth Matos challenges a familiar trap: adoption, license counts, and even hours saved do not automatically equal business impact. A useful question is: what changed downstream? Did AI help your team reduce rework, move decisions faster, improve quality, free capacity for higher-value work, or unlock growth? And importantly, do you have a way to connect that change back to a real business outcome? For HR, this is not about using AI to cut people costs. It is about understanding where people, skills, and AI capacity can work together to create more value. We’d love to hear from you: what is the biggest barrier to proving AI’s impact in your organization? Sound off in the comments on your experience with today's webinar and any new learnings. 11What today's hiring is in need of intelligence?
There is a lot of discussion in this community about what AI can do in recruitment, so I want to raise the opposite question. AI adds real value at the top of the funnel, where volume and fatigue create most of the noise, and where a lot of bias quietly enters in the first thirty seconds someone spends scanning a CV. A layer that ranks on evidence rather than CV polish takes a genuine problem off the recruiter's plate. The way I have started framing it is that intelligence and automation are two different things. Intelligence helps the recruiter build a stronger shortlist. Automation is what breaks the process when teams try to extend AI into the final call, the culture read, or the trust conversation with the candidate. Those are judgment stages, and quality of hire drops the moment they get handed off to a machine. The practical line I suggest to talent teams is simple. Let AI decide who deserves your attention, and let humans decide who gets the offer. Curious where this group draws that line today. Has anyone pushed further into automation and then pulled it back? 12The role your People team is missing (and can’t name yet). Why “we tried some AI” quietly stalls — and the one hire that turns it into something real.
A few months ago I stopped trying to describe what I needed and started noticing the shape of the gap instead. I knew exactly what I wanted to build. An AI-enabled People function — agents handling the repetition, managers getting what they need without chasing me, the whole thing running on a system instead of on my own effort. I could see it clearly. And I kept getting stuck in the same place. Not on the vision. On the build. Someone had to actually make it. Connect the systems. Turn the idea into something a manager could open on a Monday and use. And that someone — the person who does that specific job — didn’t exist on my team, and didn’t have a name in our org chart. That gap has a name now. I’ve started calling it the People Technologist, and I’ve come to think it’s about to become one of the most important roles in modern People teams. What the role actually is The People Technologist is the person who builds what the People function designs. Not a data analyst. Not an HRIS admin. Not “the person who’s good with the system.” Those roles keep the existing tools running. The People Technologist builds new capability — the agents, the workflows, the connections between systems that let a small team do what a much bigger one used to. They sit at a seam almost nobody staffs for: fluent enough in People to understand the work, technical enough to build the solution. Most HR people can design a process but can’t build the thing that runs it. Most engineers can build the thing but don’t understand the people problem well enough to know what to build. The People Technologist lives in the overlap. Give them a design and they turn it into something real. Give them a manual, repetitive process and they turn it into a workflow. Give them a policy and they build the system that applies it consistently, at scale, with the guardrails baked in. The People Architect decides what should be built. The People Technologist is why it actually gets built. That distinction is the whole point. Designing an AI-enabled People function and building one are two completely different disciplines — and we’ve spent years pretending they’re the same job. Three signs you’re missing this role You don’t need a strategy review to spot the gap. You can feel it in how AI actually plays out in your function. • Your AI efforts are all individual, never institutional. People use ChatGPT to draft their own emails, and that’s it. Nothing gets built that the function owns and everyone relies on. The value stays personal and never compounds. • Every good idea dies at “who’s going to build it?” You have the vision. You’ve even scoped it. But there’s no one whose actual job is to make it real, so it goes on a list, and the list doesn’t move. • You’re the bottleneck for the thing meant to remove bottlenecks. The automation exists because you built it on a weekend. Only you understand it. It breaks when you’re away. You’ve become a single point of failure for the system that was supposed to create leverage. If you recognise all three, it isn’t a motivation problem or a talent problem. It’s a missing role problem — and no amount of effort from the people you already have will close it, because none of them were hired for this. Why this role doesn’t emerge on its own Here’s the trap. This gap almost never gets filled, and there’s a structural reason. When a People team feels the strain, it hires the roles it already knows: another Business Partner, another recruiter, a coordinator. Sensible hires — but each one adds hands, not capability. They help you do more of the same work. None of them builds the system that would mean you didn’t need to do so much of it in the first place. So the function grows the way it always has: linearly, with headcount, most of the growth going into repetition. The very thing that would break that cycle — someone who builds capability instead of absorbing volume — never gets hired, because it isn’t on the list of roles People teams know to hire for. It’s a blind spot, not a failing. You can’t recruit for a role you don’t have language for. Which is exactly why naming it matters: the moment the People Technologist becomes a role you can name, it becomes a role you can hire, develop, and build a team around. And the timing isn’t neutral. Every quarter you wait, the gap between functions that build and functions that only buy gets wider — because the ones building are compounding, and the ones buying are still adding hands. Where this goes I don’t think the People Technologist is a nice-to-have for large teams. I think it’s one of three roles at the centre of how modern People functions will be structured: the Architect who designs it, the Technologist who builds it, and the Partner who makes it land. Three disciplines, one system. Most teams have some version of the Architect and the Partner already. It’s the Technologist that’s missing — and it’s the one that turns a good People strategy into something that actually runs. I’ve been building this out into a full methodology — how the three roles fit, what the Technologist builds first, how you’d hire or grow one, and how the whole thing becomes an operating system rather than a pile of tools. I’ll be unpacking it here piece by piece over the coming weeks. If you’re building an AI-enabled People function — or you’ve felt exactly the stuck I described at the top — I’ll be writing more. Because the question isn’t really whether AI belongs in your People function. It’s who’s going to build it when it does. 12Anyone can build an automation. Almost no one builds one that survives
Someone told me recently, with real pride, “we built it ourselves in a weekend.” And honestly? I loved it. I still do. A People team that opens a laptop and builds something instead of sitting through a fourth vendor demo has learned more about their own process in two days than a procurement cycle would teach them in two quarters. Building before buying is one of the healthiest instincts I’ve seen emerge in People and Talent Ops in years. If that’s you, keep going. But I have to say the uncomfortable thing, because nobody else seems to be saying it: A prototype is not an operating model. And most of what’s being built this year has been built as a prototype dressed up as a system. I’ve watched this film enough times to know how it ends. Let me tell you how it goes, and then let me tell you what to do differently — because the fix isn’t “stop building.” The fix is to build like someone who’s seen the sequel. The Friday-afternoon build has a predictable death Here’s the lifecycle, and I’d bet money you’ve seen at least half of it. Someone builds a clever automation on a Friday afternoon. It works. It genuinely saves the team hours. Word gets around, people start relying on it, and within a few months it has quietly become mission-critical — without anyone ever deciding it should be. Then the cracks. Only one person actually understands how it works. It was never documented, because documenting a Friday hack feels absurd at the time. The business grows. You hire into three new countries, each with its own leave rules and pay logic and data-protection regime that the original build never imagined. You acquire a company, and suddenly there’s a second HRIS and a second payroll provider that the automation was never designed to talk to. And the thing that saved you time last year is now the bottleneck everyone routes around. The person who built it has moved teams, or moved on. Nobody can safely change it, so nobody does. It becomes a small, load-bearing piece of technical debt with a human single point of failure attached. That’s expensive. And here’s the part I really want to land: it’s not expensive because you built it. It’s expensive because it was never architected to survive growth. This isn’t a hunch. It’s the best-documented failure in automation. I want to give you some numbers, because I think they make this stick in a way that my opinion alone can’t. The most quoted figure in the automation world is EY’s: 30 to 50% of initial RPA projects fail. That’s not a fringe statistic. It’s been the industry’s open secret for the better part of a decade. But the deployment failure isn’t even the interesting part. The scaling failure is. More than 50% of RPA projects fail to grow beyond 10 bots, and more than 70% plateau at fewer than 50. Read that again. The problem isn’t that people can’t build automations. They build plenty. The problem is that the automations don’t survive contact with growth. They stall the moment the organisation gets more complex than the day they were written. And why do they die? Not because the technology malfunctions. Around 70 to 75% of RPA’s total cost goes to implementation, maintenance and support — versus only 25 to 30% on the actual licensing. The build is the cheap part. Keeping the thing alive as the world changes around it is where the money — and the misery — actually lives. As one analysis put it bluntly, these projects don’t fail because the bots break; they’re symptoms of architectural brittleness. Here’s my favourite finding, because it’s the one that should make every People leader sit up. Deloitte tracked how many organisations had scaled automation to any real degree — 50 or more automated processes. Between 2017 and 2018, that number crept from 3% to 4%. A full year of enterprise effort, billions in spend, and the share of companies that actually scaled moved by a single percentage point. That is what happens when you build without architecting. At the population level. For a decade. “But this time it’s AI, so it’s different.” It isn’t. It’s worse. I can hear the objection, because I hear it constantly: that’s old robotic-process-automation stuff. We’re using AI now. AI is flexible, it handles the messy cases, it’s not brittle like those old rule-based bots. All true. And it changes nothing about the core problem. If anything, it raises the stakes. McKinsey’s projection is the one I’d tattoo on the wall of every People team experimenting with agents right now: 40% of agentic AI initiatives could be abandoned by 2027 — not because the agents fail at their tasks, but because organisations lack the frameworks to safely deploy autonomous decision-making at scale. Sit with that. The failures ahead of us won’t be technical. They’ll be governance failures. The AI will work fine. What’ll be missing is the architecture around it: who decides what the agent is allowed to do without a human, how you audit the decisions it makes, who owns it when it gets one wrong. The exact questions a weekend build never asks. So no — moving from rule-based automation to AI doesn’t rescue you from this trap. It hands you a more capable tool and a bigger blast radius. A brittle rule-based bot fails loudly and obviously. A poorly-architected AI system fails quietly, plausibly, and at scale, making confident decisions about real people that nobody designed it to be trusted with. The distinction nobody names Here’s the line I keep coming back to, and it’s the whole point: There is an enormous difference between building something that solves today’s problem and designing something that still works through scale, expansion and M&A. The first one is fast, useful, and exactly right for the company you are this quarter. The second is designed for the company you’re becoming. Both are valuable. But they are not the same skill, and pretending they are is why so much good work quietly rots. Anyone can build an automation. Very few people build systems that survive growth. That’s not a knock on the builders — it’s just a different discipline, and it’s the one almost nobody is teaching. So here’s what “architecting” actually means in practice. Three principles. None of them require you to slow down your prototyping. They just change what you build. 1. Design for the edges, not the average The Friday build is optimised for the company you are today: one HRIS, one country, today’s headcount. Architecture assumes the edges you can already see coming. Assume a second HRIS and a second payroll. You will either acquire a company or switch providers — probably both, eventually. Build so that a new system plugs in, rather than so that everything breaks the day it arrives. Assume more than one country. Different leave rules, different pay logic, different data law. Design the exceptions in from day one, because retrofitting internationalisation into a system built for one jurisdiction is a rebuild, not an update. Assume ten times the volume. If the process only works because someone eyeballs every case, it will not survive scale — it’ll just convert growth into an ever-longer queue of manual review. The moment a human has to touch every instance, you haven’t automated the work. You’ve hidden it. 2. Kill the single point of failure If one person understands how something works, that’s not an asset. It’s a risk wearing an asset’s clothing. Document the logic, not just the steps. Anyone can write down what the automation does. What matters is why it decides what it decides — the rules underneath — because that’s what the next person needs in order to change it safely without detonating something downstream. And make it legible to the whole team. This is the one I feel most strongly about. A system that only its original builder can touch isn’t really a system. It’s a hostage situation with a friendly face. The builder goes on holiday and the team holds its breath. The builder leaves and a piece of your operation goes dark. You did not build resilience; you built a dependency and called it efficiency. 3. Separate the logic from the tool This is the most important one, and the most ignored. Your rules — how you level people, how you escalate a case, what your policy actually is — are yours. They should not live trapped inside one vendor’s platform. Tools change. Your logic shouldn’t have to change with them. Build so you can swap a tool without a rebuild. The day you change HRIS should not be the day all your automations die. If it is, you didn’t build on the vendor — you built inside it, and you’ve handed them a quiet veto over your ability to ever move. And keep the capability in-house. If the only people who understand how your process works are on the vendor’s payroll, you don’t own your own process. You’re renting it, and the rent goes up. The mindset, in one line I tell every People team the same thing: prototype fast, learn quickly, but architect for the business you’re becoming — not the one you are today. Build the weekend hack. Seriously, build it. Learn from it. Then, before it quietly becomes load-bearing, take a breath and ask the boring, unglamorous questions that separate a prototype from a system. What happens when there are two payrolls? What happens when the builder leaves? What happens when we swap the tool? What happens at ten times the volume? The numbers are unambiguous about what happens if you don’t ask. Somewhere between a third and a half of these efforts fail outright. The overwhelming majority never scale. And the next wave — the AI one — is projected to fail for reasons that have nothing to do with the technology and everything to do with the architecture we’re not building around it. The good news is that this is a choice. The failure isn’t inevitable, and it isn’t about talent. It’s about whether you designed for growth before growth arrived, or hoped the thing you built on a Friday would somehow scale itself. It won’t. It never does. But you can build the one that does. 20Where AI matching supports the ATS, and where a gap still shows up
Most modern ATS platforms now include some form of AI matching, and for what the ATS was designed to do, that layer genuinely helps. The ATS was built to manage application flow, maintain an audit trail, handle compliance, and give the recruiting team one place to move candidates through the pipeline. AI matching sits on top of that and speeds up sorting, which is real value. What still comes up in most conversations with talent teams is that the shortlist does not always convert into a strong hire. The pattern is usually the same. Matching engines compare the language of a CV against the language of a JD, and CV language was never built to carry a reliable signal of capability. A backend engineer writes "built event-driven services on Kafka" while the JD says "experience with distributed systems at scale," and the engine scores it as weak even though it is a strong fit. The way I have started thinking about it is that this is less a failure of the ATS and more a mismatch between expectation and design. The ATS is doing what it was built to do. Capability signals have to come from a different layer, whether that is validated skill assessments, verified project work, or evidence from the platforms where the work actually lives. When you evaluate AI matching layered on your ATS, what test do you run to check whether it is reading skill or reading vocabulary? Would love to hear what has worked for your team. 13The New C-Suite Title Isn't Replacing HR. It's Racing It.
Every HR leader I talk to right now is asking some version of the same question: “Who actually owns AI at my company?” For a while the answer felt obvious. HR owns the workforce, AI touches the workforce, so HR owns AI. That assumption is already out of date (I know, AI is moving that fast). Here's what's actually happening. Two separate moves are underway, and most people are conflating them. Move one: A new seat gets created, and HR isn't automatically in it “Chief AI Officer” has become the fastest-growing title in the C-suite. IBM's 2026 CEO study found 76% of surveyed organizations now have one, up from 26% the year before. Named appointments include JPMorgan Chase, Walmart, Siemens, SAP, Pfizer, GE HealthCare, HSBC, Lloyds, UnitedHealth Group, American Express, Lowe's, Target, CVS Health, and Deloitte, where Joe Atkinson runs the function globally. The part that should get HR's attention: one of the CAIO's standard responsibility buckets is workforce readiness, preparing people to work alongside AI. That's a direct lift from HR's traditional territory. And the reporting lines confirm where the authority is landing: roughly 60% of CAIOs report to the CEO, 25% to the CTO, 15% to the COO. CHRO doesn't show up in that breakdown at all. Fortune's reporting on this puts it plainly: the CHRO seat at the table isn't disappearing, but the authority attached to it is migrating elsewhere, toward finance and operations, which speak the language of margins and workforce economics rather than culture and development. Move two: HR rebrands itself before someone else claims the mandate This is the more direct answer to what people are hearing about "new titles taking over HR." Jacqui Canney at ServiceNow became Chief People and AI Enablement Officer in January. Tracey Franklin at Moderna became Chief People and Digital Technology Officer, merging HR and technology under one seat. And a title has started circulating at HR conferences that hasn't fully landed yet: Chief Work Officer, floated by Databricks' CPO Amy Reichanadter among others, built on the premise that the job is no longer managing people, it's managing work, regardless of whether a human or an agent does it. And these aren't cosmetic changes, they're more pre-emptive. HR leaders who take this move are betting that expanding the title now is cheaper than losing the mandate later. The honest read Neither move has won. Industry advisors tracking this, including Randy Bean and Gartner's Jonathan Tabah, describe the CAIO role as still "transitional". It could become permanent and absorb workforce strategy for good. Or it could get folded back into the CTO, COO, or CHRO portfolio once the AI transformation matures and the novelty of a standalone title wears off. Right now, it’s too early to say, but the pieces are already moving on the chess board. If you're an HR leader, are you waiting to see how this resolves or are you attempting to get in front of it? Bigger question - do you truly want to own it? I’ve had confidential conversations with CPOs who have secretly confided in me that they honestly don’t want to own AI but they are happy to support it. What do you think? 43How do we help our managers lead when we’re still figuring things out ourselves?
That’s the big question almost every HR and People leader is trying to solve right now. AI changed the workplace so fast that our usual training and playbooks couldn't keep up. Managers are looking to us for answers, but the truth is, nobody has a perfect blueprint yet. Instead of waiting for the dust to settle, some People teams are just building the playbook as they go. HiBob is a great example. On July 24th, we're sitting down with their Chief People Officer Nirit Peled-Muntz, for an honest chat about how she’s supporting her managers through the chaos. We’ll cover: How to help managers make good calls when there isn't a clear roadmap Teaching teams to balance AI efficiency with human intuition Building manager training and guidelines while the company is already running full speed This is a live session, so please bring your real questions. It’s going to be an open conversation among peers, not a boring presentation. Practi, if you haven't come across it, is a practitioner community focused on hands-on AI workflows — this session is part of our live series with People leaders RSVP here 22
