Writing things down, especially for action items, can clarify but also track decision making to improve it because some patterns become obvious.
For example, at some point when a colleague and I took over, I did a "post-mortem" of all the people who left the company (resignations and terminations) going back a year. I wrote down how these events took place, how they were perceived, etc. A pattern emerged and one of the things that exacerbated these events was information asymmetry. Our next step as people now involved in helping to manage was to reduce that asymmetry as much as possible, and to implement a more dignified way to fire people when it came to that, and the guardrails/flags to correct course to avoid getting to that point. We made sure the feedback was much more explicit when we dealt with people who'd keep on with a certain behavior after they acknowledge it was subpar. When we speak about it, and we document the thing and the intent to change that behavior, and we do it over and over, it serves to refresh memory if you truly are forgetful, and serves to prevent "but you never told me that" or "I didn't know you meant it that way" when someone is into that sort of things.
On the technical side we write good, detailed, issues. When we fix a bug/regression, we try and figure out what drove us to have that bug/regression in the first place. How did we go wrong in our thought process? How did a wrong assumption go unchecked?
These issues help us recognize patterns and notice we've already fixed N bugs that are similar to that one. We then go fix the underlying issues for a family of problems, technical, but also in terms of business process or thoughts. This can be refactoring, introducing tests, adding a checklist, documenting something, etc.
Why did I make that mistake and am I making similar mistakes? Can I solve for a root cause so that I cannot make that mistake again even if I wanted? How can someone else not make that mistake even if I never speak with them?
If we have a regression: why was this working and is not anymore? What changed? Why? How can we prevent that? This broke because I forgot a step in a process. It has happened before. How can I make the process succeed and decouple it from my memory or whether or not I had a good night of sleep? Can this be automated? Can a part of this be automated? We systematically go through that loop and introduce efficiencies that are needed to move fast as a small, tight, team so we can focus on what matters, instead of putting down fires, whether technical or administrative. We put fires, but if the fires start looking familiar, we handle the source. One way to figure out the fires look similar is by documenting things (issues, incident reports) because then the similarity is clear and staring at you and you go "duh!". Having these instances enables you to cluster into families of problems (technical, administrative, business) and solve a more general problem after you've solved one too many specific problem.
On the business side, I also analyzed our past projects and tried to figure out what worked and what didn't and the reasons behind them. This has shaped our current process of doing business. With that analysis, a certain number of things to clarify made it into a sort of checklist with our clients. For example, one of the things that doing that made us do is to explain very clearly to the decision makers that the people who will use our product [we do bespoke enterprise products leveraging machine learning] must be at the table. We need them at the table, or we know the project will fail. One other item is to make sure we nail down the problem with the client before we even get to the "ML" stuff or implementation. One other item was to make sure the person we are dealing with has decision power and the budget.
Doing this, we're much more profitable now with the third with one eigth of the number of projects and a high success ratio, because we don't start projects we know will fail [that don't check the boxes or where there are too many red flags].
I had a file called `lessons` where I documented mistakes. It could be anything, such as arriving almost late at a client meeting because I had assumed X, or not doing the proper diligence on something because of Y, or removing a line of code in a careless commit as I thought it did nothing because there was no reference to something, but it turns out it was used at runtime dynamically.
Therefore, when I say to document things, it's not only as a "cover your ass" or as an "exibit A" against people. It's to keep evidence against bullshit, even more so yours, and address it. The goal is to function, get the job done, learn, and build a better organization that can go on and do good thing.
Sorry for the sloppy writing and no editing. I wrote a bit about some of these issues here https://news.ycombinator.com/item?id=26182988
That answer contains links to other answers related to aligning the team, product, leveraging your time, communication, etc.