A Google Drive Folder Structure That Actually Scales
Almost every Drive structure I've inherited from another team had the same problem. It was organized by topic - "Marketing," "Engineering," "Legal" - and the topics were the wrong unit. The actual question people ask when they're looking for a file isn't "what topic is this?" It's "who is allowed to see this?"
Once we reorganized around access instead of around topic, search times dropped, accidental-share incidents stopped happening, and onboarding stopped requiring a 30-minute Drive tour. Here's the structure, in full, and the logic behind it.
The four top-level folders
📁 1 - Public
📁 2 - Company (all employees)
📁 3 - Teams (per-team access)
📁 4 - Restricted (project-level access)That's the entire top level. Four folders, numbered so they sort in a meaningful order, named by who can see them, not by what's in them.
Each of these top-level folders is a Google Shared Drive, not a regular folder. Shared Drives are owned by the organization rather than by an individual, so files don't disappear when someone leaves. If you're not using Shared Drives yet, switching is the single highest-leverage thing you can do in this whole post.
What goes in each one
1 - Public
Anything that's safe to share outside the company without any access control. Marketing collateral, the public brand kit, customer-facing templates, the press kit, public job descriptions. The rule: if a stranger emailed you tomorrow asking for this file, would you send it? If yes, it goes here. If no, it doesn't.
The benefit of having this folder is that you stop having a "is this confidential?" debate about every share. If the file lives in #1, the answer is permanently "no."
2 - Company (all employees)
Internal-but-everyone material. The employee handbook, the all-hands recording archive, holiday schedules, expense policy, internal org chart, the company OKRs. Default access: everyone in the company can view; only HR/ops can edit.
This is the folder that replaces a wiki for most companies. The advantage over a wiki is that you can search inside the documents themselves, which Drive does well and most wikis do badly.
3 - Teams (per-team access)
One subfolder per team. 3 - Teams/Engineering/, 3 - Teams/Sales/, etc. Access is per-team: engineers can see Engineering; salespeople can see Sales; cross-team folks (managers, exec) get access to the ones they actually need.
Inside each team folder, let the team organize however they want. Don't impose a sub-structure from above - teams know their own work. The contract is just the top-level access boundary.
4 - Restricted (project-level access)
Anything that needs narrower access than a team: M&A material, executive comp, board prep, sensitive customer escalations, legal disputes, the candidate folder during a search. One subfolder per project, access granted explicitly and revoked when the project ends.
Having this folder named "Restricted" makes the access model obvious to everyone, including new hires who would otherwise stumble into trying to open a board deck.
Naming the files inside
Top-level folder structure is the big win, but file naming inside matters too. Three conventions worth adopting:
Date-prefix anything time-bound. 2026-Q2 board deck, 2026-04 monthly review, 2026-03-15 customer call - Acme Corp. Drive's default sort is alphabetical, and ISO dates sort correctly as text. You instantly get reverse-chronological by clicking the name column.
Use status suffixes for documents in flight. Q3 pricing proposal [DRAFT], Vendor contract [FOR REVIEW], 2026 roadmap [APPROVED]. The status is at the end so the meaningful part is still searchable, but the state is visible without opening the file.
Don't put the file type in the name. "Q3 budget.xlsx" is redundant - Drive shows the Sheets icon next to it. Save the characters for description.
The two anti-patterns this replaces
Anti-pattern 1: "My Drive" as the source of truth. A new hire creates a folder in their personal My Drive, shares it with the team, and that becomes the canonical location for something important. Six months later, they leave, the folder goes with them, and the org has to scramble to recover access. This is exactly what Shared Drives exist to prevent - move everything important off personal Drive immediately.
Anti-pattern 2: A folder per topic, deep nesting. Marketing/Campaigns/2024/Q3/Email/Welcome series/Final/. The deep nesting makes everything slow to find and impossible to reorganize. The flat-ish access-based layout above usually maxes out at three or four levels deep, which Drive's UI handles much better.
What about Notion, Confluence, SharePoint?
Same principles apply. The specific tool matters less than the access-first organization. If your wiki is structured by topic, you'll have the same problem: an "Engineering" page that contains a section that should really be company-wide, and a "Public-facing FAQ" page hidden inside a team area. Reorganizing by audience instead of by subject is the cheap fix everywhere.
That said, Drive specifically rewards this structure more than a wiki does, because Drive's access model is per-file and the folder structure is what people use to reason about defaults. A confused folder hierarchy in Drive directly produces over-sharing or under-sharing incidents in a way a confused wiki doesn't.
The migration plan
If you're inheriting a chaotic Drive, don't try to do the migration in one weekend. The path that works:
- Create the four new top-level Shared Drives.
- Announce the new structure. Pin the explanation somewhere everyone reads.
- Move new files into the new structure starting now. Don't try to migrate everything historical.
- Set a deadline (90 days is reasonable) after which the old folders become read-only.
- On the deadline, migrate the files anyone is still actively using. Archive the rest.
This approach respects the fact that 80% of files in any organization haven't been touched in a year and don't need to be migrated at all. They just need to be findable when someone occasionally searches for them, and Drive search handles that regardless of which folder they're in.