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
| Drive | Contents | Default access | Common mistake |
|---|---|---|---|
| 1 - Public | Brand kit, press kit, public templates, job descriptions | Anyone, even external | Putting internal-only material here "because it might be shared" |
| 2 - Company | Handbook, all-hands recordings, expense policy, OKRs | All employees view; HR/ops edit | Treating it as a dumping ground for any internal doc |
| 3 - Teams | One subfolder per team; team chooses internal structure | Per-team membership | Imposing a sub-structure from above |
| 4 - Restricted | M&A, exec comp, board prep, hiring loops, legal disputes | Explicit grants only; revoked when project ends | Forgetting to revoke after the project ends |
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.
Sources & Further Reading
- Google Workspace: Shared Drives vs My Drive
- Best practices for organizing Shared Drives
- Sharing files and folders in Google Drive
- Google Workspace blog: Shared Drive best practices
Frequently asked questions
Why organize by access instead of by topic?
Because the question people actually ask when looking for a file is "who is allowed to see this?" not "what topic is this?" Topic-based folders collapse around year two as topics overlap and access creep happens. Access-based folders survive turnover, scope changes, and the slow drift of new file types.
Why use Shared Drives instead of regular folders in My Drive?
Shared Drives are owned by the organization rather than by an individual. Files don't disappear when someone leaves the company. If you do nothing else from this post, switch business-critical folders to Shared Drives - it's the single highest-leverage change you can make in Drive.
What about Notion, Confluence, or SharePoint - does the same structure apply?
Same principles, yes. Reorganize by audience instead of by subject in any tool. Drive specifically rewards this structure more because Drive's access model is per-file and the folder structure is what people use to reason about sharing defaults - which means topic-based hierarchies in Drive directly cause over- and under-sharing incidents.
Should I migrate all old files into the new structure?
No. 80% of files in any organization haven't been touched in a year and don't need migrating. They just need to be findable when someone occasionally searches, which Drive does well regardless of folder. Create the new top-level Drives, move only new files into them, set a 90-day deadline after which old folders become read-only.
How deep should subfolders go?
Three to four levels maximum. Deep nesting (Marketing/Campaigns/2024/Q3/Email/Welcome series/Final/) makes things slow to find and impossible to reorganize. With the access-based top-level layout, most paths naturally stay within 3-4 levels because the access boundary is set at the top.
How should I name files inside?
Three conventions: date-prefix anything time-bound using ISO format (2026-Q2 board deck, 2026-04 monthly review) so alphabetical sort gives you reverse-chronological for free; use status suffixes for in-flight docs ([DRAFT], [FOR REVIEW], [APPROVED]); don't put the file type in the name - Drive shows the icon.