PeopleOps

WHAT IT IS PeopleOps is the operational half of the people function: running joiner, mover and leaver processes to completion, maintaining people data that other systems depend on, administering benefits and payroll interfaces, and turning written policy into something that actually happens. **Not this:** PeopleOps is not ITOps: it owns the employment lifecycle and the people data that drives downstream provisioning, not the systems and service desk that carry out the provisioning itself. WHY IT EXISTS People data is the trigger for a surprising amount of the rest of the business. Access provisioning, payroll, org reporting and compliance evidence all key off whether the people record is correct and timely. The leaver case is the sharpest: an offboarding that completes in the HR system but not in the access systems leaves credentials alive, and that gap is one of the most common findings in any access review. PeopleOps exists because the employment lifecycle is a data pipeline with legal and security consequences. WHEN TO USE IT Adopt it as soon as hiring is continuous rather than occasional, or when the first access review finds accounts belonging to people who left. The mover case — internal transfers — is usually worse than the leaver case and is discovered later, because accumulated access from previous roles is invisible unless someone looks. WHO OWNS IT A People or HR operations function owns the lifecycle processes and the people system of record. Managers own their part of the process and are the usual point of failure, so the process must be designed for a busy manager rather than an attentive one. IT and security own provisioning and deprovisioning, consuming the people data — a boundary that must be an integration rather than an email. Legal owns employment compliance and records retention. WHAT GOOD LOOKS LIKE There is one system of record for people data and other systems consume it rather than keeping their own copy. Joiner, mover and leaver are defined processes with owners and completion tracking — the leaver process in particular is verified as complete rather than assumed. Access changes are driven by the people record, including on internal moves, where previous access is removed rather than accumulated. Onboarding time to productivity is measured. Policies that create obligations have an operational implementation, and the evidence they were followed is retained for the periods required — the same evidence discipline as /complianceops. Personal data is handled under a retention schedule, which is /privacyops work. HOW TO IMPLEMENT Fix the leaver process first and verify it end to end, including every system that grants access, because this is the item with immediate security consequence. Then address movers, which usually requires deciding that role changes revoke as well as grant. Establish the single system of record and integrate rather than export. Measure onboarding to first productive contribution — the same signal /devex uses. Put a retention schedule on people data. Keep manager-facing steps short enough that they are completed without chasing. HOW TO ASSESS YOURSELF Take last quarter's leavers and check every system for surviving access. Take someone who changed role and list what they can still reach from the previous one. Ask which system is authoritative for the org chart and whether the others agree with it. Take the scored self-assessment at /assess and plan the gaps with /roadmaps.