> What does this look like in practice? There are basically _four_ systems where we store information: Recordings of Meetings, good if you want to re-watch a m

> What does this look like in practice? There are basically _four_ systems where we store information: Recordings of Meetings, good if you want to re-watch a meeting you missed. Google Documents which I would consider more ephemeral, (but then our Frontend Meeting goes back hundreds of pages as a Google Doc). Slack is used, we have hundreds of channels. Actually information is not retained forever in Slack, which I like because it forces people to document things elsewhere. The biggest benefit: git + issues / merge requests. Most of our handbook and company policies are markdown files in git. So even with renames and reformatting you can track the MR that changed it and 99% of the time find the reason _why_ someone changed it. Either the assumptions are still valid or you can propose another change if they aren't. If it is really dubious as to why something is the way it is, there will be someone responsible for that thing and you reach out. > How easy is it to find relevant information in the archives or documentation? Very. (Most) of the handbook is public, so any search engine is your friend. Google Docs search is alright. Otherwise checking things out locally is easy too and the history / relevant things are right there. Furthermore we have dozens/hundreds of Slack channels, where you ask your question and usually you get a relevant answer which you can document in a better and relevant place. > Are there times when you cannot locate such information and must wait for the appropriate person to be online to get an answer? If so, what types of communications typically cause these delays? As an employee it happens from time to time, think Finance, or Legal, or Compliance or Human Resource issues. As an Engineer, you get used to it. You never work on "one thing" any given day, but you kind of adopt a strategy where moving slow means moving fast. It sounds like a contradiction, but if a lot of people have kind of equally important streams of work going on at the same time, each person can move forward and we always have enough relevant things being finished every day/month/year for our users and customers. So personally I look at my highest priority for the next week / day, try to identify whether I need input from others early (no better: earlier) and make sure I get this feedback and resolve blockers. If I run into new blockers, I solicit new feedback as early as possible, e.g. by pushing a broken/unfinished MR and pinging the relevant people on it, asking their opinion. Once the code is ready, fan out and get all the approvals needed. I think a small bug-fix is mergeable within a day, medium sized addition 3 to 5 work days and big feature better be chunked into Feature Flag + a few of those medium sized additions.