More than just Spreadsheets

Role-based work usually starts out simple and liberating. It removes ambiguity, distributes authority, and gives teams a language for how work actually happens. Then growth arrives. Complexity multiplies, people hold multiple roles, and decisions need to be captured and trusted across time. At that point, general-purpose tools that were perfect on day one begin to bend and eventually break. This blog post outlines the typical journey of an organization or team when adding roles, which we have experienced first-hand.

It started with spreadsheets

A spreadsheet is the quickest way to map roles, responsibilities, and owners. In a single table you can define purpose, accountabilities, optional domains, and who owns what. The flexibility is intoxicating. Sorting and filtering keep ambiguity at bay for a while, and you can extend as you learn. The problem is not the first fifty rows; it is what happens after five hundred. As roles evolve weekly, dependencies and tensions appear, and multiple people inhabit overlapping scopes, the grid stops being a map and starts becoming a maze.

The pain shows up in subtle ways at first. A single row is asked to be many things: Sometimes a role, sometimes a project, sometimes a circle and those meanings drift as different people add columns for their needs. Rules that matter for governance, like domain exclusivity or unique role names, live in team memory instead of the data. Version conflicts creep in as parallel edits create competing truths. Most importantly, there is no native workflow for change. Proposals, objections, consent, and outcomes become tribal knowledge captured in meeting notes and chat threads rather than a durable system.

Moving on to Notion

Moving to a tool like Notion feels like the upgrade. You get databases, relations, templates, and attractive views bring your role catalog to life. You can now model circles, connect roles to documentation, and even create templates for governance records. For a time, it works beautifully. As the team grows and the governance cadence becomes real, cracks reappear. Only now they are more operational than cosmetic.

Schemas drift as new teams tweak templates to suit local needs. Permissions are too coarse to mirror the fine-grained reality of decision domains and editing rights. Governance is a process, but a wiki is a canvas; it can record that a proposal existed, not ensure it followed a lifecycle you can trust. Time also becomes a first-class concern. Roles evolve, and you need to know exactly what was true last quarter for incident analysis or compliance, not just restore a page to an older version. Referential integrity becomes manual labor: ensuring exclusivity of domains, uniqueness of names, and clean cascades when removing or splitting roles. Notifications, too, become noisy or silent at the wrong moments because the system cannot infer who is truly affected by a change.

Dedicated Software becomes inevitable

Role-based work is not merely content management. It is a living operating system with rules, relationships, and rhythms. Dedicated software treats that operating system as structured data with constraints and workflows rather than as text decorated with links. The shift is philosophical as much as technical: from storing what we said to governing how we change.

In practice, this means modeling the core primitives: people, roles, circles, domains, accountabilities, policies, tensions, proposals, and decisions as first-class citizens. It means enforcing invariants like unique role names within a circle, exclusive domains, required purpose and accountabilities, and valid assignees based on capacity and fit. It means governance flows that begin with a captured tension, move through proposal drafting and consent, and land in an auditable record that automatically updates the structure. It means a complete history of change, viewable as diffs, commentable, reversible, and attributable. It means time-aware queries that answer not just “what is true” but “what was true on a specific date.” It means visualizing dependencies so you understand the ripple effects of a change before you make it. And it means aligning editing permissions with authority domains and policies rather than with page ownership.

Day-to-day operations

The lived experience of the team with dedicated software shifts in small, compounding ways. Decisions move faster because authority is explicit and enforced. Meetings end sooner because the facts of the structure, the policies, and the decision history are in the system, not in someone’s head. Handovers are cleaner because the role’s purpose, accountabilities, domains, dependencies, and recent decisions are visible to the next holder on a single screen. Growth becomes less chaotic because adding a product line or splitting a circle becomes a structural operation with predictable outcomes rather than a cascade of duplicated pages and broken links.

Leaders gain a more truthful view of governance health. Instead of anecdotes, there are metrics:

• Unresolved tensions by circle
• Overloaded role holders by capacity
• Stale roles that have not changed in months
• Areas with recurring objections that signal unclear policy

Distributed teams operate more independently because boundaries are visible, enforceable, and routinely improved. Transparency no longer depends on who remembers to share a document; it is a property of the system.

Common objections

We already have a wiki

is both true and beside the point. A wiki stores knowledge; governance changes structure. Knowledge demands flexibility; governance demands integrity. When one tool tries to serve both, it ends up being neither flexible enough for learning nor rigorous enough for change.

Can’t we just be disciplined

underestimates organizational entropy. As people rotate and the cadence accelerates, small inconsistencies compound into cloudy authority and shadow processes. Discipline scales when the system embeds it. Otherwise, discipline becomes fragile, upheld only by the most conscientious individuals until they are stretched thin or move on.

This feels heavyweight

assumes software adds ceremony where none existed. The ceremony is already present but captured in spreadsheets, meeting notes, and back-channel agreements. Purpose-built tools remove ceremony by automating the steps that were manual, aligning them with a flow the team already follows, and making the results dependable.

What good looks like

A healthy flow begins with a captured tension. From that entry, a proposal is drafted and linked to the roles and policies it would affect. The item appears automatically on the next governance agenda. In the meeting, consent is sought, reasoned objections are handled by referencing shared policies, and the outcome is recorded with facilitator, timestamp, and rationale. Accepted changes are applied to roles and domains immediately and atomically. People affected receive a concise diff of what changed, why, and what to do next, including linked follow-up tasks in the work tracker. A new hire stepping into a role sees everything they need on day one, including the decision history that shaped the role they now hold. Leaders can review dashboards showing where governance is thriving and where attention is needed.

Starting in Excel taught speed. It let the team experiment quickly and develop instincts for definition and naming. It also made it difficult to preserve coherence under growth. Moving to Notion taught structure and connection. It gave relationships and views that felt closer to the living system. It still left the heavy lifting (integrity, lifecycle, time, and authority) on human shoulders. Both steps were essential. They helped articulate how the team wants to live its roles and make decisions. The turning point was recognizing that the process had matured beyond what general-purpose tools could guarantee.

As a rule of thumb: If your roles change monthly, decisions have formal outcomes, people hold multiple roles, and you care about who can decide what without asking permission, you have crossed from documents to an operating system. Operating systems deserve software that treats them accordingly.

Closing thought

Role-based work is clarity in motion. Spreadsheets and wikis tend to give you one or the other. Clarity that calcifies or motion that blurs. Dedicated software offers both. It preserves the freedom to adapt while protecting the agreements that make adaptation safe. That is how autonomy scales without chaos and how governance becomes a force multiplier rather than friction.