Promoted to the Team's Language — Trackers, Wikis, and Git (5)
Personal memos and notes are read only by you. Decisions and procedures the team needs to know should be promoted to the issue tracker, the wiki, and the repository. We look at Toss's automatic documentation, architecture decision records, the GitLab handbook, the documentation cultures of Google and Spotify, and the DORA research on the link between documentation quality and performance. Part 5 of the record-keeping AI workflow series.
My memory and notes are, in the end, read only by me and the AI. What colleagues need to know is shared only once it's moved into the team's language.
Stop at personal records and you're cut off from the team
Across the earlier articles we built up rules, memory, and notes. But all of it is a record only you and the AI read. Work with AI at length to reach a good conclusion, and if it isn't reflected in the issue tracker, wiki, or repository, colleagues have no way to know what you did. The moment you stop at personal records, you're cut off from the team.
That's why you need promotion — moving content referenced repeatedly in your daily notes, and procedures, decisions, and conclusions colleagues need to know, up into team systems.
Where you promote to
- Issue tracker (Jira, Redmine, OpenProject, etc.) — progress, ownership, deadlines. Put session results in a ticket comment or attachment. But "done" isn't the same as "resolved," so leave the verification result as a comment.
- Wiki (Confluence, Notion, Outline, etc.) — the canonical source for things like procedures, design decisions, and meeting conclusions. Written so even a new hire can understand, without cutting the context.
- Git repository — not just code and scripts but also skills, rules files, and settings. Shared across multiple machines and teammates, with the commit message doubling as a short work record.
The principle is one: a single piece of information lives as the original in only one place. Write the same content in three spots and it will surely drift apart. After promoting, don't copy the original into personal memory — leave only a link.
Leading teams already work this way
This isn't idealism — it's how strong organizations actually run.
- Toss built a system that summarizes Slack discussions and automatically accumulates them in a document store, and those documents in turn become training data for an in-house documentation chatbot. The title of their article is telling — Why Toss frontend developers no longer search for documents. Records piled up until even searching became unnecessary.
- Architecture decision records (ADRs) should live in the source control repository, not a wiki — that's the ThoughtWorks recommendation. Records have to move together with the code so they don't drift apart (ThoughtWorks Technology Radar).
- GitLab is famous for its "handbook-first" culture, writing its entire way of operating in a public handbook. This document, running to thousands of pages, is "the single source of truth for how we work," and it remains even after individuals leave.
- Google and Spotify have institutionalized treating documents like code — docs-as-code. Google uses Markdown next to the code (g3doc) instead of a scattered wiki; Spotify uses TechDocs in its developer portal, Backstage. In Korea, LINE has published a case of keeping developer documentation on GitHub and running it as docs-as-code.
Documentation isn't a cost — it's an amplifier
There's the objection: "I'd rather do more work than spend time writing docs." The data says the opposite. Google's DORA research has repeatedly confirmed that teams with better internal documentation quality get far larger performance gains from the same technical practices. The likelihood of hitting reliability targets was more than twice as high when documentation quality was good, and DORA sums it up: "quality documentation drives the execution of every technical practice we studied." Documentation amplifies the effect of the other practices.
Conversely, the loss when there's no record is exactly what we saw back in Part 1. When knowledge is bound to individuals alone (in the Panopto study, 42 percent of institutional knowledge existed in just one person's head), it vanishes wholesale the moment that person leaves.
Remembering it as a flow
The whole flow sums up like this.
Daily note → if repeated, memory → if the team also needs it, wiki → if everyone must follow it every time, the rules file.
The further down you go, the more people read it, and for longer. The AI writes the draft; a person does the final check for anything posted externally.
What comes next
In the final article we lay out the pitfalls you're bound to meet running this system, and an adoption roadmap split across four weeks so you don't burn out trying to do it all at once — Pitfalls and a 4-Week Adoption Roadmap.
If you'd like a picture of how to connect AI records to your team's tools (tracker, wiki, repository), reach out via Contact.
The "Using AI as a Colleague That Remembers" series
- Why AI Forgets Yesterday — Session Amnesia and the Cost of Context
- Rules in One Place — How to Write an AI Rules File
- One Fact Per File — AI Automatic Memory
- To the Me of the Next Session — Daily Notes and Handoff
- Promoted to the Team's Language — Trackers, Wikis, and Git (current article)
- Pitfalls and a 4-Week Adoption Roadmap