When a VP of Engineering announces she is leaving, two things happen simultaneously in most organisations. One is a personnel event: a person who has been part of the company is about to not be. The other is a structural event: a place in the organisation that has been occupied is about to become vacant. Most companies experience these as the same event, which means the departure triggers an immediate question: who is going to fill this person's role? Rather than the more interesting one: what does this position actually require, and is it still the right position for where the organisation is going?
The distinction matters more than it might initially appear. It is, at its core, the difference between thinking about an organisation as a collection of people and thinking about it as a designed structure that people occupy. These two frames produce different questions, different analyses, and, over time, different organisations.
The dominant model in HR technology and most organisational thinking is person-centric: the organisation is represented as a set of people, with reporting relationships between them. The org chart is built from the bottom up by connecting individuals to their managers. When someone leaves, the chart has a hole. When someone new joins, they are added as a node in the network. The structure of the organisation, in this model, is the aggregate of its current population.
Person-centric systems have real virtues. They are intuitive: people are the most immediately real thing about any organisation, and they map naturally to how payroll, benefits, and most HR administration works. The vast majority of HRIS platforms, from Workday to BambooHR to HiBob, are built primarily around the person as the central record, and for the administrative purposes those systems primarily serve, this is a sensible architectural choice.1
But person-centric thinking has a structural limitation that becomes significant as organisations grow and as the questions they need to answer become more structural in nature. In a person-centric model, a vacant position does not exist: there is no person to anchor it, so it cannot be represented. A role that has been deliberately held open while the organisation decides whether to hire or to restructure is invisible in the data. Succession planning — identifying who might grow into a more senior role before the need becomes urgent — is difficult to model because the position only exists as long as it is occupied. And scenario planning, the ability to model what the organisation looks like under a different structural configuration, requires working around the model's fundamental assumption that structure is a property of people rather than an independent property of the organisation itself.
This distinction has been standard in enterprise HR systems built on SAP's Organisational Management module since the early 1990s, and is embedded in the data models of platforms designed specifically for organisational design work.2 The separation transforms what analytical questions become tractable. Vacant positions can be counted, budgeted for, and represented in the org chart as design intent rather than as absent individuals, which means the organisation as designed and the organisation as currently staffed are both visible, and the gap between them is legible. Scenario planning can model the structural implications of a reorganisation without conflating "changing the structure" with "deciding what happens to specific people." A departure becomes a personnel event rather than a structural event: the position persists, with all its attributes, and the question of what to do with it — fill it as-is, redesign it, eliminate it — is separable from the urgency of an empty seat.
The deeper significance of the position-centric frame is what it makes visible as a matter of structural design.
Consider span of control: the number of direct reports each manager carries. In a person-centric model, spans of control can be calculated, but they are a function of current headcount — they reflect who happens to report to whom today, which is itself a product of hiring history and personnel decisions made over many years. In a position-centric model, spans of control are a design parameter: how many positions should each management position be responsible for, and why? The analysis can distinguish between structural intent and operational reality, and between spans that have drifted through personnel change and those that were deliberately set.
Or consider the job architecture, the framework that assigns each role to a level and function within the organisation. Job architecture is fundamentally a property of positions rather than people: it describes what the role requires and how it sits relative to other roles, not who currently occupies it. A position-centric data model is what makes it possible to maintain a coherent job architecture as people move in and out of roles, because the architecture lives on the position rather than being derived from the individual.
Or consider the organisation during periods of structural change: a reorganisation, a growth phase, a reduction in force. In a person-centric model, structural decisions and personnel decisions are entangled from the start, because the structure is made of people. Deciding to eliminate a management layer immediately raises the question of which managers are affected, making it difficult to reason about the structural question independently of the personnel implications. In a position-centric model, the structural design can be worked through first — what should the organisation look like? — and the personnel questions addressed as a subsequent, separable exercise.
The most practically consequential difference between person-centric and position-centric thinking shows up in the nature of the questions each frame makes natural.
A person-centric organisation, facing the need to reduce costs, asks: which people should we let go? A position-centric organisation asks: which positions, in the organisation we want to run, are essential — and then, as a distinct question, who is assigned to the positions that remain?
This matters not only analytically but ethically. Decisions about organisational structure ought to be made on the basis of what the organisation needs to do and how it needs to be configured to do it; decisions about which individuals occupy which roles are a subsequent question. Conflating the two — making structural decisions through the lens of the individuals currently involved — is one of the most common failure modes in organisational redesign, producing outcomes that reflect personal relationships and personnel preferences rather than structural logic. The position-centric frame does not resolve this tension automatically, but it creates the conditions under which structural and personnel decisions can be made in the right order.
The principle is simpler than its implications: the organisation is not its current population. Positions persist; people move through them. And designing an organisation means designing the positions (their levels, their relationships, their job profiles, the architecture that connects them) rather than simply managing the people who currently fill them.
1 For an analysis of person-centric HRIS architectures and their limitations for organisational design purposes, see Josh Bersin, HR Technology 2025: Market Disruptions and Platform Evolution, Bersin & Associates, 2024 (available at joshbersin.com). The observation that major HRIS platforms use the employee record as the primary organisational object is consistent across Workday, SAP SuccessFactors, BambooHR, HiBob, and Rippling documentation. ↩
2 SAP's Organisational Management (OM) sub-module, introduced as part of SAP R/3's HR component in the early 1990s, distinguishes between Organisational Units (functions or teams), Positions (structural roles), Jobs (job profiles), and Persons (individuals) as separate object types, related through defined relationship types. This separation of position from person is the architectural foundation for vacant position tracking, succession planning, and structural scenario modelling in enterprise HR systems. For an overview, see SAP SE, Organizational Management (SAP Help documentation).