How many employees do we have? Yerodin has been asking for three weeks. He does get answers, just a different number every time, and not one of them comes with a reason why that one should be the right one. Nothing is missing in the systems, not a row and not a status, and something is missing all the same — it simply never got written down, because nobody ever decided it.
The question comes from Yerodin van Dusseldorp, controller at FastChangeCo, the fictional company I use to make real situations from projects and coaching sessions tangible. The case behind it is real — I ran into it in a coaching session not long ago, and this was the question.
Last week was about a meaning that once existed and went missing on the way to the column. This time it runs the other way. The meaning was never decided at all. You cannot lose what was never decided, and you certainly cannot pull it back out of the data.
The column that looks complete
One question, three weeks, three numbers — and every answer arrives with a caveat.
Xuefang, junior data modeler, looks at the HR table. There is a column called employee_status, it is filled everywhere, and the values are clean and readable. As far as she can tell, everything needed is right there: filter on the right values and count.
Philomena has been at FastChangeCo for over fifteen years, and as a business analyst her job is precisely this: translating between the business and IT. She sits down with Xuefang and goes through the column. Those values come out of the HR system and describe how somebody is carried there — contract type, status, reason for absence. Which of them make a person an employee in the sense of Yerodin's question is a business decision, and no system makes that call. The company does.
Except here nobody ever did. Nobody forgot it either; the question just never came up while no one needed the number.
An AI gets no further at this point. It reads the column, spots the values and the pattern behind them faster than any of us. Which of those values add up to an employee, it cannot know — that was never in the data. That says more about us than about the AI, and I worked it through in the spring using the term customer.
Every answer moves the number
Maintained, complete, perfectly readable. It just never says which of these values make someone an employee.
So Philomena sits down with the people who ought to know. What comes back is not a number yet. It is a list of questions.
Somebody on a full-time contract counts, no argument there. Part-time is where it starts: one person, or half a person? Two different questions, and you end up with two different numbers. The gap is not a rounding error — in Germany 29 percent of everyone in work is part-time, and among women it is close to half. Is someone on parental leave still an employee? And is an employee still an employee while out sick — if so, up to what duration? Then the working student with his twelve hours a week, and finally the contractor who has sat on the team for four years and invoices through his own company.
Each of these questions comes down to a yes or a no, and each answer moves the number. FastChangeCo is a conglomerate with tens of thousands of people on the books. None of this is about decimal places, then: every single question here is worth hundreds or thousands of people.
Five open decisions, and almost 10,000 people between the smallest and the largest figure.
None of those decisions sits in the data. They were never made, so they cannot be there — no source system, however clean, delivers something nobody ever agreed on.
It went unnoticed for a long time. Every department worked out its own figure, each on its own quiet assumption about who belongs, and while the results lived in separate reports nobody compared them. They get compared the moment somebody looks at them side by side, or needs them for one shared report.
That was the aha moment in the coaching session. In the technical data model the question could not be answered, no matter how long we stared at it. Only in the business model could we work out what the definitions of an employee even are — and from there it was clear which data to select.
About this series: This is part 2 of 3 of "Data Modeling Fundamentals". The overview is in the hub article. Part 1 followed a single term through the three levels; part 3 arrives on September 23 with the method question and the checklist.
One number nobody agrees on — sound familiar?
Getting definitions out of the business, negotiating them, and writing them down so someone can count with them later: that is the core of the information modeling training. New dates are in preparation.
“That is already defined”
Four purposes, four different totals — and every one of them is correctly calculated.
This is where the objection comes in, and it is a fair one. When I put the question on LinkedIn in August, it came from Aaron Reese: the thing is defined, legally, through payroll. Whoever is on it counts, absences included; the contractor is not on it. The real question, he argues, is not how many employees you have but how many people work for you. And straight after that: if you outsourced your call centre, are they still yours?
He is right, for one purpose. For payroll the question is settled, and it was settled by the legislator rather than by us. The annual report works in full-time equivalents and lands on a markedly smaller figure. In Yerodin's capacity planning the contractor very much counts while the long-term sick person drops out. And whoever counts the IT licences needs yet another set: everybody who holds an account.
How much the counting rule drives the result shows outside of headcount as well. WIdO, the research institute of Germany's AOK health funds, analysed what illnesses lasting longer than six weeks amounted to among their insured employees in 2024: 3.3 percent of all sick-leave cases — and around 40 percent of all days lost. Same people, same illnesses, and depending on whether you count cases or days it is either a footnote or nearly half.
So there is no single number, there are several, and each belongs to a particular question. That is the job of the conceptual model: holding on to which definition belongs to which question. Which of them wins is not the job at all. Declare one the only true one and you have mostly handed the problem to the other three.
Who signs off on the definition
A conceptual model: one term, its subtypes, a definition and an owner for each.
Amal models it. It is far too early for a table; what it becomes is a term with subtypes (varieties of the same term): employee, with the individual forms of employment underneath, each carrying its definition in one sentence and an owner behind it. Plus the mapping of which purpose adds up which subtypes. At this point a conceptual model is no more than that, and it needs to be no more.
The uncomfortable part comes next. Nobody knows a definition like this, it has to be decided, and that takes someone willing to own it. In my experience it gets stuck twice on the way there. First, you often cannot find the people who can even say how it is handled today. And once you have them, whoever is allowed to make the final call turns out to be someone else again: they either do not want to, or want to run it past a dozen committees first.
At FastChangeCo, Michael Mueller takes it upstairs; he reports straight to the CFO, and for the annual report the number is her topic anyway.
What gets pinned down that way holds. A structure, a method, tables eventually: all of it comes on top and leaves the definition intact. There are approaches built on exactly that, keeping the business model clear of the technology — fact-oriented modeling (in German) is one of them.
What you end up with is one sentence per term that people have agreed on, and next to it whoever owns it. The diagram is the smaller result.
Now FastChangeCo knows what an employee is. That is still a long way from a table, and which method fits is the question after this one. That is next week — along with how you tell whether a model is any good.
So long,
Dirk
Sources
Part-time rate: German Federal Statistical Office, Mikrozensus 2024 (in German).
Long-term illness: WIdO, the research institute of the AOK health funds, analysis of absence days 2024 (in German), based on data for AOK-insured employees. Both are German figures; I work out of Germany, so those are the ones I can stand behind.
Aaron Reese's objection comes from the public discussion under this post from August 2026.
FastChangeCo is a fictional company; the numbers in the example are invented, their magnitudes taken from the statistics above.