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.