Anonymising Lessons Without Losing Them
Shashank Manjunath
Every essay on this desk is built from a mistake someone made, on a real team, with a real client on the other end of it. I've written now about a dozen of them in some detail, and I have never once named the person who made the mistake, the client whose work was affected, or, in most cases, the exact team or division involved. I get asked, fairly often, whether that stripping-out costs the essays their credibility — whether "an analyst on a team I worked with" reads as vaguer, weaker evidence than a named case study would. I don't think it does, and I want to explain the discipline that keeps it from becoming that, because the discipline is the actual craft here, not the anonymising itself.
The easy way to anonymise, and why it's wrong
The lazy version of anonymisation is to sand the story down until it's generically true of any team anywhere — "a team implemented AI and had some challenges with trust." That version is safe and useless in exactly equal measure. It protects everyone and teaches no one anything, because the specificity that makes a lesson transferable is exactly the specificity that got sanded off in the name of caution.
The discipline I actually use is different: strip out everything that identifies the people, and keep everything that identifies the mechanism. A story about a junior analyst rubber-stamping AI drafts because nobody had established who was allowed to overrule the model is a story about a mechanism — permission structures, standing, escalation paths — and that mechanism is exactly as instructive whether I tell you it happened at "a mid-size Bangalore services firm" or refuse to tell you anything about the firm at all. What I strip is the firm's name, the person's identity, the specific client, the exact dates that would let someone triangulate who's involved. What I keep, deliberately and in detail, is every fact about how the failure worked — the sequence of decisions, the specific wrong output, the exact fix that resolved it.
"The people are private. The mechanism is the whole point of writing this at all. Anonymising the wrong half of that sentence is how a case study becomes useless."
The test I run before publishing
In practice this means a few concrete habits, developed the hard way after an early draft came uncomfortably close to identifiable. I never use a real title, department, or tenure detail that would narrow the pool of "who this could be" to a handful of people inside a firm anyone could name. I change or omit the specific client industry when the industry itself is identifying — "a client in a sector I won't name" rather than a specific vertical that, combined with the firm and the timeframe, would narrow things to one deal. I let enough time pass between an event and publication that the internal memory of "which quarter was this" has faded for anyone outside the small group who lived it. And I always, without exception, run the draft past the person or people most directly involved before it goes anywhere, not for their approval of the lesson, but specifically to ask: does this feel safe to you, reading it as a stranger would?
That last step has changed essays more than any other part of the process. People are, understandably, more sensitive to exposure than an outside editor would guess — a detail that feels harmless to me because I've forgotten which specific week it happened in can feel glaringly identifying to the person who lived it, because they remember exactly which week it was and exactly who else was in the room. Their read on the draft is the only read that actually matters for this test, and I've cut details on their say-so that I genuinely didn't think were risky, because the discomfort itself was the signal, not my own judgment of the risk.
- Strip identity, keep mechanism — the who is private; the how is the entire value of the essay, and the two are separable more often than people assume.
- Time and title are the real identifiers, not the story — a vague enough job title and a wide enough timeframe do more anonymising work than vague prose ever will.
- The subject's discomfort is the test, not my own judgment — I run every draft past the person involved and treat their unease as data, even when I can't see the risk myself.
- A sanded-down lesson isn't a safer lesson, it's a useless one — protecting people and stripping out everything transferable are not the same operation, and conflating them is the most common failure mode in this kind of writing.
A composite is not a fabrication
There's one more habit worth naming, because it's the one most likely to raise an eyebrow if I don't explain it: some essays on this desk describe a "composite" case — a mechanism I've watched play out, in slightly different form, on two or three separate teams, collapsed into a single narrative for clarity. I want to be transparent about when I do this and why it isn't the same thing as making something up.
Every mechanism I write about actually happened, more than once, in the form described. What a composite changes is the packaging: instead of writing three shorter, thinner essays about three teams that each hit a slightly different version of the same failure, I combine the clearest details of each into one coherent story, because the reader is better served by one sharp example than three blurry ones. The rule I hold myself to is that nothing in a composite is invented — every specific detail, every quoted line, every consequence, actually occurred somewhere in the underlying material — and I say so, briefly, when it applies, rather than letting a reader assume every essay here is a single unbroken narrative about one team. The alternative, pretending every story is a clean single-team account when the real material is messier and more distributed than that, would be a worse kind of dishonesty than the one anonymising is meant to solve.
"A composite collapses three real failures into one clear story. It never invents a fourth one to make the story neater."
Why this is worth the extra step
The honest version of this practice costs real time — every essay on this desk goes through at least one extra review pass specifically for exposure risk, on top of the normal editorial passes everything else gets. I keep doing it because the alternative isn't a faster version of the same essay. It's a different, worse kind of essay: either so specific it burns trust with the people whose mistakes it's built from, or so vague it stops being useful to the reader it's supposedly written for. The whole value of this desk is that it's written from inside a real rollout, with real, ugly, specific detail intact. Anonymising the people is what makes that possible to publish honestly at all, and it only works if you're disciplined about anonymising exactly the right half of the story.
If you're writing something similar about your own team, the shortest version of the discipline I'd hand you is this: ask, for every sentence, whether removing it would make the essay less true or just less traceable. Cut the sentences where the answer is "less traceable." Keep every sentence where the answer is "less true," even when keeping it is the uncomfortable choice, because that sentence is very likely the one your reader actually needed.
Shashank Manjunath
The Human Layer · Editor & sole writer
An Indian builder-operator writing about AI, teams, and the cross-cultural patterns shaping tech — read from Asia outward, with the West as the contrast class. This is a one-person publication; reply to any email and it reaches me directly.