Hi, I'm Colten.

Engineers solve problems. There can't be anything more important than a clearly defined problem, otherwise known as a requirement.

User stories are a fantastic formula for writing one down because they carry the bare minimum context: this user is facing this need, and solving it will provide this value. That formula works for features, and it works for bugs too.

Writing things down, especially as requirements, empowers teams to collaborate well, stay on the same page, and criticize the actual report instead of each other. Sometimes something is a feature, not a bug. Sometimes somebody has a real need, but only because they don't know how the system works, or that a feature already exists that could serve them. With clear problems, engineers can plan and implement effectively, a team can communicate well, and a business can move forward aware of its own history. This is how you avoid repeating mistakes.

I took much of this from my time at Amazon, where the writing is second to none. Teams write business value documents, requirements documents, high and low level design documents, one pagers, and that is just the tip of the iceberg. The culture there says every meeting must have a collaborative document where folks can easily leave comments and questions. Just about every meeting starts with fifteen minutes of silence while everyone reads the document and leaves comments. Then a brief touch base: any high level thoughts before we dive into the comments? The meeting leader walks through every comment and leaves updates right in the document. There is a paper trail, everybody has been heard, and every topic gets addressed.