Placeholder for a Conversation

> I don't care if the body of the ticket is empty and as the Engineer you prefer to write it in a notebook.

> I don't care where the conversation gets recorded, or at all (provided the people are capable of remembering it).

That -"provided the people are capable of remembering it"- is quite a restriction you got there. If some engineer writes it in their own notebook, some other one simply goes by their own memories, etc, then I'm willing to bet there will be different memories of how it went and at least some of those will be fragmented or lost. And every time you need that information, you'll find yourself having to re-search it, re-compile it, and reconcile it again. And then someone leaves and that perspective of the conversation history is lost forever.

I mean, sure, don't put the tool over the actual conversation. But then again, please, do use a tool to register history, key arguments, accepted limitations, relevant decisions, actions taken.

> This is strong evidence of a team working with extremely shared context.

Not really, no. It may be a reflection of that... or it may be a reflection of something else entirely. Like some people making small notes so they will remember and nobody else reacting to them. Ideas that come up but are never discussed afterwards.

The visible result of this can be exactly the same as what you describe and yet the situation is totally different.

Decision logs are incredibly valuable for documenting __why__ a particular decision was made. This can be in Jira, wiki, or whatever your team uses.

When new people join and ask, "Why are we using X and not Y?" then you should have a place where you can refer them to that has a short list of those reasons, what was considered, and why a particular solution was used.

The premises upon which a decision was made will change over time, and when they do then that decision can/should be revisited.

My favorite tactic is to intentionally write down overly constrained or even "obviously" wrong tickets or issues or what have you, to provoke a disagreement and thereby spark a conversation.

You have to write down something for others to disagree with first, however. This is the function of the ticket.

I think this post is missing the final piece - folding those conversations back into the original ticket or document. That's how you record the output of conversations, decisions, and keep the document "alive."

This works until it doesn't. It's all fine and good to talk to someone verbally about big ideas, but don't make work out of it.

Otherwise you wind up with a VP calling you six months later demanding to know why something was done a certain way, it's costing the business a lot of money and all you can say is "I think I was told to do it that way"

I'm seething because you should have documented your conversation.