Remote Frog

Collecting data about work is relatively easy. Turning it into useful context without turning people into objects of surveillance is much harder.

People Analytics can help detect inequalities, improve processes, and better understand working conditions. But PA has a dark side. It can also manufacture opaque scores, reward what is easiest to count, and give a scientific-looking to poor decisions. The difference is not only in the model. It is in the purpose, the governance, and the decisions we allow the system to support.

RULE 1: We build context for decisions, not an oracle

An analytical signal should open up a conversation, not close it down. It can help reveal patterns in workload, opportunity, feedback, or mobility. It should not automatically dictate how much a person is worth. Anything else is basically buying tickets for disaster.

Rule 2: Seven principles for not losing the plot

1. Explicit purpose. Before starting a project, is it clear which decision the system will support and which uses are off-limits? What specific problem are we trying to solve?
2. Clear ownership with a credible sponsor. Or, in other words: who is interested, who will mobilize resources and support the implementation of whatever follows from the project, and who carries the risk? Obviously, whenever there is an owner and a client, we should define success measures too: how will we know the system actually helps?
3. Minimum necessary data. Collect what is essential, not everything that technically exists. It is also worth asking: what is the least invasive data that could still help? Real transparency. Explain what data is used, where it comes from, and who can see it.
4. Assess risks. Understand the project’s impact both when it works well and when it fails. What is the cost of a false positive or a false negative? Imagine explaining the system, with real examples, to the person most affected by an error. Could you justify the purpose, the data, the logic, and the appeal mechanism without hiding behind “the algorithm says so”?
5. Testable fairness. Look for differences in coverage, quality, and impact across groups when appropriate.
6. Access and correction. Allow errors to be reviewed and relevant context to be added. Responsible human review. We need a person at the end of the process. Not a decorative one there to tick a box, but someone with judgment, time, and the ability to question the system. Which obviously also means asking: how will that person understand and challenge the output?
7. Expiry and review. Metrics get old. Some deserve early retirement. We should not keep metrics around if they are no longer business priorities. Otherwise, let’s at least make sure the project and its artifacts come with a default expiry date. When will we switch it off if nothing happens that makes us think otherwise?

If any of these pieces is missing, we have a source of risk with a nice interface. And sometimes not even a nice one.

Side note: if you use proxies, be very careful

Sometimes you cannot measure exactly what you want, and you have to rely on a proxy. Fine. But if that is the case, use it with humility 😛 and make it clear what it captures, what it misses, and what it should never be used for.

The idea is to measure the system, not to classify individuals

Not everything that can be scored should be scored. And certainly not everything that gets scored deserves to make decisions about people.

Count to a million before building an artifact that measures people. People Analytics artifacts should always try first to measure processes, precisely so those processes can be improved.

People Analytics is at its best when it makes system-level problems visible and helps people make better human decisions. It loses the plot when it replaces a difficult conversation with a comfortable score.