# Decide where the boundary goes

This is the one decision in the course that is expensive to change. [Workspace](/glossary/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](/glossary/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](/glossary/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](/glossary/activity-log), 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](./02-the-dashboard.mdx), the fifteen-second habit on the view you will use
most. Then [onboard your first member](./03-members-and-roles.mdx).

The [workspace setup checklist](/resources/workspace-setup-checklist) is the condensed form of this whole
course, for when you are actually doing it.

---

**Video:** [Set up a workspace](/videos/set-up-a-workspace) (same material, with a transcript).

---

Source: https://university.eugo.io/lesson/workspaces-and-organizations/orgs-and-workspaces