Building Durable Engineering Systems Through Async-First Documentation
The Architecture of Trust: Why Async-First Work is a Competitive Advantage
In this conversation, Ben Balter explains the mechanics of remote engineering. He argues that async-first work is not just a productivity trick, but a way to build durable, fair systems. The problem with synchronous culture is that it encourages presence theater, where people perform being online to mask deeper issues with decision-making and psychological safety. By treating documentation as a formal record rather than a chore, teams can move away from reactive, personality-driven management toward a transparent, scalable model. This transition requires patience to get through the initial friction, but it creates a lasting competitive advantage: a system that functions regardless of any single person's availability, which allows for better, more inclusive collaboration that scales as the company grows.
The Hidden Cost of Presence Theater
Most teams default to synchronous communication like Slack, Zoom, and instant messaging because it feels fast. Balter argues that this creates a tragedy of the commons. When everyone prioritizes their own need to be heard or to get an answer immediately, the organization's shared knowledge base becomes fragmented and temporary.
I like to say that a decision without a URL, going back to the law analogy, and this is without a URL gets re-litigated forever. You keep going back to what did we decide here? Why did we decide that?
-- Ben Balter
When information lives only in chat, it is effectively lost. This forces teams to revisit the same decisions repeatedly, creating a cycle of inefficiency that worsens as the organization grows. Systems thinking shows that the immediate benefit of a quick sync creates a downstream cost: the loss of a durable, searchable record. Conventional wisdom fails here because teams think they are moving faster by avoiding documentation, but they are actually building a system that requires constant human intervention to function.
Why Immediate Pain Creates Lasting Moats
Moving to an async-first culture is uncomfortable. It requires the discipline to write down thoughts, wait for responses, and accept that not everything needs an immediate reaction. Balter notes that this discomfort is the point.
The value of async, even though it might feel slower in the moment, you get better decisions faster because you take time upfront, you shift left in your decision making to get rid of all that ambiguity, to chase down all those edge cases to get an durable artifact.
-- Ben Balter
By shifting the effort left, or doing the hard work of writing and documentation early, teams avoid the struggle of trying to reconstruct why a decision was made months later. This is a classic systems trade-off: immediate pain for long-term stability. Most teams will not wait for this payoff, which is exactly why those who do build a significant advantage. They are not just solving the current ticket; they are building a history of their own engineering culture.
The System Responds: Transparency as an Asset
Balter suggests that transparency is often treated as a liability because people fear written records can be used against them. However, he reframes this through a systemic lens: transparency as an asset. When you work in the open, you are not bragging; you are making it easier for others to understand your work.
By narrating your work in a durable medium, you allow the system to respond to you. Others can see your progress, catch errors early, and offer feedback before you have invested too deeply in a flawed direction. This changes the incentive structure of the entire team. Instead of surprise reveals that catch stakeholders off guard, the work becomes a collaborative process. The system responds by routing around bottlenecks, and the individual gains a reputation for reliability based on verifiable contributions rather than green dot presence.
Key Action Items
- Implement Drafting Templates (Immediate): Adopt a standard header for all internal documents that explicitly states the status, such as Drafting. This lowers the defense mechanisms of readers, inviting them to contribute to the idea early rather than critiquing a finished product.
- Shift to Primary Responsible Person (DRI) Models (Next Quarter): Move away from committee-based decision-making. Empower a single person to act as a tastemaker for specific projects to break the cycle of consensus-seeking that stalls progress.
- Audit Your Information Diet (Next Quarter): Stop keeping communication tools like Slack open by default. Batch your responses to specific times of the day to avoid the firehose effect and protect your focus.
- Build a Brag Doc via Git History (12-18 Months): Stop relying on memory for performance reviews. Use your git history, PRs, and issue comments as a record of your contributions. This creates a verifiable trail that makes self-advocacy a byproduct of your actual work.
- Standardize Decision Records (12-18 Months): Mandate that significant decisions must be accompanied by a URL. If it is not linked to a durable artifact, it did not happen. This prevents the re-litigation loop that drains engineering capacity over time.