The meeting that should have been a pull request, and vice versa

TL;DR#

Two things went wrong in the same month. A 90-minute meeting with eight people produced a decision nobody wrote down, which was re-litigated twice. And a 900-line pull request accumulated 41 comments over nine days, resolving a design disagreement one comment at a time.

Both were medium mismatches. The decision needed a written artifact to survive; the design disagreement needed thirty minutes of synchronous time to converge.

The useful question is not "fewer meetings" or "more documentation". It is: does this need convergence (synchronous) or a durable record (written)? Most things need one, and the expensive mistakes come from picking the wrong one — or from using one when you need both.

The case this post is about#

The meeting. "Sync architecture discussion", 90 minutes, eight attendees, called because three people disagreed about conflict resolution.

09:00  problem recap (15 min)
09:15  three positions presented
09:40  genuine discussion; positions converge on last-write-wins per field
10:05  agreement, verbally, by everyone present
10:20  "great, let's do that" — meeting ends

A good meeting. It converged, which is what synchronous time is for.

Then:

+3 weeks   a new engineer proposes merge-based resolution in a PR review
+6 weeks   the same proposal, from someone who had been in the meeting
+11 weeks  a third time, in a design doc for an adjacent feature

Nothing was written down. The convergence happened and evaporated.

The pull request. A sync engine, 912 lines, reviewed line by line.

rounds: 6 · comments: 41 · days open: 9 · force-pushes: 11
round 2  "should conflicts be last-write-wins or merge?"   ← the meeting's question, again
round 4  "the queue should be pluggable"
round 5  "the interface has only one impl, is it needed?"   ← contradicting round 4

Six rounds of asynchronous exchange to resolve a design question. Fourteen hours of actual work spread across nine days of latency.

The symptom#

The meeting's cost, which arrived later:

the meeting itself            8 people × 1.5h  = 12 engineer-hours
re-litigation, 3 occasions                     = ~11 engineer-hours
total                                          = ~23 engineer-hours

The meeting was not wasted — the first 12 hours bought a correct decision. The next 11 were spent re-deriving it because no artifact existed.

The pull request's cost:

author active time      ~11 hours
reviewer active time     ~3 hours
elapsed                   9 days
outcome: an approved design neither person would have chosen from scratch

And the pattern, once I looked at a quarter of both:

meetings that produced a decision:                   14
of those, with a written artifact afterwards:         4
of those re-litigated within a quarter:               1 of 4 (written) · 7 of 10 (unwritten)

PRs with >10 substantive comments:                   17
of those, where the architecture changed in review:  14
of those, that had had a prior design discussion:     2

Seventy percent of unwritten decisions came back. Fourteen pull requests held a design negotiation that had never had a meeting.

Why the obvious fixes failed#

"Fewer meetings." We cut recurring meetings by a third. The decisions still needed making, so they moved into Slack threads and pull-request comments — the slowest available medium for convergence. Meeting hours fell and decision latency rose.

"Write everything down." We mandated notes for every meeting. Notes were taken for six weeks, in a folder nobody opened, because meeting notes are a transcript rather than a decision record — the re-litigated conflict-resolution decision was in a 400-word note that said what each person had said and not what was agreed.

"Smaller pull requests." Generally right and it does not apply to a genuinely cohesive change. The sync engine does not decompose into four independently mergeable pieces without inventing seams nobody wanted.

"Async-first by default." A policy we adopted and then quietly abandoned. It is correct for status, proposals and review; applied to a three-way design disagreement it produced the nine-day pull request.

The actual mechanism#

Two orthogonal properties, and each medium is good at one:

Convergence — several people with different positions arriving at one. Needs rapid back-and-forth, the ability to sketch, and the ability to change your mind without it being a visible reversal. Synchronous time is unmatched at this; a thread is actively bad, because each exchange costs hours and a line-anchored comment biases the conversation toward editing what exists rather than considering what does not.

Durability — the conclusion surviving, findable, with its reasoning, for someone who was not there. Needs a written artifact. A meeting produces zero of this; memory is not a medium.

                  converges well   durable
meeting                 ✓✓            ✗
thread / PR comments     ✗            ✓ (but scattered)
a written doc            ✗            ✓✓

Which means most consequential things need both, in order: a meeting to converge, then a document to make the conclusion durable. Picking one is the mistake, and picking the wrong single one is the expensive version.

Convergence and durability are different needs. A meeting converges and does not persist; a document persists and does not converge. A decision needs both, in that order — and most process friction is using one where the other was required.

The fix#

A routing rule, a meeting output requirement, and a comment threshold on reviews.

1. The routing rule, agreed by the team:

## Which medium
Does this need people to CHANGE THEIR MINDS to reach one answer?
  → a meeting. 30 minutes, 3–4 people maximum, named decider.

Does it need to be FOUND LATER by someone who was not there?
  → a written artifact (ADR, PR description, doc).

Both? → meeting first, then the artifact. The meeting is not finished until
         the artifact exists.

Neither? → a Slack message, or nothing.

The "both" case is the one we were failing, in both directions.

2. A meeting is not over until its decision is written:

## Decision meeting protocol
- Agenda states the DECISION to be made and the decider.
- 3–4 attendees. Anyone else gets the artifact afterwards.
- The last 10 minutes are for writing the ADR, in the meeting, on the shared screen.
- If there is no decision, the output is "no decision, next step is X by Y".

Writing it in the meeting, on a screen, is the part that works. Assigning it as a follow-up means it does not happen — we tried both and the follow-up version produced four ADRs out of fourteen meetings.

3. And the pull-request threshold, with a named action:

## Review escalation
At 10 substantive comments OR a third review round, the reviewer stops
commenting and books 30 minutes with the author.

This is the review working — it found a design question, which a thread
cannot resolve. The call's output goes into the PR description.

A count rather than a judgement, so invoking it is routine. And the output goes back into the pull request, which is how the convergence becomes durable.

4. One more thing that reduced meetings more than any policy: a written proposal before the meeting, read in the first five minutes:

## Proposal: sync conflict resolution  (read before, or in the first 5 minutes)
Recommendation: last-write-wins, per-field timestamp.
Options considered: A last-write-wins (recommended) · B merge · C user-chooses
Why not B: no field in the current model has a sensible merge; adding one later is additive.
Why not C: requires a UI surface we have not scoped, and most conflicts are
           self-conflicts across a user's own devices (84% of observed conflicts).
Open question for the meeting: does C become necessary when we add shared lists?

A proposal with a recommendation and a single open question turns a 90-minute discussion into a 25-minute one, because the convergence work has been narrowed to what genuinely needs it.

How this turned out#

Six months, against the previous six:

                                        before      after
decision meetings                          14          19
  with a written artifact                    4          19
  re-litigated within the period             8          1
median attendees                            6.5        3.5
median duration                            75 min     32 min
engineer-hours in decision meetings       ~105        ~42

More meetings, less time, and one re-litigation instead of eight. The meeting count going up is the interesting part — several things that had been grinding through threads became short meetings.

Pull requests:

                                   before (17)   after (23 crossing the threshold)
median review rounds                     5            2
median days open                        7.5          2.0
median comments                         31           12
architecture changed during review      14 of 17      3 of 23

And the one re-litigation, which is worth reporting:

ADR-011 (SQLDelight over Room) re-opened at month 4 by a new engineer
  → they read the ADR, checked the "revisit if" condition, and closed their own
    question in 15 minutes without a meeting

That is the system working rather than failing: the question was asked, and the artifact answered it.

The cost of the protocol:

10 minutes of each meeting spent writing the ADR
  19 meetings × 10 min × 3.5 people = ~11 engineer-hours
re-litigation avoided (est. from the before rate)   ~20 engineer-hours

One honest limit: the 3–4 attendee cap caused real friction twice. Someone excluded from a decision they cared about objected, legitimately — and the fix was not to invite more people but to circulate the proposal beforehand and the ADR afterwards, with an explicit "object here" window. A small meeting plus a broad written loop works; a small meeting alone reads as exclusion.

What this generalizes to#

Ask what the medium needs to achieve, not how much of it you want. "Fewer meetings" and "more docs" are quantity goals. Convergence and durability are the actual requirements, and each medium is good at exactly one.

A meeting without an artifact has a half-life. Ours was about three weeks. Memory is not a storage medium, and the people who were not there are the majority of everyone who will need the decision.

A thread cannot converge a disagreement. High latency plus line-anchored comments plus an approval gate is the worst available medium for a design question, and the comment count is the signal that one is happening.

Write the record while the people are still in the room. Ten minutes of a meeting, on a shared screen, produced 19 of 19 artifacts. The same task as a follow-up produced 4 of 14. The difference is entirely about when, not about discipline.

Related#

• The code review that should have been a conversation — the review threshold in detail
• The architecture decision nobody wrote down, re-litigated four times — what the artifact should contain
• I measured my own tooling for a month and deleted half of it — measuring process honestly

Keep reading#

This is part of Developer productivity, honestly — what actually makes the work go faster, measured rather than assumed. Follow MobileByteSensei for the rest.