I’ve been working remotely for over 6 years, the last 4 with distributed teams across multiple time zones. My conclusion: synchronous meetings are the last resort, not the first option.

Async-first work doesn’t mean “never talk.” It means prioritizing written, deferred communication so each person can work at their most productive time without constant interruptions.

The pillars of async-first

PRs as the unit of communication

A pull request is not just code. It’s the primary vehicle for technical communication:

## Description
Implements recurring payment processing from CSV upload.

## Context
We've been processing payments manually each month. This automates 
the workflow: validate rows → enqueue jobs → notify on errors.

## Key decisions
- **Each row is a separate job**: so a single bad row doesn't block the rest.
- **CSV parsed in a job, not the controller**: keeps response under 200ms.
- **Notifications via Laravel Notifications**: can be email, Slack or both.

## How to test
1. Upload `tests/fixtures/valid_payments.csv` via the admin panel
2. Run `php artisan queue:work --once`
3. Check `database/notifications` for results

## Screenshots
[Link to screen recording of the flow]

Closes #452

A PR like this lets the reviewer understand context, decisions, and how to test without needing a meeting.

ADRs: decisions that don’t get lost

Every relevant technical decision gets documented as an Architecture Decision Record:

# ADR-023: CSV Payment Processing

## Status
Accepted

## Context
We need to process recurring payments from CSV uploads.
Options: sync processing, batch job, or per-row jobs.

## Decision
Per-row jobs dispatched to a dedicated queue.

## Consequences
+ Partial failures don't block entire batch
+ Can retry individual failed rows
+ Easier to monitor per-payment
- More Redis/RAM usage for job metadata
- More complex error reporting (per-row status)

## Alternatives considered
1. Sync processing in controller: blocked for large CSVs, timeout risk
2. Single job for entire CSV: one bad row fails everything

ADRs live in docs/adrs/ and are referenced from PRs. Anyone on the team can understand why a decision was made without asking.

The async-first daily rhythm

Those 3-hour uninterrupted blocks are where real work happens. A single 30-minute meeting in the middle of deep work can cost 2 hours of lost productivity (recontextualization time).

Meetings that are worth it

I’m not anti-meeting. I’m anti-meeting-without-an-agenda. These meetings have a clear purpose:

Rule: if there’s no written agenda 24h before, the meeting is cancelled.

Tools I use

• PRs and code: GitHub + GitHub Actions
• Documentation: Markdown in the repo (ADRs, READMEs)
• Async communication: Slack (topic channels, not urgent DMs)
• Recordings: Loom for complex explanations
• Issues: Linear
• Decisions: ADRs in docs/adrs/

Conclusion

Async-first work is not an abstract philosophy. It’s a set of concrete practices: writing PRs with context, documenting decisions, blocking time for deep code, and reducing meetings to the necessary minimum.

If you’re looking for a senior profile who already works this way and can help your team adopt these practices, check my availability.

Related Articles

• My Remote Setup 2026: Hardware, Software and Rituals — Equipment, tools, environment
• Async-First: Working Remote from Barcelona — Work philosophy, daily routine
• Laravel + Vue for Distributed Teams — Inertia architecture, async workflow, onboarding