Why we auto-delete slack messages - killing tribal knowledge at Last9
At last9, we auto-delete slack messages after 2 days on all personal Direct Messages. These retention policies force teams to improve documentation, kill tribal knowledge and drive accountability for mistakes, errors.
Why we auto-delete slack messages - killing tribal knowledge at Last9
“The best history of mankind is preserved in caves because it was set in stone. The short messages that pigeons carried, no matter how important, disappeared.” - Piyush.

I’m a Science buff. Turns out a bunch of folks at Last9 love SciFi. Even better - A bunch of em love Cixin Liu’s Remembrance of the Earth series. It’s one the best SciFi books I’ve ever read. It’s adored by millions, and has an entire litany of fan theories and literature around the future of humanity. It’s profound, as much as it’s educational. A particular piece in the 2000+ page series captures one among many profound revelations;

💡If we want to store data for a billion years for future civilizations, what would be the most ideal way?

Hmmm…

“If you count the markings made on stones back when our ancestors, the hominids, made the first tools as information, then the earliest instances occurred during the Pliocene, two point five million years ago. And we did indeed find information left one hundred million years ago, though it wasn’t left by humans: dinosaur footprints.”

The book concluded, after extensive research and experimentation, following multiple proposals, everyone agreed that the best way to preserve information was…

💡Carving words into stone.

… 🧐

Mind you, this is a fictional book spanning 18.9 million years. And that was the best solution. It’s profound, because for the space we operate in, shared context is critical, but also hard. Knowledge is hard. Transmitting this knowledge from one mind to another, with all its shared context, is even harder. And yet, so much of software engineering entropy can be averted by sharing this baggage of context. But, here’s the hard truth: We will fail. That’s inevitable. But fighting for its pursuit is a marked differentiator in any org.

Ok, enough theory.

Calculate the time taken to onboard any new joinee in any function. This is hard. In engineering, it’s the hardest of all. Because code is hard. Analyzing the biases of someone else’s code; nightmare. But to be true, this is for all functions in an org.

What if there was a way to nip this by dictating everyone to share context by writing? That’s half the problem solved. Because this information is there forever. You just need to build a second brain to map this information at the most relevant times.

Now, suddenly, documentation takes precedence.

Aysnch comms give us time to weigh and factor decisions. It’s persistent, and lasts for others to understand shared context. Real-time comms are like mini-dopamine hits that can fester entropy over time.  

Some bug with EMEA customers - show me documentation on what happened, how did you spot it, what did you do, have we informed customers, time taken to fix the issue et al. Now, context is across the org. Anyone can look at this doc, ask questions and get answers. This stays on for posterity.

Writing is, after all, thinking better.

A culture of transparency

As a company, we’re in the business of eradicating all forms of tribal knowledge. This starts with dogfooding - practicing what we preach.

For the uninitiated; what’s tribal knowledge you ask?

Any form of knowledge that’s not documented anywhere, and is passed on from person to person. These Chinese whispers, ‘he said, she said’ is how orgs suffer from sub-optimal velocity in building products, processes and people.

As an org, we want all knowledge to be documented, and hence, our slack has a strict 2 day retention policy on personal DMs. This forces folks to talk on channels and… act. If things are not sorted async, it goes in documents. This is a trove of knowledge for everyone in the org. We can glean through past failures, and remediate better.

Behaviourally, it helps us get away from trying to debug issues on slack, and focus on core, actual work. Culturally, this helps us across the board. Slack gives context, but the larger piece around knowledge rests for the entire org.  

To be sure, this is not easy initially. Every new joinee has a learning curve when they realize slack messages ‘disappear’. But these policies help us collectively. Oh, and things we’re particular about: No private channels. This should be obvious by now.

Shaping culture should start by inclusion, not exclusionary high-handedness. Even our sales call mistakes, failures are all public to the org so we can all learn.

These are small steps, but given the intrigue among folks, thought i’d pen some thoughts around how we approach synchronous comms.

And therefore, Slack should forever be a volatile medium; a feature, not a bug. 😜


Want to know more about Last9 and our products? Check out last9.io; we're building reliability tools to make running systems at scale, fun, and embarrassingly easy. 🟢

Share to:
Twitter
Reddit
Linkedin
#Deep Dives #Last9 #Last9 Engineering

You might also like...

India vs Pakistan, Site Reliability Engineering, and Shannon Limit
India vs Pakistan, Site Reliability Engineering, and Shannon Limit

How does one ‘detect change’ in a complex infrastructure, so you don’t lose out on critical revenues — A short SRE story

Read ->
Battling Alert Fatigue
Battling Alert Fatigue

Alert fatigue is a silent productivity killer. Eventually, the most relevant alerts are un-checked, killing customer experience. Here are some tips to reduce alert fatigue

Read ->
Guide to Service Level Indicators and Setting Service Level Objectives
Guide to Service Level Indicators and Setting Service Level Objectives

A guide to set practical Service Level Objectives (SLOs) & Service Level Indicators (SLIs) for your Site Reliability Engineering practices.

Read ->

SRE with Last9 is incredibly easy. But don’t just take our word for it.