Make with Notion 2024: Build your dream setup in Notion with Andrew Mason

Andrew Mason frames Notion not as a document tool, but as infrastructure for building company culture through repeatable rituals. He argues that teams should use Notion the way product teams build software: ship an MVP, gather feedback from “employees as customers,” and iterate—while also learning when to use Notion’s power and when to stick with simpler page structures.

He begins with a tour of Descript’s workspace structure. At the top sit team spaces like a handbook area for relatively static onboarding and reference material. Most day-to-day work lives in an “app” section: collections of databases organized around operational rituals such as quarterly planning, goal setting, strategic initiatives, and project management. Teams can create their own sub-views, but Descript also avoids excessive fragmentation by keeping many efforts in shared global databases rather than spawning separate project systems for every team.

A key “Aha moment” comes from how Mason organizes personal writing. Instead of forcing every new document into a page hierarchy, he creates a single “docs” database and treats it like Google Docs—using database views and properties to manage workflow. He highlights a second advantage: structural decisions aren’t one-way doors. Pages can be moved between databases or locations without breaking everything, making it easier to evolve the system as the company changes.

Mason then connects Notion structure to “mise en place,” the French idea of getting ingredients ready before cooking. He describes how Descript replaces Slack’s unsearchable sprawl with structured tables for industry intelligence and product inspiration. Rather than dropping links and screenshots into chat where they disappear, teams log them into Notion tables (using tools like the Notion Web Clipper) and tag them so the company can retrieve a five-year historical record of onboarding research and competitive insights.

For decision-making, Mason describes a ritual called Catalyst, adapted from Kota. When someone needs feedback and alignment, they create a Catalyst record with a status that moves from “seeking feedback” to “seeking alignment.” A defined “brain trust” group reviews asynchronously and can mark alignment levels; only “strongly unaligned” can block progress. Mason also describes a companion “input” table that routes meaningful contributions without cluttering inline comments, with statuses that determine whether a response or meeting is needed.

The talk shifts into practical governance: enforce iconography conventions, keep core databases centralized, lock down field creation to prevent schema chaos, and avoid “pet peeves” like required reading buried in nested lists. He warns against overusing synced blocks and against creating endless new properties for every detail—sometimes a header or template field is enough.

Finally, Mason lists mistakes that undermine trust: incessant tinkering with frameworks like OKRs, building overly complex “glorious” apps that are hard to maintain, hit-and-run database creation without an ongoing owner, and maintaining multiple sources of truth across tools (he cites messy overlap between Notion and Linear). The goal is a system that people actually maintain—and that keeps working as teams and priorities evolve.