Attrition as survival

Every row in Apex becomes two numbers: a duration t, and an event flag. For the 210 with a last day, t is the years from join to exit and the flag is 1: the stay ended and we saw it end. For the 861 without one, t is the years from join to the snapshot date, 1 July 2026, and the flag is 0: the stay is at least t long, and that is all we know. The second kind is censored. A censored row is not missing data; it is a lower bound, and the survival arithmetic uses it as one.

There is a third kind of row, and it is the one that matters most tonight: the row that does not exist. Anyone who joined Apex and left before 1 January 2026 is not in the table. Their stay ended, we would have seen it end, and we never will, because the export was taken after they had gone. The figure draws two of them faint. Deep-dive session 1 called the export a photograph; the survival curve is where the photograph starts to lie in a measurable direction.

The two medians already disagree. Among the 210 exits the table can see, tenure at exit has a median of 1.52 years: 29.5 percent left inside their first year and 61.0 percent inside two. Among the 861 still employed, tenure so far has a median of 5.01 years. Whatever the true curve looks like, the people who leave are leaving early, and the people who stay have stayed long. The curve has to reconcile both.

Take the mean of Apex's tenure column and you get a number that goes up every month nobody leaves, because every censored stay grows by a month while the finished ones stay fixed. Take the mean of tenure at exit instead and you get 1.52 years as a median, which describes the leavers and says nothing about the 861 who have not left. Neither number is the average length of a stay at Apex. The survival function sidesteps the problem by never asking "how long" of any one person; it asks, at each t, "of the people who reached t, how many were seen to leave at t", and a censored person counts in the first group at every t up to their own and never in the second. The customer version of the same arithmetic, on subscriptions instead of staff, is in the Customer Retention course; the mechanics are identical and the data there has the shape this one lacks.

Start with S = 1 and everyone at risk: 1,071. Take the shortest stay. If it ended in an exit, S becomes S times (1 - 1/1,071). Either way, one fewer person is at risk. Take the next shortest, and so on. By the end of the first year, the table has seen 62 exits, S has fallen to 0.940, and 946 people are still at risk. By two years: 128 exits seen, S 0.872, 803 at risk. By three: 180 exits, 0.813, 670 at risk. By five: 206 of the 210 exits have been used, S is 0.778, and 441 people remain at risk, all censored stays that will each remove one from the count and none from S.

Two properties follow from the arithmetic and are worth saying aloud. Censoring never moves the curve down, it only shrinks the denominator for the next exit, which is why a censored stay is information and not a gap. And the curve is only defined as far as the longest stay; Apex's longest is a little over fourteen years, so "median tenure" from this curve does not exist, because S never reaches 0.5.

The at-risk counts and exit counts above are computed from the constructed table in the build-along; they are the numbers the loop passes through on its way to the four readings.

Kaplan-Meier describes one curve. The moment the question becomes "does Sales leave faster than R&D, adjusting for entity and join cohort", the tool is Cox's proportional hazards regression, "Regression Models and Life-Tables", Journal of the Royal Statistical Society Series B 34(2) 187-202, 1972. It models the hazard, the instantaneous rate of leaving at each t, as a baseline shared by everyone times a multiplier per covariate. It is named tonight and not fitted, for a reason that is the subject of Part 3: a regression on a biased curve inherits the bias, and a hazard ratio between two departments computed from a survivor table compares two distorted hazards. Fit it on an event log. The Customer Retention course fits the same curve to customers, where the event log usually exists, and is the place to see the estimator on data that can bear it.

Sentence one. At any tenure t, the estimator's denominator counts everyone in the table who reached t, and the 861 survivors reached t in 2015, 2019, 2023, whenever, so the denominator contains years of exposure from long before the export. Sentence two. The numerator at t counts exits at t, and the only exits in the table happened between January and June 2026, so every year of exposure before 2026 is in the denominator with no possibility of contributing to the numerator. A fraction whose denominator includes exposure that cannot produce an event is too small at every t; a hazard that is too small at every t gives a survival curve that is too high at every t. The direction is certain.

What the proof does not tell you is the size. The size depends on how many people left before 2026 and when, and those are the rows that are not there. The curve could be a little too high or a great deal too high; the table cannot distinguish the two. So the honest report of this curve is: "on the people present in 2026, 0.940 at one year, biased upward by an amount this table cannot measure". Both halves of that sentence are findings.

There is a hint of the size in a number already on the page. Half of the 210 visible exits happened inside 1.52 years, and 61.0 percent inside two, while the curve says 87.2 percent of stays survive two years. Those two facts can coexist only if a great many people who would have left early are not in the table to be counted. That is exactly what the photograph did.

The fix is not a different estimator; Kaplan-Meier is doing its job. The fix is the input: one row per join and one row per exit, for everyone who ever joined, back to a start date that is stated. Then a person who joined in 2019 and left in 2022 is two rows, contributes three years to the denominator and one exit to the numerator, and the fraction at every t is exposure against events that could actually happen. The minimum event log for this session is four columns: person id, event date, event type (joined, left), and the reason if any. With it, the only censoring is the honest kind at the right edge, where stays are still running on the day of the export.

Two practical routes to that log. Ask the HR system for the change history of the status field rather than the employee export; most systems keep it and few are asked. Or, from today, keep every monthly export with its date, and diff consecutive months: ids that vanish left, ids that appear joined. Twelve months of that habit gives a real first-year hazard for the cohort that joined in the first month, which is one true number more than the photograph can ever give.