DoorDash Staff Full-Stack Developer Interview Preparation Guide

A bug that only appears under heavy load needs a test harness that can manufacture load deterministically, since waiting for production traffic to happen to trigger it again is not a repeatable investigation.

Building the harness

1. Synthetic traffic generation at a controlled, repeatable concurrency and request mix (a load-testing tool driving realistic request shapes, not just raw throughput).
2. Seed shared state deterministically (fixed starting data, fixed random seeds where the system uses randomness) so the only varying factor between runs is scheduling/timing, not also data variance.
3. Concurrency controls and deterministic schedulers where available, to bias the interleaving toward the suspected contention point rather than relying purely on load volume to eventually hit it.
4. Time manipulation (accelerating or controlling clock-dependent logic) when the bug involves timers, TTLs, or scheduled work, so you don't need to wait real-world hours to observe a time-triggered condition.
5. Minimize noise, prove causality: run the same load profile with and without the suspected contributing factor (a specific code path enabled/disabled, a specific config toggled) and compare failure rates statistically rather than trusting a single run either way.

A concrete run

Suppose the suspected bug is a cache-eviction race that only shows up under heavy concurrent writes. Running the harness at a fixed seed (seed=42) and concurrency=20 reproduces the race 0 times in 50 runs; the same harness at concurrency=200 reproduces it in 12 of 50 runs, a clear, statistically meaningful signal that concurrency level, not chance, drives the failure, and a concrete number, 12 of 50 at 200 versus 0 of 50 at 20, a reviewer can rerun and check rather than take on faith.

Applying this without dedicated load-test infrastructure

A single server that fails intermittently under heavy load, or that can't reproduce in staging, benefits from the cheaper version of the same idea: increase load safely on that one host (careful, bounded synthetic load) while capturing fine-grained logs/traces, rather than waiting for the next natural production spike.

Trade-offs and pitfalls

Synthetic load rarely matches production traffic shape exactly (arrival patterns, payload variety, cache warmth); the harness's value is in reliably reproducing the class of failure for iteration, not necessarily reproducing the exact production timeline, so a fix validated only against synthetic load still needs confirmation against real traffic before being called durable.

Direct answer
An operation is idempotent if executing it once has the same observable effect as executing it two or more times with the same input; this matters because a network failure can leave a client genuinely unsure whether its request succeeded, and idempotency is what makes 'just retry' a safe default answer instead of a risky one.

Structured elaboration

• Idempotent examples: PUT /users/5 {name: "Alice"} (setting a resource to an absolute value: repeating it produces the same end state); a DELETE of an already-deleted resource (still ends in 'resource gone', whether it's the first or fifth delete call); a read (GET) is trivially idempotent since it changes nothing.
• Non-idempotent examples: POST /orders with no protection (each call creates a NEW order, so retrying after an ambiguous network failure risks a duplicate order); PATCH /accounts/5/balance {increment: 10} (each retry adds 10 again, unlike a PUT that sets an absolute value).
• Achieving idempotency for a naturally non-idempotent operation: (1) an idempotency key the client attaches to every retry of the SAME logical attempt, with the server storing and replaying the result of the first execution; (2) a unique constraint or deduplication check at the database level (a unique index on order_request_id) that rejects a duplicate insert outright; (3) redesigning the API itself to be naturally idempotent where possible (an absolute PUT instead of a relative PATCH increment).

Trade-offs and pitfalls
Idempotency keys and dedup stores cost storage (every key needs to be retained at least as long as a client might plausibly retry) and add a lookup on every request; the trade-off is almost always worth it for anything with a real-world side effect (money, inventory, sending a notification), and often skippable for pure reads or naturally-idempotent writes. The most common mistake is assuming an operation is idempotent because it 'usually' produces the same result, without actually verifying it under concurrent or partial-failure conditions specifically.

Direct answer

Choose Redis when you need richer data structures, persistence, or replication/high-availability (HA) built in; choose Memcached when you need the simplest possible pure key-value cache with the lowest per-operation overhead and multi-threaded read scaling out of the box.

Structured elaboration

• Data types: Redis supports strings, hashes, lists, sets, sorted sets, and more, useful when the cache itself needs to do more than store opaque blobs (e.g., a sorted set for a leaderboard). Memcached only stores simple key-value byte strings.
• Persistence: Redis can persist to disk (RDB snapshots, append-only file, AOF) so data can survive a restart; Memcached is purely in-memory with no persistence, so a restart is always a full cache flush.
• Replication / high availability: Redis has built-in replication and clustering (Sentinel for failover, Cluster for sharding); Memcached has no native replication, relying on the client or an external layer for HA.
• Memory efficiency: Memcached's simpler data model generally has lower per-key memory overhead for pure key-value use cases; Redis's richer data structures and features carry some additional overhead.
• Eviction semantics: both support least-recently-used (LRU) style eviction, but Redis offers more configurable policies (allkeys-lru, volatile-ttl, allkeys-lfu, and others) versus Memcached's simpler slab-based LRU.
• Operational features: Redis has a larger ecosystem for observability, Lua scripting for atomic multi-step operations, and pub/sub; Memcached's multi-threaded architecture can give it an edge on raw throughput for simple get/set at very high concurrency on a single node.

Worked example

For a session store: if sessions are pure key-value blobs, Memcached is a perfectly reasonable, simpler choice. If sessions need persistence across a restart (avoiding logging every user out simultaneously) or replication for HA, Redis with AOF persistence and Sentinel-managed failover is the safer choice, at the cost of a slightly more complex operational footprint.

Trade-offs and pitfalls

Choosing Redis "because it can do more" for a workload that is genuinely simple key-value adds operational surface area (persistence tuning, replication topology) without benefit; match the tool to the actual requirement. Memcached's lack of native replication means a node loss is a hard cache-miss event for everything that node held, with no automatic failover; that must be an explicit, accepted trade-off, not an oversight.

Answer (Full‑Stack Developer perspective)

Summary
I’d choose PostgreSQL tsvector for simple apps with modest traffic and search needs; pick Elasticsearch/OpenSearch when you need advanced relevance, facets, and large-scale queries.

Indexing complexity

• PostgreSQL: easy — maintain tsvector columns or triggers; single transaction with app DB. Example: CREATE INDEX ON documents USING GIN(to_tsvector('english', content)).
• ES/OpenSearch: more setup — mapping, analyzers, ingest pipelines; ETL to sync DB → search index.

Freshness

• PostgreSQL: near‑real‑time since data and index live together.
• ES: eventual consistency unless synchronous writes are implemented; requires changefeed/CDC for low lag.

Scaling

• PostgreSQL: vertical scaling; GIN indexes can grow large and slow; sharding is complex.
• ES: designed to scale horizontally across nodes and shards for high query throughput.

Advanced queries

• PostgreSQL: supports ranking (ts_rank), phrase search, basic facets via aggregates.
• ES: richer relevance tuning, multi-field boosting, fuzzy, synonyms, aggregations/facets, suggestions.

Operational overhead

• PostgreSQL: minimal — one system to manage, backups and monitoring already in place.
• ES: additional cluster ops, tuning, memory management, and cost.

Recommendation
If requirements are simple and you want lower ops, use tsvector. If you need sophisticated UX (autocomplete, faceted navigation, heavy query load), invest in Elasticsearch/OpenSearch.

Design overview
Minimal REST surfaced by Orders service; Courier service (discovery/availability) and Notification service handle nearby courier lookup and delivery of push/WS messages. Use event-driven updates (webhooks or pub/sub) for scale.

Endpoints

1. Create order
   POST /orders
   Request:

{
  "user_id":"u_123",
  "pickup": {"lat":37.77, "lng":-122.41, "address":"1 Market St"},
  "dropoff": {"lat":37.79, "lng":-122.40, "address":"100 Pine St"},
  "items":[{"id":"i1","qty":2}],
  "priority":"normal",
  "requested_eta_mins":30
}

Response:

{
  "order_id":"o_456",
  "status":"searching_courier",
  "created_at":"2026-03-03T12:00:00Z"
}

Action: Orders service calls Routing/Courier service with pickup location + constraints to get eligible couriers (radius, capacity, status). Then calls Notification service to push an offer.

2. Notify courier (internal; from Orders -> Notification)
   POST /internal/notifications/courier-offer

{
  "courier_id":"c_789",
  "order_id":"o_456",
  "pickup":{"lat":37.77,"lng":-122.41},
  "dropoff":{"lat":37.79,"lng":-122.40},
  "expires_at":"2026-03-03T12:02:00Z"
}

3. Courier accepts/rejects
   POST /orders/{order_id}/offers/{courier_id}/response

{
  "courier_id":"c_789",
  "response":"accept"   // or "reject"
}

Response:

{
  "order_id":"o_456",
  "courier_id":"c_789",
  "result":"accepted",
  "assigned_at":"2026-03-03T12:01:10Z"
}

4. Order status lookup
   GET /orders/{order_id}
   Response includes routing fields to help UI:

{
  "order_id":"o_456",
  "status":"assigned | searching_courier | cancelled",
  "assigned_courier":{"id":"c_789","eta_mins":5},
  "offers":[{"courier_id":"c_101","state":"pending","expires_at":"..."}]
}

Key fields for routing & tracking

• pickup/dropoff lat,lng (routing)
• user_id, order_id (correlation)
• priority/constraints (capacity, vehicle_type)
• offer_id or courier_id + expires_at (race/timeout handling)
• assigned_at, status, offered_at (audit)

Notes / reasoning

• Keep synchronous create lightweight; asynchronously fan-out offers.
• Use short TTL on offers to avoid races; first accept wins (Orders service enforces compare-and-set/DB transaction).
• Internal endpoints marked /internal to separate microservices and auth.
• Use pub/sub for large scale (Notifications subscribe to courier-offer events).

Direct answer

Scan the expression once left to right, accumulating the current number and, on hitting an operator (or the string's end), resolving the previous operator against a value stack rather than a running total directly. Addition and subtraction push a signed value onto the stack to be settled later; multiplication and division pop the stack's top, combine it with the current number immediately, and push the result back, because those two operators must bind tighter than whatever addition or subtraction comes before or after them. The stack is what lets the scan defer every addition and subtraction until the very end, once every higher-precedence operation touching a given operand has already been folded in, summing the stack at that point gives the correct, precedence-respecting result.

Structured elaboration

Why a single accumulator is not enough

Evaluating left to right with one running total works for pure addition and subtraction, but multiplication and division must apply to their immediate neighbors before anything else touches those values. A single accumulator has no way to "undo" a value it already folded into the total in order to multiply it by something appearing later.

What the stack defers, specifically

Each time a complete number is read, look at the operator that preceded it:

• +: push the number as-is; it will be added in at the end.
• -: push the number negated; subtraction is addition of a negative.
• * or /: pop the stack's current top, combine with the new number right now, and push the combined result back, this is what "deferring lower-precedence operations" really means in reverse: it is addition and subtraction that get deferred, while multiplication and division are resolved immediately because their operands are already fully known.
  At the very end, summing the whole stack applies every deferred addition and subtraction in one shot, correctly, because every *// touching any of those values has already been folded in before it ever reached the stack.

Handling division sign and formatting

Division must truncate toward zero (not Python's default floor division, which rounds toward negative infinity for negative operands), so int(a / b) rather than a // b is used to match the conventional integer-arithmetic contract.

Worked example

def calculate(s: str) -> int:
    s = s.strip()
    stack = []
    num = 0
    op = '+'
    n = len(s)
    for i, ch in enumerate(s):
        if ch.isdigit():
            num = num * 10 + int(ch)
        if (not ch.isdigit() and ch != ' ') or i == n - 1:
            if op == '+':
                stack.append(num)
            elif op == '-':
                stack.append(-num)
            elif op == '*':
                stack.append(stack.pop() * num)
            elif op == '/':
                prev = stack.pop()
                stack.append(int(prev / num))
            op = ch
            num = 0
    return sum(stack)

print(calculate("3+2*2"))
print(calculate(" 3/2 "))
print(calculate(" 3+5 / 2 "))
print(calculate("14-3/2"))
print(calculate("1*2-3/4+5*6-7*8+9/10"))

This prints:

7
1
5
13
-24

Tracing "3+2*2": read 3, hit +, push 3 (stack [3]), op becomes +. Read 2, hit *, push 2 (stack [3, 2]), op becomes *. Read the final 2 (end of string triggers resolution with op = '*'): pop 2, multiply by the new 2, push 4 (stack [3, 4]). Sum is 7, matching the printed output. "14-3/2" similarly resolves 3/2 to 1 via truncating division before the pending subtraction is ever applied, giving 14 - 1 = 13.

Key points

• The stack holds fully-resolved, precedence-correct terms; the final sum() is the only place addition and subtraction actually happen across terms.
• * and / never get their own stack entries, they immediately combine with whatever the stack's top already holds.
• Multi-digit numbers accumulate via num = num * 10 + int(ch) before any operator triggers resolution.

Complexity

Time: $O(n)$, a single pass over the string. Space: $O(n)$ in the worst case for the stack (an expression that is entirely additions and subtractions of single terms pushes one entry per term), though it can be reduced to $O(1)$ extra space by tracking only the running total and the most recent term instead of a full stack, at the cost of a less direct mapping to "what the stack is doing" pedagogically.

Edge cases

• Leading, trailing, or embedded spaces: skipped by the ch != ' ' check, which does not trigger a resolution and does not get added into the accumulating number.
• Multi-digit numbers: accumulated digit by digit before any operator resolves them.
• Expression ending exactly on a number (no trailing operator): the i == n - 1 condition forces one final resolution using whatever operator preceded that last number.
• Division truncating toward zero for negative results: using int(prev / num) rather than prev // num avoids Python's floor-toward-negative-infinity behavior on mixed-sign division.

Trade-offs & pitfalls

The most common bug is using // for division and getting a different (floored, not truncated) result on negative operands; int(a / b) sidesteps this by truncating through the int() conversion itself. A frequent design question is whether to extend this to full recursive-descent parsing to support parentheses and unary operators (Basic Calculator III-style): the single-pass stack approach generalizes naturally to nested parentheses by recursing into a sub-expression whenever ( is seen and returning the sub-result to the outer scan, whereas true operator-precedence parsing with a formal grammar is a more general (and more code-heavy) solution better suited to expressions with many operator types or user-defined precedence rules.

Direct Answer

Two-phase commit (2PC) is a protocol that lets one coordinator get a group of participants, each owning a different resource such as a database or another service acting as a resource manager, to commit or abort a single transaction atomically. It works by first asking everyone to prepare, and only telling everyone to actually commit once every participant has confirmed it's ready.

The Two Phases

• Prepare (vote) phase: the coordinator sends Prepare to every participant. Each participant does whatever local work is needed to guarantee it can commit if told to, such as writing an undo or redo log entry, acquiring the necessary locks, or checking constraints, then replies Yes or No. Once a participant votes Yes, it must hold its prepared state and locks until it hears the final decision; it can no longer unilaterally change its mind.
• Commit/abort phase: if every participant voted Yes, the coordinator sends Commit to all of them; if any participant voted No, or didn't respond, it sends Abort to all of them. Each participant applies the decision and releases its locks.

The Classic Blocking Failure

If the coordinator crashes after collecting Yes votes from every participant but before sending out the final Commit or Abort, every participant is stuck holding its prepared state and its locks indefinitely. A participant can't safely decide on its own: if it guesses Commit but the coordinator, once recovered, had actually decided Abort because some other participant it hadn't heard from yet said No, that guess would violate atomicity. So each participant has no safe choice but to wait.

This is a real operational problem, not just an inconvenience, because those held locks are on real resources. Any other transaction that touches the same rows, files, or records is blocked too, for as long as the coordinator stays down. A single stuck 2PC transaction can produce an effective outage across everything those locks reach.

A Mitigation: Durable Coordinator Logging and Recovery

The coordinator writes its decision, and the votes it collected, to a durable write-ahead log, a log written to disk before the coordinator acts on it so it survives a crash, before sending Commit or Abort. On restart, or when a replacement coordinator takes over, elected through its own consensus mechanism, it replays that log to learn what it had already decided for any in-flight transaction and resends the correct outcome to whichever participants are still blocked. This doesn't remove the blocking window entirely, but it bounds it to however long recovery takes, instead of leaving participants blocked forever.

Worked Trace

Three participants: a relational database (DB), a document store (Doc), and, for illustration, a payment gateway wrapped with a prepare step (PG). Coordinator C.

1. C sends Prepare to DB. DB validates and locks, replies Yes.
2. C sends Prepare to Doc. Doc validates and locks, replies Yes.
3. C sends Prepare to PG. PG validates, replies Yes.
4. C now has 3 of 3 Yes votes and is about to send Commit, but it crashes before sending anything.
5. DB, Doc, and PG are all blocked, each holding its prepared locks; none of them can safely commit or abort on its own, since each only knows its own vote was Yes, not the others'.
6. A recovered, or replacement, coordinator reads its durable log, sees that all three votes were Yes and that Commit was the decision about to be sent, and resends Commit to DB, Doc, and PG. All three commit and release their locks.

Heterogeneous Resources and a Real-World Wall

2PC's coordinator and participant model works across different kinds of resources in principle: a relational database and a document store can both act as participants as long as each exposes a real prepare step, which is exactly what the XA standard, the X/Open standard defining a two-phase-commit interface for resource managers, formalizes for relational databases. The practical wall most teams hit is that an external payment gateway typically doesn't expose anything like a prepare/commit interface at all; it's a single, irrevocable HTTP call. That's one concrete reason a workflow like reserve inventory, charge card, and ship is usually built as a saga rather than a literal distributed transaction: at least one of the participants can't be plugged into 2PC as a real participant.

When to Reach for a Saga Instead

Reach for a saga instead of 2PC when at least one step can't participate in a real prepare/commit handshake, such as a third-party API with only a single irreversible call, when holding locks for the full duration of the workflow is unacceptable for availability or latency, or when some steps are long-running, such as waiting on a person, a batch job, or a slow downstream service, and you can't justify holding resources locked that long.

Trade-offs and Pitfalls

• A common wrong turn is assuming a participant can unilaterally abort on its own after a timeout once it has already voted Yes. It can't, safely, because it doesn't know whether the coordinator already told everyone else to commit; that's exactly why 2PC is called blocking.
• Presumed-commit and presumed-abort optimizations reduce how much needs to be logged in the common case, but they don't remove the fundamental blocking window; they just make the typical path cheaper.
• Three-phase commit adds an extra round specifically to shrink this blocking window, but it doesn't fully eliminate it, and it's rarely deployed in practice because of the added message and latency cost for a problem that a saga usually sidesteps entirely.

Direct answer
Proving blameless postmortems causally reduce recurrence, rather than assuming it, requires comparing incident outcomes between groups that did and did not receive the full blameless-postmortem treatment, while controlling for the fact that incidents are relatively rare, which makes a small, underpowered comparison unreliable.

Structured elaboration

• Define the primary metric precisely. Incident recurrence rate for the same or closely related failure category within a defined window (say, six months) after a postmortem, and mean-time-to-recovery for any recurrence that does happen, are both reasonable primary outcomes.
• Form comparison groups given low incident frequency. A staggered rollout across teams (some teams adopt full blameless postmortems now, others adopt a few months later) gives you a natural comparison without denying anyone the practice indefinitely, and it's more feasible than a strict randomized controlled trial in most organizations. Alternatively, compare incident classes that received a full postmortem against similar-severity incident classes from before the practice was adopted, using the organization's own history as the comparison.
• Account for low frequency directly. Because a single team's incident count is small, aggregate across many teams or many incident categories to get enough statistical power, and be honest that with genuinely rare, high-severity incidents, you may only be able to speak confidently about a proxy (like recurrence of the underlying vulnerability class in code review or testing) rather than recurrence of an actual outage.
• Control for confounders explicitly. Teams that adopt blameless postmortems early are often also the teams already investing more broadly in reliability practices, so any observed improvement could be due to that general investment rather than the postmortem practice specifically; a staggered rollout across otherwise-similar teams helps isolate this, and tracking a secondary metric less directly tied to postmortems (like general code quality trends) as a check helps rule out a confound affecting everything at once.
• Report the honest limitation. Even a well-designed study in this space will likely have wide confidence intervals given how rare severe incidents genuinely are; report that uncertainty rather than overstating confidence in a clean causal result.

Worked example
An organization with 40 teams rolls out mandatory blameless postmortems to half the teams (chosen to be broadly similar in size and incident history) starting this quarter, with the other half adopting the practice three months later. Primary metric: recurrence rate of a related incident category within six months of any postmortem-eligible incident. After the study window, teams in the early-adoption group show a lower recurrence rate than the later-adoption group during the period before the second group adopted the practice, and the gap narrows once the second group also adopts it, which is more convincing evidence of a causal effect than a simple before-and-after comparison on a single group would have been, since it rules out a general org-wide trend as the sole explanation.

Trade-offs and pitfalls
The most common mistake is treating a simple before-and-after comparison on one group as proof of causation, when it's equally consistent with unrelated organizational improvements happening over the same period. A second is understating how much statistical power genuinely rare, severe incidents cost you, and presenting a result with far more confidence than the small sample size actually supports.

Direct answer

Solo, one week, minimal spec, launch-critical: the plan has to front-load clarifying scope and de-risking the biggest unknown on day one, ship the smallest correct version early, and hold a visible cut-list so a slip becomes a scope decision instead of a missed deadline. The plan below assumes a five-day work week.

Structured elaboration

The shape that makes a solo one-week delivery survivable is: clarify and de-risk early, build the narrowest correct path next, harden and observe before the deadline, and always know what gets cut first if something goes wrong. Acceptance criteria and monitoring have to be decided before day one ends, not discovered on day five, because there is no one else to catch a wrong assumption for you.

Worked example

Day 1: A short conversation with the requester to pin down acceptance criteria and write a one-page mini-spec covering the primary case and the assumptions I'm making, with explicit sign-off. Spend the rest of the day spiking the single riskiest unknown (for example, confirming the actual shape of an upstream dependency's response) before committing to a design around it.

Day 2: Build only the happy path end-to-end, wired behind a feature flag on an isolated branch. No edge cases yet; the goal is one correct path proven working top to bottom.

Day 3: Add handling for the two or three failure modes that actually matter in production, and write automated tests for the happy path plus those failure modes. End of day: a short async or 15-minute check-in with the stakeholder on progress against the day-1 plan.

Day 4: Test against production-like data, wire up monitoring (an error-rate and latency view, with an alert threshold) so day one in production is observable, and do a dry run with a teammate reviewing the diff and the plan.

Day 5: Ship behind the flag to a small slice of traffic first, verify against the acceptance criteria from day 1, then widen. Final checkpoint communication to the stakeholder covering the go/no-go decision and the rollback plan, with buffer time held back in case the initial ramp surfaces something.

Acceptance criteria: correct behavior on the primary path, handling for the top failure modes, monitoring live before go-live, and a documented rollback plan.

Checkpoint schedule: end of day 1 (scope confirmed), end of day 3 (progress check), end of day 5 (go/no-go).

Cut list if blocked, in order: first, secondary or nice-to-have edge cases; second, defer broader test coverage down to just the top failure modes; third, negotiate scope itself (for example, ship only the read path and defer the write path); last resort, tell the stakeholder directly that scope is being cut rather than silently letting the date slip.

Trade-offs and pitfalls

Skipping the day-1 scope conversation to "save time" is the single most common way a solo, tight-deadline effort fails, because any wrong assumption compounds for the rest of the week with no one to catch it. Building broad edge-case coverage before the happy path even works end to end risks having nothing shippable if day 5 arrives early. Waiting until day 5 to think about monitoring means the first production issue is invisible until a user reports it. And having no pre-agreed cut list forces an improvised, worse decision under pressure exactly when there is the least time to make a good one.

Direct answer

First diagnose why the meeting is stalling: usually it's because status-sharing and decision-making are mixed together, and no one is clearly accountable for closing a decision when people disagree. The fix separates the two (status moves async, meeting time is reserved for decisions), names a decision owner per topic, and tracks decisions in writing so they don't get relitigated the next week.

How to redesign it

Step 1: diagnose before redesigning. Ask whether people are status-updating instead of deciding, whether it's unclear whose call something is, or whether decisions do get made but aren't tracked so they resurface. Each cause has a different fix.

Step 2: separate status from decisions.

Step 3: track decisions so they don't restall. Keep a lightweight decision log: what was decided, who owns it, and the date. If an item can't close live, name a follow-up owner and a deadline instead of letting it silently carry over.

Step 4: reconsider the cadence. If most items now resolve async, a lower-frequency decision meeting paired with a written weekly status may serve the group better than a fixed weekly sync for everything.

Worked example

Situation: a cross-functional project with design, engineering, and data has a standing 60-minute weekly sync. Status updates take up 45 minutes, decisions surface in the last 15, and things 'decided' in the room get revisited the following week.
Action: introduced a pre-read posted 24 hours ahead covering status and any open decisions that need a live call; restructured the meeting to skip status entirely and spend the full time on flagged decisions, each with a named owner; started a shared decision log so a closed decision has a record to point back to.
Result: the meeting shortened from 60 to 30 minutes because status moved out of the room, and decisions stopped resurfacing because there was now a written record of what was actually agreed and by whom.

Trade-offs and pitfalls

• Cutting the meeting without giving people another outlet just moves the stalling into chat threads. Live time is still needed for genuine disagreement, don't eliminate it entirely.
• Naming a decision owner can feel like taking authority away from the group. Frame it as who is accountable if the call turns out wrong, not as a power grab.
• Async pre-reads fail without a light enforcement habit. If nobody protects the norm, it quietly reverts to status-in-the-room within a few weeks.
• Adding a decision log and a template is itself process. If it isn't paired with removing something (like the status round-robin), it just adds overhead on top of the original problem.