Chief of Staff Tools: The Stack That Actually Works

Two newsletters dominate the Chief of Staff space — Operators and Chief of Staff Network. Both have substantial audiences. Almost no software company is intentionally positioned for the CoS role. The tooling content that exists is mostly generic productivity advice with "chief of staff" added to the headline.

This is a real gap, because the CoS stack has distinct requirements that generic productivity tools don't address. Here's what actually works.

What a Chief of Staff actually needs to manage

Before building a stack, it helps to be clear about what a CoS actually owns. The role varies significantly across organizations, but the operational core is consistent:

• The leadership team's decision record — what was decided, when, by whom, and why.
• The leadership meeting cadence — scheduling, agenda management, pre-reads, follow-ups.
• Cross-functional alignment — tracking commitments made across teams and following up on them.
• Strategic project management — owning initiatives that span multiple teams or functions.
• The executive's context — keeping the principal informed and making sure they have what they need before every interaction.

Each of these functions needs a different tool. Trying to do all of them in one tool (usually Notion) usually means none of them are done well.

The stack, broken down by function

Project and initiative tracking: Linear or Asana. For strategic projects that span multiple teams, a proper project tracker with status, owner, and deadline fields is non-negotiable. Notion databases can approximate this but lack the notification and workflow features that keep cross-functional projects moving. Linear is preferred for organizations with engineering-heavy cultures; Asana for operations-heavy ones. The choice matters less than having one canonical place where all active initiatives live.

Documentation and knowledge base: Notion. For leadership team docs, meeting notes, playbooks, and the CoS's own reference materials. The key requirement is that information is findable and doesn't require knowing which folder someone saved it in. A consistent tagging and naming convention matters more than the tool itself.

Communication: Slack (or Teams). Most CoS roles live in Slack for day-to-day communication. The discipline required here is resisting the urge to use Slack as a decision-making or documentation tool. Use Slack for communication; use other tools for decisions and knowledge.

The missing layer: decision record and async governance. This is the gap in almost every CoS stack. Every function above handles a piece of the CoS's responsibilities, but none of them capture the team's decision state — what was decided, by whom, with what authority, and what was rejected. This information either lives in meeting notes (hard to find), Slack (impossible to find), or the CoS's memory (not scalable). A governance tool that captures declarations, decisions, and context fills this layer.

The tools to avoid

Spreadsheets for project tracking. A Google Sheet with project status works for three to five projects. At ten or more initiatives, it becomes a maintenance burden that degrades faster than it improves. The CoS ends up spending time maintaining the sheet rather than managing the projects.

Email threads for decision documentation. Email creates the illusion of a paper trail but fails the findability test. Locating a specific decision in a thread from four months ago requires knowing who was on the email and approximately when it happened. Decision records require searching by topic.

Multiple instances of the same tool. Some organizations have three different wikis, two project trackers, and four Slack workspaces. The CoS's job becomes managing the tools rather than managing the work. Consolidation — even imperfect consolidation — is almost always worth the short-term disruption.

What the CoS stack looks like in practice

A workable stack for a Series B-stage company:

• Linear for engineering-related initiative tracking
• Asana for cross-functional initiatives and OKR tracking
• Notion for documentation, meeting notes, and playbooks
• Slack for daily communication (with strict norms about what belongs there)
• StandIn or equivalent for decision records and team state governance

The CoS doesn't need to own all of these — they need to be the connective tissue between them. Their job is ensuring that decisions made in Slack are captured in the decision record, that initiatives tracked in Linear are surfaced to the leadership team in Asana, and that the principal always has the context they need from Notion before key meetings.

Frequently asked questions

Should the CoS have their own tools separate from the rest of the company?

No. The CoS's job is to reduce context gaps across the organization, not create their own. Using tools that nobody else can see defeats the purpose. The CoS should work in the same tools as everyone else, with additional ownership of the governance and decision record layers that the rest of the team often doesn't maintain.

How do you handle a principal who doesn't use the tools?

The CoS's job includes the principal's tool usage. If the principal doesn't use Notion, the CoS should summarize what's there and deliver it in whatever format the principal consumes (email, a pre-read doc, a verbal briefing). The tools exist to reduce the CoS's overhead, not to force new habits on the principal. Adapt the delivery mechanism; maintain the underlying system.

What's the most common CoS tool mistake?

Over-indexing on the communications layer (Slack, email) and under-investing in the knowledge layer (decision records, initiative tracking). CoS roles that live primarily in communications tools find themselves reactive and context-dependent. CoS roles with strong knowledge infrastructure can proactively manage the team's commitments and surface the right information at the right time without being asked.