Decode the AI Shift

AI in HR

Share Your Voice

Explore how artificial intelligence is reshaping HR — from smarter recruiting to predictive analytics, employee experience, and beyond. Share tools, strategies, and lessons learned as we navigate the AI shift together.
Karthika Biju
Karthika Biju
·Helping starts structure and scale their AI enabled People systems and functions

The 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.
1
2
Karthika Biju
Karthika Biju
·Helping starts structure and scale their AI enabled People systems and functions

Anyone 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.
2
0
IGC
IGC
Bobber

Every company can buy AI. Far fewer are built to benefit from it.

You can invest in every AI tool on the market. But if your people do not know when to use AI, where it adds value, or how to use it well, adoption will stall. To get past the guesswork, we asked 1,200 AI decision makers questions to pinpoint the exact AI behaviors that drive real business value and created a practical guide for HR leaders. In the guide, you'll see: 🔹 AI readiness benchmarks to assess where you and your organization stand 🔹AI skills orgs should actually measure beyond the hype and the headlines 🔹A framework for assessing AI capability to move from data and insights to action "Organizations are asking managers to lead a massive workforce evolution, but the majority haven’t given them the tools or shared standards to succeed." By defining a core set of observable AI behaviors, organizations can: 🔹 Source talent more accurately 🔹Develop their people more effectively 🔹Avoid relying on vague signals for ROI and build a scalable program that embraces the best of AI HOW TO GET THE GUIDE? Share your thoughts below on where your organization is seeing the biggest AI readiness gap or just comment “GUIDE” for the full resource, and we'll direct message it right to you!
6
26
Alex Rashkovan
Alex Rashkovan
·Co Founder & CEO Atalef.ai

Where 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.
1
3
Asif Chowdhary
Asif Chowdhary

AI Analysis of Candidates

There are technologies out there that allow you to compare candidate resume with job descripton and then provide an analysis if the candidate is a good fit or not. LinkedIn is also doing it. Do you think if we add Interview transcripts and then conduct AI analysis based on a set criteria that additional data point will further help in evaluating candidates
1
1
Matt McFarlane
Matt McFarlane
Featured Contributor
·Helping startups build comp practices that are clear, fair and competitive.

Is the AI librarian a role of the future?

I've been chewing on a question since an interview I did last week, and I'd love other people professionals' perspectives on it: is the librarian about to become a role of the future? Here's my thinking. Years ago I worked for a company that had an actual librarian. A real one. There was a room full of books, industry reports and publications we'd produced, and it was one person's job to look after it all. They made sure that when you needed something, you could find it, and that what you found could be trusted. Honestly, at the time it felt like a leftover from another era. Looking back, I don't think I appreciated what the role actually was: a single person accountable for whether the company's knowledge worked. Fast forward to last week. I interviewed a People leader whose company had just launched what they call their company brain (I'll share the full conversation once the episode is out). The rough shape of it: Context on how the company works, its goals, and who matters to each role Every major decision, captured through decision memos and automatically indexed so they're searchable forever A library of AI skills, roughly 120 at launch, organised into packs per role An onboarding flow that hands each new starter the skills built for their job, then recommends others based on where they say their friction is Employees work with AI that sits on top of all that context. The brain is how the AI knows the company. The build impressed me. But the longer we spoke, the louder one question got: Who manages this thing? Not the infrastructure. The knowledge itself. Because when I thought about that question afterwards, the job description started to look very familiar. Librarians were never just people who shelved books, and the discipline has proper names for its work: Collection development. Deciding what belongs in the library. In company brain terms: which context gets in, which decisions get captured, and what AI should be allowed to act on versus what stays a human judgment call. Cataloguing. Organising knowledge so it connects. Skills that reference each other and branch into related areas, rather than duplicating or contradicting one another. Weeding. Pulling stale stock off the shelves. I'd argue this becomes the most important job of the lot. A stale page on a wiki misleads the occasional reader, who will probably double-check anyway. Stale context in a company brain gets applied by AI, at scale, with total confidence. The reference interview. When you ask a librarian for a book, their first move is working out what you're actually trying to solve. The modern equivalent is helping people match problems to skills, and spotting the gaps where a skill should exist but doesn't yet. We've also run the "nobody owns it" experiment before. Most of us have watched an intranet or a wiki launch with energy and rot within a year because nobody owned keeping it alive. The difference this time is that the archive isn't passive. Work runs on it. If the brain is wrong, the work is wrong. Now, the pushbacks I keep testing this against. Maybe AI manages itself. You can imagine agents that flag stale context, catch contradictions, and suggest new skills based on how people are using the library. Some of that will happen. But someone still writes the rules those agents follow, and someone still owns the calls about what's sensitive, what's wrong and what's missing. That sounds like a person to me. Maybe it's a slice of an existing role rather than a headcount. At the company I interviewed, one person built the entire brain alongside their day job. That works at launch. I'm less convinced it works at 500 employees, 400 skills and three years of accumulated decisions. And if it is a role, where does it sit? L&D has a claim (a skills library looks a lot like the next training catalogue, and it completely rewires onboarding). Ops could claim it as infrastructure. Knowledge management, where it still exists, would say this was their job all along. IT will want it for governance reasons. I don't have a firm answer yet. So I'm throwing it to the group, because I haven't landed on a position: Would you make this a dedicated role, or fold it into an existing one? Whose? Is anyone already doing this in your company, formally or informally? What do you call them? What would you actually put in the job description? Or am I overcooking it, and the tooling will make most of this self-managing within a couple of years?
2
1

Ethics, Fairness & Governance

Share Your Voice

This space is where HR professionals wrestle with emerging AI questions: What's fair? What's legal? What policies actually work?
IGC
IGC
Bobber

The Double-Edged Sword of AI in Hiring

AI has transformed recruiting from a manual, paper-heavy process into something that looks and feels much more streamlined. Résumés can be scanned in seconds, candidates can be ranked based on predictive analytics, and interview scheduling can be automated so recruiters spend more time on high-value conversations. For organizations dealing with high application volumes, this is a game-changer. But speed comes at a cost. Candidates increasingly wonder if they are being fairly judged, or if their applications are dismissed by an algorithm before a human ever sees them. AI also tends to favor candidates who “look like” the data it’s been trained on, which raises real concerns about perpetuating bias. HR teams are now faced with a paradox: AI promises efficiency, but it also risks reducing candidates to data points. Forward-thinking companies are approaching this tension by layering human judgment on top of AI insights. For example, AI might recommend a shortlist, but recruiters still review every résumé to catch non-traditional candidates who could excel. Others are investing in tools with transparent criteria, so candidates can understand what’s being evaluated. Question for the group: If your team is using AI in recruiting, how do you ensure that the process is both efficient and fair—and that candidates still feel seen as people, not just profiles?
0
0
IGC
IGC
Bobber

Beyond the Algorithm: Ethics in HR

AI is reshaping HR in ways we couldn’t imagine five years ago—flagging top performers as “flight risks,” surfacing hidden bias in recruiting, or raising new questions about privacy and policy. These aren’t just tech glitches; they’re ethical dilemmas with real impact on people and workplaces. This space is where HR leaders come together to ask the hard questions: What’s fair? What’s legal? What actually works in practice? Join the conversation to share experiences, challenge assumptions, and explore how to build more transparent and responsible workplaces. 👉 What’s the biggest ethical challenge you’ve faced (or worry you’ll face) as AI takes a bigger role in HR?
0
0

Practical Tools & Applications

Share Your Voice

Every week there's a new AI tool promising to revolutionize HR, but which ones actually deliver? This space is where you get honest reviews from people who've moved beyond the free trials and live with these tools daily. No vendor demos, no affiliate links.
Christine Song
Christine Song
Featured Contributor
·Your network truly is your net worth.

The 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?
3
3
Kyle Lagunas
Kyle Lagunas
Featured Contributor

Newsflash: Your AI Rollout Isn't (only) Challenging Because of the Technology

In my research at Kyle & Co, I'm observing a trend in HR's AI transformation: Most organizations approach AI the same way they've approached every other software rollout. Find a use case. Procure a tool. Launch it. Hope it sticks. Then wonder why adoption stalls six months in. Here's the thing: It's not a technology problem—it's a people problem… And it always has been. That's the central argument behind our latest ebook AI Transformation and Change Management, a new resource from the Human-Centric AI Council (HCAIC) and lead author Alicia Miller (a seasoned transformation leader with a background in I/O psychology and AI enablement). The guide is practical, grounded, and refreshingly honest about why AI adoption is harder than most change playbooks account for. You can access it as part of our full transformation toolkit! AI Is Fundamentally Different. Your Change Management Strategy Needs to Be Too Traditional software came with a manual. You trained people on the steps, they produced consistent outputs, and you moved on. AI doesn't work like that. The outputs are probabilistic—they vary by user, by context, by how the question is asked, etc. The models keep learning and changing, which means yesterday's best practice can be tomorrow's outdated prompt. And then there's the "black box" problem... when employees can't explain why the system said what it said, trust erodes fast. That's before you get to the harder stuff—the fear that AI is coming for jobs, the blurring of what "my role" even means anymore, the sheer volume of models and tools competing for attention. The guide names these dynamics directly, because you can't design around a problem you haven't acknowledged. The COM Model: A Change Framework YSK (You Should Know) One of the most useful things in the guide is what Alicia calls the COM Model: Capability, Opportunity, and Motivation. It's a behavioral change lens applied to AI adoption, and it reframes where organizations typically get stuck. Capability is the one most teams focus on (training programs, role-based learning paths, L&D roadmaps, etc.). That work matters—but it's not enough on its own. Opportunity is about creating the actual space and conditions for people to learn and experiment. Even when employees want to engage with AI, they often don't have the time, the sandboxes, or the explicit permission to explore. The most experienced people (i.e. the ones whose judgment you most need) are also the busiest. Without protected experimentation time and real access to tools... adoption stagnates. Motivation is where the real complexity lives. People need to understand what's in it for them—not abstractly, but concretely. They need fears addressed directly, not managed around. And they need to see it working before they'll fully commit. Skeptics don't respond to vision statements. They respond to evidence. Surprise! Culture Is the Hidden Variable in Change Management The ebook spends meaningful time on something most rollouts underinvest in: Cultural readiness. AI-enabling cultures share specific traits: a tolerance for experimentation (including failed experiments), continuous learning norms, psychological safety, and genuine knowledge sharing. That last one is interesting. Because AI outputs vary based on how you work with them, the people who've figured out what works have an edge... and organizations need them to share it, not hoard it. If your culture punishes failure, people won't experiment. If it rewards individual performance over team contribution, knowledge won't flow. No training program fixes that. From Pilot to Scale: Where Most Organizations Actually Get Stuck One of my favorite parts of the ebook was the section on pilots. It covers something I’ve been thinking about a lot lately, and I think it’s particularly useful for HR teams being asked to prove ROI before getting broader investment (aka all of us). A good pilot tests more than technical feasibility. It surfaces adoption barriers. It identifies what roles will shift and what capabilities are missing. It gives you the change management intelligence you need to scale responsibly—not just the business case your CFO wants to see. The guide walks through how to structure POCs and pilots to actually evaluate business value... including approaches like randomized control trials and quasi-experimental designs. Suffice to say, this is not typical change management content. It reflects Alicia's background and the HCAIC's commitment to evidence-based practice. I’m really proud of it! A Resource Especially Relevant for the In Good Company Community I think it’s super cool that our friends at HiBob built this community for people-first leaders who believe that how you treat employees is how you build companies worth working for. It's validating for me and for our work with the HCAIC, as it’s exactly the lens this ebook brings to AI. The goal isn't to make your workforce "use AI." The goal is to help your organization evolve into new ways of working where AI is embedded, outcomes improve, and people remain at the center of how value is created. That's not a soft position. It's a strategic one. And it requires HR to lead change, not just support it. The good news is that you don’t have to go it alone—because you’re in good company!
2
2
Kyle Lagunas
Kyle Lagunas
Featured Contributor

Reality Check: Why Human-Centric Change Is the Only Way AI Scales in HR

We’re already one month into the new year, and already I’m seeing renewed focus on AI in HR. I posted on my personal blog the trends I’m tracking for the year, but the biggest lesson we need to learn in 2026: Transformation requires more than cool tools. Follow me on a journey that’s a tale as old as time. HR launches an exciting AI pilot. Your early champions jump on as part of your push past go-live, inspiring an early ramp of adoption… But then things plateau after just a few weeks--until ultimately it fizzles out with only a fraction of the impact you anchored your business case to. The business declines to invest in Phase 2, pointing to a weak proof of concept, and moves onto more reliable outcomes—like cutting costs and offshoring services. If you’ve been there, you know it’s super disheartening--all of that work, all of those calories, all of that momentum… just swept under the rug. It’s the worst. It’s one of the biggest reasons we started the Human-Centric AI Council: We know that lasting, meaningful change is one of the pillars of human-centric AI in HR--and that it’s really hard to affect. So if you’ve been there and felt this (or hesitated because you’re afraid of it), then know this: This isn’t a failure of ambition or technology. It’s a failure of how we approach change. AI is a completely different kind of technology. It’s changing not just how fast work gets done, but how work gets done--and by whom. That’s why adoption feels harder than expected: It requires way more change management than a few training videos and an email campaign. In the HCAIC’s latest change management guide, led by Alicia Miller--Pillar Lead for Change Management--one message is clear: AI adoption succeeds or fails based on people, trust, learning, and judgment--not deployment checklists. We’re publishing the ebook later this month, but I wanted to give you a preview, featuring the practices that stood out most. If you’ve read my blogs here before, you know I get a little long-winded (imagine how precocious I was as an eight-year-old! Lol), so I’ll share some pull-quotes from the eBook first, then offer a deeper dive for my friends with longer attention spans--and/or more interest in the actual best practices we’re purporting in this resource. The Quick Quotes: AI Change Management in 100 Words or Less: AI Isn’t Broken—Your Expectations Are. AI is probabilistic, not predictable. Adoption depends on judgment, trust, and learning—not consistent outputs. Trust Is the Real Output of a Pilot. Pilots test credibility, surfacing human feedback that shapes adoption, risk tolerance, and real-world value. Experimentation Dies When It Competes With “Real Work”. Without protected time and safety, learning stalls and experimentation becomes optional. Scripts Don’t Survive Contact With AI. Static training fails. Frameworks and principles help people adapt as tools and outputs change. Momentum Spreads Sideways, Not Downward. Peer learning and cross-functional networks scale adoption faster than top-down mandates. Fear Is a Structural Constraint, Not a Communications Gap. Unchecked anxiety suppresses learning; psychological safety enables progress. The Real Tea: 6 Key Takeaways from the HCAIC’s Forthcoming AI Change Management Ebook 1) AI Isn’t Broken. Your Expectations Are. One of the most consistent adoption failures comes from treating AI like deterministic technology--stable, predictable, and repeatable. But AI is probabilistic by design. Variability isn’t a flaw; it’s the cost of intelligence. What differentiates organizations that move forward isn’t better tools--it’s comfort with judgment over certainty. Employees who are trained to evaluate, refine, and contextualize outputs build confidence. Employees who are promised consistency experience variance as failure. Our AI Momentum Model research reinforces this directly. Organizations stuck in “Exploring Possibilities” in AI for HR often mistake awareness for readiness, circling AI without developing the evaluative capability needed to move forward. Figure 1. Degrees of organizations use of AI in HR, 2025 Leaders, by contrast, exhibit higher AI literacy and are far more likely to describe themselves as confident practitioners who can enable others. Figure 11. AI and Technology Literacy Across the HR Organization 2) Trust Is the Real Output of a Pilot Many pilots fail not because the technology underperforms, but because they’re designed to answer the wrong question. Technical feasibility alone doesn’t create momentum. Credibility does. But what we're observing in our research (five years of trendspotting, btw) leaders who progress beyond pilots treat them as learning and trust-building mechanisms, not proof points. These organizations use pilots to surface adoption barriers, calibrate risk, and build coalitions across HR, IT, compliance, and the business. Figure 12. Changes in AI Strategy Over the Past Year The data is stark: Nearly half of HR teams remain stuck in exploration, but those that advance to integrated or AI-first models consistently outperform laggards on retention, quality of hire, and workforce agility. Momentum correlates directly with impact, and pilots are the inflection point where trust either compounds or collapses 3) Experimentation Dies When It Competes With “Real Work” Organizations often say they want experimentation, but leave workloads untouched, timelines unchanged, and failure quietly punished. Employees respond rationally… they deprioritize learning a new approach to the same old work. The Momentum Model uncovers why this approach matters: HR organizations that remain too conservative when piloting AI lose influence not because they lack ambition, but because exploration without a clear value proposition for end users signals optionality. The message people hear is, “You should try this” vs. “You can contribute to solution design before we deploy it.” Leaders who build momentum send a different signal: They protect time, normalize iteration, and make learning visible. Experimentation stops being extracurricular and becomes part of how work gets done. That cultural permission is a major separator between Leaders and Laggards. 4) Scripts Don’t Survive Contact With AI The static, step-by-step training we’ve used for decades was designed for stable, static tools. AI breaks that assumption almost immediately. Interfaces change. Models evolve. Outputs shift. Our AI Momentum research outlines why organizations stall when they rely on procedural training alone: Capability gaps--especially in literacy (shared above) and integration (shared below)--are among the strongest brakes on momentum. Figure 16. Integration of HR Systems and Data to Support AI Without shared mental models for how AI should be evaluated and applied, pilots remain isolated and fragile. Leaders invest instead in frameworks that facilitate action. How to define problems, evaluate output quality, manage risk, and escalate judgment calls--these capabilities are more than a wishlist for HR teams that are getting things done. This is why literacy emerges as the single strongest unlock in the model. When people understand how to think with AI, adoption scales even as the technology changes. 5) Momentum Spreads Sideways, Not Downward Some of the most valuable AI learning never comes from formal programs. It comes from peers solving real problems and sharing what worked—or what didn’t work (as expected or at all). One of the clearest paths to lasting change is also one of the cornerstones of corporate culture: Coalitions. Figure 13. Ownership of AI Strategy for HR and Its Functions In our research, Leaders don’t keep AI as “HR’s project.” They share ownership across HR, IT, compliance, and business leaders, creating shared accountability and faster diffusion of learning. Organizations that fail to build these coalitions remain siloed, even when budgets or tools are available. Those that succeed turn individual experimentation into organizational capability — the difference between pilot fatigue and sustainable momentum 6) Fear Is a Structural Constraint, Not a Communications Gap Job anxiety isn’t a side issue in AI adoption—it’s a central one. When people fear automation, they withhold effort, avoid experimentation, and hoard knowledge. We see this often: Organizations with low literacy and weak governance default to risk avoidance, scrutinizing AI use cases into oblivion. Fear fills the gap left by understanding. Figure 15. Presence of HR-specific governance to guide the utilization of AI in the organization Leaders, by contrast, treat governance as a confidence accelerator, not a brake. Clear guardrails reduce uncertainty and give teams permission to move. The data confirms that organizations with visible governance, higher literacy, and active risk postures move faster—not because they ignore risk, but because they manage it deliberately. Psychological safety becomes an enabler of momentum, not an abstract cultural aspiration. Reframing Change Management in AI for HR: Maintaining Momentum with Human-Centricity If there’s a throughline here, it’s this: When AI adoption stalls, it’s usually not because the idea was bad or the team wasn’t capable. It’s because we underestimated how much change we were actually asking people to absorb. So when pilots fizzle, I don’t see failure. I see organizations trying to force a new kind of work through old muscles. The teams that are getting traction aren’t louder or faster. They’re more intentional. They spend time upfront resetting expectations. They protect space for experimentation instead of squeezing it between meetings. They put guardrails in place not to slow things down, but so people feel safe enough to actually use the tools. And they talk openly about fear instead of pretending it’s a comms problem. Momentum doesn’t magically appear after rollout. It’s built (awkwardly, unevenly, over time, etc.) by the choices leaders make about people, not tools. That’s the real work in front of HR right now—and what we’re supporting at the HCAIC. Be on the lookout for the full ebook next month!
2
3
Sofia Lim-Oliver
Sofia Lim-Oliver
Bobber
Featured Contributor
· I explore what it means to live and work with greater purpose, wholeness and humanity - so that together we can thrive at work and at life.

If you're sick of hearing "be more human"...

Every conference. Every webinar. Every conversation. Leadership in the AI age. Leading with AI. Leading Humans and AI. Of course, AI is the big challenge and opportunity of our time. But what's been driving me crazy is all the fluff: - Vague calls to “be more human” - Recycled leadership models with AI copy-pasted - Or just slapping AI on the title to fill seats. I'm a mother of a 4 year old. I don't have time for fluff. I can barely get dinner on the table. So I got fed up. And I went looking for what “leadership in the AI age” actually, practically means. Here’s what I landed on: AI doesn’t change what leadership is — it changes the conditions under which leadership happens: - Speed is higher - Certainty is lower - Leverage is asymmetric (small decisions can have huge impact) - Thinking quality matters more than experience “Be more human” looks lovely on a t-shirt but it's not the answer we need. My favorite litmus test for practicality is: What can we do differently in a team meeting on a Wednesday afternoon? 👓 1. Frame the question before jumping to answers Instead of opening with “Here’s the plan”, start with: “Here’s the question we’re actually trying to answer — and here’s why it matters right now.” 👀 Why? This shifts the meeting from who has the smartest answer --> are we solving the right problem? It also stops AI (and humans) from running ahead with polished answers to the wrong question. 📣 2. Say out loud what you know — and what you don’t “Here’s what we think we know.” “Here’s what we’re assuming.” “Here’s what’s still unclear.” 👀 Why? Doing this lowers false certainty, invites challenge without drama, and models that not-knowing isn’t weakness. It sounds simple but it's surprisingly rare - and powerful when it's said out loud. 🧫 3. Be explicit about what you’re betting on vs. what you’re testing “This is a reversible decision, so we’re going to move and learn.” “This one’s harder to undo, so here’s what we need to validate first.” 👀 Why? This helps teams understand when speed matters more than correctness, when AI outputs are inputs, not answers, and it makes human judgment visible — instead of hidden behind AI-based confidence or tools. 👉 If this was useful, like or share so it reaches other leaders who are also drowning in AI-flavoured fluff. I’ll keep sharing what I’m learning about leading in the AI age — hopefully without the hype!
3
2
Jessica Zwaan
Jessica Zwaan
Featured Contributor
·Author of Built for People: People Ops as a Product

Knowledge will be outweighed by confident judgment...

Reading through Bob's HR trends predictions today and I couldn't help but comment on one I wanted to hear anyone's opinions on! https://www.hibob.com/guides/hr-trends-2026/ "Prediction 4: Knowledge will be outweighed by confident judgment" Two of the suggestions are: Invest in cognitive learning. Shift learning budgets toward building cognitive capabilities: critical thinking, judgment, problem-solving, and decision-making. Use problem-based learning. Incorporate real-world scenarios, cross-functional challenges, and reflection exercises that can strengthen people’s judgment and adaptability. And I'm wondering, what have y'all done (if anything) on workshopping and creating places for practical application of these skills? As someone who prides herself in "knowing a lot about all the little bits and pieces" I've been actively trying to build that skill into something I can tap deeper into using AI, but I'm yet to find a way to really communicate or share those skills at scale. Would love y'all's thoughts!
6
0
Jessica Zwaan
Jessica Zwaan
Featured Contributor
·Author of Built for People: People Ops as a Product

New York City Hackathon!

Hi folks, After the wicked event in NYC last week I was wondering if it might make sense for us to do an in-person (or virtual) AI Hackathon? I think we could spin something really valuable up for practical applications of AI and Agentic tooling in HR. Some inspiration: https://medium.com/@drocher/how-i-built-more-than-10-recruitment-ai-agents-in-less-than-a-month-with-zapier-582fe8de0157 And from the incredible Emily at Zapier herself: https://www.youtube.com/watch?v=TQl-y8gR6dw (I'm sure we can try to invite Emily along too if she is free!)
6
3

Artificial intelligence is reshaping how HR teams work — from automating routine tasks to informing strategic people decisions. Conversations in this space reflect real-world experiences with AI tools, ethical challenges around fairness and governance, and practical lessons on using AI responsibly in talent, analytics, employee experience, and people operations.

Members share honest perspectives on what works, what doesn’t, and how AI impacts daily HR practices, including recruiting, performance management, and workforce planning. Whether you’re wrestling with policy questions or testing new automation tools, you’ll find grounded insights here.

Want to explore more about broader HR topics and peer insights? Head back to In Good Company to browse all discussions, learn about the community, or check the FAQs for curated HR answers.