How We Model a 22-Person Company in Notion

How BitSafe Runs on Notion, Part 2 of 5

Notion gives a team enough flexibility to represent almost anything. That freedom can produce a workspace nobody can explain.

We wanted the opposite. Any employee should be able to understand where work lives, and an agent should be able to retrieve the same structure without learning a different convention for each department.

For a 22-person company, the answer was a deliberately small operating model. Strategy connects to projects. Projects connect to tasks. Documents preserve knowledge. Meetings feed decisions and follow-ups into the same system. Shared directories keep names and relationships consistent.

The central claim is simple: a useful company model does not capture everything. It captures the few relationships that make ownership and context visible.

Our operating spine has three levels.

Pillars represent long-lived areas of the company. They give each function a durable home for its goals, projects, documents, and operating guidance. A pillar changes slowly because it describes an area of accountability rather than a temporary initiative.

Projects represent time-bound efforts. A project has a defined outcome, an owner, and a status. It may span several teams, but it should still be possible to say who is accountable for moving it forward.

Tasks are the unit of work. A task names the action, the owner, and its current state. Tasks can carry due dates or relate to a meeting, but they should remain small enough to complete.

We resisted adding more hierarchy. Subtasks can exist when needed, though they do not become another operating layer. Every new level adds another place for work to disappear.

This spine gives the company one consistent answer to three questions: where does this work belong, who owns the outcome, and what happens next?

Projects show movement. Documents preserve understanding.

Our Documents database holds policies, SOPs, technical specifications, reports, proposals, research, and other artifacts the company may need to trust later. Keeping those formats together improves retrieval across functions and reduces duplicated guidance.

Three controls make that central database workable.

First, every important document has one responsible person. Collaboration can be broad, but accountability cannot be vague. The responsible person owns whether the page remains accurate.

Second, status separates work in progress from approved material and archived history. Drafts can remain available without presenting themselves as settled guidance.

Third, verification provides a visible trust signal for material that has been checked. An agent can still use an unverified page as context, but it should not silently treat every page as equally authoritative.

This database has more operational value than a conventional wiki. The relations connect a document to the project, team, product, or company it informs. The page explains the idea, while the properties place it inside the operating system.

A meeting page should not become the place where work goes to hide.

We keep meetings as their own structured records because the source matters. The record can preserve a summary and supporting transcript, then link to the companies, projects, documents, or tasks discussed.

The useful output is smaller than the meeting itself. A decision belongs in durable context. An action belongs in the task system. A follow-up with a company should connect to the company record.

This approach avoids two common problems. The first is treating the transcript as the deliverable. The second is copying the same action into several team trackers.

A meeting can remain the evidence behind a decision without becoming a second source of truth for execution.

Relations only help when the records they point to are stable.

We maintain shared directory databases for entities that appear across the company, such as people, teams, companies, contacts, and applications. These records function as master data. Other databases relate to them instead of recreating them as text fields.

That sounds like a small design choice. It changes what the workspace can answer.

A project can link to the same company discussed in a meeting. A document can connect to the same application referenced by product and sales. An agent can retrieve the full trail without guessing whether two spellings refer to one organization.

The operating lesson is to centralize identity before centralizing activity. If the company cannot agree on what an entity is, cross-workspace reporting will remain fragile.

A schema can look clean on launch day and decay quickly.

We use ownership at two levels. Every operating object has an accountable person where that makes sense. A smaller group owns the shared schemas and the options inside them.

Most employees should be able to create and update records without needing to understand database design. Domain owners can maintain views and templates for their teams. Changes to global schemas require more care because a renamed property can affect dashboards, workflows, and agent instructions at once.

The purpose is consistency. When an agent reads a project status or company category, the term should mean the same thing across the workspace.

This also makes change visible. A new field needs a reason. Usually it should support a decision, a routing rule, a risk check, or a recurring retrieval need. Fields without a downstream job create maintenance without producing value.

A polished dashboard can disguise a weak model.

We build views and dashboards after teams have used the underlying records long enough to expose the questions they actually ask. Leadership may need a summary of projects at risk. A team may need tasks grouped by owner. An agent may need a filtered queue for work awaiting review.

Those are presentation problems once the data is reliable. Building the presentation first usually locks in assumptions before the team knows whether the records support them.

The same principle applies to formulas and automations. Start with the source fields and ownership. Add derived views when a real pattern appears.

The model became more useful as we removed things.

We stopped maintaining separate document databases for each function because cross-company search suffered. We avoided a separate object for every stage of a relationship when one shared entity and a clear status could do the job. We removed fields that teams did not use, even when they looked conventional in another tool.

Each subtraction reduced the decisions an employee or agent had to make during capture.

This is the architecture we would recommend to another small company: begin with a work spine, a durable document layer, structured meeting outputs, and shared identities. Add relations only when they answer a recurring question. Assign ownership before adding automation.

The result is not a digital copy of the whole company. It is a dependable map of the parts that people and agents need to coordinate.

Subscribe to the BitSafe newsletter for more from the Canton ecosystem and occasional field notes on how BitSafe operates.