Remote Work Isn't a Perk Anymore. It's an Engineering Decision.

I've worked remotely for over a decade now. Not because it was trendy during the pandemic, and not because I couldn't find an office job. I work remotely because — after ten years of doing it — I've come to believe it produces better engineering outcomes when teams are intentional about how they communicate.

That said, the RTO (return-to-office) push is real. Amazon, Dell, and others have mandated five-day in-office schedules. The federal government followed suit. And the conversation has gotten heated — a recent longitudinal study from Perceptyx found that 61% of employees say their companies have made remote policies more restrictive, while nearly half say they'd quit if required to spend more time in the office. The tension is palpable.

But most of the RTO debate focuses on productivity metrics and employee satisfaction surveys. What I rarely see discussed is the engineering argument — that distributed work, done well, forces habits that make software teams better regardless of where anyone sits.

Documentation becomes non-negotiable

In an office, you can lean over and ask someone why a particular service is configured the way it is. Remotely, that knowledge needs to live somewhere durable. This is a good thing. The best-run remote teams I've been on documented decisions, context, and rationale as a matter of course — not as busywork, but because it was the only way to function.

This extends beyond code comments and README files. It means writing down why a technical decision was made, not just what was decided. It means architecture decision records, onboarding guides that actually stay current, and runbooks that someone can follow at 2 AM without pinging the one person who knows how the system works.

Separate your todos from your tasks

One thing I've learned the hard way: personal organization and project management are two different systems, and they need to stay separate. Your Jira tickets or Linear issues are team-facing — they track what the project needs. Your personal todo list is your system for managing your day: the PR you need to review before standup, the email you need to send, the thing you said you'd look into but hasn't become a ticket yet.

When these get conflated, things fall through the cracks. Remote work makes this worse because there's no ambient awareness — nobody sees you scribbling a reminder on a sticky note. I keep a simple daily notes file alongside whatever project management tool the team uses. Nothing fancy, just a running log of what I'm doing, what I'm waiting on, and what I said I'd do. It sounds trivial, but it's the single habit that's kept me reliable across a decade of remote work.

Meeting notes are an engineering artifact

This might be the most underrated practice in remote teams: treating meeting notes as real documentation, not an afterthought. Every meeting where a decision gets made should produce a written record of what was decided and why. Otherwise, three weeks later, nobody remembers whether the team agreed to use queues or cron jobs for that background process.

I've recently started using AI transcription tools for this, and they're genuinely useful — not as a replacement for paying attention, but as a safety net that captures the details you'd otherwise lose. Having a searchable transcript of a technical discussion is remarkably handy when you're trying to remember the reasoning behind a choice that seemed obvious at the time.

The process argument

If your process breaks when people aren't co-located, the process was fragile to begin with. The hallway conversation that never gets documented, the decision made over lunch that nobody wrote down, the context that lives entirely in one person's head — these aren't features of office work. They're liabilities that offices let you get away with.

Remote work doesn't create communication problems. It exposes the ones that were already there.

I'm not arguing that remote work is universally better, or that offices have no value. But I am arguing that the discipline remote work requires — writing things down, being explicit about decisions, maintaining systems that work asynchronously — is good engineering practice. Period. The best remote teams I've worked with weren't successful because of any particular tool. They were successful because they treated communication as a first-class engineering concern.