Your org chart should be a snapshot, not a stream

Almost every HRIS we've replaced for a customer had the same flaw: the org chart could only show now. Pull it up today, you saw the org today. Pull it up after a reorg, you saw the new org. The question we kept hearing — "what did the org look like before the reorg?" — wasn't answerable without an export, a backup, or someone's memory.

That's a small thing until it isn't. Then it's a big thing.

When historical org structure actually matters

• Compensation review. You're calibrating Q4 promotions. Half the relevant managers have moved teams in October. Whose feedback counts toward whose review depends on who reported to whom during the review period, not who reports to whom today.
• Performance investigations. Someone raises a concern about a former manager. Reconstructing who was actually their manager at the time matters, both for fairness and for evidence.
• Severance calculations. In several jurisdictions, severance depends on tenure with the company, with the team, and sometimes with the specific manager.
• Comp committee reporting. "How has the engineering org grown over the last 18 months?" needs a series of snapshots, not a current view.

Two ways to model history, only one good

The first approach — what most older systems do — is a stream of changes. Every time someone moves teams, gets promoted, changes manager, you append a row to a history table. To answer "what did the org look like on March 14th?" you replay the stream up to March 14th. This works in theory and is awful in practice.

The second approach — what we built — is snapshots. We materialise the full org structure at the end of every day. Yesterday's org, last week's org, last quarter's org are all just rows. Querying any historical state is the same operation as querying the current state, with a different date.

The reorg problem

The interesting case is reorgs. A reorg isn't a single change — it's twenty changes that happen "together" but get entered over a week as managers update their teams. If you snapshot every day, you get a stair-stepped picture of the reorg unfolding, which is honest but ugly.

Our solution is to support a "planned change set." Reorgs land in a draft, the people involved review and approve, and on the agreed effective date the whole change set posts as a single transition. The history shows the org pre-reorg and the org post-reorg, with the transition itself as a labelled event you can click into to see what changed.

What we tell new customers

The snapshot history starts the day they go live. So if a major reorg is on the horizon, that's a reason to migrate sooner, not later. The historical view isn't a feature you'll demo to your CEO. It's a feature your HR team will quietly love every time it comes up.

If you'd like to see how the snapshot model handles your particular org's complexity, we're happy to walk through it.

Further reading: the Kimball Group's classic slowly-changing-dimension work is where most of this thinking comes from.