Skip to content
allanninal.dev/build
Collaborate

Part 3 of 7 · Exit interview collector series ~5 min read

How answers stay separate from people

This is the part that determines whether anybody answers honestly, and it is easy to claim and easy to get subtly wrong. The claim being made is specific and limited, and worth stating precisely rather than as a reassuring adjective.

Key takeaways

  • Two tables: leavers, and responses. No query in the system joins them.
  • The token linking a response to an ask is one-way and is not stored on the leaver.
  • The pair of responses from one person is linkable to each other, and to nobody.
  • What a leak would expose is stated plainly, because vague reassurance is not a control.
  • In a team of eleven, anonymity is not achievable and the system says so.

Two tables

How exit responses are stored separately from leaver identitiesA vertical chain of four steps entered by a box labelled A leaver, holding a name, dates and an address. Step one mints a response token that is random rather than derived, storing only its hash on the leavers table. Step two sends the link with the token in the URL. Step three receives the answers keyed by token into a responses table that holds no name, no email and no leaving date. Step four aggregates only, producing counts and themes. A note says the token is random, so knowing a leaver tells you nothing about which responses are theirs.AWS ACCOUNTA leavername, dates, addressMint a response tokenrandom, not derivedLeavers tablestores the tokenhash, not the tokenSend the linktoken in the URLAnswers come backkeyed by tokenResponses tableno name, no email,no leaving dateAggregate onlycounts and themesThe token is random. Knowing a leaver tells you nothing about which responses are theirs.
Fig 1. How the two tables stay apart. The token is random rather than derived, which is the difference between a separation and the appearance of one.
  • Database
  • App integration
  • Security & identity
  • Analytics
  • Front-end & mobile
  • People

Why random rather than derived

A token derived from an identity — a hash of the email address, say — feels clean and defeats the whole purpose. Anybody holding the list of leavers can compute the same hash and look up the responses. The separation is only real if the mapping cannot be recomputed, which means the token is random and the leaver row holds a hash of it rather than the token itself.

The consequence is that once a link is sent, nobody at your end can determine whose responses are whose. That includes whoever built the system, which is the property that makes the claim credible.

What is linkable

The two responses from one person are linkable to each other, because both asks use the same token. That is deliberate and it is what makes the comparison in Part 4 possible. They are not linkable to a name, a role, a department, a manager or a leaving date.

The leaving date is worth calling out. It is enormously tempting to store it on the response — it would let you trend feedback over time — and in a business with a handful of leavers a quarter it is very nearly an identity. So responses carry only the quarter they were collected in, and even that is only used once the quarter has several responses in it.

Being honest about the limits

What this system does and does not promise

  • It promises: nobody at your business can look up what one named person said, including whoever administers the system.
  • It promises: no single response is ever shown to anybody, in any report, in any form.
  • It does not promise anonymity. With eleven staff and two leavers this quarter, a theme about the warehouse rota is attributable by anybody who was there.
  • It says so on the form. “We cannot promise you cannot be identified from what you say. We can promise nobody here will be shown your answers on their own.”
  • A leak would expose: a set of responses with no names attached, and a separate list of who left. Joining them would require the tokens, which are not stored.

That third bullet is uncomfortable and belongs on the form. Systems that promise anonymity they cannot deliver get one round of honest answers, and then somebody works out who said what, and the well is poisoned for years. Promising less and delivering it is the only version that survives.

Deletion

What remains after a leaver record is deletedA horizontal row of five boxes. Leaver row: deleted at twelve months. Token hash: goes with it. Responses: kept, and now unlinkable. Themes: still work. Nothing to join: permanently. A note says after twelve months the separation is not a policy any more but arithmetic.WHAT DELETION LEAVESLeaver rowdeleted at 12 monthsToken hashgoes with itResponseskept, unlinkableThemesstill workNothing to joinpermanentlyAfter twelve months the separation is not a policy any more; it is arithmetic.
Fig 2. What is deleted and what remains. Removing the leaver row makes the separation permanent rather than procedural, and the themes keep working because they never used identities.
  • Security & identity
  • Analytics
  • Front-end & mobile
  • People

Deleting the leaver row at twelve months costs nothing — the responses do not need it and the themes never used it — and it converts the separation from something enforced by code into something enforced by the absence of data. That is a much stronger position to be in if anybody ever asks.

Next: how the answers become themes.

All posts