The most common question we get from People leaders is some version of: do I need to hire technical people to do this? The honest answer is no — and the more interesting answer is that hiring engineers into a People function to "do AI" usually backfires. Engineers solve the problem they understand, which is rarely the problem the team has.
What works, almost everywhere we have seen it work, is the champion model.
What a champion is
A champion is someone already inside the team — usually a senior coordinator, a People Partner, an Ops lead, a Talent Partner — who has two things at once: deep tacit knowledge of how the work actually flows, and genuine curiosity about wiring things together. They are not engineers. They are not hires. They are people you already pay, given a different mandate.
The reason this works is grain. The champion already knows where the friction is, because they live in it. They know which steps everyone hates, which approvals are theatre, which handoffs drop information. An engineer would have to discover all of that before they could build anything. The champion starts with it.
What a champion needs
Three things, in order.
Air cover. A named exec sponsor — usually the CPO or Head of People — who has said, in writing, that this person can spend a defined slice of their week on building. Twenty per cent is the floor. Less than that and the builds never finish. The cover matters because the champion will be asked, repeatedly, to drop the build work for "real" work. The sponsor's job is to say no on their behalf.
Tools and a budget. Not a big budget. A small one with no procurement friction. A workflow tool (n8n, Make, Zapier — pick one and stop debating). An LLM provider with the right enterprise terms. A vector store if the work needs memory. A few hundred a month, total. The friction of asking for these tools each time is what kills momentum, not the cost.
A small starting brief. One workflow. Bounded. Painful. Owned by a colleague who is willing to test the new version. Not "transform recruiting." Not "automate onboarding." One thing. The first-day Slack message sequence. Or interview scorecard summarisation. Or the weekly headcount reconciliation.
Give them those three things and stand back. (Champions also need somewhere to build: a shared AI workspace is the usual first artefact.)
Why three or four, not one
A single champion is fragile. They get sick, they get pulled into a crisis, they leave. The work stops and the institutional memory walks out the door.
Three or four champions across the team — distributed across TA, HRBP, and Ops, ideally — give you something different. They review each other's work. They share patterns. They cover each other when one is buried. They form the nucleus of a real practice.
Four is roughly the number where you start to see emergent behaviour: workflows being reused, naming conventions appearing without anyone mandating them, junior people in the team asking "can we do that for X?" because they have seen it work for Y.
What champions are not
They are not a committee. They do not write strategy. They do not run an "AI taskforce." They build things. The moment the role becomes governance or planning, the model has failed. There are other people for that. Champions ship.
They are also not the eventual owners of every workflow. A good champion builds something, hands it to the team that uses it, and moves on. The workflow lives inside its function. The champion's job is to build the next one.
The compounding effect
Six months in, a healthy champion model produces something that looks unimpressive on a slide and is genuinely transformative inside the team. There are eight or twelve workflows running. Each saves a few hours a week. Together they have changed what the People function spends its time on.
More importantly, the team's relationship with AI has shifted. It is no longer a thing they read about. It is a thing they make. New joiners learn the craft from the champions, not from an enablement deck. The capability lives in the people, not the policy.
This is the test. Two months after the engagement ends — if there was an engagement — the champions are still building. They have extended the work into corners nobody asked them to touch. They are training the next champion already.
That is what we mean by capability. Not a tool you bought. A practice the team holds.
What this connects to
Auto-recommended next reads in the People Ops cluster, ranked by shared concepts and headings:
- An AI enablement operating model for People leaders
- Designing the AI-native People team
- Prompting patterns for People Ops
- The HR Architect: a new role inside the People function
Common questions
- Do we need to hire engineers to build AI capability inside our People function?
- No. Hiring engineers into a People function to "do AI" usually backfires — they solve the problem they understand, which is rarely the problem the team has. The champion model uses people already inside the team — senior coordinators, People Partners, Ops leads, Talent Partners — who know where the friction is because they live in it. They are people you already pay, given a different mandate.
- What does a champion actually need to succeed?
- Three things, in order. Air cover: a named exec sponsor (usually the CPO or Head of People) who has said, in writing, that the champion can spend at least twenty per cent of their week on building. Tools and a small budget with no procurement friction — one workflow tool, an LLM provider on the right enterprise terms, a few hundred a month total. And a small starting brief: one bounded, painful workflow owned by a colleague willing to test the new version. Not a programme. One thing.
- Why three or four champions, not just one?
- A single champion is fragile. They get sick, get pulled into a crisis, or leave — and the work stops. Three or four champions distributed across TA, HRBP, and Ops review each other's work, share patterns, and cover each other when one is buried. Four is roughly the number where emergent behaviour starts: workflows being reused, naming conventions appearing without anyone mandating them, junior people asking "can we do that for X?" because they've seen it work for Y.
- What does success look like six months in?
- Eight or twelve workflows running, each saving a few hours a week, together changing what the function spends its time on. More importantly, the team's relationship with AI has shifted — it's no longer a thing they read about, it's a thing they make. New joiners learn the craft from the champions, not from an enablement deck. The real test: two months after the engagement ends, the champions are still building, extending the work into corners nobody asked them to touch, and training the next champion.
If this resonated, there's more.
Subscribe to receive new Intelligence pieces as they're published. No noise — just the work.
By subscribing you agree to our Privacy Policy. Unsubscribe any time.
