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.

The slowest part of most projects I’ve worked on wasn’t the code. It was the queue: decisions stacked up behind one manager’s calendar, waiting for a nod that took three days to arrive. Async communication and autonomous teams are the standard fix, and I’m a believer, but the shift is mostly a trust problem dressed up as a tooling problem.

Why everything needs a sign-off in the first place

#

It’s worth being fair about where approval culture comes from. Control feels like precision — if every decision crosses the manager’s desk, nothing drifts off course. A bad call doesn’t just dent the project, it dents the manager’s reputation, so fear does a lot of the work. Sometimes there’s genuine doubt about whether the team has the experience to decide well. And sometimes it’s pure residue: the org chart has always worked this way, so it keeps working this way.

Notice that only one of those four reasons is actually about the team. The rest are about the manager.

What autonomy actually requires

#

Autonomy without alignment is just chaos with better morale. If people genuinely understand the objectives, their independent decisions mostly point in the same direction — that’s the whole trick. Training matters too, because a well-equipped person is easier to trust than an enthusiastic one. And keep some boundaries: certain decisions genuinely should stay with management, and saying which ones out loud prevents the worst surprises. After that, let the feedback loop run and treat the inevitable mistakes as tuition rather than evidence.

If trust has already been damaged — and in teams crawling out of approval culture, it usually has, in both directions — there’s no shortcut. Name the problem in an open conversation, let management own its share of the mistakes first, and then be boringly consistent for months. Clear roles and regular check-ins do more repair work than any grand gesture.

The async part is the easy part

#

Tools first, but briefly: Slack or Microsoft Teams will do fine. The real work is documentation — when nobody’s in the same room or the same timezone, written decisions become the team’s memory. Set response norms so async doesn’t quietly become unresponsive; “within a day” beats “whenever”, and they belong in the team’s communication plan next to who gets which update. And actually teach people to write a good async update, because the skill isn’t innate: enough context to decide, the decision needed, and a deadline. Something like this:

Decision needed by Thursday: payment retries
Failed card payments currently retry once, after 24 hours, and “where’s my order?” is now our most common support ticket.
Option A: retry three times within 24 hours (about half a day’s work). Option B: leave it and email the customer instead.
I’d go with A. Details and numbers are in the linked doc.
If there are no objections by 5pm Thursday, I’ll start on A.

Anyone can read that at 7am or 11pm, in any timezone, and answer it without a meeting.

You can roll out Slack in an afternoon. The trust takes months, and it’s the part that decides whether any of this works. Get the objectives clear and make mistakes cost a lesson instead of a career — the async part mostly takes care of itself after that.