Setting up a talent function, in the order it has to happen

There is no dataset in this one. It is the sequence I would use if I had to build a talent function again from very little, and the reasoning behind the order, which is the part that usually goes missing when this gets written up.

The brief always arrives the same way. Hiring is not working, someone senior has been asked to fix it, and within a fortnight there is an org chart with boxes for sourcing, coordination and business partnering. The chart is not wrong. It is just the fourth thing, and it keeps getting done first.

1. Decide what the function is accountable for

Before any structure, write down what talent acquisition owns, what it influences, and what it does not touch. Then get a hiring executive to disagree with it in writing.

The three that matter: does TA own the decision to open a role, or only the process once it is open? Does TA own the offer, or does compensation? Does TA own the hiring manager’s calendar in any enforceable sense?

Most functions are held accountable for time to fill while owning none of the three levers that move it. That is not an organisational design problem, it is an accountability problem, and no box on a chart will fix it later.

2. Find out what you are actually hiring

Not the plan. The last eighteen months of what really happened: volumes by role family, by location, by seniority, and how much of it was replacement rather than growth.Replacement hiring behaves differently from growth hiring. It is unplanned, urgent and usually a symptom of something else. A function built entirely for growth handles it badly.

Almost every function I have seen is organised for the hiring it wishes it did rather than the hiring it does. Two hundred customer support roles a year and eleven engineering roles is a different organisation from the reverse, even at identical headcount.

3. Fix intake before sourcing

The intake conversation (what the role is, why it exists, what good looks like, what the process will be, what the manager has to do and by when) is the single highest-leverage thirty minutes in the whole process, and it is the first thing to be skipped when the team is busy.

Fixing sourcing before intake produces more candidates for a role nobody has agreed on. That is not progress; it is a larger version of the same argument, held later, with more people in it.

Make intake a required, documented step with a named output. If a manager will not do it, that is useful information about whether the role is real.

4. Now design the structure

Only here. And the choice is narrower than it looks: you are picking how much you specialise.

A generalist model, where one recruiter runs the whole process for a set of managers, is more resilient, easier to staff, and better where volumes are low or unpredictable. A specialised model, splitting sourcing from process management, is more efficient at volume and much more fragile: it needs coordination that has to be designed, staffed and maintained, and every handover is a place where candidates go quiet.

The mistake is choosing the specialised model because it looks like what large functions have, without staffing the coordination it silently depends on. Large functions have that coordination. It is just not on the chart.

5. Tooling last

An ATS will faithfully encode whatever process you have. If the process is unresolved, you are paying a vendor to make the confusion permanent and much harder to change.

The exception is anything you need for a legal obligation. That part is not optional and does not wait for the rest.

The test

Six months in, ask a hiring manager who has just closed a role two questions: what did you have to do, and when did you know what was happening? If they can answer both without checking their email, the function is working, whatever the chart looks like.

---

What I would not do again: publish a target operating model before step two. It commits you in public to a structure you have not yet earned the right to choose, and every subsequent piece of evidence gets read as a threat to the plan rather than as information.