Employee Lifecycle

What does the stage model actually claim?

That the relationship between a person and an employer is not uniform over time, and that the differences between its periods are large enough to be worth naming. What someone needs, what the employer owes them, and what a poor experience costs are genuinely different before an offer, in the first weeks, in the settled middle years and at the end. Naming those periods gives an organization somewhere to put an observation that would otherwise float free. The claim is modest and it is sound. What is not part of the claim is that the periods are discrete, that everyone passes through them in order, or that each is the same length. A person promoted into a new function re-enters an early stage without ever leaving the organization.

Why do different employers count a different number of stages?

Because the boundaries are drawn, not found. Nothing in the underlying reality separates the end of onboarding from the beginning of development; somebody decided where to put the line, usually at whatever point their own systems or their own org chart already changed hands. An employer whose recruiting and HR functions are separate will draw a boundary at the offer, because that is where a file moves. An employer running one team across both will not see a boundary there at all. The consequence is that the count of stages tells you about the organization that drew it rather than about employment as such, and comparing two models by their number of stages is an argument about presentation. Choose the granularity that matches where work actually changes hands in your organization, and stop refining it once every boundary corresponds to a real transfer.

What is the model good for, if not for following?

Diagnosis. Read as a description of stages it produces a diagram; read as a description of boundaries it produces a list of the places where something is likely to have been dropped. Almost every recurring people problem an employer has can be located at a boundary rather than inside a stage: what a recruiter promised that nobody who manages the person ever heard, a development conversation that assumed information from an assessment run before the person was hired, a departure that surprises people who read the same warning signals separately and never compared them. None of those is a failure of a stage doing its job. Each is a failure of transfer. The model earns its keep the moment somebody uses it to ask which boundary a specific problem crossed, and it stops earning anything the moment it becomes wall art.

What happens at the boundary between two stages?

Ownership changes, and ownership is the thing that does not transfer cleanly. On one side of a boundary a named person is answerable for the individual; on the other side a different named person is, and in between there is a period during which the answer to who owns this is genuinely nobody. A commitment made during hiring is the standard example, because it was made by someone whose accountability ends at acceptance to someone whose experience of it begins afterwards. The failure is structural rather than careless: nobody is neglecting a duty, the duty simply expired on one side before it began on the other. Asking who is accountable the day after a boundary, and getting a name rather than a department, tests whether the transfer exists.

A defined handover is a cheaper fix than any redesign of the stages themselves, and it consists of very little: a named owner on each side, an agreed moment at which responsibility moves, and a short set of things that must travel with the person rather than being reconstructed later. What must travel is usually not documentation. It is the commitments made, the reservations somebody had and did not want in writing, the context that explains why this person was chosen over a stronger candidate on paper. The boundary between hiring and the first weeks is where this is most visible, which is why the transfer from a recruiting file into [an onboarding process](/employee-onboarding-software) is worth designing explicitly rather than leaving it to whoever remembers.

Why does a person's record fragment across the lifecycle?

Because each stage was automated separately, by a different team, at a different time, to solve a problem that stage had. Recruiting bought a system to run a pipeline. Payroll and administration bought one to hold employment facts. Learning, performance and engagement each acquired their own, often without anyone asking whether the person in one was the same record as the person in another. The individual then exists as several partial people, joined by a name and little else. Consolidating into a single [HCM system](/hcm-software) is the obvious answer and it is expensive, slow, and frequently deferred for sound reasons. What matters more is whether one identifier follows the person from first contact to final record, because that makes the fragments joinable even while they remain apart.

The cost of fragmentation is not administrative, it is that questions spanning more than one stage become unanswerable. Whether the people who leave early were sourced through a particular channel, whether those rated highly in their first year are the ones who go on to be promoted: each requires joining records that live in different systems under different keys, and each is therefore answered by somebody's impression instead. Impressions are formed from the vivid cases, which are unrepresentative by definition. Buying [analytics software](/hr-analytics-software) does not repair this on its own, because the tool can only join what was recorded with a common key. That is decided years earlier, when somebody chooses whether the candidate and employee records share an identity.

What does the model look like when it is treated as a checklist?

Theatre, and expensive theatre because it is indistinguishable from work. A stage is declared, an owner is assigned at function level rather than to a person, a set of activities is listed under each heading, and a slide is produced showing the whole thing as a circle. Everything on the slide is true and nothing about the organization has changed. The tell is that the activities listed under each stage are almost always things the organization was already doing; the exercise renamed them and grouped them, which feels like design and is labeling. Meanwhile the boundaries appear on the diagram as arrows, and arrows are the one element nobody is ever asked to own. A diagram with an owner written on every arrow is worth more than a beautiful one with none.

The alternative is unglamorous and short. Name a person, not a department, as accountable on each side of every boundary you have chosen to draw. Write down what must travel across it and by when. Then leave the stages alone, because the work inside them was already owned by somebody and did not need a framework to justify it. This produces no diagram worth circulating, which is part of why it is rarely what gets done. It has one property the diagram lacks: when something is dropped, there is a specific person to ask and a specific transfer that failed, rather than a general observation that the employee experience could be better. It also survives a reorganization, since a named handover can be reassigned to whoever inherits the role.

Whose lifecycle does the model actually describe?

A single permanent employee moving forward through time, which is a narrower population than most employers have. A contractor engaged repeatedly across several years has a relationship the model recognizes only in fragments, since each engagement restarts it and the accumulated familiarity appears nowhere. An internal mover leaves one manager's world and joins another's without any of the stages that would ordinarily mark it, which is why internal transfers so often reproduce, inside the organization, exactly the failures the model was built to expose at the front door. A person who leaves and returns is described as two separate people. The lens was drawn for the simplest case, and the cases it handles poorly are the ones an employer is most likely to be handling by improvisation.

The useful response is not to extend the diagram until it covers every path, which produces something nobody reads. It is to notice that each awkward case is awkward for the same reason: it crosses a boundary the model did not anticipate, so no transfer was defined for it. A returning employee crosses from a former-employee record into a current one, and what should be carried across is a real question whose answer varies by employer and by what the records are allowed to retain. An internal mover crosses between two managers with no ceremony and frequently no record of what was agreed. Treating these as boundaries in their own right, each with an owner on either side, extends the model without redrawing it.