Simple and Boring Talent Database Decision that will Save You a Headache Down the Line

↓

​Learn more about the People Analytics course →​

Friends,

Before we get going... Let me do a quick plug!

Every AI conversation seems to boil down to the same question:

Which jobs survive, and which don't?

And this weekend, I even met an AI engineer who is tasked with practically eliminating her own job. Freaky, eh?

I don't think the jobs will disappear per se, but rather they will evolve.

On September 23, join us at the Toronto People Analytics Group as Jin Yan from Revelio Labs (Our event Sponsor) breaks down what's actually happening at the job activity level: which tasks AI is already reshaping, and why job titles are the wrong lens for workforce strategy.

And they have a HUUUUUGE dataset to back it all up!

This will be a live event in Toronto and the spaces are limited.

Here are the details!

Now, back to the newsletter!

There are few things less exciting than deciding how an employee ID or position code should be formatted.

It sounds like a task you delegate to a junior HR admin or an IT contractor on a Friday afternoon.

“Just make it something clean that people can read."

And so, someone sits down and designs what seems like an extraordinarily clever, organized naming convention.

It looks like this: TOR-FIN-MGR-0042

At first glance, it’s brilliant. Anyone looking at a spreadsheet or an org chart immediately knows what they're looking at:

• TOR = Toronto
• FIN = Finance
• MGR = Manager
• 0042 = Sequence number

It’s logical. It’s clean.

It makes us, human beings, feel like the universe is organized.

Until reality hits.

The Anatomy of a Database Nightmare

Fast forward eighteen months.

Employee 0042 gets promoted to Director.

Six months later, they transfer to New York.

A year after that, Finance gets reorganized and split into "Corporate FP&A" and "Accounting."

Now, you have a massive problem.

That position ID—TOR-FIN-MGR-0042—is lying to everyone who looks at it. The person holding it is a Director, living in Manhattan, working in Accounting.

Your People Analytics team is now faced with a terrible dilemma:

1. You update the key to NYC-ACC-DIR-0042. The ID is now accurate again! Except you just broke every historical record, downstream payroll mapping, ATS integration, and longitudinal engagement join in your data warehouse. To your analytics models, the old manager in Toronto vanished, and a brand-new director appeared in New York out of thin air.
2. You leave it as TOR-FIN-MGR-0042. Your integrations still work, but every reporting dashboard now requires custom logic to explain why "TOR" actually means "NYC" and "FIN" actually means "ACC." You’ve institutionalized technical debt.

This is what happens when you build intelligent keys (also known as semantic or meaningful keys).

By trying to make an identifier do two jobs at once, you guarantee that it will eventually fail at both.

Same goes for field storage.

Keep one idea in one field.

Identity vs. Description

The core issue comes down to a fundamental principle of data architecture that every People Analytics professional should memorize:

Your employee ID or position code should tell the database who or what something is—never where, how, or in what state it currently exists.

• Identity is permanent. Employee 847291 is Employee 847291, regardless of whether they work in Toronto, New York, or from a beach in Costa Rica.
  ​
• Attributes are temporary. Job title, location, department, manager, salary band, and employment status are constantly changing.

When you pack temporary attributes into a permanent identifier, you are creating a future lie. The moment the real world changes, your key becomes false, or your historical continuity breaks.

How Key Design Breaks Longitudinal Analytics

If you only care about snapshot reporting—how many people work in Finance today?—bad keys are annoying, but manageable.

If you care about longitudinal People Analytics—how talent flows through your organization over time—bad keys are catastrophic.

Here is what happens to your analytics pipeline when identifiers change every time an attribute shifts:

• Turnover & Retention: An employee moves from the UK to Canada, gets assigned a new "geographical" ID, and your model logs a turnover event in the UK and a external hire in Canada. Your tenure calculations reset to zero.
  ​
• Internal Mobility: You try to map career paths, but because position IDs were renamed during a company restructuring, you can’t trace whether a role evolved or was completely replaced.
  ​
• Rehire Analysis: An employee leaves and returns two years later. If your system assigns a new ID based on their new department, your systems treat them as a stranger, completely wiping out their prior performance and training history.

People Analytics relies heavily on building time-series datasets. Your ID anchor should not change.

Comparing Common ID Strategies

Not all key generation strategies are created equal.

Let's compare them:

• Sequential Numeric IDs (e.g., 100001, 100002)
  • Pros: Simple, short, completely meaningless (which is good), and easily understood.
  • Cons: Predictable. In some lightweight web portals, sequential IDs can present minor security risks if users can guess the next employee's record URL by adding 1.
• UUIDs / GUIDs (e.g., c82f9d50-4d32-4e89-a2e6-7b8c34f198d0)
  • Pros: Globally unique across disparate systems, completely meaningless, impossible to collision-predict. Fantastic for data warehouses integrating multi-entity systems.
  • Cons: Completely unreadable to human beings. Typing a 36-character string into an Excel lookup is a recipe for frustration.
• HRIS-Generated IDs
  • Pros: Standardized out of the box in platforms like Workday, SuccessFactors, or SAP.
  • Cons: Often tied strictly to a single instance. If your company undergoes an acquisition or migrates HRIS platforms, these IDs often get overwritten or mapped incorrectly if not properly governed by a central data warehouse.

What to do? What to do?

If you want an analytics environment that scales, survives HRIS migrations, and supports longitudinal modeling, follow these principles for your workforce records:

1. If you can look at an ID and guess the employee's department, level, or location, the ID is broken. Strip all semantic meaning out of your primary keys.
   ​
2. Once an identifier is assigned to an employee or a position, it must never change. NEVER! Not for promotions, not for rehires, not for global transfers.
   ​
3. Store location, job title, and department in dedicated data fields that can be effective-dated and tracked over time, leaving the key untouched.
   ​
4. Do not name positions based on their organizational hierarchy or job family code. Use an arbitrary position number (e.g., POS-994821) and map the reporting hierarchy separately.
   ​
5. If your ATS, Payroll, LMS, and HRIS might generate their own internal IDs. Ensure your central data lake maps all of these back to one single, system-agnostic enterprise employee ID.
   ​
6. When a position is abolished or an employee leaves, retire that ID permanently. Reusing an old employee ID for a new hire six years later creates phantom historical data that is a nightmare for us all.

The Best ID Tells You Nothing

K

Whenever you’re ready, there are 2 ways I can help you:

#1

If you’re still looking to get started in People Analytics, I recommend starting with my affordable course:

​Practical People Analytics: Build data-driven HR programs to 10x your professional effectiveness, business impact, and career. This comprehensive course will teach you everything from building an HR dashboard for business results to driving growth through more advanced analytics (i.e., regression). Join your peers today! ​
​

#2

If you are looking for support in your human capital programs, such as engagement, retention, and compensation & benefits, and want to take a more data-driven approach, contact me at Tskhay & Associates for consulting services. Or simply reply to this email!