The problem with folders that grow organically
Most folder trees are not designed. They grow. A new folder is created whenever a file does not obviously fit, and over time you end up with folders inside folders inside folders, some with only one item, others holding hundreds. Names reflect the mood of the day: “Misc,” “Other,” “New Folder (2).”
The trouble is not that folders are a poor tool. It is that a structure built without a plan stops being predictable. A good structure is one where, if you know what a file is, you can guess where it lives. That property is what survives as files pile up.
Keep it shallow
Depth is the first enemy. Every extra level is another decision when saving and another click when retrieving. Three or four levels is typically enough for most personal and team use. When you find yourself at level six, the structure is probably doing work that names or search should do instead.
Width matters too. A folder with dozens of subfolders is hard to scan. Aim for a modest number of items per level, often under a dozen or so, and when a folder grows past what you can comfortably read at a glance, consider whether it should be split by a clear criterion, such as year.
There is no magic number. The test is whether a person can find the right folder without thinking hard about it.
Pick a primary way to divide things
Files can be organized by project, by client, by type, by date or by status. The mistake is mixing these at the same level. A folder containing “Clients,” “2025,” “Invoices” and “Drafts” forces constant ambiguity: where does a 2025 invoice draft for a client go?
Decide on one primary axis for the top level, then use a different, consistent axis below it. Some common choices:
- By project or client. Works well when most of your work is organized around distinct engagements. Inside each project, use a standard set of subfolders.
- By area of responsibility. Useful for ongoing roles, such as finance, marketing and operations, where work does not have a clear end.
- By date. Works for records that accumulate regularly, such as tax documents or receipts. Year folders keep each pile bounded.
- By type. Often the least helpful as a top level, since documents, spreadsheets and images from one project end up separated. Type works better as something search can filter on than as a folder.
The pillar discussion of file organization explains how to choose by starting from how you look for things.
Use a standard internal layout
Once you have project folders, copy the same internal structure into each. For example (hypothetical):
- 01 Brief and planning
- 02 Working files
- 03 Deliverables
- 04 Records and correspondence
Number prefixes keep the order fixed instead of alphabetical, and the repeated layout means you never wonder where something goes. A blank project template folder that you copy for each new engagement turns this into a few seconds of work, a technique related to document templates.
Resist adding a unique structure to each project. The value comes from sameness.
Separate active, reference and archive
A structure that mixes current work with long-finished material gets harder to use each year. A simple top-level split helps:
- Active. Things you are working on now. Kept small.
- Reference. Material you consult but do not change, such as policies, manuals or research.
- Archive. Completed work, moved out of the way but still stored.
When a project finishes, it moves from active to archive. The mechanics of doing this well are in project archiving. This cycle is what keeps the active area from growing indefinitely, and it is the main reason a structure can continue to work for years.
Add an inbox and avoid “Misc”
Include one landing folder for unsorted items, and process it regularly. A folder named “Misc” or “Other” is different: it becomes permanent and fills up with files nobody can find. If you notice a “Misc” folder growing, treat it as a sign that a category is missing, and create it.
Name folders for what they hold
Folder names follow similar principles to file names. Use plain, specific words, and keep them consistent. Spell client and project names the same way everywhere. Avoid names that depend on context only you know, like “Stuff from John.” The conventions discussed in file naming apply here, particularly the idea of sorting well.
Do not create a folder for one file
A common cause of excessive depth is creating a folder as soon as there are two possible homes for a file. Instead, wait until a group of files is large enough to need containing, perhaps five to ten. Until then, keep them in the parent folder with descriptive names.
Shared structures need care
When a team shares folders, the structure has a social side. People will save files wherever it seems reasonable to them unless the rules are clear and visible. Write the top two levels down, and limit who can create or restructure folders at the top. Moving a folder in a shared drive can break links people have saved or sent, so changes should be announced. Sharing permissions should follow the structure so that confidential folders are not exposed by accident, and a clean layout makes access easier to review.
Don’t rely on folders alone
Folders force a file to live in one place, but many documents belong to several categories. Tags, search and links can cover those cases. If a file relates to both a client and a topic, put it in its main home and make it findable through its name or tag in the other. Using a single, strict hierarchy for everything is usually less practical than combining a simple structure with good names and search.
Test and adjust
To check whether your structure works, try retrieving five random files from the past year and time yourself. If any take more than a minute, find out why: was the folder unclear, the name vague or the file in the wrong place? Adjust, then check again after a few months. A structure should be revised when work changes, not treated as permanent.