team
A team of seven has no shortage of documents. There is a shared drive with four years of files in it, a wiki that two people update, a channel where the real answers get typed and then scroll away, and at least three documents called "process v2 FINAL". Nobody is missing information. The problem is that finding the current version of anything takes a message to a colleague, and the colleague is not certain either.
This is what documentation management actually means at small scale. It is not the enterprise records problem of retention schedules, audit trails and regulated archives. It is a placement problem: for each kind of thing a team writes down, there has to be one obvious home, and everyone has to know which home it is without being told again. Most of the pain comes from a handful of decisions that were never made, so the same document ends up in three places and none of them is authoritative.
Storage stopped being the constraint a long time ago. Every team already has more than enough space, more than enough places to put a file, and usually more than enough search. What teams do not have is a way to tell, at a glance, whether the document in front of them is the one that counts.
Three symptoms give it away. Somebody asks a question in chat that is answered in a document, because asking is faster than trusting the document. Two documents describe the same process and neither says which supersedes the other. A new hire is onboarded by a person rather than by reading, because the written version is known to be stale.
Authority is the thing to design for. A document has authority when three things are true about it: exactly one copy exists, its location is predictable from what it is, and someone is named as responsible for it. Large document management systems buy that with check in and check out, permissions and version trees. A team of seven can buy it with conventions, and conventions cost nothing except being enforced for the first two months.
The order matters here. Teams almost always try to fix findability first, usually by adopting a new tool with better search. Search on top of five unreconciled copies returns five results and solves nothing. Decide what is authoritative, then make it findable.
Nearly everything a small team writes falls into one of three kinds, and the reason a single tool never feels right is that the three have opposite requirements.
Reference is the document that answers a question repeatedly. How deployment works, what the refund policy is, how to set up a laptop. It is read far more often than it is written, it should have exactly one version, and it is worthless if it is out of date.
Decision records capture what was chosen and why. Why the database was not migrated, what was agreed with a client about scope, which of two designs was picked. These are written once and never edited. Their value is that they are frozen, and editing one destroys it.
Working notes belong to a piece of work in flight. The brief, the list of open questions, the draft copy, the screenshots someone pasted in. These change constantly and then stop mattering the moment the work ships.
| Kind | Read or written more | Should it be edited | Best home |
|---|---|---|---|
| Reference | Read, many times | Yes, kept current | A wiki or docs space, one page per topic |
| Decision record | Read rarely, matters greatly | No, frozen once written | Attached to the work it decided, or a dated log |
| Working note | Written constantly | Yes, until the work ships | On the card or task itself |
The common mistake is to put all three in the wiki. Working notes flood it with pages that are dead within a fortnight, which is what makes people stop trusting the wiki for reference. The second common mistake is to keep all three in chat, where nothing can be edited and nothing can be found after a month.
The single change that clears out the most clutter is moving working notes to the work item. If the brief, the acceptance criteria and the open questions live inside the card for the job, three problems disappear at once.
Nobody has to name or file the note, because its identity is the task. Nobody has to hunt for it, because whoever is doing the work already has the card open. And it dies correctly: when the card is done, the note goes with it into the archive instead of sitting in a shared folder looking like current documentation.
This is why the description field on a task matters more than it appears. A card that holds only a title forces the real content somewhere else. A card that supports headings, lists, pasted images and attachments can hold the whole brief, and then the note and the work never drift apart. Most modern task tools support this, and it is worth checking how much a card can actually carry before committing to one. The features that decide this are rich text in the description, file attachments, and a comment thread on the card itself.
The comment thread does a job that is easy to miss. Questions about a piece of work get asked and answered somewhere. If that somewhere is chat, the answer is unfindable in a month. If it is the card, the reasoning stays next to the thing it explains, and the decision record largely writes itself.
Reference documentation rots, and it rots quietly. The page that described the deploy process is still there, still readable, still confidently wrong about the step that changed in March.
Two fields fix most of this, and neither requires a tool that supports them natively. The first is an owner, written at the top of the page as a name. Not a team, a person. A document owned by "engineering" is owned by nobody. The second is a review date, also at the top: the date the content was last confirmed as true, not the date the file was last touched. A typo fix changes the modified timestamp and tells the reader nothing about accuracy.
A team of seven does not need fifty reference pages. It needs perhaps fifteen, each of which somebody would actually miss. The discipline is to delete rather than archive. Archived documents still turn up in search and still get read by the person who does not notice the label.
A workable rule is that every reference page must answer a question someone asked in the last six months. If nothing prompted it, it is a page written to feel organised, and it will be wrong before anyone reads it.
Deep hierarchies are where documents go to be lost. Two levels is usually enough: a handful of areas, and pages inside them. If a page could plausibly sit in two areas, the structure is already too detailed for the amount of content, and flattening it will make things easier to find than any amount of tagging.
There are two honest options for a small team, and the choice is less about features than about how many places people have to check.
A dedicated document tool gives better editing, better nesting and better search within documents. A work tool that holds documents keeps them next to the tasks they describe, so there is one fewer application to open and one fewer login to manage. Teams that pick the dedicated tool often end up with a wiki nobody opens, because the work happens elsewhere and the wiki requires a deliberate visit.
| Approach | Strength | What it costs |
|---|---|---|
| Dedicated document tool | Strong editing, nesting, document search | A separate place to check, and drift from the work |
| Documents inside the work tool | Notes sit with the task, one login, one search | Less powerful for long structured reference pages |
| Shared drive with files | Familiar, works offline, no new tool | No version authority, no ownership, weak search |
Notion's free plan, to take one widely used example, is positioned for individuals organising personal projects rather than for teams, so a team using it collaboratively is looking at a paid tier per member. A side by side look at how a document oriented tool and a board oriented tool differ in practice is set out in the comparison with Notion. The point of the comparison is not which is better but which shape matches where the team already spends its day.
Price is worth checking against how many people genuinely need to write rather than read. Many tools charge per member regardless, while some do not count view only guests. For a team where three people write documentation and nine need to read it, that distinction changes the bill more than any feature does.
Documentation management includes a question that only becomes urgent once: what happens when someone leaves.
If reference documents sit in individual accounts on a personal drive, departure takes them. The fix is not a policy reminder, it is placing documents in team owned locations from the start, so that no single account's removal can orphan anything. Check this by asking whether any current document would become inaccessible if one named person's account were closed today. If the answer is yes, that document is in the wrong place.
Joining is the mirror image, and it is the best available test of the whole system. Hand a new colleague the documentation and nothing else for their first day. Whatever they have to ask a person is a gap, and the list of questions they ask is a better backlog than any documentation audit. Run it once per new hire and the set of reference pages converges on the ones that matter.
External access deserves one decision made in advance rather than repeatedly in the moment. Contractors and clients need some documents and must not see others. Deciding that before anyone is invited is far easier than auditing permissions afterwards, and it usually means keeping client facing material in a separate space rather than relying on per page permissions.
Pick the ten reference pages the team actually relies on, put a named owner and a confirmed date at the top of each, and delete or genuinely retire everything else in that space. Then move working notes onto the tasks they belong to, so the reference space stops filling with documents that were never meant to last. If the second half of that is the harder part because the task tool cannot hold a real brief, Pinateca puts rich descriptions, attachments and a comment thread on every card, free for up to five people and ten boards.
A wiki is better for reference material that must stay current, because pages have one location and one version. A shared drive is better for files that are naturally documents in their own right, such as signed contracts or exported reports. The problem is not choosing the wrong one, it is using both for the same content without deciding which is authoritative.
Far fewer than most teams expect. A useful test is that every reference page should answer a question somebody asked in the past six months. Ten to twenty pages covers a team of around seven people, and a larger set almost always contains stale pages that quietly undermine trust in the accurate ones.
A document management system is software for controlled storage of files, with versioning, permissions, retention rules and audit trails, aimed at organisations with compliance obligations. Documentation management at small scale is the practice of deciding where each kind of document lives and who keeps it current. The practice matters first, and most small teams never need the software.
By putting a confirmed date and an owner at the top of every reference page and reviewing anything older than six months. The modified timestamp is not a substitute, since a formatting fix updates it without confirming a single fact. Reviewing on a schedule works better than reviewing when a problem surfaces, because by then someone has already followed the wrong instructions.
Decisions belong with the work they affect, which in practice means on the task or in a dated log that is never edited. Full meeting notes are rarely read again, so the useful output of a meeting is the decision and the reason for it, recorded where the next person working on that item will see it. Keeping the discussion attached to the card removes the step of writing the record up separately.