Daily standups are a common fixture in engineering teams — meant to align, inform, and unblock. In practice, they often feel like a ritual we endure rather than one that drives value. Most of the time is spent reciting status updates no one remembers, only to be asked the same questions by your boss an hour later in Slack. Sound familiar?

Earlier this year, we decided to try something different.

In February, we put an end to daily verbal status updates. We also reorganized our calendars to create space for deep work. Every Tuesday and Thursday are free of recurring meetings. We got here by treating engineering as a deep-work-driven role, not interrupt-driven.

Below is the internal memo that motivated this change.

If you want to work somewhere that values engineering time, speak up. Please feel free to reuse and adapt the following arguments to your situation. Or, consider joining us. We’re hiring full-stack product engineers.

---

Creating opportunities for deep work

Summary

We can make a handful of changes to improve the focus, productivity, and fulfillment of our engineering individual contributors (ICs). They all hinge on one simple idea: four hours of uninterrupted work is multiples more productive than eight individual hours of work.

It’s no coincidence that some of these changes are engrained within the culture of the most productive startup incubator. Productivity aside, my most fulfilling days as an IC have been when I had the time and space to solve challenging problems.

Changes:

• Make standup updates async, but keep parking lot*.
• Organize meetings toward the end of the day, on specific days of the week (MWF).
• Funnel non-blocking questions into a central inbox. This inbox drives parking lot (more details in Inbox).
• Utilize Kieran for non-blocking but high-urgency questions.

*Parking lot refers to the open-ended discussions that happen after updates are given. Some days, parking lot is 15-30 minutes. Other days, there are no topics so we end early.

Standup: The good and the bad

Currently, our standup is a 30-minute meeting every day around 1pm EST. We use the first ~15-20 minutes to give updates. Any extra time is used for parking lot.

The good

• Team bonding.
• Parking lot discussions.
• Working through issues in real time.
• Spreading knowledge and gaining alignment.

The bad

• The updates.
• The lack of a log.

Speaking purely in terms of dollars and cents, standup updates are a large investment. Let’s conservatively estimate $70 per attendee-hour. With eleven attendees, the effective cost of updates is $200/day. For four standups a week, that’s nearly $40,000 a year spent on giving updates.

Most people can’t remember everyone else’s update an hour after it was given, much less a day. Even if we all had perfect recall, most attendees don’t have enough information to make sense of the update. Often, an update requires additional context to be fully understood. Given these issues, the cost for these updates far exceeds the benefits.

Proposed change: Async updates

Live updates should be replaced with async updates. Async updates are implemented via a running Google Doc. This document contains:

• Daily updates.
• A parking lot inbox (described in the below section Inboxes).
• A central place for links to dashboards, documentation, demos, etc.
• A place for requested reviews: PRs, TRDs, PRDs.

Please see Appendix A for an example.

The ICs on my team are expected to post an update once a day, whenever it’s convenient for them. These updates answer the standard standup questions: What are you working on? Did you run into any unexpected issues? What are you working on next?

Blockers should be raised immediately. Non-blocking questions, thoughts, or demos should be added to our standup inbox.

If there are no topics in our inbox, we skip standup.

Meetings

In Maker’s Schedule, Manager’s Schedule, Paul Graham of YCombinator fame writes:

There are two types of schedule, which I'll call the manager's schedule and the maker's schedule. The manager's schedule is for bosses. It's embodied in the traditional appointment book, with each day cut into one hour intervals.

But there's another way of using time that's common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started.

When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.

Meetings are a great tool for spreading knowledge and gaining alignment. But they can come at the cost of an IC’s focus.

The remedy is not abolishing meetings, but reorganizing them to create space for deep work.

Our team spans across the United States. We need to schedule standups and recurring meetings thoughtfully. The goal is to maximize focus time for everyone.

Let's designate specific "meeting days" for recurring events. This includes 1:1s, team time, and IC peer group meetings. On these days, we'll try to schedule meetings toward the end of the day. While we can't find a perfect time that works for everyone, this approach will help protect focused work time.

Inbox

Ad hoc questions are another deep work detractor. A seemingly quick question on how our data model works can turn into forty-five minutes of spelunking.

Instead, add non-blocking questions to our standup inbox. If the question is blocking, do not hesitate to reach out to someone immediately.

Our standup inbox is a freeform list of questions or comments that anyone can add to at any time. This is pinned to the top of our standup doc. A “topic” can be anything: sharing a code snippet, an announcement, demo, request for help on scoping a new feature, etc. There is no topic too small! An example standup inbox can be found in Appendix A.

For those outside of engineering, let’s take full advantage of my move to people management. If you have an important and urgent question, please message me. I will help triage the request before interrupting one or more engineers.

Appendix

An example running Standup document: