Ask HN: How does your company keep track of lessons learned?

I have seen post mortems or "common problems" in knowledge bases, but outside of that the lessons learned were either addressed directly (improved process, fixed code, improved docs) or only in the heads of people involved:)

In "the circular filing cabinet"?

I work at a company with ~1k engineers.

Every every system failure, we email the entire org a postmortem google doc describing what went wrong, why, and what we are doing to prevent it from happening again. Postmortems are also as their own JIRA project.

We have implemented an collaborative wiki (wikimedia, like a copy of wikipedia but just opened for internal usage) in 2009, in a company with 200 employee. We engaged people to write everything that they think is good for the others.

email

Very fragmented all over the corporate network in all kinds of weird tools and applications.

They did make effort to standardize everything, but nobody seems to care.

We have a directory lessons_learned/ with *.md files.

It's a git repo and everyone can pull/push directly to master.

I skim the commits once a week.

It's basically plain text files. But the md extension triggers some nice eye candy in vim and other browsers.

I think we will keep this structure forever. Maybe we will (additionally) serve the files over http at some point. Maybe we might even add edit / search / push functions over http, but for now I have not planned that.

I have seen CMS come and go. And I'm tired of it. Text files are forever.

    grep -ir --color logo *

Keep and share are two different things. You can email or have a small meeting sharing results, but keeping a searchable, updated, database is hard.

Daily notes posted in slack where a bot logs to elastic search. Notes reviewed in our retros and the useful/actionable is logged in a wiki and or jira. Wiki notes are reviewed in our annual retro.

<sarcasm> My company is awesome in the sense to make sure it doesn't forget, it repeats the same mistakes every couple of years </sarcasm>

One of the first thing my co-founder and I did when we started our new project is create a table in Notion with all the previous lessons we had from our last company, and have been adding to it as we create fresh, new mistakes. Using tagging to keep it organised and readily available so when we start adding more people everyone has ready access to it.

We have a checklist system. Depending on which files are on your commit or which database objects are modified, you're presented with a checklist specific to the things you're changing. When something goes really wrong, the outcome of the post mortem often includes adding to or changing the checklist for the affected files/filetypes/team/whatever. It's not a perfect system, but it beats reading our long, confusing wiki pages.

Developing a postmortem culture is important to share the lessons learnt from production. For eg. Documenting and sharing the lessons learnt from a SRE perspective , a google doc would suffice. Some pointers at https://landing.google.com/sre/sre-book/chapters/postmortem-... Have seen Wiki being setup and fail and go stale very quickly. Lots of knowledge and learnings are tribal knowledge. Sharing tribal knowledge is effective in person or in a non wiki mode especially through brown bags or chapter meetings etc., Challenge is not everyone has the time or the energy / enthusiasm to be talking in front of a wide audience. Never seen one solution working effectively. You need to figure out the best approach based on the team culture and how the organisation is setup. For eg., some teams are hesitant to share knowledge and learnings with other groups - Conways law comes into play. End of the day it is not up to the company to track lessons learnt. It is the job or becomes the job of the person supporting production to a large extent to maintain it for making it easier to do their job. That being said , that knowledge leaves when that person moves jobs & the cycle continues

Reminds of the ironic naming of the "Lessons learned meeting". If no change is made to what people actually do, it's very hard to say that anything has really been learned, and I would put that first.

we are using a service called https://www.getoutline.com/

+ for being OSS

> How does your company keep track of lessons learned.

The dev overall, across the globe: i find retrospectives after a sprint cycle really good actually, it's a good place to call up where improvements can be made too.

On a personal level: When my mess up/mistake causes grief for someone else, I make damn sure I learn from that.

Bluntly: We don't bother. We don't even have reliable mechanisms for collecting feedback from customers.

I'm leaving soon.

I used to work for Google as an SRE a while ago.

They have pretty good procedures for keeping track of lessons learned. The book (https://landing.google.com/sre/sre-book/toc/) goes into some detail.

We don't!

One of the reasons why some people become valuable in long-tenure positions is because of the lessons learned. At a certain point, no one is going to read through every page in the wiki / archive / man pages / whatever is popular this year.

That's where onboarding and process come in: Management needs to make sure that lessons drive improving the process, that newcomers are onboarded with lessons from the past, and that everyone continues to follow the processes.

Now, jokes aside, in my company, the new owners decided they didn't like the people we were outsourcing with, and decided to replace them with their own outsourcing center. Now everyone's re-learning lessons that are probably tracked in our various wikis, repositories, ect. But, the newcomers want to run things their own way.

That's why a few long-tenured people are important.

We have Confluence pages that no one reads but it's nice we go through the exercise, I guess.

we have a wiki in microsoft teams, which no one ever reads...

Github repo with TILs (Today I Learned / Things I Learned)

At my employer we have two ways:

1. For large issues visible to customers an incident report is shared inside the company. These are written for general consumption and so lack any technically interesting aspects (they're "dumbed-down" a lot).

2. Technical "lessons learned" are curated in a Sphinx based documentation website that I started but which is starting to see more and more contributions from other tech heads in the company.

We used to have a wiki but it ossified after years of no contributions. Personally I didn't like the MoinMoin wiki engine that much but this is just personal taste of course. I started setting up the Sphinx site to encourage knowledge retention despite turnover - I kept explaining the same things again and again. Now I just share a URL when such questions come up :-).

We have a handbook based on Hugo for the tech folks thats editable by anyone and bloomfire for the general masses.

At company level lessons learned turn into internal rules. Too flexible holiday time results in more explicit rules about what is and what isn't allowed. The endgame is you become too bureaucratic after enough creative employees.