Telling People Before, Not After
What to say, when, and in what detail. The communication determines most of the outcome and is usually an afterthought.
How people find out determines how they respond for the life of the deployment. Discovery after the fact is not recoverable.
The people decision in “Telling People Before, Not After” cannot safely be reduced to a single activity measure. Used for ethical employee monitoring, ethical monitoring that preserves employee trust can provide time and project evidence, but expectations, context, documented outcomes and a fair conversation should remain the basis of any management judgement.
When
Before deployment, with enough notice to ask questions.
For an independent reference relevant to “Telling People Before, Not After”, consult the CIPD people-practice resources; it provides a useful external check on scope, terminology, governance and the claims made during procurement or review.
Before procurement is better: concerns shape what you buy, and some products permit configurations that others do not.
In several jurisdictions consultation before deployment is a legal requirement rather than good practice, and its own note covers that.
What to say
What is captured: the actual list, not a summary.
What is not captured, which is the part people read.
Why, in terms of the specific problem rather than general improvement.
Who sees what, at what level of aggregation.
How long data is kept.
Whether it will be used in performance or disciplinary processes.
And who to ask.
The question everybody has
"Will this be used against me?"
Answer it directly, in writing, whatever the answer is.
If it will be used in performance processes, say so — people will find out and the discovery is worse than the fact.
If it will not, say what prevents that, because an assurance with no mechanism behind it is not believed and should not be.
The detail level
More than feels comfortable.
"We are introducing some productivity tooling" is read as concealment and invites the worst assumption.
A page listing exactly what is captured, what is not, and who sees it is more reassuring than any amount of positive framing, because it survives being checked.
The capability question
People will ask what the software could do, not only what is enabled.
Answer honestly: these products can generally do more than you have turned on.
Then say what governs changes: who can enable more, and that any change will be announced.
That commitment is cheap and it is what makes the rest credible.
What not to do
Announce it in a paragraph at the end of an unrelated message.
Describe screenshots as "activity data".
Promise limits the configuration does not enforce.
Or deploy quietly and let people discover the agent, which guarantees the worst version of every subsequent conversation.
Keeping it current
Announce configuration changes.
Publish what the data has been used for, in aggregate, at least annually.
A programme that collects and never reports back looks like surveillance regardless of intent, and reporting back is also what makes the eventual review possible.
What to check
Were people told before deployment, with notice?
Is there a written list of what is and is not captured?
Does it say whether the data will be used in performance processes?
And has anything been published back since?