The champion model

The champion model is a staffing decision, not a training programme. You build AI capability inside a People function by picking three or four operators who already know where the work snags, protecting a fifth of their week, handing them a budget and one painful workflow, and standing back. Not by hiring engineers, and not by running the whole team through a course. Same people you already pay, given a different mandate. Most People leaders reach for a course or a headcount request. Both are slower, more expensive, and less likely to stick than the champion sitting two desks away.

What a champion is, and why an engineer is the wrong hire

A champion is someone already inside the team, usually a senior coordinator, a People Partner, an Ops lead or 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. The first is rare and takes years to build. The second you can spot in a week. You cannot easily teach either, which is why you select for both rather than train for them.

The reason this beats hiring 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 quietly drop information. An engineer has to discover all of that before they can build anything useful, and they usually discover the wrong thing, because they optimise for what is technically interesting rather than what is operationally painful. You end up with an elegant solution to a problem the team did not have.

There is a second failure mode with the outside hire, and it is the one that costs most. Bring in a contractor or an agency to build the systems, and when they leave, the systems become unmaintainable black boxes. The builders left. The capability went with them. The champion model exists precisely to keep the capability inside the building, held by people who are not going anywhere.

Who actually makes a good champion

The instinct is to pick the person with the freest calendar, or the one who put their hand up in the AI town hall. Both are usually wrong. The free calendar is often free for a reason, and the loud volunteer is frequently more interested in the topic than in the grind of shipping. What you want is the operator with an itch: the person who already builds workarounds in spreadsheets, who mutters about the same broken handoff every month, who reaches for a tool the moment something annoys them.

Run your candidates through a short filter before you name anyone. It saves you the more painful discovery three months later, when the training budget is spent and nothing has shipped.

None of this requires a technical background. It requires someone who understands the work and cannot leave a broken process alone. If you are formalising this into a job shape, that person is on the path to something like the HR Architect role, whatever the title on their contract says today.

The three things a champion needs

Once you have picked well, the model succeeds or fails on three inputs. Get all three right and a champion ships something working inside the first fortnight. Miss any one and the build stretches to months, if it happens at all.

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 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, out loud, in the meeting where the ask happens.

Tools and a small budget. Not a big budget. A small one with no procurement friction. One automation tool, and stop debating which: n8n runs about twenty pounds per builder seat per month, is SOC 2 and ISO 27001 compliant, and self-hosts if your security team needs it inside the perimeter. Add an LLM provider on the right enterprise terms, and a vector store only if the work genuinely needs memory. A few hundred a month, total, on a company card. The friction of asking for these tools each time is what kills momentum, not the cost. A six-week vendor review to approve a twenty-pound licence is how you turn an eager champion into a discouraged one.

A small starting brief. One workflow. Bounded. Painful. Owned by a colleague who is willing to test the new version live. Not "transform recruiting". Not "automate onboarding". One thing: the first-day Slack message sequence, or interview scorecard summarisation, or the weekly headcount reconciliation. The scope of the first brief is the single most common thing leaders get wrong. They hand the champion a mandate the size of a strategy deck, and the champion drowns before shipping anything. Give them somewhere to build too: a shared AI workspace is usually the first artefact a champion needs before the first workflow.

The first fortnight

The model has a natural rhythm, and the first two weeks set whether it holds. The point of the fortnight is not a polished system. It is proof, to the champion and to the sceptics watching, that something real ships fast. Ugly and working beats elegant and pending, every time.

Notice the last step. A good champion builds something, hands it to the team that uses it, and moves on. The workflow lives inside its function, maintained by the people who depend on it. The champion's job is to build the next one, not to become the permanent owner of a growing pile of automations. The moment a champion is running twelve workflows single-handed, you have rebuilt the single point of failure you were trying to avoid.

Why the champion model needs three or four, never one

A single champion is fragile in a way that is easy to underrate until it bites. They get sick. They get pulled into a crisis. They leave. And when they do, the work does not gently degrade. It stops, and the institutional memory walks out the door with them.

Three or four champions across the team, distributed across TA, HRBP and Ops, give you something a lone builder never can. 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 rather than a hero project with a bus factor of one.

Four is also roughly the number where you start to see emergent behaviour. Workflows get reused without anyone mandating it. Naming conventions appear on their own. Junior people in the team start asking "can we do that for X?" because they have watched it work for Y. That reuse and that curiosity are worth more than any single workflow, because they are the practice becoming self-sustaining. Below three, you have individuals. At four, you have a habit.

What compounds, and what starves

Two champion models can look identical on the launch slide and diverge completely within a quarter. The difference is almost never talent. It is whether the three inputs stayed protected once the launch glow faded and the business got busy. The most common way the model dies is quiet starvation: nobody kills it, the build time just gets eaten, one urgent week at a time, until the champion is back to their old job with a lapsed licence and a half-built workflow.

Watch the b column for the drift into governance especially. A champion's job is shipping, not policy. The moment the role turns into a committee, a strategy deck or an "AI taskforce", the model has failed at the thing it was for. There are other people and other forums for governance, and they matter, but they are not the champion. Champions ship. When you notice a champion spending more time in meetings about building than building, you have lost one.

There is a coaching dimension to keeping the compounding side alive. Champions who never get their work reviewed plateau, quietly, and start reinventing patterns the team already solved. A light cadence, a regular slot where champions show each other what they built and where it broke, is what keeps the curve bending up rather than flattening. It is the same reason coaching and feedback systems compound in the rest of the People function: skill without a feedback loop stalls.

What "done" actually means

Six months into a healthy champion model, you have something that looks unimpressive on a slide and changes almost everything about how the team spends its week. Eight or twelve workflows running, each saving a few hours. Together they have shifted what the People function does with its time, from routine processing toward the judgement work that needed people in the first place.

The deeper change is the team's relationship with the technology. AI 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 document. This is the "Scale" step of how we read, craft and scale an engagement: the systems are built, and now the practice that maintains and extends them is owned inside the function.

That is the real test, and it comes after the visible work is done. Two months after any outside help leaves, the champions worth keeping are still building, into corners nobody scoped. They are training the next champion already. That is what capability means: a practice the team owns long after the invoice is paid, and long after anyone is watching. If you want the wider shape this sits inside, the operating leadership pillar covers how build capability, and the champions who hold it, fit into running the function. The next question most leaders ask is how to grow the model past four into a proper AI-native People team, which is a different problem with a different answer.