Decision Logs and Async Leadership, Running a Team That Doesn't Share a Time Zone

TL;DR — Async leadership isn’t fewer meetings, it’s writing as the primary mode of work / a running decision log is the cheapest, highest-leverage artifact you can maintain / your team’s velocity is bounded by how fast context flows, not how fast people type.

I’ve worked on distributed teams across UTC+7, UTC+1, and UTC-8 simultaneously. The naive approach — replicate the office team but on Zoom — fails immediately. There’s no time when everyone is awake, no hallway to absorb context in, and no Friday lunch to align on the things you forgot to write down. If you keep trying to lead that team synchronously, you’ll burn out, the team will burn out, and the work will quietly shift to whichever time zone is closest to yours.

The shift that has to happen is to async-by-default. That means writing is the primary mode of work, meetings are the exception, and the artifacts you produce as a leader are durable rather than ephemeral. A decision log is one of those artifacts, and it’s the one I want to focus on here.

This is the sixth post in my December series on leadership and team practice. Last week I wrote about RFCs and ADRs as the long-form versions of written decision-making. The decision log is the lightweight complement.

What Goes Wrong Without a Decision Log

Without a decision log, three failure modes appear, in roughly this order.

Decisions get re-litigated. Someone asks “why did we go with library X?” in the team channel. Three people offer slightly different explanations. A fourth person disagrees with the choice and the team spends two hours of group time relitigating something that was already decided.

Decisions disappear. Two months later, someone on the team makes a contradictory call because they didn’t know the earlier decision existed. Now you have two services doing the same thing two different ways, and the conflict surfaces in a customer-facing bug.

Decisions can’t be challenged usefully. Someone wants to revisit a past choice because the context changed. Without a record, they can’t tell what the original constraints were, so the conversation becomes “I think we should change this” vs. “I think we shouldn’t,” with no shared basis.

A decision log fixes all three by making decisions discoverable, dated, and contextualized. It doesn’t have to be fancy. A single markdown file in the team’s repo, append-only, is plenty.

The Decision Log Format

Here’s the format I’ve used on three different teams. It’s deliberately light — heavier than a Slack message, lighter than an ADR.

# Decision Log — <Team Name>

> Append-only. Newest entries on top. Link to RFC or ADR if applicable.

---

## 2023-12-19: Move feature flags off LaunchDarkly to in-house service
**Context:** LaunchDarkly contract renewal is in Q1, cost up 60%. Usage
patterns are simple enough that in-house is feasible (no targeting rules,
just kill switches and gradual rollouts).
**Decision:** Build minimal in-house flag service, migrate over Q1, end
LaunchDarkly contract April 1.
**Owner:** @amal
**Links:** RFC-027, slack thread <link>
**Status:** Decided

---

## 2023-12-15: Pause work on search relevance until next quarter
**Context:** Hiring for the ML role has slipped twice; current team
doesn't have bandwidth to make non-trivial progress.
**Decision:** Pause search work. Pick up post-hire, target Q2 kickoff.
**Owner:** @amal
**Links:** none
**Status:** Decided

---

## 2023-12-11: Adopt OpenTelemetry as default tracing standard
**Context:** Three different tracing libs in use, instrumentation
inconsistent, vendor lock-in concerns.
**Decision:** OTel + vendor-neutral collector. Existing services migrate
opportunistically; new services use OTel from day one.
**Owner:** @amal, @nilay
**Links:** ADR-019
**Status:** Decided

Each entry is short. Context, decision, owner, status, links to deeper artifacts. A reader catching up after a week off can scan the log top-down in five minutes and know what changed.

A few conventions I enforce:

• Append-only. Decisions are never edited. If a decision is reversed, that’s a new entry with a link back. The log is history, not state.
• Newest on top. Counter to standard log convention, but humans read top-down. Don’t make people scroll to find what changed yesterday.
• One owner. Every decision has one accountable person, even if many people contributed. Diffuse accountability is no accountability.
• Links matter. A decision without context is half a decision. Link the RFC, the Slack thread, the customer ticket, the metric that drove the call.

The log lives in the team’s repo. It’s updated weekly by me (or whoever’s running the team). It’s the first thing I link in a Friday recap email.

The Async Leadership Cadence

The decision log is one artifact. It only works inside a broader async cadence. Here’s the rhythm I run.

Weekly Written Recap

Every Friday I post a written team recap. Headers: decisions this week (link to decision log), what shipped, what’s in flight, what’s blocked, what’s coming next week. It takes me about thirty minutes to write and saves the team probably ten times that in re-asking questions across time zones.

The format isn’t precious. The discipline of writing it weekly is what matters. Skipping a week is fine; skipping three weeks means the team starts feeling disconnected and you’ll know it from the increased Slack DM volume asking questions you’ve already answered somewhere.

Async Standups

Daily standups happen in writing, in a channel, posted by each engineer when their day starts (whatever time zone). Three lines: yesterday, today, blockers. People read them when their day starts. No one schedules a synchronous standup.

The trick is that the quality of written standups is much higher than spoken ones, because written ones are public, searchable, and committed to. People put more thought into them. You also catch blockers earlier, because the engineer in UTC+7 doesn’t have to wait for the UTC-5 manager to wake up to mention them.

One-on-Ones Stay Synchronous

There’s one place I don’t go async: 1:1s. Trust-building, hard conversations, and career discussions are too high-stakes to do in writing. I do those by video, weekly or biweekly, and they’re the only meetings I treat as non-negotiable. Everything else can be rescheduled.

Office Hours Instead of Meetings

Twice a week I hold “office hours” — a 90-minute block where I’m online and available for any team member to drop in for any reason. People come if they have something to discuss, skip if they don’t. This replaces a lot of the ad-hoc meetings that would otherwise accumulate.

The async-vs-sync mix isn’t ideological. It’s just that the cost-benefit math is different for distributed teams, and you have to be deliberate about which mode each kind of work belongs in.

The Decision Cadence

Decisions in an async team have to be made on a clock. Without a clock, they drift indefinitely, because there’s no hallway to force a quick “let’s just decide this” moment.

The cadence I run is:

• Reversible decisions: decided by the owner, posted to the log within 48 hours. No formal review.
• Significant decisions (cross-team impact or hard to reverse): RFC, named reviewers, two-week review window, decision recorded as an ADR.
• High-stakes decisions (architecture, vendor, policy): RFC, named reviewers, two-week review, plus a 60-minute synchronous decision meeting at the end to resolve any remaining disagreement.

This taxonomy matters because most teams over-process reversible decisions and under-process irreversible ones. Naming the category upfront — and writing it into the decision log — keeps the team’s process matched to the actual risk.

A Worked Example

A team I worked with had a recurring problem: every quarter they’d realize that some “decision” from the previous quarter had never actually been made. Someone had floated an idea, people had nodded, and then… nothing. The work either drifted or got duplicated.

We instituted three rules:

1. Any proposal floated in a meeting that doesn’t end with a named owner and a deadline is recorded as “discussed, not decided” in the decision log.
2. Once a week, the log is reviewed: anything still marked “discussed, not decided” is either escalated to a decision or formally dropped.
3. Owners post the resolution back to the log, with a one-paragraph rationale.

Within three months the “ghost decisions” problem disappeared. Not because we’d installed any new tooling, but because the act of writing things down — even at the lowest fidelity — forced the team to either commit or release.

Common Pitfalls

Treating async as “fewer meetings.” Async isn’t about meeting volume. It’s about whether the artifacts of work are durable. A team with five meetings a week and great written artifacts is more async than a team with one meeting a week and no written record.

Decision log as a graveyard. If no one reads it, it’s worse than nothing. Link to it constantly — in recaps, in PRs, in onboarding docs. Make it part of the rhythm.

Writing for archival instead of for use. Decision log entries should be readable in thirty seconds by someone catching up. Long, polished writeups belong in RFCs and ADRs. The log is a navigation aid, not a destination.

Forgetting to record non-decisions. “We decided not to do X” is as important as “we decided to do X.” Record both. Otherwise the same proposals keep showing up.

Conflating decision logs with project trackers. The decision log is decisions, not tasks. Don’t merge them; the log gets noisy and tasks get lost. Keep them separate, link liberally.

Assuming async works for every kind of work. Some work — early discovery, ambiguous problem framing, sensitive feedback — genuinely needs synchronous time. Async-by-default doesn’t mean async-always. Be honest about the cases where a 30-minute call beats three days of doc revisions.

Wrapping Up

Distributed leadership comes down to whether your decisions and your team’s context can survive being asynchronous. A decision log is a small, almost embarrassingly simple artifact, and yet it does more for distributed teams than most of the heavyweight process work that gets proposed in its place. Start the log this week. Backfill the last month of decisions. Read it on Friday. See what happens.

Next post: event storming as a discovery tool — going back to the consultative discovery thread with one of the most useful collaborative techniques I’ve adopted.