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.

Nobody enjoys being asked “how’s it going?” — and as the one leading a project at work, I still need to know how it’s going. My compromise is the git graph: I look at it before I ask anyone anything, and most of the time it already has the answer. It shows commit activity, branching and merging at a glance, and nobody has to sit in a meeting for it.

What the graph actually tells you

#

If you haven’t looked at one closely: every node is a commit, every divergent path is a branch, and the whole thing reads as a timeline of the project. That layout carries a surprising amount of information:

• A glance shows how many branches are active and how often commits are landing.
• A branch that suddenly goes quiet, or one that hasn’t merged for weeks, usually means someone is stuck. That’s an early warning worth having.
• Merge frequency tells you how the team collaborates. Frequent merges mean work is actually being integrated; long-lived branches usually mean someone has drifted off into siloed work.

Fewer interruptions, better conversations

#

The obvious win is that I don’t have to interrupt anyone to know where things stand. The bigger win is what happens when a conversation is needed: it starts from the graph rather than from assumptions. “This branch hasn’t moved since Tuesday — anything blocking you?” is a much better opener than “any updates?”

It also helps to make the routine explicit. Mine is a quick glance most mornings and a proper look once a week. The team knows that’s the rhythm, so nobody gets surprised.

Don’t turn it into surveillance

#

This is the part I have to keep reminding myself of. Commit count is not value — one thoughtful commit can beat fifty noisy ones. Seeing every commit doesn’t entitle you to question every decision; trust the team and step in only when a pattern genuinely looks like trouble. And when you do bring the graph into a conversation, it’s a starting point for feedback, not evidence for a prosecution.

Viewing the graph in the terminal

#

Nothing to install, just Git:

git log --graph --oneline --all --decorate

What each flag does:

• --graph draws the branch and merge lines down the left-hand side.
• --oneline puts each commit on one line: its short hash and the first line of its message.
• --all shows every branch and tag, remote ones included, instead of only the branch you’re on.
• --decorate prints branch and tag names next to the commits they point at. Recent versions of Git already do this when the output goes to a terminal, but the flag keeps them when you pipe the output somewhere else.

Nobody wants to type that every morning, so make it an alias:

git config --global alias.graph "log --graph --oneline --all --decorate"
git graph

On a long-lived repo the full graph scrolls forever. A few ways to cut it down:

git graph --since="2 weeks ago"    # only the last two weeks
git graph -20                      # only the last 20 commits
git log --graph --oneline main..feature                # on feature, not yet in main
git log --graph --oneline --left-right main...feature  # both sides, marked < and >

The last two compare two branches, and they use plain git log rather than the alias because --all would pull every other branch back in. Two dots shows what feature has that main doesn’t. Three dots with --left-right shows what each side has that the other doesn’t, which is a quick way to see how far a long-lived branch has drifted.

Viewing the graph in VS Code

#

VS Code has a graph built in. Open the Source Control view (Ctrl+Shift+G) and the Source Control Graph is one of the sections in that panel; it has been there since version 1.93 (August 2024). By default it follows the current branch and its remote, and the branch picker in the graph’s title bar adds others. For a quick look, that’s all you need.

For every branch at once, install the Git Graph extension by mhutchie (search for “Git Graph” in the Extensions view). Open it from the Git Graph item in the status bar, the Git Graph icon at the top of the Source Control view, or the Command Palette with Git Graph: View Git Graph (git log). Click a commit to see the files it changed, or click one commit and Ctrl/Cmd-click another to compare the two. It hasn’t had a release since 2021, which is one more reason the built-in graph is worth knowing about.

If the Git Graph button doesn’t appear, the extension probably hasn’t found a repository. By default it only checks the folders you opened, not their subfolders, so open the repository’s own folder or raise git-graph.maxDepthOfRepoSearch in the settings.

Other tools

#

Most Git tools draw a graph somewhere. gitk --all is Git’s own history browser. GitHub, GitLab and Bitbucket each have a “network” or “graph” view on the repository page. And the desktop clients, SourceTree (free, from Atlassian), GitKraken, Tower and TortoiseGit on Windows, all have one too.

Whichever you pick, the goal is the same: understand the progress, don’t count the commits.

Most of the project messes I’ve been pulled into weren’t caused by bad code. They were caused by the right information not reaching the right person until it was too late. Since stepping up as project lead at work, I’ve been keeping notes on how I’d want to run communication if I ever end up in the CTO seat. Here they are.

Decide who needs to know what

#

The unglamorous foundation is a communication plan: who needs to be informed, what they need, how often, and through which channel. I’d push for one at the start of every project, with names attached — communication that’s everyone’s job ends up being no one’s job. The same goes for stakeholders: work out who actually cares about the project, learn how each of them prefers to be updated, and don’t send the CEO the same update you post in the dev channel. Finally, set a few explicit protocols — expected response times, what counts as urgent, which channel is for what. Most “communication problems” are really just unstated expectations.

An example communication plan for a software project

#

This is the plan I’d start with and then adjust. Each row is an audience, not a meeting:

Underneath the table go the protocols, written as plainly as possible: urgent means it blocks a release or a customer, so call rather than message; questions go in chat, decisions go in the tracker; replies within a working day. For the decision log I use decision documents, kept as GitHub Issues so they sit next to the work.

Two things make a plan like this work. Every row has a name in the last column, and the leadership update is written rather than spoken, so it can be forwarded without losing anything.

Tools and rhythms

#

Tools matter less than people argue about them. Slack for chat, Trello for tasks, Zoom when a conversation needs faces — pick what fits the team and move on. Rhythm matters more: daily stand-ups if you’re working agile, weekly updates on longer cycles, and actually holding to them. And write things down. Decisions, changes, action items — into Notion or Jira, as part of the process rather than an afterthought. Six months later, the doc is the only memory anyone has.

The soft parts are the hard parts

#

Everything above is mechanics. The harder work is asking the team whether the communication is actually working, and changing it when it isn’t. It’s training people up, too — teams come from varied backgrounds, and not everyone has seen a well-run project before. It’s listening properly instead of waiting for your turn to talk, and dealing with conflict early, while it’s still small. None of it stays solved, either: what worked last quarter quietly stops working, so keep checking.

Working as a distributed/asynchronous development team

#

This talk is worth your time if your team is remote or async-heavy:

I don’t do all of this perfectly — nobody does. But every project that went smoothly for me had most of these in place, and every one that hurt was missing at least three.