Human Resource Management (HRM)

What work does the HR function actually own?

Five areas, in most organisations. Getting people in, which covers workforce planning, the hiring process and everything that happens before a start date. Paying them, which covers pay structures, benefits and the statutory obligations attached to employment. Developing them, which covers capability, progression and succession. Governing the relationship, which covers policy, conduct, grievance, restructuring and exit. And holding the record, which covers the data every one of the other four depends on. Different organisations draw the boundaries differently, and some of the work sits elsewhere entirely: payroll often reports into finance, and learning sometimes sits with the operating units. The function is defined by which of these accountabilities it holds and answers for, not by which tasks its team happens to perform in a given week.

What does HRM mean, and how is it different from personnel management?

HRM is the abbreviation for human resource management, used for both the function itself and the body of practice it draws on. The older term, personnel management, described the administrative half of the same work: contracts, records, pay and attendance. The broader label came into use as the field took on responsibility for how an organisation acquires and builds capability rather than only for processing the paperwork employment generates. The change of name is not decoration. It marks a change in what the function is asked to answer for, from whether the records are correct to whether the organisation has the people it needs and is treating them in a way it could defend. Plenty of teams still called HR do only the first, and the label alone tells you nothing about which.

Who does the HR function report to, and why does that matter?

Usually the chief executive, sometimes a chief operating or finance officer, and occasionally nobody senior at all in a company that has not yet decided the function is a leadership seat. The reporting line matters because it decides which conversations HR is present for. A function reporting into finance tends to be asked about cost and head count, and to be brought in once decisions about structure have been taken. A function reporting to the chief executive is more likely to be in the room while those decisions are being formed, which is the only point at which advice on structure, pay or restructuring can change an outcome rather than tidy up after one. Neither line is automatically right, but it is worth knowing which one an organisation has chosen and what it costs.

Why is the HR function not the same thing as HR software?

Because they answer different questions. The function decides what the organisation rewards, how much discretion managers hold, which risks it will carry and which it will not, and what it will say to somebody whose role is being removed. Software records those decisions and executes the transactions that follow from them. A system can calculate a pay run, hold a leave balance and route an approval; it cannot choose the pay policy, set the approval thresholds, or judge whether a case has been handled fairly. Buyers who treat a purchase as the answer to a functional problem tend to encode an unsettled argument into a workflow, where it becomes harder to see and harder to revisit than it was as an open disagreement. The order that works is to settle the policy question first, then choose a system capable of expressing the answer.

The distinction also decides who is accountable when something goes wrong. If a manager says the system would not let them do something, the honest question is whether that constraint was a deliberate policy choice or an accident of configuration nobody reviewed. Both happen. A function that understands its own decisions can answer that question; one that has delegated its thinking to a vendor's defaults usually cannot, and finds out what its policy is by reading a screen. That is also why the two should be reviewed on different cycles. Software is replaced when it stops fitting; policy should be revisited when the organisation changes shape, which happens more often and rarely coincides with a renewal date. A workable rule of thumb: if removing the software would leave nobody able to state the rule, the function never wrote the rule down. See what an HRMS actually does for the system side of that boundary.

How is HR work divided as an organisation grows?

It starts undivided. In a small company one person, often not a specialist, holds all of it: contracts, pay questions, the hiring process, whatever policy exists. That works because volume is low and one person can hold the whole picture in their head. It stops working at the point where transactional load crowds out everything requiring judgement, which arrives well before anyone plans for it. The first split is usually between running the operation and improving it, because the operation always wins a contest for attention and improvement work quietly never starts. What triggers the change is rarely a head count figure, and treating it as one produces a structure sized for a company that does not exist yet. The better signal is which work has been deferred for a full quarter without anyone deciding to defer it.

The mature shape is commonly described in three parts. Specialist groups design the programmes, in reward, talent, learning or employee relations, and own the thinking in their area. A service or operations team runs the transactions at volume and answers routine queries. Embedded practitioners advise a particular business unit's leaders while decisions are being made, a role covered in more detail under the business partner. The model is widely copied and often copied badly. It fails when the service layer is under-resourced, because unanswered queries flow straight back to the advisers it was supposed to free; and it fails when specialists design programmes the operating teams were never asked whether they could run. The split is a division of accountability, not a set of job titles to adopt because larger organisations have them.

What does the HR function own that cannot be delegated?

The decisions, and the ability to justify them afterwards. An outside provider can run a payroll, administer benefits, screen applicants or handle the first line of employee queries, and many organisations sensibly buy some of that. What does not transfer is the choice of what the organisation pays for, what it tolerates, how it treats people when things go wrong, and whether it can explain any of that to an employee, a regulator or a court. Providers work to a specification. If the specification is wrong, the work is performed efficiently and is still wrong, and the organisation carries the consequence rather than the provider. That is true whether the provider is an outsourcer or a piece of configured software following rules somebody set once and forgot.

This has a practical consequence for how outsourcing is scoped. Before handing anything over, the function should be able to state the rule the provider will apply, the cases it expects the provider to escalate rather than decide, and who inside the organisation reads what comes back. Arrangements that skip this are usually discovered later through a pattern nobody was watching: a category of query answered consistently in a way the organisation would not have chosen, or a decision taken at the wrong level because nobody defined the level. None of that is an argument against outsourcing. It is an argument for retaining the judgement while contracting out the execution, which is a different thing from retaining a contract manager who reads a service report once a month.

How do you tell whether an HR function is working?

Not by activity. The volume of cases handled, policies published or sessions delivered describes effort, and a function can be extremely busy while the organisation gets worse at hiring, keeps losing the same roles and settles the same dispute repeatedly. The signals worth watching are about outcomes the function influences: whether roles that matter are filled and stay filled, whether managers make pay and structure decisions the organisation would defend, whether people leave for reasons that were visible in advance, and whether the same category of problem recurs. Some of that is measurable and some is only assessable by talking to the managers concerned, which is slower and considerably more informative than a dashboard.

Two cautions. First, most of these outcomes are shared with the line, so attributing them to HR alone produces argument rather than improvement; they read better as a joint measure that prompts a conversation about which part of the system is failing. Second, a function judged purely on service metrics will optimise for those metrics, closing queries quickly and referring the difficult ones elsewhere, which looks like improvement and is not. The more revealing question is whether managers consult the function before making a decision or after making it. A function that hears about a restructure once it has been announced is being used as an administrator, whatever the reporting line on the chart says about it.