Decide where the boundary goes
This is the one decision in the course that is expensive to change. Workspace storage does not move between workspaces, so redrawing the boundary later means moving data.
Twenty minutes now. Work through it for your own team as you read.
First, the one fact people get wrong
Two workspaces in the same organization do not share storage, installed libraries, or resource allocation.
They do share the organization's plan limits.
Isolation separates environments, not capacity. Splitting a team into two workspaces does not give them independent headroom. One team running hard against the ceiling still affects the other. If capacity is the problem, the answer is the plan, not the boundary.
Answer these four for your own situation
1. Who needs the same libraries?
People sharing dependencies belong together. Split them and each environment drifts separately: the same package at two versions, and a notebook that works for one person and not the other.
2. Who needs the same data?
Workspace storage is not shared. If two groups need the same files, either they share a workspace, or the data lives in object storage.
For anything large, object storage is the better answer regardless. A cluster cannot read one machine's local disk anyway.
3. Who should not be able to break each other's work?
This is the actual reason to split. If the answer is "nobody, we all work on the same things," you probably want one workspace.
4. Who is accountable for each one?
Write a name against every workspace you are considering. A workspace without an owner is one nobody maintains, and it will still be there in a year holding storage.
Then pick a shape
Your answers usually point at one of these:
| Shape | Fits when | Costs |
|---|---|---|
| Per team | teams have different dependencies and data | little, and usually the right answer |
| Per project | strict data separation matters | more workspaces to administer, people in several |
| Per environment | you need somewhere breaking things is safe | doubles setup for the same team |
Combinations are common: per team, plus one shared production workspace.
If you are unsure, start with one. Splitting later is easier than merging, because merging means reconciling two environments that have drifted.
The mistake worth naming
One workspace per person.
It sounds tidy and generates permanent work: every environment maintained separately, every dependency installed repeatedly, and no natural home for shared work.
People need their own sessions, which they get automatically. They rarely need their own workspace.
Name them before you have six
Names appear in the dashboard, in activity logs, and in conversation. analytics-prod carries
information; workspace-2 does not.
Pick a convention now. It costs nothing today and is annoying to change once people have bookmarks.
What you now know
- That isolation separates environments but not capacity, which is the detail that misleads people.
- Four questions that settle the boundary, and that "start with one" is a legitimate answer.
- Why per-person workspaces are a trap.
Next: do the weekly check, the fifteen-second habit on the view you will use most. Then onboard your first member.
The workspace setup checklist is the condensed form of this whole course, for when you are actually doing it.
Video: Set up a workspace (same material, with a transcript).