In short
Searching for things is a distributed cost nobody records: a few minutes per instance, several instances a day, across everyone. Reduce it with three decisions rather than a reorganisation. Choose one location per type of thing, adopt a naming pattern that sorts correctly and states its status, and archive aggressively so that what remains is current. Do not rebuild the whole structure: apply the rules to new material and to anything you touch, because a reorganisation nobody maintains recreates the problem within a year.
Key takeaways
- The cost is invisible because each instance is small and nobody counts small instances.
- Uncertainty about which version is current is more expensive than the search itself.
- Name things so they sort correctly and declare their status. Dates first, status last.
- Archive ruthlessly. Most search difficulty is caused by old material competing with current material.
- Fix forward. Apply the convention to new files and anything you open, not to a weekend reorganisation.
The cost nobody measures
Ask anyone how much time they lose looking for things and they will say almost none, and they will be wrong, in the same direction, every time. The reason is that the unit is small. Ninety seconds finding a file does not register as an event, so it is never recalled and never counted.
The aggregate is not small. In a business where material is spread across a drive, an email chain, a project tool and someone's desktop, a person will look for something several times a day, and about a third of those searches end in a question to a colleague, which costs two people rather than one.
There is a second cost that is larger and even less visible: uncertainty. Finding a file is one thing; knowing it is the current one is another. When people are unsure, they either check with someone, which costs a round trip, or proceed on the wrong version, which costs a rework loop discovered days later. That second outcome is one of the four standard causes of rework described in rework: why your team keeps doing things twice, and it is entirely a filing problem.
The expensive question is not where is it. The expensive question is whether the one you found is the one you should be using.
Three decisions, not a reorganisation
The instinct is to set aside a weekend and rebuild the folder structure. This produces a tidy drive, an exhausted person, and the same disorder eighteen months later, because nothing changed about the behaviour that produced it.
Three decisions do more, and none requires a reorganisation.
| Decision | What it removes |
|---|---|
| One location per type of thing, written down | The hesitation about where to save, which is what produces desktop copies |
| A naming pattern that sorts and states status | Most of the searching, because sorted lists answer questions without a search |
| An archive that is used, not a folder called old | Current material competing with superseded material for attention |
Structure the first one around how work flows rather than around the org chart. Client work belongs under the client, not under the department that happened to produce it, because that is how people look for it. And keep the hierarchy shallow: three levels is plenty, and deep trees fail because filing correctly starts to take longer than saving somewhere convenient.
Naming things so they sort and declare themselves
A naming convention is worth having only if it does two jobs: makes a list sort into a useful order, and tells you the status of a file without opening it.
A pattern that achieves both:
YYYY-MM-DD — Client or project — What it is — Status
- The date first, in year-month-day form. This is the single highest-value element, because it makes chronological sorting the default rather than something you request. Dates written any other way sort meaninglessly.
- The client or project next, using the same name every time. Consistency matters more than which name you choose.
- What it is, in the words the team actually uses.
- Status last: DRAFT, FINAL, SENT, SIGNED. This is the field that prevents the uncertainty cost.
Convention, applied consistently, beats any folder structure. A well-named file is findable by search from anywhere; a well-filed file with an ambiguous name is findable only by someone who remembers where it went.
Write the convention down in one place with three examples. Conventions explained verbally survive about two weeks, and new joiners inherit whatever they can infer from what they see, which is usually the inconsistent version.
Versions: the expensive uncertainty
Version confusion is where filing disorder converts into actual money, because work built on a superseded document has to be redone and the error surfaces late.
The familiar failure is the suffix ladder: final, final-v2, final-USE-THIS, final-v2-amended. Everyone recognises it and it persists because each individual rename is rational in the moment.
Two rules resolve it:
- One live copy, in a known location. If your tools support editing in place with history, use that and stop making copies at all. The history is the version record.
- Superseded versions move to an archive folder immediately, rather than living alongside the current one with a different suffix. Proximity is what causes the wrong file to be opened.
Where a document genuinely needs numbered versions, such as anything sent externally or signed, put the version in the name and the date at the front, and keep only the current one in the working folder. The principle is the same one that governs data across systems in single source of truth: copies are acceptable, uncontrolled copies that can be edited independently are not.
Archive aggressively
Most difficulty finding things is not caused by poor structure. It is caused by volume: current material competing for attention with everything produced in the last four years.
An archive is not a folder called old that nobody opens. It is a deliberate separation between what is in use and what is retained.
- Move completed work out of the active area when the engagement closes, as a step in closing it rather than as a periodic clean-up.
- Keep the same structure in the archive. Retrieval should not require a different mental model.
- Archive on a trigger, not a calendar. Project closes, file moves. Anything scheduled for a quiet month will not happen.
- Check retention obligations before deleting anything, and note what those are somewhere findable rather than relying on memory.
The improvement from archiving is usually more noticeable than the improvement from restructuring, and it takes a fraction of the effort, because it addresses the actual cause.
Making it hold without policing
Any convention that depends on people remembering it will decay in the first busy week, which is the general failure described in why process changes don't stick. The version that holds changes the defaults instead.
| Instead of | Do this |
|---|---|
| Reminding people to use the naming convention | Templates that open pre-named, so the pattern is the starting point |
| Asking people to save in the right folder | Link the folder from wherever the work happens, so the right place is the nearest place |
| A quarterly tidy-up | Archiving as a step in closing a project, triggered by the close |
| A weekend reorganisation | Apply the convention to new files and to anything you open. The active set converts within months |
That last row is the one that makes this achievable. Fixing forward means the effort is distributed into moments when someone is already handling the file, and it concentrates on exactly the material that is actually in use. The files nobody opens are also the files nobody is looking for, and reorganising them is work with no return.
None of this is glamorous, and it is one of the few operational improvements that a small business can complete in an afternoon and feel within a week. The Mayim Ops assessment counts manual handling and rework hours directly, and time spent locating and verifying work is one of the larger components that never appears in anybody's estimate of where the week went.
Frequently asked questions
What is a good file naming convention?
One that sorts chronologically and states status: an ISO-format date first, then the client or project, then what the thing is, then status. Dates written as year-month-day sort correctly by default, which removes most of the need to search at all.
How do you organise a shared drive?
Decide one location per type of thing, mirror the structure your work actually follows rather than your org chart, and keep the hierarchy shallow. Deep folder trees are hard to navigate and harder to maintain, and people stop filing correctly as soon as filing takes longer than saving to the desktop.
How do you stop people saving files in the wrong place?
Make the right place the easiest place: templates that save to the correct location by default, links to the folder in the places people work, and a shallow enough structure that the right choice is obvious. Reminders do not work, because the failure happens when someone is busy.
Should we reorganise all our old files?
Usually not. Apply the convention to new material and to anything you open, and archive the rest rather than restructuring it. A full reorganisation costs days, is out of date within months, and does not address the behaviour that produced the disorder.
How do you manage document versions without a system?
Keep one live copy in a known location and move superseded versions into an archive folder immediately rather than renaming them with suffixes. Version confusion is expensive because it produces work built on the wrong information, which is discovered late and redone.