In all of my coworkers across all projects, I'm the only one who does this. I'm pretty sure nobody reads them either. I don't mind though, it has paid for itself countless of times already, since I always reference it.
Today our 40 person org has 1,337 knowledge base articles (as of yesterday, a coincidence, and we probably have a different number today).
It started with myself (CEO) creating all of the initial documentation.
3 months after my first employee joined, I started holding her accountable to creating and updating documentation.
It's not a one time thing.
You can't say, "your job is to do documentation" once.
It's consistently talking about it.
It's scoping in documentation updates and refreshes into bi-weekly sprints and quarterly goals.
Once she was onboard, we began to hold everyone else in our organization accountable too.
Again, it's never a one time thing to get anyone bought it.
It needs to be constantly discussed and scoped.
Today, all of the managers are bought in.
Instead of me explaining the importance of documentation, it's our org's managers embodying and instilling the culture of documentation into everyone new.
They understand the value of having their reports check the KB first.
They understand the value of being able to link someone to a KB instead of repeating themselves.
They understand the value of being able to work more async.
They understand the value of not being a bottleneck for someone else.
I stopped spending much time creating documentation about 6 months ago - and the number of documents just keeps increasing.
Today, I'll push documentation forward for new position / roles.
I'm working on delegating finance - and spent a bunch of time putting together documentation on how to handle the company's money.
- Expense policies
- Org software purchases
- Invoicing and payroll
- Phishing and security
- etc
Auto generated READMEs (and their handcrafted equivalents) are worse than useless. Not only are you wasting your time creating one (and giving yourself the sense of having accomplished something when you haven't) but the effect of a README creation is one-to-many, so consider that wasted time and then throw a multiplier on it. That's the cost of a dummy README. Don't create them, people.
It’s a mixed blessing. In that case, the people who peppered us with questions slowly learned to find answers themselves. On the flip side when people ask you questions you get a better idea of what’s going on elsewhere in the project.
Later though, when it turned out we had a bad batch of hard disks on our dev boxes, the setup docs went from pretty okay to complete.
My wife asked me to write out on a piece of paper all of our bank, investment and insurance account names, numbers and passwords just in case I died during my last business trip.
Like any backup plan, unless it’s regularly tested it should be presumed to not be working
https://www.macrumors.com/2021/06/08/ios-15-legacy-contacts/
I still probably need a technical executor for some of my encrypted stuff as that's a little more complex.
I ended up passing and my only protection right now is the disability insurance offered by my employer. Experts say these policies are almost worthless, but they’re better than nothing.
Like all true insurance, we’d expect disability insurance to be expected value negative but this isn’t something it’s practical to self insure.
I'm reminded of how so much of what we know about history is because of the diaries and correspondence that happened to survive to the present day. There are surprising gaps in what we know about day-to-day life in the distant past because nobody bothered (or was able) to write it down.
People usually bias their writing towards what they consider to be important information. And they leave out what they consider obvious context.
So we have a lot more information about battles and kings, then about daily life.
People are less biased towards highfalutin in the ways they produce garbage.
Battles and kings and things that seem important when they are current, but aren't as interesting in a few hundred years as insight into daily life.
Can you give some advice around that? Was it one blog in general, one per team, per person? What tool did you use for it? What else do you think is notable about it?
The notable thing about the system was that people began to know their colleagues better, discover stuff together, and partner up to do interesting experiments.
Before that, I started by writing fortnightly newsletters to everyone in the company. It was just what happened in the last two weeks. I was just the messenger. I highlight designers, developers, DevOps, QA people, etc., with snippets of their exciting work. It became an instant hit.
I'm not particularly fond of managers/leads who do the talking for what their team or juniors did. So, I had to bring in that culture of every doer doing their talks or bringing them to the forefront. The only way to start that was to write to everyone who did what last week. Now, when I get in that junior developer to talk about what he did, his thinking behind it in the next meeting, people know and are prepared. Also, even if some managers/seniors continue to talk over their junior team, people already know who did the work.
I dig that saying. It’s a sad thing, but a good developer should make themselves obsolete by the end of their run. It’s our form of ethics.
I stumble on one DevOps guy who wrote every bloody thing happening in the system. He likes doing it, but from the way people were asking questions in the common chatrooms, group emails, I knew nobody read them. He loves plain text, nicely formatted with the old-school Unix-styles et al. I had talks with him outside of work and found him fascinating; I asked him help with my hobby, home-lab tinkerings, etc.
By that time, I had already started internal blog groups and was encouraging people to write. And indeed, a lot of people came out to write about engineering, marketing, product, and it became a routine for people to show off what they can do, what they love, and what they are good at.
In one of my regular company-wide emailers, I dedicated a big piece to the DevOps guy, pointing to his work and the beauty of his documentations. People loved it, and they began reading it. He remained a friend. That mailer was the only way I could highlight people I encounter doing good work, to the whole team up to the CxOs.
By the time I left the company, I was responsible for many vital things in the company, but I could transition everything smoothly with the documents and credential details (thanks to 1Password).
In the last year or so, I have been thinking more about -- always be dying. I think the similar vein of Always be Quitting; I try to document, write out details, just in case I die and my family has to figure out the intricacies.