The Ulrich Model

The Ulrich model is an argument about how the HR function should be organised. It is the reason your customer has a person called an “HR Business Partner”, a separate team called “Comp & Ben”, and a shared inbox where payroll questions go. If you have wondered why an HR department is split up the way it is, this is the answer, and it is roughly thirty years old.

You need it for two reasons. It tells you what the job titles in front of you actually mean, and it tells you which of those people will ever open our software.

What HR looked like before it#

One department, undifferentiated, usually called Personnel. The same team wrote the employment contracts, ran the payroll, handled a grievance between two engineers, filed the statutory reports, and was asked once a year what the headcount plan should be.

Because transactional work has deadlines and strategic work does not, the transactional work won every time. Payroll runs on the 24th whether or not anyone has thought about why the sales team keeps losing people. So Personnel was judged on paperwork, priced as overhead, and left out of decisions about the business it served. That is the problem Ulrich set out to solve.

What Ulrich actually argued#

In Human Resource Champions (1997), Dave Ulrich argued that HR should be defined by the outcomes it delivers rather than the activities it performs, and that those outcomes fall into four distinct roles. He laid them on two axes: whether the work is about the future or about day-to-day operations, and whether it acts on processes or on people.

Ulrich's original four roles. The point of the axes is that these are different jobs with different clocks, and one team measured on the bottom row never gets to the top one.

Strategic partner. Aligning HR practice with where the business is going: workforce planning, the cost of a hiring plan, which capability is missing.
Change agent. Making change actually land in people: restructures, new ways of working, culture.
Administrative expert. Running the transactional machine efficiently and correctly: payroll, records, contracts, statutory filing.
Employee champion. Representing the employee’s interests and handling what happens to individuals.

The claim underneath all four is the one worth carrying: HR should be judged on what it delivers to the business, not on how busy it is. Everything else is downstream of that.

The three-legged structure the industry built from it#

Ulrich described roles. Organisations wanted an org chart, and what they built is the three-legged stool: business partners, centres of excellence, and shared services. Most people saying “the Ulrich model” today mean this structure rather than the four roles, and the two are routinely conflated. Ulrich himself has been critical of how the structure got implemented.

The logic of the split is that the roles have incompatible economics, so they are separated into three groups and each is judged on its own terms.

Business partners#

An HR Business Partner, universally shortened to HRBP, is embedded in one business unit and reports into HR. Their job is to understand what is happening in that unit and decide what it needs: who is at risk of leaving, whether a team is structured wrongly, what a restructure will cost. They diagnose, they advise the manager, and they pull in whichever specialist is needed.

Crucially, the HRBP does not process anything. That is the whole point of the role: the manager gets one person who knows their context, instead of a directory of departments.

Centres of excellence#

A CoE owns one subject across the entire company. The usual set is compensation and benefits, talent acquisition, learning and development, and employee relations. They hold the deep expertise: the person who knows job grading, or the current regulation, or how to design a bonus scheme that will not backfire.

Because a CoE sees the same problem in every unit, it designs the answer once, writes the policy, and hands it to the business partners to apply. A CoE that spends its time on individual cases has stopped being a CoE.

Shared services#

Shared services, often called HR Ops or HRSS, runs the transactions for everybody: payroll, contract letters, leave balances, employment verification letters, onboarding paperwork, the HR helpdesk. It is usually tiered like IT support: a self-service portal, then a general helpdesk, then a specialist for the hard cases.

Here judgement is the enemy. The value of shared services is that the same input produces the same output every time, at a cost per transaction low enough that nobody thinks about it. This is where payroll lives, and therefore where our product lives.

One way to hold all of it#

Those three legs map onto something you already know from the other side, which makes the structure easy to reason about once you have the definitions above.

Your GP knows your history, asks what changed, and decides what you need. She does not run your blood test. That goes to a lab which will run the same test three hundred times today and hand back a number. The specialist she refers you to has never met you but has seen your condition in four hundred other people, and knows which treatment holds up.

The business partner is the GP. The centre of excellence is the specialist. Shared services is the lab. Three jobs, one patient, and the patient only ever spoke to one of them.

One door. The manager never chooses between a centre of excellence and shared services, and never needs to know which of the two produced the answer.

Why the split exists at all#

The reason is not tidiness. It is that the jobs have opposite economics.

The business partner’s value comes from knowing one context deeply, which caps how many units one person can cover. Shared services’ value comes from not knowing the context at all, which is precisely what lets it process three hundred payslips without slowing down. Put both jobs in one person and you do not get a flexible generalist. You get someone permanently behind on transactions who has stopped asking the manager what changed, because the payroll deadline is real and the conversation is not.

Same unit, same people, same four requests. The only thing that changed is whether the transactions sit with the partner, and the queue is the whole argument for the split.

The four ways it breaks#

Each of these is visible from outside, which makes them worth spotting on a sales call or in the first week of an implementation.

The partner is doing transactions. Your HRBP contact answers payroll questions, chases missing timesheets, and reissues contract letters. They will tell you they have no time for anything strategic, and they are right. This is the most common failure in the market and the one we sell against.

Operations is setting policy. Nobody wrote a rule, so payroll decided one by repetition. The tell is that the answer to “why is it done this way” is “it has always been done this way”, and nothing is written down. Every rule lives in one person’s head, and that person takes leave in December.

The centre of excellence is doing case work. The compensation lead personally handles individual salary queries. Nothing is designed once, so everything gets decided twice.

There is no partner at all. Managers go to whoever answers. Below a few hundred employees this is not a failure, it is just the size, and it matters more to us than the other three.

Which one are you talking to?#

Titles vary and you will often not be told one. Listen to the nouns instead.

The business partner names people. “Budi’s team lost two engineers and the third is wobbling.”
The centre of excellence names policies. “Our probation terms do not match the new regulation.”
Shared services names volumes and deadlines. “Four hundred payslips, cut-off on the 20th, bank file out on the 24th.”

When it goes wrong: someone uses all three registers in one conversation. That is not confusion. It is the case below, and it changes what you should show them.

When all three are one person#

The model describes a large organisation. Most of our customers are one person doing all of it.

Below a few hundred employees there is a single HR manager who is the partner in the morning, the specialist when a regulation changes, and the operator on the 24th. Ulrich’s separation is not wrong at that size, it is simply unaffordable, and pretending otherwise is how enterprise HR software becomes unusable for a business with forty staff.

The same three jobs, and all three still have to be done. The only difference is that one person does them and switches between them several times before lunch.

Why this matters to our strategy#

Our bet is that this market is won by being trusted enough not to be re-checked, not by covering more regulations than anyone else. The Ulrich model is where that bet meets reality, because it tells you exactly who is doing the re-checking and why.

The person opening a spreadsheet to verify our numbers is in shared services, on a deadline, with no centre of excellence to ask and no business partner to escalate to. They re-check because being wrong lands on them personally and there is nobody else in the building who could catch it. That is not a habit we can argue them out of. It is a rational response to being the only person in the chain.

So the thing that retires the spreadsheet is not another compliance feature. It is a payroll run that explains itself well enough that a single tired operator can defend every number to a director who never opens the product. Everything on our roadmap should be read against that.

What this means for what we build#

Payroll is a shared services product. The person in front of our payroll screens on the 24th is running a process against a deadline, not exercising judgement. Everything follows: the same input must produce the same output, exceptions must be pushed in front of them rather than waiting to be found, and nothing may demand a policy decision at the moment of running. Asking operations to set policy is one of the four failures above, and a screen can cause it.

Reporting is a leadership product. Whoever signs the contract usually never opens the payroll screen. They want the total, the headcount, and whether anything is on fire. Build it as its own surface, not as a summary bolted onto an operational page.

Settings are a centre-of-excellence product, and in a company of forty the centre of excellence is the same tired person, in a hurry, in the wrong month. Every setting needs a sane default and a plain explanation of what it changes, because there is nobody down the corridor to ask.

Before designing any screen, answer one question: is the person in front of it the partner, the specialist, or the operator.

Domain Standards & Learning Map lists this among the foundations everyone should hold, with a competence test attached.
Roles & Access is how these jobs map onto permissions in the product.
User Journeys walks each of them through a real week.