Skip to content
Inside
the CEO
Suggest a guest
Menu
Working rhythm · Knowledge Hub

C-suite meetings: time for decisions, not status recaps

The quality of a meeting is determined by the decision or shared understanding it creates. A status update that can be read does not always need an hour together.

01

Written preparation reduces dependence on attendance

GitLab publishes rules that make meetings accessible to asynchronous contributions: an agenda, an owner, documentation, recorded actions and consideration of time zones. This is a practical set of working practices, not a claim that meetings are never needed.28

02

Separate different modes of conversation

Work separately with facts, options and the decision. Before a strategic discussion, participants should know whether they are expected to provide information, challenge assumptions or make a final choice. Otherwise, part of the team is still exploring the problem while the rest is already trying to approve a plan.

03

Disagreement is needed before a decision; clarity afterwards

McKinsey recommends defining the meeting’s purpose in advance, along with the facts needed and the people whose input genuinely affects the choice. Otherwise, executives may discuss options without knowing who has the right to decide. Once a decision is made, record the owner and next step; Amazon’s disagree and commit principle does not remove the need for a reasoned discussion beforehand.4026

04

One meeting, one mode of work

Distinguish operational reviews, investment choices, strategic discussions and risk reviews in the executive team’s calendar. The first needs deviations and action owners; the second needs alternatives and the cost of saying no; the third needs assumptions and challenges; the fourth needs early signals and authority to stop. If every mode is mixed into one two-hour meeting, the loudest urgency crowds out what matters. McKinsey recommends preparing decisions, while GitLab shows how to move status updates and materials into a written, asynchronous process.2840

05

Create a memory of decisions

After the discussion, briefly record the question, alternatives, decision owner, main assumptions, person responsible for execution and review date. In the next cycle, compare not only task completion but also whether the assumptions proved true. Such a log protects the team from repeating the same argument and rewriting history retrospectively. When the discussion is sensitive, access to details can be restricted, but the decision itself and responsibilities should not remain only in the memories of a few attendees. The approach combines GitLab’s written coordination with McKinsey’s principles of decision preparation.2840

06

Inside the CEO practice

Send a short memo with the question, alternatives, recommendation and uncertainty. End the meeting by recording the decision, owner, deadline and review date. Use live conversation for complex conflicts, sensitive issues and crises. Afterwards, create a shared written record of the context.

For your team

Questions before a decision

  1. What would happen if this meeting were replaced with a document?
  2. Who needs to make the decision?
  3. Do we distinguish disagreement with a decision from a lack of clarity about it?
Primary sources

Sources

  1. 26
  2. 28
  3. 40