PeopleOps

PeopleOps (people operations) is the discipline of running everything that happens to a person at work, from offer to exit, as a dependable operation: one trusted record of who works here, in which role, for whom and at what pay; documented processes that change that record; services that answer people’s questions on time; and measurements that show whether the whole system treats people well and fairly.

Every hire, promotion, move, pay change and exit changes data that payroll, IT, finance, managers and the law depend on. PeopleOps makes those events happen correctly, on time, once, and with evidence: a new hire has a laptop and accounts on day one, a leaver loses access the moment they leave, pay decisions can be explained, and leaders can trust the headcount number.

Written for beginners, People Ops practitioners, HRIS analysts and engineers integrating HR data, and leaders deciding how to organise the function. Sources were last verified on 2026-10-16.

Mostly, yes. “People Operations” is a name, not a standard: the CIPD says its Profession Map “sets the international standard for our profession”, meaning the people profession,^[1] and ISO/TC 260 publishes its standards under the title “Human resource management”.^[2]

The label is most closely associated with Google. Laszlo Bock was Google’s Senior Vice President of People Operations until 2016,^[3] and his publisher calls him the “head of People Operations”.^[4] Secondary accounts say he was hired into that role in 2006;^[5] no primary source opened here dates the renaming, so treat “2006” as reported and “Google coined it” as unproven: Google is the best-known adopter, not a documented inventor.

The label is used in three ways; ask which one a speaker means:

1. A new name for the whole HR function: recruiting, employee relations, pay, policy, everything.
2. The operations team inside a larger People function, running the system of record, lifecycle transactions, HR service delivery and people data next to business partners and specialists. In GitLab’s public handbook, for example, People Operations owns the onboarding template and runs offboarding cases.^[6][7]
3. A philosophy: HR run with the habits of an operations team (data, documented processes, self-service, service levels). Google says its People Analytics team was founded so that “all people decisions and strategy are informed by data”.^[8]

What changes when an organisation adopts PeopleOps, rather than only renaming HR, is observable: one effective-dated system of record with an owner for every attribute; events, not emails, so a hire or termination entered once drives payroll, identity and equipment; written service levels (“access removed within one hour of termination”); self-service documentation; programmes tested against data; and privacy by design. If none of these change, the rename is cosmetic.

• Not identity management. PeopleOps decides that someone joins, moves or leaves; identity teams change the accounts (IdentityOps, AccessOps).
• Not surveillance. Keystroke and individual commit counts are not people analytics; DevExOps measures engineering systems, not individuals.
• Not legal counsel. PeopleOps applies law through policy and process; advice comes from lawyers (LegalOps).
• Not culture by decree. Leaders and managers shape culture; PeopleOps measures it and supports it with processes.
• Not only administration. A team that only processes forms leaves the expensive problems (bad hires, unfair pay, avoidable attrition) alone.

Every organisation already “does HR”; the question is whether the work is reliable. The “before” column is a composite of common failure patterns, not a report about a company.

The cost of not doing this work lands on security (NIST treats personnel termination as a security control: disable access within an organisation-defined period, revoke credentials^[9]); legal deadlines that run on the HR calendar (US Form I-9 Section 2 within three business days of the first day of employment;^[10] UK right-to-work checks before employment starts^[11]); money and fairness (payroll errors, unexplained pay gaps, growing reporting duties); and people (Google found that teams with highly effective managers were more likely to achieve better results, be happier and experience lower turnover,^[12] one company’s finding about itself).

• Worker: anyone working for the organisation; the worker type says employee, contractor or intern.
• System of record (SoR); HRIS / HCM: the system whose value wins for an attribute; the HR information system or suite, usually the SoR for job, manager and pay.
• Effective dating: history is kept and each change carries its effective date (entered 20 March, effective 1 April).
• Position, job, grade: a seat in the organisation; a role definition; a group of jobs of similar value for pay.
• Joiner–mover–leaver (JML): hire, internal move and exit; “birthright” access is what every joiner in a role gets automatically.
• Pay range (band); range spread: minimum, midpoint and maximum pay for a grade (G4: 60,000–75,000–90,000); spread = (maximum − minimum) ÷ minimum, here 50%^[13].
• Compa-ratio; range penetration: pay ÷ range midpoint^[14] (70,000 ÷ 75,000 = 0.93); position between minimum (0%) and maximum (100%), here 33%.
• eNPS: % promoters (9–10) − % detractors (0–6) on “recommend as a place to work”, adapted from customer NPS^[15][16].
• Minimum reporting group: for example, five respondents^[17].
• People Partner, CoE, shared services: a generalist for a business area; a specialist centre of expertise; a central hub for administrative HR work^[18].
• PEO; EOR: professional employer organisation, a co-employment payroll and tax provider (the US runs a voluntary certification programme)^[19]; employer of record, which legally employs your worker where you have no entity.
• DSAR: data subject access request.
• Adverse-impact screen: each group’s selection rate ÷ the highest group’s rate (15% ÷ 25% = 0.60), often checked against the US “four-fifths” (0.80) rule of thumb.
• Reduction in force (RIF): several dismissals for reasons unrelated to the individuals (layoffs, collective redundancy).

Hold three pictures at once:

1. A ledger. The system of record is an append-only, effective-dated history of facts about workers and positions; you can always answer “what was true on 1 March?”.
2. A state machine. Each person moves through states (candidate to alumni); every transition has a trigger, an owner, checks and downstream effects. Bugs live in transitions nobody owns.
3. A service desk. Employees and managers are customers with a service catalogue, intake forms, owners and service levels.

Most PeopleOps failures are one of these pictures breaking: the ledger is wrong (bad data), a transition misfires (an orphan account, a missed payroll change), or the desk is a black box (nobody knows who answers what).

Only milestones traceable to sources are listed; this is not a history of human resource management.

• 1978: US agencies adopt the Uniform Guidelines on Employee Selection Procedures and their “four-fifths” screen,^[20] making selection something to measure for fairness.
• 2000s–2016: Google runs HR as People Operations, with people analytics, under Laszlo Bock;^[5][3] the name and the data-first habit spread through technology companies.
• 2015: SCIM 2.0 (RFC 7643, RFC 7644) gives HR attributes a standard path into identity systems.^[21][22]
• 2018, 2025: ISO 30414 on human capital reporting is published, then revised.^[23]
• 2018–2027: the GDPR,^[24] California’s CCPA for employee data,^[25] New York City’s hiring-tool law,^[26] the EU AI Act, the Pay Transparency Directive and India’s Digital Personal Data Protection (DPDP) Rules^[27][28][29] make employee privacy, algorithms and pay externally accountable (dates in the regulatory map).

PeopleOps sits in a web of hand-offs. The figure shows what crosses each boundary; the table names the owners.

%%{init: {"flowchart": {"wrappingWidth": 112, "nodeSpacing": 12, "rankSpacing": 18, "padding": 8}}}%%
flowchart LR
  BZ["BizOps: headcount plan in, hiring data out"]
  PV["PrivacyOps: privacy rules, DSAR process"]
  AC["AccessOps: review results after moves"]
  DX["DevExOps: aggregate signals only"]
  SP["SupportOps, ITOps: service-desk patterns"]
  P["PeopleOps"]
  ID["IdentityOps: JML events out, account status back"]
  ED["EduOps: enrolments out, completions back"]
  LG["LegalOps: employment questions"]
  CO["ComplianceOps: control evidence"]
  BZ <--> P
  PV --> P
  AC --> P
  DX -.-> P
  SP --> P
  P <--> ID
  P <--> ED
  P --> LG
  P --> CO
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class P core
  class ID,AC,BZ,LG,PV,CO,ED,DX,SP neutral

No official PeopleOps manifesto exists. The charter below is this Atlas’s proposal for a team to adopt, edit and sign; its numbers are examples, not benchmarks. Mission: make every moment of working here, from offer to exit, correct, timely, fair and humane, with people data the organisation can trust.

1. One record, many consumers: one system of record and one owner per attribute; other systems subscribe, never re-key.
2. Effective-dated truth: every change has an effective date, author and reason; history is never overwritten.
3. Transitions are controls: joining, moving and leaving are security, payroll and legal events with owners and evidence.
4. Services have service levels, written down and measured.
5. Measure systems, protect individuals: analytics answer group questions; individual decisions follow fair, documented processes with a right to be heard.
6. Minimum necessary data: a stated purpose and recorded lawful basis, restricted sensitive fields, deletion on schedule.
7. Write it down where employees can read it, and adopt on evidence: check that a practice worked.

Measurable goals (examples). Day-one readiness ≥ 95%; access disabled within one hour of termination for ≥ 99% of leavers; zero overdue statutory deadlines; every flagged pay gap explained or fixed (the scorecard tracks them).

Non-goals. Tracking individual activity, owning strategy or headcount budgets, or replacing managers’ responsibility for their teams; counsel confirms legal requirements per jurisdiction.

Invariants. Whatever the tools: nobody is active in payroll and terminated in HR (or the reverse) for longer than the reconciliation interval; nobody sees pay, health, diversity or investigation data without a role that needs it; every termination has an effective date and time before access is removed; and no report lets an individual’s answers be inferred.

Six layers, each depending on the one below:

Three technical ideas carry most of the weight:

• Stable identifiers. Key every record on an immutable worker ID, never on email or name; emails change at marriage, rehire and rebranding.
• Effective and future dating. Entering changes before they take effect (a hire two weeks out, a termination at 17:00 next Friday) lets downstream systems prepare and act on time.
• Attribute ownership. For every attribute, decide which system wins: the HRIS might own legal name, job, manager and cost centre; the identity provider username and email; payroll tax setup. Microsoft’s documentation of HR-driven provisioning calls the HR system “the source of authority” for new identities, with changes flowing to accounts and terminations disabling them.^[30]

How the team is organised as it grows (editorial heuristics, not benchmarks; thresholds vary with countries, unions and complexity)

The shared-services, partner and expertise split (glossary) is a common pattern, not a requirement.

RACI for the core lifecycle

R = responsible, A = accountable, C = consulted, I = informed. One A per row.

The lifecycle is the spine of PeopleOps. The diagram shows the states a worker record passes through and the events that move it; the first state usually lives in the applicant tracking system (ATS) before any HR record exists.

stateDiagram-v2
  state "Candidate (ATS record)" as Candidate
  state "Pre-hire" as PreHire
  state "Not hired" as NotHired
  state "Active (moves stay Active)" as Active
  state "On leave" as OnLeave
  [*] --> Candidate
  Candidate --> PreHire: offer accepted
  Candidate --> NotHired: rejected
  PreHire --> NotHired: no-show
  PreHire --> Active: start date
  Active --> OnLeave: leave
  OnLeave --> Active: return
  Active --> Notice: resign, dismiss
  OnLeave --> Notice: separation
  Notice --> Terminated: effective time
  Active --> Terminated: summary exit
  Terminated --> Alumni: retention
  Alumni --> PreHire: rehire
  Alumni --> [*]: deleted

Every arrow needs an owner and a list of downstream effects, and the risky arrows are the forgotten ones: no-shows (accounts already created), separations during leave, rehires (old access reactivated) and moves (access accumulates).

Day 0, 1 and 2 for the function itself: design (operating model, attribute ownership, job architecture, legal obligations per country), go-live (migration with reconciliation, integrations, parallel payroll) and run (queues, reconciliation, audits, the annual calendar); the 30/60/90-day roadmap sequences it.

Service delivery tiers

Tiers answer simple questions fast and send complex or sensitive ones to the right expert; the exact split is yours to design, and the service catalogue says which tier owns each request.

%%{init: {"flowchart": {"wrappingWidth": 112, "nodeSpacing": 20, "rankSpacing": 30}}}%%
flowchart TB
  E["Employee or manager: question or request"]
  T0["Tier 0: self-service portal and knowledge base"]
  T1["Tier 1: PeopleOps service desk, cases with SLAs"]
  T2["Tier 2: specialists (payroll, benefits, reward, HRIS, mobility)"]
  T3["Tier 3: policy owners, counsel, CoE leads"]
  ER["Confidential channel for employee relations"]
  PP["People Partner for the area"]
  E --> T0
  T0 -->|"not resolved"| T1
  T1 -->|"specialist"| T2
  T2 -->|"policy or legal"| T3
  E -->|"`grievance, harassment, health`"| ER
  ER --> PP
  T2 -.->|"articles"| T0
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class T0,T1,T2,T3 core
  class ER risk
  class E,PP neutral

The critical design choice is the confidential bypass: a grievance must never sit in a queue many people can read.

Governance, cadences and controls

Three controls are worth adopting from day one: change control for HRIS configuration (one click on a security group can expose everyone’s pay); a policy lifecycle (owner, review date, versions, plain-language summary); and role-based, logged access to HR data, with analysts on pseudonymised extracts unless identity is necessary.

People data flows from hiring into a system of record and out to every system that needs to know who works here (a vendor-neutral, logical view).

%%{init: {"flowchart": {"wrappingWidth": 112, "nodeSpacing": 18, "rankSpacing": 30}}}%%
flowchart TB
  PLAN["Headcount plan"] --> HRIS
  ATS["Applicant tracking"] -->|"accepted offer"| HRIS
  HRIS["HRIS or HCM: effective-dated record, audit log"]
  HRIS --> EVT["Integration layer: events and APIs, also to IT assets, learning, cases"]
  HRIS -->|"`minimised extract`"| WH["Analytics store and dashboards (restricted: pseudonymised, minimum group sizes)"]
  EVT --> PAY["Payroll and finance"]
  EVT --> IDP["Identity provider, then SaaS apps via SCIM"]
  PAY --> REC["Daily reconciliation; exceptions go back to the HRIS"]
  IDP --> REC
  REC -.-> HRIS
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class HRIS,EVT core
  class WH risk
  class ATS,PLAN,PAY,IDP,REC neutral

Integration patterns and trade-offs

Choosing between a suite, best-of-breed tools and provider bundles is covered in the decision framework. Design rules that prevent most integration incidents:

1. Build the three fundamentals into every mapping: the immutable worker ID as the key (email only as an attribute), future-dated events that consumers schedule for the effective time, and the attribute-ownership matrix.
2. Make terminations the highest-priority event type, with alerting if delivery fails.
3. Reconcile daily: “terminated in HR but active in identity” must be an alert, not a report.
4. Treat rehires explicitly: reactivate the old identity with no previous access, or create a new one by policy.

%%{init: {"sequence": {"wrap": false, "width": 100, "actorMargin": 30, "messageMargin": 22, "noteMargin": 8, "boxMargin": 6, "diagramMarginX": 6, "diagramMarginY": 6}}}%%
sequenceDiagram
  participant IT as IT, identity
  participant HR as PeopleOps
  participant M as Manager
  Note over IT,M: Recruiting: offer accepted, start in 15 days
  Note over HR: Pre-hire record,<br>worker ID
  HR->>IT: Prepare disabled<br>account, device
  HR->>M: Day-one plan<br>reminder
  rect rgb(232, 243, 242)
    Note over IT,M: Happy path: all checks complete
    HR->>IT: Enable account<br>at start
    Note over HR: Payroll and<br>benefits active
    M->>HR: Day-one ready
  end
  rect rgb(251, 236, 235)
    Note over IT,M: Exception: a check is delayed or fails
    Note over HR: Move the date<br>or rescind
    HR->>IT: Hold account<br>and device
    HR->>M: New date or<br>cancellation
  end

GitLab opens each onboarding issue at least four days before the hire date, with common tasks due within 30 days;^[6] Google measures the result with surveys at 30, 90 and 365 days (Scenario 2 in use cases).

Moves are where access accumulates and payroll goes wrong. A mover workflow should:

1. Record the change once, effective-dated (job, manager, location, cost centre, pay), and check pay against the new range.
2. Notify identity so birthright access changes, and review everything else; NIST’s PS-5 control asks organisations to confirm ongoing need for access when people are reassigned.^[9]
3. Update the manager everywhere, because approvals follow the manager attribute.
4. For cross-border moves, start the country checklist (tax, work authorisation, contract) before the effective date.

%%{init: {"flowchart": {"wrappingWidth": 130, "nodeSpacing": 22, "rankSpacing": 30}}}%%
flowchart TD
  A["Resignation or dismissal decision"] --> B{{"Termination entered with date and time before the effective moment?"}}
  B -->|"yes"| C["Future-dated termination event published"]
  C --> D["At effective time: identity disables account; sessions and tokens revoked"]
  D --> E["Property return, final pay per jurisdiction, exit survey, handover"]
  E --> H["Record moves to alumni; retention clock starts"]
  B -->|"`no: entered late or not at all`"| X["Account stays active after departure"]
  X --> R["Daily reconciliation flags it: terminated in HR, active in identity"]
  R --> S["Emergency disablement and access review"]
  S --> T["Root cause logged, process fixed"]
  T --> E
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class C,D,E,H core
  class X,R,S,T risk
  class B decision

NIST leaves the time limit for disabling access to each organisation,^[9] so set yours by risk (this page’s examples use one hour); Scenario 1 in use cases shows one company’s published windows. For involuntary exits, pre-enter the termination with restricted visibility and an effective time matching the meeting, so access goes as the conversation happens (Artefact 5).

Beyond joiner, mover and leaver handling: the workloads near the law, then playbooks for onboarding, performance, pay, listening, data quality and reductions in force. The learning programme (needs, budget, mandatory training) is PeopleOps work; course delivery is EduOps.

Three workloads sit close to the law; this page covers the operating work and the hand-off to counsel (LegalOps), not the legal tests.

• Worker classification: record a worker type and rationale at intake and review it when the work changes. Status is decided by legal tests that differ by country and between employment and tax law (for example GOV.UK;^[32] the US IRS^[33]).
• Leave and workplace adjustments: entitlements per country and contract, return-to-work plans and payroll inputs, with health data in restricted fields.
• Employee-relations investigations: confidential intake, a named investigator, restricted records. A fair process, as in the UK Acas Code (being updated as of October 2026), establishes the facts, hears the employee before a decision, allows accompaniment, offers an appeal and, where practicable, separates investigator and decision-maker in misconduct cases.^[34]

Talya Bauer’s SHRM Foundation guide names four building blocks, and calls organisations Passive, High Potential or Proactive by how far beyond the first one they go.^[35] Use them as a checklist:

1. Compliance (legal and policy rules): contracts, statutory forms on time, policy acknowledgements, equipment and access. Automate it; it is necessary, not sufficient.
2. Clarification (the job and its expectations): a written 30/60/90-day plan from the manager by day three.
3. Culture (formal and informal norms): how decisions are made and work is documented; the team’s behaviour matters more than the handbook.
4. Connection (relationships and information networks): a named buddy, introductions, a joiner cohort.

The evidence is more modest than the practice built on it. The CIPD’s evidence review, based on rapid evidence assessments by the Center for Evidence-Based Management,^[36] found that specific, challenging goals work for straightforward tasks but less for complex ones, that feedback is crucial for goal setting, and that appraisal generally helps performance but “by no means always”; it recommends separating developmental conversations from administrative ones (pay and promotion) and stresses perceived fairness.^[31] Design rules that follow:

• Decide each conversation’s purpose; mixing development, pay and under-performance makes every conversation defensive.
• Keep goals and evaluation separate. Google’s guide states that “OKRs are not synonymous with performance evaluation” and targets a 0.6–0.7 average for ambitious goals;^[37] pay people for hitting OKRs and they will set easy ones.
• Calibrate where ratings drive money, and compare rating and promotion distributions across groups where numbers allow.
• Train managers. Google’s Project Oxygen drew on more than 10,000 data points from reviews and feedback surveys, plus interviews, to define ten behaviours of effective managers, such as coaching and empowering without micromanaging.^[12]

Pay governance turns individual negotiations into a system that can be explained to employees, auditors and regulators.

%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 20, "rankSpacing": 30}}}%%
flowchart TB
  JA["Job architecture: families, levels, grades"] --> MK["Market data matched to jobs"]
  MK --> RG["Pay ranges: minimum, midpoint, maximum"]
  RG --> OF["Offers within range; exceptions approved"]
  RG --> MV["Moves priced against the new range"]
  OF --> CY["Pay review cycle with budget and guidelines"]
  MV --> CY
  CY --> SC{{"Screens: out of range, compa-ratio by group, pay gaps"}}
  SC -->|"explained"| DOC["Document the legitimate factors"]
  SC -->|"unexplained"| FIX["Adjust pay and fix the cause"]
  DOC --> RP["Reporting where law requires it"]
  FIX --> RP
  RP -.->|"next cycle"| JA
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class JA,MK,RG,OF,MV,CY,DOC,RP core
  class SC decision
  class FIX risk

Keep definitions written and stable (range spread and compa-ratio are in the glossary). The midpoint differential is the gap between adjacent grade midpoints as a percentage of the lower one; broadbands typically span 100% or more from minimum to maximum.^[13] If your compa-ratio uses a reference point other than the midpoint, such as a market rate, say so.

EU pay transparency. The Directive requires pay information before employment, bans salary-history questions and gives workers a right to request average pay levels by sex for equal work or work of equal value, through national laws due by 7 June 2026.^[28] Gap reporting is phased by employer size: 250+ workers by 7 June 2027 and yearly; 150–249 by 7 June 2027 and every three years; 100–149 by 7 June 2031 and every three years. A joint pay assessment with workers’ representatives follows when a category of workers shows a gap of at least 5% that is neither justified by objective, gender-neutral criteria nor remedied within six months.^[28] The thresholds are written per employer (“employers with 250 workers or more”) and the Directive does not mention corporate groups; national law may go further, since Member States may require employers under 100 workers to report (Art. 9(5)) and may keep rules more favourable to workers (Art. 27).^[28]

Surveys are useful only if they lead to action and protect respondents.

%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 20, "rankSpacing": 30}}}%%
flowchart TB
  Q["Questions tied to decisions; thresholds set"] --> C["Collect responses"]
  C --> G{{"Group large enough to report?"}}
  G -->|"no"| SUP["Suppress it, and a neighbour if subtraction would reveal it"]
  G -->|"yes"| A["Analyse trends, drivers, comments"]
  SUP --> A
  A --> P["Share results; teams pick one to three owned actions"]
  P --> F["Follow up in public on what changed"]
  F -.->|"next round"| Q
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class Q,C,A,P,F core
  class G decision
  class SUP risk

Confidentiality thresholds are a concrete control. Microsoft’s Viva Glint, for example, hides rated scores for groups below five respondents by default (adjustable to three), applies “suppression” so hidden scores cannot be recovered “using simple math”, and needs ten respondents before showing comments.^[17] Write yours down before launch.

eNPS borrows the customer Net Promoter method (taught in CXOps).^[15] Workday Peakon, for example, asks “How likely is it you would recommend [Company] as a place to work?” and says it follows eNPS methodology.^[16] No standards body defines eNPS, and one number hides the reasons; pair it with driver questions and comments.

Keep a data dictionary (meaning, owner, allowed values, sensitivity, retention per field); validate at entry (a manager must be an active worker, a cost centre must exist); audit samples quarterly against source documents; and fix root causes with form changes, not reminders. ISO 30435:2023 covers workforce data quality.^[2]

A reduction in force (RIF) is the riskiest leaver event PeopleOps runs: many exits at once, each with legal deadlines, a fair selection, accounts to revoke, pay to calculate and people to support, usually under confidentiality. The rows are dated orientation (checked 16 October 2026), not legal advice; plan every RIF with counsel (LegalOps).

The sequence adds the statutory clock to the involuntary-exit SOP (Artefact 5).

%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 20, "rankSpacing": 28}}}%%
flowchart TB
  D["Decision, confidential group, calendar per country"] --> POOL["Selection pool and documented criteria"]
  POOL --> SCR{{"Screen and legal review clear?"}}
  SCR -->|"no"| REV["Revise criteria or pool; record why"]
  REV --> POOL
  SCR -->|"yes"| CON["Consultation where law requires it"]
  CON -.->|"`selection changes`"| POOL
  CON --> PRE["Pay checked; terminations pre-entered with restricted visibility"]
  PRE --> EXE["Meetings held; accounts disabled at each effective time"]
  EXE --> VER{{"List, terminations and disabled accounts match?"}}
  VER -->|"no"| INC["Each mismatch handled as an incident"]
  VER -->|"yes"| SUP["Support leavers and those who stay"]
  INC --> SUP
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class D,POOL,CON,PRE,EXE,SUP core
  class SCR,VER decision
  class REV,INC risk

1. Decide and protect: scope, a small project group, no plans in shared HRIS views, calendars or notifications.
2. Build the calendar backwards from the exit dates; the latest legal deadline sets the earliest possible exit.
3. Set the pool and job-related criteria before names, then run the adverse-impact screen (Lab 4) with counsel; with small numbers, a screen starts an investigation rather than ending one.
4. Consult where required, record proposals and responses, and expect the selection to move.
5. Prepare notices and money: payroll checks notice pay, severance and final pay before letters go out.
6. Pre-enter every termination with restricted visibility and an effective time matching each meeting; give system owners the full list, including non-SSO tools.
7. Verify the same day: approved list = terminations entered = accounts disabled; every mismatch is an incident.
8. Support leavers and those who stay: outplacement, manager briefings, re-planned workloads.

Keep the selection evidence (criteria, scores, screen results, consultation records): it is what a challenge will examine. Success means every statutory deadline met, zero mismatches, no payroll errors and no avoidable rise in regretted attrition over the next two quarters.

Separate what you must do (law, contracts, collective agreements) from what you may adopt (standards, frameworks). Legal facts are dated once, in the regulatory map below; other sections link to it.

• NIST SP 800-53 PS-3, PS-4, PS-5:^[42][9] screening, termination and transfer controls; required for US federal information systems through FIPS 200 (national security systems excepted),^[43] a good model elsewhere.
• SCIM 2.0 (RFC 7643, RFC 7644):^[21][22] an optional standard for provisioning people attributes.
• ISO/TC 260 standards (voluntary):^[2] among them vocabulary (ISO 30400), recruitment (30405), cost-per-hire (TS 30407) and workforce data quality (30435); ISO 30414:2025 for human capital reporting, with 14 required baseline metrics.^[23]
• Frameworks and definitions (voluntary): the CIPD Profession Map,^[1] Bauer’s Four C’s,^[35] OKRs as documented by re:Work,^[37] BLS JOLTS turnover terms^[44] and the WorldatWork–Deloitte pay-structure glossary.^[13]

• GDPR Arts. 6, 9, 12(3), 88 (EU):^{[45][46][47][24]} lawful basis per purpose, special-category limits, one-month rights responses, national employment rules (see lawful basis).
• CCPA (California)^[25] and DPDP Act and Rules (India):^[29] employee-data rights; the CCPA since 1 January 2023; the DPDP Rules (notified 14 November 2025) phase in over 18 months and give ninety days to answer rights requests. How the Indian Act treats employment processing without consent was not verified here.
• Form I-9 (US)^[10] and right-to-work checks (UK):^[11] mandatory checks and deadlines at hire.
• Gender pay gap reporting (GB, 250+ employees)^[48][49] and Pay Transparency Directive (EU):^[28] gap reports, pay information, joint assessments; EU transposition was due 7 June 2026, first reports by 7 June 2027 (phasing in pay governance).
• AI Act (EU):^[27] employment and worker-management AI, such as CV-sorting, is classified high-risk; its obligations apply from 2 December 2027, the date set by the AI Omnibus (in force 27 July 2026). Workplace emotion recognition has been prohibited since 2 February 2025.
• Local Law 144 (New York City):^[26][50] for tools that assess candidates for hiring or promotion only, an independent bias audit within one year before use (rates and impact ratios by sex, race/ethnicity and intersectional categories), a public summary and notices; enforced since 5 July 2023; no pass mark and no required action, but anti-discrimination law applies.
• Automated-decision regulations (California):^[51] anti-discrimination law applied to automated decisions about applicants and employees, with records kept at least four years; in effect since 1 October 2025.
• Other states: Colorado’s SB26-189 (signed 14 May 2026) re-enacts its 2024 AI law as rules on automated decisions in employment and other areas, some duties from 1 January 2027;^[52] for Illinois, a law-firm alert reports AI-in-employment duties in force since 1 January 2026 and proposed notice rules withdrawn in June 2026 (statute not opened).^[53]
• Uniform Guidelines, 29 CFR 1607 (US federal):^[20] the four-fifths screen and a validation framework. Contested: still in the CFR,^[54] but a 9 June 2026 Justice Department opinion, binding on the executive branch, calls them unconstitutional and reads disparate impact narrowly;^[55] OPM dropped them from federal personnel rules on 31 July 2026;^[56] the EEOC lists rescission for November 2026.^[57] The statute’s disparate-impact provision and state laws remain. Ask counsel.
• Redundancy and layoff rules: see reductions in force.

Start with jobs, not brands. Product names are examples whose official pages or repositories were opened on 2026-10-16, not endorsements; features change.

Before you sign, test the exit: can you export full effective-dated history, attachments and audit logs in a documented format?

Automate where events are frequent, rules are clear and errors are costly: lifecycle events to identity, payroll, equipment and learning; reminders for statutory forms, probation reviews, contract ends and visa expiries; documents from approved data; reconciliation; case routing. A human decides hiring and rejection, termination, out-of-guideline pay, discipline, accommodations and investigations: automation prepares the file, a person is accountable, and the affected person is heard.

Regulation of these uses is growing and uneven (dated in the regulatory map): map every jurisdiction where candidates or workers are before you buy. A vendor’s model is still your decision process, so get its documentation, run your own adverse-impact screen and keep a human who can explain the outcome (procurement checklist in the toolkit).

Artefact 1: attribute ownership matrix

Artefact 2: a lifecycle event

Example status: syntax-checked by the Atlas validator, not executed (illustrative schema for an internal event bus).

{
  "event_type": "worker.terminated",
  "event_id": "8f0c2a7e-5d3b-4f61-9a2e-1b7c3d9e4f10",
  "occurred_at": "2026-10-12T09:14:03Z",
  "effective_at": "2026-10-16T17:00:00+01:00",
  "worker_id": "W-004211",
  "worker_type": "employee",
  "termination": {
    "category": "voluntary",
    "regretted": true,
    "last_working_day": "2026-10-16"
  },
  "changed_by": "W-000317",
  "source_system": "hris",
  "schema_version": "1.2"
}

Note what is absent: no reason narrative, health or performance data. Downstream systems need the fact and the time.

Artefact 3: a SCIM update for a mover

For a worker who moves department and manager, a SCIM PATCH with RFC 7643’s enterprise user attributes and RFC 7644’s PatchOp message.^[21][22]

Example status: syntax-checked, not executed (requires a SCIM 2.0 service provider; IDs are placeholders).

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "replace",
      "path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department",
      "value": "Payments Platform"
    },
    {
      "op": "replace",
      "path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:costCenter",
      "value": "CC-4410"
    },
    {
      "op": "replace",
      "path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager",
      "value": { "value": "2819c223-7f76-453a-919d-413861904646" }
    }
  ]
}

Artefact 4: onboarding checklist as code

Checklists in version control (GitLab uses issue templates^[6]) give history, review and reuse.

Example status: syntax-checked, not executed (a template format for a generic workflow tool).

template: onboarding
version: 3
applies_to:
  worker_types: [employee]
  countries: [all]
due_window_days: 30
tasks:
  - id: preboard-contract
    owner: peopleops
    due: "start-10d"
    description: Contract signed and stored in the HRIS
  - id: preboard-device
    owner: it-assets
    due: "start-5d"
    description: Device shipped with tracking number recorded
  - id: day1-access
    owner: identity
    due: "start"
    description: Account enabled at local start time; birthright groups assigned
  - id: day1-plan
    owner: manager
    due: "start+3d"
    description: Written 30/60/90 plan shared with the new joiner
  - id: week1-buddy
    owner: manager
    due: "start+5d"
    description: Buddy assigned and first meeting held
  - id: us-i9-section2
    owner: peopleops
    due: "start+3 business days"
    when: { country: US }
    description: Form I-9 Section 2 completed
  - id: survey-30
    owner: people-analytics
    due: "start+30d"
    description: 30-day onboarding survey sent
completion_rule: every task is either done or marked not applicable with a reason

Artefact 5: offboarding SOP (involuntary exit)

1. T−2 working days. People Partner confirms decision and timing with the manager; PeopleOps prepares the termination record with restricted visibility and an effective time matching the meeting.
2. T−1. IT and identity list the systems, including non-SSO tools, shared credentials and bots the person owns.
3. T (meeting start). Manager and People Partner hold the conversation; the termination takes effect, identity disables the account and revokes sessions, and IT locks the device if policy requires.
4. T+1 hour. PeopleOps confirms disablement in the reconciliation report; system owners confirm non-SSO removals.
5. T+1 working day. Files, repositories and shared mailboxes transferred; property return arranged.
6. Payday rules. Final pay per the contract and local law.
7. T+5 working days. Checklist closed with evidence; exceptions escalated.

Variants: voluntary exits skip the choreography and add an exit survey; death in service needs family liaison and benefits claims; a move to contractor status is a full offboarding plus a new, limited onboarding (GitLab’s documented practice^[7]).

Artefact 6: HR request intake form

Example status: syntax-checked, not executed (a form definition for a generic case-management tool).

form: employment-change-request
audience: managers
fields:
  - name: worker_id
    type: worker_lookup
    required: true
  - name: change_type
    type: choice
    options: [promotion, transfer, manager_change, location_change, hours_change]
    required: true
  - name: effective_date
    type: date
    required: true
    validation: "must be today or later; not more than 90 days ahead"
  - name: new_grade
    type: grade_lookup
    required_if: { change_type: [promotion] }
  - name: proposed_base_pay
    type: money
    visibility: [requester, total_rewards, peopleops]
    validation: "warn if outside the range for new_grade"
  - name: justification
    type: text
    required: true
routing:
  approvals: [requester_manager, people_partner]
  extra_approval_if_outside_range: total_rewards
sla:
  first_response_working_days: 1
  completion_working_days: 5

Artefact 7: HR service catalogue (extract)

Each request has one owner, a channel, a service level and a confidentiality class that decides which queue may see it. Five of ExampleCo’s rows:

Review the catalogue quarterly against case data: requests that keep arriving outside it need a row or a Tier 0 article.

Four labs on synthetic data only: Python 3.8 or later and a bash shell, standard library only, no accounts, no cost. Each lab was run on 2026-10-16 exactly as printed (Python 3.8.10, Ubuntu Linux); expected outputs are copied from those runs.

Objective. Compute headcount, hires, separations, separation rates and first-year leavers from an effective-dated event log, and understand each formula. Prerequisites. Python 3.8+. Time. 20 minutes. Risk. None (synthetic data).

1. Create a working folder and the event log.

Example status: verified by execution on 2026-10-16 (bash, Linux).

mkdir -p ~/peopleops-labs/lab1 && cd ~/peopleops-labs/lab1
cat > events.csv <<'EOF'
employee_id,event,effective_date,hire_date,reason,regretted,department
E001,hire,2026-01-05,2026-01-05,,,Engineering
E002,hire,2026-01-12,2026-01-12,,,Sales
E003,termination,2026-01-30,2024-03-01,voluntary,yes,Engineering
E004,hire,2026-02-02,2026-02-02,,,Support
E005,termination,2026-02-13,2025-11-03,voluntary,no,Sales
E006,termination,2026-02-27,2021-06-14,involuntary,no,Support
E007,transfer,2026-03-02,2023-09-04,,,Engineering
E008,hire,2026-03-09,2026-03-09,,,Engineering
E009,termination,2026-03-20,2025-08-18,voluntary,yes,Engineering
E010,termination,2026-03-31,2019-02-11,voluntary,no,Finance
EOF

2. Save the script as metrics.py.

Example status: verified by execution on 2026-10-16 (Python 3, standard library).

"""Quarterly people metrics from an effective-dated event log (standard library only)."""
import csv
from datetime import date

START_HEADCOUNT = 120          # active employees on 2026-01-01 (from the HRIS snapshot)
PERIOD_START = date(2026, 1, 1)
PERIOD_END = date(2026, 3, 31)

with open("events.csv", newline="") as f:
    events = list(csv.DictReader(f))

hires = [e for e in events if e["event"] == "hire"]
leavers = [e for e in events if e["event"] == "termination"]
voluntary = [e for e in leavers if e["reason"] == "voluntary"]
regretted = [e for e in voluntary if e["regretted"] == "yes"]

def tenure_days(e):
    return (date.fromisoformat(e["effective_date"]) - date.fromisoformat(e["hire_date"])).days

first_year = [e for e in leavers if tenure_days(e) < 365]

end_headcount = START_HEADCOUNT + len(hires) - len(leavers)
avg_headcount = (START_HEADCOUNT + end_headcount) / 2

def rate(n):
    return round(100 * n / avg_headcount, 2)

print(f"Period {PERIOD_START} to {PERIOD_END}")
print(f"Headcount start={START_HEADCOUNT} end={end_headcount} average={avg_headcount}")
print(f"Hires={len(hires)} Separations={len(leavers)} Transfers={sum(e['event'] == 'transfer' for e in events)}")
print(f"Separation rate (quarter)       = {rate(len(leavers))}%")
print(f"Voluntary separation rate       = {rate(len(voluntary))}%")
print(f"Regretted voluntary rate        = {rate(len(regretted))}%")
print(f"Leavers with < 1 year tenure    = {len(first_year)} of {len(leavers)}")
print(f"Annualised separation rate      = {round(rate(len(leavers)) * 4, 1)}% (naive x4; see caveats)")

3. Run it with python3 metrics.py.

Expected output.

Period 2026-01-01 to 2026-03-31
Headcount start=120 end=119 average=119.5
Hires=4 Separations=5 Transfers=1
Separation rate (quarter)       = 4.18%
Voluntary separation rate       = 3.35%
Regretted voluntary rate        = 1.67%
Leavers with < 1 year tenure    = 2 of 5
Annualised separation rate      = 16.7% (naive x4; see caveats)

Validation. By hand: 5 ÷ 119.5 × 100 = 4.18%, mirroring the US Bureau of Labor Statistics convention (separations ÷ employment × 100) with average headcount as a documented internal denominator. The transfer (E007) is not a separation; BLS also excludes transfers within the same location.^[44] Multiplying by four is naive when leaving is seasonal.

Troubleshooting. FileNotFoundError: run the script in the folder that contains events.csv.

Teardown. rm -rf ~/peopleops-labs/lab1

Objective. Reconcile the HR record with an identity-provider export, find terminated-but-active accounts and accounts with no HR record, and measure on-time revocation. Prerequisites. Lab 1. Time. 30 minutes. Risk. None (synthetic data).

1. Create the two exports.

Example status: verified by execution on 2026-10-16 (bash, Linux).

mkdir -p ~/peopleops-labs/lab2 && cd ~/peopleops-labs/lab2
cat > hris.csv <<'EOF'
employee_id,work_email,status,termination_effective_utc
E101,ana@example.com,active,
E102,ben@example.com,terminated,2026-10-01T17:00:00Z
E103,chen@example.com,terminated,2026-10-02T09:00:00Z
E104,dev@example.com,terminated,2026-10-05T12:00:00Z
E105,eva@example.com,active,
E106,femi@example.com,terminated,2026-10-06T16:30:00Z
EOF
cat > idp.csv <<'EOF'
email,status,disabled_at_utc
ana@example.com,active,
ben@example.com,disabled,2026-10-01T17:20:00Z
chen@example.com,disabled,2026-10-03T11:00:00Z
dev@example.com,active,
eva@example.com,active,
femi@example.com,disabled,2026-10-06T16:45:00Z
gil@example.com,active,
EOF

2. Save as reconcile.py. (It joins on email because many identity exports lack the HR worker ID; real systems should join on the immutable ID.)

Example status: verified by execution on 2026-10-16 (Python 3, standard library).

"""Compare the HR system of record with the identity provider export (standard library only)."""
import csv
from datetime import datetime, timedelta

SLA = timedelta(hours=1)   # policy: access disabled within 1 hour of termination effective time

def load(path, key):
    with open(path, newline="") as f:
        return {row[key].lower(): row for row in csv.DictReader(f)}

def ts(value):
    return datetime.fromisoformat(value.replace("Z", "+00:00"))

hris = load("hris.csv", "work_email")
idp = load("idp.csv", "email")

orphans = [e for e, r in hris.items() if r["status"] == "terminated" and idp.get(e, {}).get("status") == "active"]
unknown = [e for e in idp if e not in hris and idp[e]["status"] == "active"]
missing = [e for e, r in hris.items() if r["status"] == "active" and e not in idp]

within, breached = [], []
for e, r in hris.items():
    acct = idp.get(e)
    if r["status"] != "terminated" or not acct or not acct["disabled_at_utc"]:
        continue
    latency = ts(acct["disabled_at_utc"]) - ts(r["termination_effective_utc"])
    (within if latency <= SLA else breached).append((e, latency))

leavers = sum(r["status"] == "terminated" for r in hris.values())
print(f"Leavers in HRIS: {leavers}")
print(f"ORPHAN active accounts (terminated in HRIS, active in IdP): {orphans}")
print(f"Active IdP accounts with no HRIS record: {unknown}")
print(f"Active employees without an IdP account: {missing}")
for e, lat in breached:
    print(f"SLA BREACH {e}: disabled {lat} after termination")
print(f"Revocation within SLA: {len(within)}/{leavers} = {round(100 * len(within) / leavers)}%")

3. Run python3 reconcile.py.

Expected output.

Leavers in HRIS: 4
ORPHAN active accounts (terminated in HRIS, active in IdP): ['dev@example.com']
Active IdP accounts with no HRIS record: ['gil@example.com']
Active employees without an IdP account: []
SLA BREACH chen@example.com: disabled 1 day, 2:00:00 after termination
Revocation within SLA: 2/4 = 50%

Validation. Ben (20 minutes) and femi (15 minutes) met the one-hour policy; chen took 26 hours; dev is still active: 2 ÷ 4 = 50%. The denominator is all leavers, so the orphan counts as a failure.

Troubleshooting. ValueError: Invalid isoformat string: Python before 3.11 rejects a trailing Z, which is why the script replaces it with +00:00.

What to do next. Disable dev@example.com and follow the runbook; find an owner for gil@example.com (perhaps a contractor created outside the HR process).

Teardown. rm -rf ~/peopleops-labs/lab2

Objective. Calculate eNPS overall and by team, hide small teams, and apply complementary suppression so hidden teams cannot be recovered by subtraction. Prerequisites. Python 3.8+; Lab 1. Time. 30 minutes. Risk. None (synthetic data).

1. Create the responses (team and score only; no names).

Example status: verified by execution on 2026-10-16 (bash, Linux).

mkdir -p ~/peopleops-labs/lab3 && cd ~/peopleops-labs/lab3
printf '%s\n' "team,score" \
  Platform,8 Platform,6 Platform,9 Platform,3 Platform,9 Platform,10 Platform,7 Platform,8 Platform,9 \
  Payments,3 Payments,9 Payments,7 Payments,4 Payments,5 Payments,8 Payments,6 \
  Mobile,9 Mobile,7 Mobile,10 Mobile,9 Mobile,6 Mobile,8 \
  Data,9 Data,8 Data,3 Data,10 Data,5 Data,7 \
  Design,10 Design,2 > responses.csv

2. Save as enps.py.

Example status: verified by execution on 2026-10-16 (Python 3, standard library).

"""eNPS by team with a minimum reporting group and complementary suppression (standard library only)."""
import csv
from collections import defaultdict

MIN_GROUP = 5        # do not show a team score with fewer respondents than this
MIN_HIDDEN = 5       # hidden respondents must total at least this, or the next-smallest team is hidden too

scores = defaultdict(list)
with open("responses.csv", newline="") as f:
    for row in csv.DictReader(f):
        scores[row["team"]].append(int(row["score"]))

def enps(values):
    promoters = sum(v >= 9 for v in values)
    detractors = sum(v <= 6 for v in values)
    return round(100 * (promoters - detractors) / len(values))

everyone = [v for vs in scores.values() for v in vs]
print(f"Company: n={len(everyone)} eNPS={enps(everyone)}")

hidden = {t for t, vs in scores.items() if len(vs) < MIN_GROUP}
# Complementary suppression: if the hidden teams are few, a reader could subtract the
# visible teams from the company total and recover them, so hide the next-smallest team as well.
while hidden and sum(len(scores[t]) for t in hidden) < MIN_HIDDEN:
    visible = sorted((len(vs), t) for t, vs in scores.items() if t not in hidden)
    if not visible:
        break
    hidden.add(visible[0][1])

for team in sorted(scores):
    n = len(scores[team])
    shown = "suppressed" if team in hidden else f"eNPS={enps(scores[team])}"
    print(f"{team:<9} n={n:<2} {shown}")

3. Run python3 enps.py.

Expected output.

Company: n=30 eNPS=3
Data      n=6  suppressed
Design    n=2  suppressed
Mobile    n=6  eNPS=33
Payments  n=7  eNPS=-43
Platform  n=9  eNPS=22

Validation. Company: (11 promoters − 10 detractors) ÷ 30 × 100 ≈ 3. With only Design (two respondents) hidden, anyone could subtract the visible teams from the company total, so the script also hides the next-smallest team (Data), as commercial tools’ suppression setting does.^[17] Payments’ −43 from seven people is a conversation starter, not a verdict: one changed answer moves it by about 14 points.

Troubleshooting. Scores too large? Passives (7–8) must count in the denominator but in neither group.

Teardown. rm -rf ~/peopleops-labs/lab3

Objective. Compute compa-ratio and range penetration, flag out-of-range pay, compute mean and median gender pay gaps (GOV.UK formula) and run a four-fifths screen on selection rates. Prerequisites. Python 3.8+; Lab 1; the glossary terms for pay ranges. Time. 45 minutes. Risk. None with synthetic data; with real data this is restricted analysis needing an approved purpose, a recorded lawful basis and legal input.

1. Create bands, pay and selection data.

Example status: verified by execution on 2026-10-16 (bash, Linux).

mkdir -p ~/peopleops-labs/lab4 && cd ~/peopleops-labs/lab4
cat > bands.csv <<'EOF'
grade,minimum,midpoint,maximum
G3,48000,60000,72000
G4,60000,75000,90000
EOF
cat > pay.csv <<'EOF'
employee_id,grade,sex,annual_base,weekly_hours
P01,G3,F,52000,40
P02,G3,M,61000,40
P03,G3,F,58000,40
P04,G3,M,66000,40
P05,G3,F,47000,40
P06,G4,M,78000,40
P07,G4,F,70000,40
P08,G4,M,88000,40
P09,G4,F,74000,40
P10,G4,M,93000,40
EOF
cat > selection.csv <<'EOF'
group,applicants,selected
A,120,30
B,80,12
EOF

2. Save as fairness.py.

Example status: verified by execution on 2026-10-16 (Python 3, standard library).

"""Pay-band and selection-rate screens on synthetic data (standard library only).
A screen flags things to investigate; it is not a legal or statistical conclusion."""
import csv
from statistics import mean, median

with open("bands.csv", newline="") as f:
    bands = {r["grade"]: {k: float(v) for k, v in r.items() if k != "grade"} for r in csv.DictReader(f)}
with open("pay.csv", newline="") as f:
    people = list(csv.DictReader(f))

print("id   grade sex compa  penetration flag")
for p in people:
    b = bands[p["grade"]]
    pay = float(p["annual_base"])
    compa = pay / b["midpoint"]
    penetration = (pay - b["minimum"]) / (b["maximum"] - b["minimum"])
    flag = "BELOW-MIN" if pay < b["minimum"] else "ABOVE-MAX" if pay > b["maximum"] else ""
    print(f"{p['employee_id']}  {p['grade']}    {p['sex']}   {compa:.2f}   {penetration:6.0%}      {flag}")

def hourly(p):
    return float(p["annual_base"]) / (52 * float(p["weekly_hours"]))

men = [hourly(p) for p in people if p["sex"] == "M"]
women = [hourly(p) for p in people if p["sex"] == "F"]
print(f"Mean hourly gap   = {100 * (mean(men) - mean(women)) / mean(men):.1f}% of men's mean pay")
print(f"Median hourly gap = {100 * (median(men) - median(women)) / median(men):.1f}% of men's median pay")

for grade in sorted(bands):
    m = [p for p in people if p["grade"] == grade and p["sex"] == "M"]
    w = [p for p in people if p["grade"] == grade and p["sex"] == "F"]
    cm = mean(float(p["annual_base"]) for p in m) / bands[grade]["midpoint"]
    cw = mean(float(p["annual_base"]) for p in w) / bands[grade]["midpoint"]
    print(f"{grade}: mean compa-ratio men={cm:.2f} women={cw:.2f} (n={len(m)}+{len(w)})")

with open("selection.csv", newline="") as f:
    groups = {r["group"]: int(r["selected"]) / int(r["applicants"]) for r in csv.DictReader(f)}
top = max(groups.values())
for g, r in sorted(groups.items()):
    ratio = r / top
    print(f"Group {g}: selection rate {r:.1%}, impact ratio {ratio:.2f}{'  < 0.80: investigate' if ratio < 0.8 else ''}")

3. Run python3 fairness.py.

Expected output.

id   grade sex compa  penetration flag
P01  G3    F   0.87      17%      
P02  G3    M   1.02      54%      
P03  G3    F   0.97      42%      
P04  G3    M   1.10      75%      
P05  G3    F   0.78      -4%      BELOW-MIN
P06  G4    M   1.04      60%      
P07  G4    F   0.93      33%      
P08  G4    M   1.17      93%      
P09  G4    F   0.99      47%      
P10  G4    M   1.24     110%      ABOVE-MAX
Mean hourly gap   = 22.0% of men's mean pay
Median hourly gap = 25.6% of men's median pay
G3: mean compa-ratio men=1.06 women=0.87 (n=2+3)
G4: mean compa-ratio men=1.15 women=0.96 (n=3+2)
Group A: selection rate 25.0%, impact ratio 1.00
Group B: selection rate 15.0%, impact ratio 0.60  < 0.80: investigate

Validation. Men’s mean pay is 77,200 and women’s 60,200: (77,200 − 60,200) ÷ 77,200 = 22.0%, the GOV.UK gap formula,^[49] with hourly pay simplified (annual base ÷ 52 ÷ weekly hours; GOV.UK uses ordinary pay in the relevant pay period). Group B’s rate (15%) ÷ group A’s (25%) = 0.60, below the four-fifths threshold of the US Uniform Guidelines, which also warn that small samples need care.^[20] Treat 0.80 as an internal trigger for investigation, not a safe harbour: the Guidelines’ federal status is contested in 2026 (see the regulatory map).

Interpretation. The unadjusted gap mixes grade mix and pay within grade (see adjusted gaps); women’s mean compa-ratio is lower in both grades, but with two or three people per cell nothing is statistically meaningful. Review P05 and P10, look for documented legitimate factors, and involve counsel.

Teardown. rm -rf ~/peopleops-labs/lab4

Two cases are documented by the organisations involved, one applies documented rules to a fictional employer, and one is illustrative (a post-acquisition HRIS merger follows the go-live preflight).

GitLab’s offboarding standard says a termination approved and completed in Workday automatically creates parent and child cases on the last working day; system owners revoke access within five working days (critical systems within 24 hours), laptops come back within two to four weeks, and each ticked checkbox records that access was revoked or never given.^[7] Automation makes the HR entry the single point of failure, so its timing becomes a control; the standard flags one manual fallback step as needing confirmation, a reminder that fallbacks drift. Trade-off: speed and evidence versus dependence on a timely HR entry. Success: tasks closed within the stated windows.

Google repeats the same short, voluntary, confidential survey at 30, 90 and 365 days (tools, productivity and skills, culture and connection), analyses it by segment, and used the results to link company orientation with local onboarding and add community-building.^[61] Copying the survey without that follow-through gains nothing. Trade-off: trend data versus survey fatigue. Success: improvement across cohorts and lower first-year attrition (measured as in cohort and survival views).

The tool assesses candidates for hiring, so Local Law 144 applies (regulatory map), including notices to candidates who live in the city ten business days before use.^[50] PeopleOps and Legal commission and publish the bias audit, add notices to adverts and the application flow, and offer a human review path. The law sets no pass mark, so they add their own control, not a city rule: monthly impact ratios, any group below 0.80 investigated (Lab 4). Pitfalls: treating last year’s audit as permanent, and reading a passed audit as proof of fairness. Trade-off: throughput versus legal and fairness risk. Success: a current audit, provable notices, every flagged ratio investigated.

Build the job architecture, set ranges from market data, analyse gaps for equal work and work of equal value, close unexplained gaps, stop asking about salary history, then publish ranges as each country’s law requires; ranges published before the architecture is fixed cannot be defended. Timeline (phasing in pay governance): three national entities of 100–149 people would first report gaps by 7 June 2031 (an entity under 100 has no directive duty unless national law adds one), a single employer of 300 by 7 June 2027; the pay-information and salary-history rules have no size threshold.^[28] Trade-off: exposing legacy inconsistencies versus future claims. Success: a range for every job and every unexplained gap closed or scheduled.

Measure the service (is the lifecycle working?), the outcome (are people staying, growing, treated fairly?) and the data (can we trust the numbers?), with written, stable definitions.

Leading indicators (terminations entered on time, readiness, open SLA breaches) can be acted on now; lagging ones (attrition, pay gaps, audit findings) confirm results. Report attrition as rolling twelve-month rates.

Worked calculation

• Separation rate = 56 ÷ 400 × 100 = 14.0%. Voluntary = 40 ÷ 400 = 10.0%. Regretted = 22 ÷ 400 = 5.5%.
• Of 80 people hired in the previous year’s cohort, 12 left within twelve months: first-year attrition = 12 ÷ 80 = 15.0%.
• Day-one readiness: 88 of 96 = 91.7%, below a 95% goal; late contract signature, not IT, caused six of the eight misses.
• Access revoked within one hour: 50 of 56 = 89.3%; all six misses were involuntary exits entered after the event.

The numbers point to early-career issues and to late HR entries behind the access and readiness misses: a process fix, not a technology purchase.

Cohorts and survival curves. A period attrition rate mixes last month’s hires with twenty-year veterans, so track each hiring cohort’s share still employed at 3, 6 and 12 months. On any snapshot date most people have not left; their final tenure is unknown (censored), and averaging leavers alone is biased. The Kaplan–Meier method handles this: the probability of staying past a point is the product of the conditional probabilities of staying through each interval, and censored people count as “at risk” until they drop out of view. Its key assumption, that people whose observation ends early have the same prospects as those still followed, is “not easily testable”,^[62] so write down how you treat transfers, dismissals and the snapshot date.

Adjusted and unadjusted pay gaps. The headline gap is computed “without correcting for differences in individual and job characteristics”; Eurostat explains that it reflects both differences in the average characteristics of men and women and differences in the financial returns for the same characteristics.^[63] An adjusted analysis estimates the gap that remains among comparable workers, for example by regressing pay on documented legitimate factors (grade, job family, location, tenure) plus sex. Two cautions: a control can carry the bias you are looking for (if women are graded lower for the same work, controlling for grade hides it), so also analyse who reaches which grade; and equal pay is judged per category of equal work or work of equal value, which is how the Directive’s 5% joint-assessment trigger is framed.^[28]

Causation, noise and traps. Google’s people-analytics guide warns against confusing correlation with causation and against regression to the mean.^[8] Small groups swing wildly: use rolling windows and counts. Activity counts (trainings delivered, policies published) say little about outcomes, and eNPS as a target raises scores and lowers information (see the judgement call). “Industry average attrition” rarely states its denominator, so this page gives none: compare yourself with yourself. Constructs differ too: Gallup’s engagement measure (20% of employees worldwide engaged in 2025, by its count) is not an eNPS.^[64] Every dashboard states its worker types, treatment of rehires and transfers, suppression rules and extraction date.

People data is among the most sensitive an organisation holds: identity documents, bank details, pay, health, family, diversity, performance and investigations. This is not legal advice; laws are dated in the regulatory map.

Least privilege inside HR systems. Define HRIS roles by need (managers see their reports’ job data, not health data; payroll sees bank details; analysts see pseudonymised extracts; very few see investigations); keep diversity and health data in restricted fields; log access to sensitive fields; and review HRIS role assignments quarterly, because people inside HR change jobs too.

Under the GDPR and laws modelled on it, the first design question for any use of HR data is not “is it useful?” but “on what lawful basis?”, recorded per purpose (Article 6).^[45] Typical bases at work are the contract (the European Data Protection Board’s example: salary and bank details so wages can be paid), a legal obligation (tax, right-to-work records) and legitimate interests, which need a balancing test against the worker’s interests and rights.^[66][45]

Consent rarely works at work. The Board “deems it problematic for employers to process personal data of current or future employees on the basis of consent as it is unlikely to be freely given”; employees can consent freely only in exceptional circumstances, when refusing has no adverse consequences at all.^[66] A clicked box does not make a survey or a monitoring tool “consented”.

Special-category data (among others racial or ethnic origin, trade-union membership, biometric data used to identify people, health, sex life or sexual orientation) needs an Article 9 exception, such as obligations “in the field of employment and social security and social protection law” authorised by Union or Member State law or a collective agreement (Art. 9(2)(b)), or occupational medicine and assessing working capacity (Art. 9(2)(h)); Member States may add conditions for genetic, biometric and health data.^[46] Operating rules that follow:

• A lawful-basis column in the HR record of processing (with PrivacyOps) and on every analytics request (request form).
• Diversity data only as a voluntary, separate purpose with a “prefer not to say” option, stored apart and reported only in aggregate above the minimum group size; health data only as leave, adjustments and occupational health need, in restricted fields.
• For surveys, analytics and monitoring, a documented basis and proportionality assessment, and national rules such as works-council consultation checked before launch.

Rights requests and evidence. Former employees often exercise data rights during disputes; the deadlines are in the regulatory map and the workflow belongs to PrivacyOps, while PeopleOps makes sure HR data can be found, reviewed for third-party information and released on time. Keep proof that controls ran (disablement logs, checklist completions, HRIS role reviews, pay-screen decisions, survey thresholds, deletion logs); framework-level evidence belongs to ComplianceOps.

The cost drivers are the People team (levers: self-service, automation, clear tiers), software (often priced per employee or module), payroll and benefits providers, integration, and rework from late entries and re-keying.

This page gives no benchmark costs or HR-to-employee ratios: published figures use different definitions and samples, and none could be verified. Compute your own: people-team cost per employee (People salaries, software and providers ÷ average headcount), cases per PeopleOps FTE alongside SLA attainment, cost per hire, and the cost of a late termination (incident hours plus accepted risk), which often justifies automation.

Capacity. Load is lumpy (hiring waves, pay and performance cycles, surveys, reorganisations, layoffs): keep the pay and performance cycles apart and keep a tested RIF playbook. A custom HRIS is rarely justified; when buying, count lifecycle cost (implementation, integration, yearly configuration, audits, eventual migration).

Sustainability. PeopleOps’ own footprint is small (reuse returned laptops; onboarding travel). Workforce well-being is a people topic in its own right; ISO lists it among the topics of new metrics in the 2025 edition of its human capital reporting standard.^[23]

Monitor PeopleOps like a production system; the governance cadences list the routine checks. The alarms: a terminated-but-active account past the SLA (daily HRIS–identity reconciliation); HRIS–payroll mismatches in status, pay or cost centre before each pay cut-off; lifecycle checklists past due (weekly); and a selection or scoring tool that fails its by-group audit (before use and at least yearly, required for some tools: see the regulatory map), which is suspended pending review.

Key risk indicators: late terminations, overdue statutory tasks, people with access to pay data, surveys launched without thresholds, policies past review.

%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 20, "rankSpacing": 30}}}%%
flowchart TD
  A["Reconciliation alert: terminated in HR, still active"] --> B["Disable identity and non-SSO accounts; revoke sessions and tokens"]
  B --> D{{"Any sign-in or data access after the termination time?"}}
  D -->|"no"| E["Record exposure window; close as near-miss"]
  D -->|"yes"| F["Open security incident; preserve logs"]
  F --> G["Assess data accessed; notify per policy and law"]
  E --> H["Root cause: why was the HR entry late?"]
  G --> H
  H --> I["Fix the process; track terminations entered on time"]
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  class A,F,G risk
  class D decision
  class B,E,H,I core

Runbook steps, owners and timings.

1. Contain (Identity, 15 minutes): disable the account; revoke sessions, refresh tokens and API keys; remove from groups.
2. Contain non-SSO (system owners, 1 hour): disable local accounts listed in the application inventory (here, the CRM).
3. Assess (Security with PeopleOps): pull sign-in and audit logs from termination to containment; here, one CRM sign-in on Tuesday and a customer-list export.
4. Respond (Security, Legal, Privacy): open an incident, preserve evidence, decide whether the export is a notifiable personal data breach under applicable law, and contact the former employee through Legal.
5. Fix (PeopleOps, Identity): pre-enter terminations with restricted visibility (Artefact 5), bring the CRM under SSO or name its owner in the checklist, and alert on past-dated terminations; report terminations entered on time monthly (target ≥ 98%).

Lesson. An HR process step caused the security failure, which is why PeopleOps owns the trigger even though identity owns the action.

1. The rebrand: HR renamed People Ops with the same spreadsheets. Instead: deliver three of the observable changes in the naming story.
2. The HRIS as a filing cabinet, updated after the spreadsheets. Instead: make the HRIS where changes happen.
3. Email-driven lifecycle (“please set up X for Y on Monday”). Instead: events.
4. Copying Google without context or follow-through. Instead: adopt the reasoning and test the practice.
5. Surveillance analytics: keystroke or activity scores called insight. Instead: group-level, purpose-limited analysis.
6. Survey without action, one rating for everything, tool before process. Instead: see the listening and performance playbooks and the attribute-ownership matrix.
7. Myth: “AI will make hiring objective.” Tools can encode historic bias, which is why the EU classes such uses as high-risk and several jurisdictions regulate them (regulatory map).^[27]

Use a deliberate PeopleOps model when several of these hold: you hire or lose people every month; you employ in more than one country or state; several systems need people data; you have had day-one misses, orphan accounts or payroll errors; leaders distrust the headcount; you face pay-reporting, AI or privacy obligations; or an acquisition, audit or funding round will examine people data.

Do not build a separate team (yet) when you are small, in one country, hire rarely and have one payroll: one accountable owner, a reputable payroll provider or PEO, two checklists and one well-kept record are enough. Do not rename HR only to sound modern.

Alternatives: a PEO, an employer of record (where you have no entity), outsourced payroll with in-house HR, or a fractional HR leader; each trades control and data access for speed and lower fixed cost. Hidden responsibilities: data quality, integrations, reconciliations, rights requests, country calendars and policy upkeep; if nobody has time for them, the model decays.

%%{init: {"flowchart": {"wrappingWidth": 110, "nodeSpacing": 14, "rankSpacing": 26}}}%%
flowchart TD
  S["Start: size, locations, pace of change"] --> Q1{{"Staff where you have no entity?"}}
  Q1 -->|"yes"| EOR["Employer of record there; keep your own HR record"]
  Q1 -->|"no"| Q2{{"Under about 50 people, own-entity staff in one country?"}}
  EOR --> Q2
  Q2 -->|"no"| Q3{{"More than five people-data systems, or JML failures?"}}
  Q2 -->|"yes"| SMALL["No team yet: one owner, a provider, checklists"]
  Q3 -->|"no"| GEN["People generalist with ops skills, plus an HRIS"]
  Q3 -->|"yes"| Q4{{"Integration skills in-house?"}}
  Q4 -->|"yes"| BEST["Team: suite plus specialised tools"]
  Q4 -->|"no"| SUITE["Team: one suite with native connectors"]
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class Q1,Q2,Q3,Q4 decision
  class EOR,SMALL,GEN,BEST,SUITE core
  class S neutral

The thresholds (about 50 people, five systems) are editorial heuristics; legal context, growth and risk appetite matter more. Re-run the tree every six months or after a major change.

Weighted matrix: choosing a system-of-record approach

Assumptions. A fictional 400-person company in three countries with two engineers who can maintain integrations and customers who audit access controls. Scores run 1 (poor) to 5 (strong), set after demonstrations; weights sum to 100.

Suite: 20×5 + 20×4 + 15×4 + 15×3 + 15×5 + 10×2 + 5×3 = 395. Suite plus specialised tools differs only in experience (+30) and security (−15), giving 410.

This is this Atlas’s maturity model, not an official standard: locate yourself and pick the next step.

Most organisations do not need Level 5 everywhere: a 150-person company at Level 3 for lifecycle and Level 2 for analytics may be exactly right.

Assumes a 150–500-person organisation with an under-used HRIS and a new PeopleOps lead; larger or regulated organisations need longer. The sequence matters more than the dates.

Quick wins: a shared joiner and leaver calendar for IT; no termination effective in the past; one intake form for employment changes; no pay data in email. Dependencies: identity capacity for connectors, payroll cut-offs, legal review, leadership agreement on metric definitions.

Quick start (first week)

• Name one accountable owner for the employee lifecycle
• List every system that stores people data, with an owner, and decide the system of record per core attribute
• Write the joiner checklist (with statutory steps per country) and the leaver checklist (with non-SSO systems)
• Share a weekly list of upcoming joiners and leavers with IT and payroll

Preflight before an HRIS go-live

• Effective-dated history migrated; headcount, pay totals and manager hierarchy reconciled record by record
• Security roles tested with real scenarios (manager, payroll, analyst, employee)
• Integrations tested for hire, move, termination, rehire and cancelled hire
• Parallel payroll run planned or waived with a reason; rollback plan ready; data export (exit) tested
• After an acquisition: non-urgent changes frozen in the old system; jobs mapped by work, not titles, with every grade change explained in writing; identity provisioning switched only once reconciliation is clean

Survey launch and AI tool procurement

• Survey: purpose and lawful basis written down (not “consent” by default); group, suppression and comment thresholds set before launch; “confidential”, not “anonymous”, unless that is true
• AI tool: use classified (screens, ranks, schedules, evaluates or monitors workers?); jurisdictions mapped against the regulatory map; lawful basis recorded; vendor bias audit reviewed; own screen planned; human decision-maker and appeal route defined; privacy assessment done

For a reduction in force, use the eight RIF steps as the checklist; the quarterly audit items are in the governance cadences.

One-page PeopleOps charter

PEOPLEOPS CHARTER                                     Version: 1.0   Owner: <name>   Review: <date>
Mission:      <one sentence: what the employee lifecycle should feel like and guarantee>
Scope:        Lifecycle transactions, HR system of record, HR service delivery, people data and metrics,
              performance and pay processes, policy, HR compliance and HR data privacy
Out of scope: Accounts and access (Identity), company planning (BizOps), course delivery (EduOps), legal advice (Legal)
Principles:   1 One record, many consumers  2 Effective-dated truth  3 Transitions are controls
              4 Services have SLAs  5 Measure systems, protect individuals  6 Minimum necessary data
Service levels: Day-one readiness >= <x>%   Access disabled within <t> of termination >= <y>%
                HR cases answered within <d> working days >= <z>%
Metrics reviewed monthly: <list>
Decision rights: <who approves policy, pay exceptions, HRIS changes, survey thresholds>
Signed: <Head of People>  <CIO or Identity owner>  <Finance or Payroll owner>

Architecture decision record (filled example)

ADR-007: The HRIS is the system of record for the manager attribute
Status: Accepted (2026-10-16)
Context: Managers were maintained in the HRIS, the identity provider and the expense tool. Approvals went to former managers
         after reorganisations, and identity groups based on manager were wrong.
Decision: The HRIS owns the manager attribute. The identity provider and all tools read it through the provisioning
          connector. Local edits in other tools are disabled.
Consequences: Reorganisations must be entered in the HRIS with effective dates before they take effect. The PeopleOps
              team adds manager changes to the reorganisation checklist. A daily report flags manager mismatches.
Alternatives considered: Identity provider as owner (rejected: HR approvals live in the HRIS);
                         per-tool ownership (rejected: the cause of the problem).

Retention schedule (structure only). Counsel and PrivacyOps fill each period, with its legal source, per country; this page gives no periods because none was researched at source. Header fields: owner (PeopleOps lead), approvers (Privacy, Legal), countries covered, review date.

Rules: disposal means deletion or anonymisation, and every run is logged as evidence; a legal hold suspends disposal; a record class without a source is not approved.

Monthly people scorecard (one page)

Each month adds two columns, the value and its twelve-month trend; definitions are in Metrics and KPIs. Every number states its period, denominator and worker types; groups below the reporting threshold are not shown.

People-data request form

Requester: <name, role>         Date: <date>
Question to answer:             <decision this will inform>
Data needed (fields):           <minimum fields>
Population and period:          <who, when>
Identifiable data needed?       <no / yes, with justification>
Lawful basis:                   <basis per purpose; Art. 9 condition if special-category data>
Output audience:                <who will see results>
Minimum group size applied:     <n>
Retention of extract:           <delete by date>
Approved by (People analytics lead / Privacy):  <names, date>

Hand-off boundaries are in How PeopleOps relates to other Ops. The business-function pages share habits (one source of truth, defined hand-offs, service levels) but serve different customers, so success is measured differently.

The useful contrast is the customer: workers cannot switch HR provider, so their experience must be measured deliberately; the alternative signal, people leaving, arrives late and costs the most.

Established: event-driven HR-to-identity integration^[30][21]; survey confidentiality through minimum groups and suppression^[17]; fairness screens whose arithmetic is stable even where their legal status changes. Changing: the rules in the regulatory map and ISO 30414’s 2025 edition with auditable requirements.^[23] Emerging, evidence still forming: skills-based organisation (pilot in one job family, because skill taxonomies decay); lifecycle-triggered listening (timelier, but tiring and riskier for anonymity); LLM assistants that answer policy questions with citations; causal methods in people analytics. Treat with caution: vendor claims to predict performance from personality, video or language, and engagement scores with undisclosed questions.

Prerequisites: none; spreadsheets, basic statistics and awareness of local employment and data-protection law help.

• 1 day: “What PeopleOps is” and “Vocabulary, origins and neighbours”; draw your joiner and leaver flows; list the systems holding people data.
• 1 week: Labs 1–3, an attribute-ownership matrix and a leaver SOP. 30 days: baselines for readiness, revocation and data accuracy; fix one transition; Lab 4.
• Specialise and build a portfolio: HRIS engineering (a tested reconciliation script), people analytics (a cohort retention analysis), total rewards (a pay-structure model) or HR service delivery (a service catalogue).

Paths by persona. Beginner: the first three parts (to “Principles and operating model”), the onboarding playbook, Labs 1 and 3. Practitioner or engineer: architecture and workflow, the reference implementation, Labs 2 and 4, failures. Leader: the problem, operating model, metrics, privacy, the decision framework, maturity and the judgement call. For a career framework, see the CIPD Profession Map.^[1]

Decide: the system of record per attribute; the lifecycle owner; service levels; the lawful basis for each use of people data; minimum group sizes; how pay ranges are set and checked; which AI uses are allowed where.

Practise: future-dated entries; events, not emails; daily reconciliation; the Four C’s; development separate from pay; fairness screens each cycle; a service catalogue with a confidential path.

Measure: day-one readiness; on-time revocation and termination entry; regretted attrition and cohort retention; case SLAs; data accuracy; out-of-range pay and pay gaps; eNPS with response rate.

Watch out for: the cosmetic rebrand; surveillance analytics; “consent” as the default basis at work; metrics as targets; AI without audit; layoffs without a statutory calendar; benchmarks without definitions.

The situation. A 600-person company proposes that 20% of each manager’s bonus depends on their team’s eNPS improvement (option A). Option B: use survey results for diagnosis, and judge managers on documented behaviours (regular one-to-ones, acting on survey results, developing people) plus outcomes such as regretted attrition, reviewed with context.

Assumptions. Teams average eight people; the survey is confidential with a minimum group of five; managers see their team’s aggregates; the policy would run for at least two years.

Why the attractive option A is likely wrong here.

1. Noise. With eight respondents, one person moving from promoter to passive shifts the score by 12.5 points; year-on-year changes will be dominated by noise and turnover, not management quality.
2. Goodhart’s law. Once the measure is a target, managers can raise it without improving anything (pressuring participation, hinting at the “right” answers), and the survey stops telling the truth.
3. Confidentiality pressure. Managers with money at stake will push for finer cuts of data, and respondents will sense it.
4. Fairness. The CIPD review stresses perceived fairness in appraisal;^[31] pay on a noisy number managers only partly control is unlikely to feel fair to them either.

What option A gets right is accountability, so option B needs teeth: survey follow-through in managers’ development plans, leaders reviewing action completion, and a behaviour-based performance process for persistent problems.

Decision under these assumptions: option B. Revisit only for large teams (say 50+ respondents) with strong survey-integrity controls, and even then reward action completion, not the score. This is a reasoned recommendation, not a proven result; a pilot of option A should watch response rates, score distributions and comments for gaming.

You should now be able to explain the three usages of “PeopleOps”; design joiner, mover and leaver flows with owners and effective dates; specify attribute ownership that prevents orphan accounts; calculate and interpret separation rates, eNPS, compa-ratio, pay gaps and cohort retention; protect individuals with minimum group sizes and a recorded lawful basis; plan a reduction in force against its statutory calendar; and evaluate which operating model fits.

PeopleOps is an honest name only when it describes a real change: the employee lifecycle run as an operation that can be designed, measured and improved, while its “units” remain people with rights. Three ideas carry most of the value: one effective-dated record that every other system trusts; transitions treated as controls, so joining, moving and leaving happen correctly and on time; and measurement that protects individuals, so data informs decisions without becoming surveillance.

Everything else is scaffolding, and much of it should wait until the basics work. A small company with a careful owner and two good checklists is doing PeopleOps; a large company with an expensive suite and emailed spreadsheets is not. One test: when someone leaves on Friday at five, does every system know by five past, and can you prove it?

All sources were opened on 2026-10-16. Legal sources are for orientation; check the official text (for EU law, EUR-Lex) before relying on them.

Further reading.

• Laszlo Bock, Work Rules! (2015): the People Operations origin story in Bock’s words (not opened for this page).

Changelog. Legal rows are due for re-verification by 2027-01-16.

• 2026-10-16, first version: labs executed on synthetic data.
• 2026-10-16, revision 1 after the fact-check: regulatory map, reductions in force, lawful basis.
• 2026-10-16, revision 2 after scoring: diagrams redrawn for phones, service catalogue, retention schedule, AI Act wording, repetition cut.
• 2026-10-16, revision 3 after the second score: regrouped into 14 parts; people-analytics method (cohorts, Kaplan–Meier survival, adjusted pay gaps); retention schedule as a table; scorecard template; two FAQs; EU threshold wording; Figure 5 redrawn; OKR artefact and acquisition scenario folded into other sections; repetition cut.
• 2026-10-16, follow-up to the third score (orchestrator): CIPD Profession Map quoted verbatim; learning path names its parts.