The Meeting Operating System
Version your team's meetings like a product — ship a new rev every 90 days.
- Difficulty
- Easy
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 90%
Singhal treats meetings not as a necessary evil but as the operating system of a scaled organization — the mechanism by which delegation, conversation and decision-acceleration actually happen. He runs it as a versioned product: every quarter he ships a new rev of the meeting system, takes feedback two months in, and revs again. He also argues it's the highest-leverage first move for a leader joining a new company, precisely because low context is an advantage when spotting inefficiency.
Origin
Singhal's own practice, developed as he moved from startups (where he says he couldn't have imagined doing this) to leading product orgs at scale — currently at version 7 with his team at Meta.
Core principles
- 01At scale, the meeting operating system is as important as the products you're building.
- 02Meeting time is the most expensive time in a company.
- 03The OS is what encodes the right degree of delegation, the right conversations, and the right acceleration on the right decisions.
- 04Versioning gives people something to plan against, which is what makes meeting time effective.
- 05Sequence for a new leader: process first, then people, then product, then strategy.
- 06Low context is an asset — you can see inefficiencies that everyone inside the system has gone blind to.
How to run it
- 1
Declare the current version
Name it explicitly: 'we're on version 7'. Treating the meeting system as a versioned artifact is what makes it revisable rather than accreted.
- 2
Specify the whole OS, not just the calendar
For each 90-day rev, define: these are the meetings; these are the discussions; this is how we organize the attendees; this is how we make decisions; this is the cadence of the week; this is when people work from home / hybrid.
Watch out A calendar of recurring invites is not an OS. The decision-making rules and the delegation model are the load-bearing parts.
- 3
Collect feedback at month two
Two months into the quarter, deliberately gather feedback on how the OS is performing before the rev.
- 4
Ship a rev every 90 days
Every three months, publish the next version. The predictability is the point: people can plan against a known system, which is what makes expensive meeting time effective.
- 5
If you're new, reboot meetings first
As a new leader in a new company, this is the one thing you can do while you still have low context. You don't yet know how the product works — but that's exactly why you can see the inefficiencies that insiders can't. Process first, then people, then product, then strategy.
Pro tip Your low-context window is short and non-renewable. Spend it here.
In the wild
Singhal's current team runs on v7 of its meeting OS. Every 90 days: here are the meetings, the discussions, the attendee structure, the decision process, the weekly cadence, the hybrid policy. Feedback comes in at month two, then he ships the next rev.
→ People can plan against a stable, known system, making the company's most expensive time — meeting time — measurably more effective. He calls the process work his 'bread and butter as a leader'.
In a startup, Singhal says he couldn't have imagined doing this — the overhead would have been absurd relative to the coordination need.
→ Clarifies the scope condition: the meeting OS is a scaled-organization tool, not a universal one.
Common mistakes
Treating meetings as a necessary evil
If meetings are framed as a nuisance to be minimised, nobody designs them — and the mechanism that actually distributes delegation and decisions in a scaled org is left to accrete by accident.
Letting the meeting system go unversioned
Without an explicit version and a fixed 90-day rev cadence, the system only ever grows. People can't plan against it, and the most expensive time in the company is spent badly.
Waiting until you have context before touching process
The low-context window is precisely when you can see inefficiencies that long-tenured people are blind to. Spend it — process first, then people, then product, then strategy.
Is it for you?
Best for
Leaders at scaled organizations, and especially leaders in their first 90 days at a new company who want a high-leverage first move
Not ideal for
Startups and small teams where coordination overhead is low and a versioned meeting OS would be pure ceremony
From the transcript
“sometimes I realize that at a scaled organization the meeting operating system is as important as the products that we're building”
“every quarter in my current teams even in my past teams I talk about our meetings like a product like we're on version 7 in…”
“I take feedback two months in and then every three months we make another rev”
“I'm a huge fan of rebooting meetings first so process first then people then product then strategies”
From the episode
Building a long and meaningful career
Nikhyl Singhal (Meta, Google)