Why they gave up on meetings

#

Their starting point will sound familiar. Nobody comes prepared, the meeting starts late, and the loudest voice wins whether it’s right or not. An hour later you’re more confused than when you walked in and wondering if there’s any paracetamol left in the drawer.

Alan tried fixing meetings first — 15 minutes max, clear agenda, decision required. It didn’t hold. Discussions drifted, nobody could remember what was said, and absent or remote people were simply out of luck. So they moved the whole thing into writing.

The claims they make for it ring true to me. Writing forces you to slow down and actually think, so the discussion gets more nuanced and better argued. Everything is documented instead of half-remembered. It stops being an eloquence contest. And because the forum is open to the whole company, anyone can contribute — not just whoever happened to be in the room.

GitHub as the company forum

#

The forum itself is GitHub, a platform built for code review that Alan cheerfully hijacked. The setup is almost embarrassingly simple:

1. Create a GitHub account.
2. Create a private repo with no code in it (theirs is called “Topics”).
3. Add a labelling system to categorise conversations.
4. Use the Issues tab: open issues are live discussions, closed ones are decisions made.

They’ve passed 17,000 issues. That’s a lot of meetings that never had to happen, and — the part I find most appealing — a searchable history of why every decision went the way it did. If you want to challenge an old decision, you can first read which arguments won last time.

When to open an issue

#

Not every decision earns an issue. Their filter is four questions: who will be affected? how reversible is it? how urgent is it? do I need more context before deciding?

Broadly, high-impact and hard-to-reverse decisions go to the forum; the rest can stay in Slack. They lean on the one-way vs two-way door distinction: a one-way decision (too expensive or painful to reverse — their example is a price increase) gets the full written treatment, while a two-way decision (cheap to undo, worst case you lose some energy) doesn’t need the ceremony.

LOCI: who does what

#

Every discussion assigns roles using the LOCI model — Lead, Owner, Consulted, Informed.

The Lead is accountable for the decision’s success and makes sure the context is understood across the team. They say upfront how involved they want to be, then trust the Owner and take responsibility for what the team produces, speaking up only when they strongly disagree. One Lead per discussion.

The Owner makes the final call and drives the project. They keep contributors informed and contributing on time, investigate the problem, open and close the issue, and share the decision. If they hit a wall they can’t get past, they go to the Lead. One Owner per decision.

Consulted people are the ones whose input genuinely matters to the trade-off. They’re expected to contribute promptly — even if only to say “nothing to add” — and to raise the alarm (escalating to the Lead if needed) when they think the decision is badly wrong. Alan caps this group at about six, because more input starts costing schedule.

Informed people simply get told, usually once the decision is made. One-way communication, nothing expected back. The Owner decides who’s affected enough to be notified.

The anatomy of an issue

#

Every issue uses the same template, which both sharpens the thinking and quietly teaches junior people how to break a problem down:

• Scope — the “why” of the discussion, including the underrated line “this issue is NOT about…”
• Context & materials — links to prior discussions and documents
• LOCI — who’s Lead, Owner, Consulted, Informed
• A deadline — when to contribute by, when the issue closes, when a solution is needed
• A solution proposal — one suggested answer, or options to choose between
• Questions — aimed at specific people to confirm or refute specific assumptions, so the issue isn’t a message in a bottle

Writing rules that keep things moving

#

A written debate can drag just as badly as a spoken one, so they have rules. Be concise — they quote Boileau: “What is well conceived is clearly stated.” If you can’t write it simply, you’re not actually sure of it yet. Apply the “So what?” test to everything you write; if the implication of your comment isn’t obvious, spell it out.

For the Owner, the follow-up matters as much as the opening. Keep the discussion pointed at the million-dollar question — the one sticking point that actually matters — rather than letting it dissolve into details. Recap regularly what’s been agreed and what’s still open. And treat Slack reminders as a last resort, reserved for overdue contributions or genuine urgency.

Owners also hide comments that don’t move the conversation forward, and everyone is expected to know their way around GitHub’s formatting — headings, footnotes, tables, keyboard shortcuts — because in writing, form carries almost as much as substance.

No consensus, no spectators

#

Two rules stop this from turning into decision-by-committee.

First, the Owner decides as what Alan calls an “enlightened despot”. They investigate ideas, measure risks, question peers — but they don’t seek consensus and they don’t have to implement everything they’re told. Alan is blunt about not being a democracy: every employee is a shareholder, and the company’s interest comes before the team’s or the individual’s. When the Owner is reasonably sure of the right bet, they decide, everyone tries it, and once the impact is visible they review whether it was the right call.

Second, contributor numbers are controlled. Jeff Bezos’ two-pizza rule applies to async work too: the more people on an issue, the less each one contributes. Past about six contributors, the spectator effect kicks in and participation quality drops. Notifications follow the same philosophy — Alan trusts everyone to have configured their own GitHub notifications (Settings, then tick “Web and Mobile” under both “Participating” and “Watching”), so direct tags in the Questions section are kept to a minimum.

What I’m taking from it

#

You can never fully explain a meeting to someone who wasn’t there, but anyone can read a decision. Alan doesn’t claim this is the best or only system — just the one that fits them: fewer interruptions, less spectator effect, and decisions made with a step back and the facts written down. I’m not about to move every decision my team makes into GitHub issues, but the template below is going straight into our repo.

The template, as a GitHub issue template

#

Save this as .github/ISSUE_TEMPLATE/decision.md in whichever repository you use as the forum, and GitHub offers it every time someone opens a new issue. The sections are Alan’s; the LOCI lines and the label are my additions.

---
name: Decision
about: Propose a decision and collect input in writing
title: "[Decision] "
labels: decision
---

## Scope
- The goal of this issue is ...
- This issue is NOT about ...

## Why I'm opening this issue

## LOCI
- Lead:
- Owner:
- Consulted:
- Informed:

## Timeline
- Contributions by:
- Decision by:

## Context and materials

## Proposal

## Questions

GitHub Issues or GitHub Projects?

#

If you’re thinking about GitHub for project management more broadly, the two pieces do different jobs. Issues hold the discussion and, once closed, the decision. A GitHub Project is a board or table laid over issues from one or more repositories, with your own fields for status, owner or deadline. For a decision forum like Alan’s, labels and the issue list are enough. Add a Project when you want every open decision on one screen, sorted by the date it has to be made, and when you start tracking delivery work in the same place, which is where most teams end up using both.