Quick take
Remote work is genuinely great for focused engineering work, hiring across borders, and reclaiming your commute hours. It’s also genuinely bad for loneliness, blurred boundaries, and the slow erosion of team trust when you stop being intentional about it. I’ve been running remote and distributed teams for years and this is what I’ve actually learned, not what the corporate blog template says.
Why I care about this topic
I’ve been working remotely in some form for most of my career. Not by accident, but because I kept building teams that were distributed by default. When you’re hiring engineers across multiple countries, “remote-first” stops being a philosophy and starts being a logistics problem you solve every week.
So when the pandemic hit and every company suddenly discovered remote work, I watched the discourse with a mix of amusement and frustration. Amusement because most of the “tips” being shared were things distributed teams had figured out years ago. Frustration because the loudest voices were often people who had been remote for six months and were already writing definitive guides about it.
This isn’t that. This is what I’ve learned from actually doing it for years, including the parts that nobody puts in their LinkedIn posts.
The real benefits
Deep work actually happens. This is the biggest one and it isn’t even close. In an office, your calendar gets colonized by meetings, drive-by questions, and the guy who wants to tell you about his weekend every Monday at 9:15. At home, I can put on headphones, close Slack, and write code or review architecture for three hours straight. That kind of focus is rare in an open office. It’s the default when you work remotely.
You hire from everywhere. When I stopped requiring people to live near an office, the talent pool didn’t just grow – it changed completely. Some of the best engineers I’ve worked with lived in cities I had never heard of. When you’re a smaller company that can’t compete with FAANG salaries, being remote-friendly is one of the most powerful recruiting advantages you can have.
No commute is life-changing. I know this sounds obvious but people underestimate it. Getting back one to two hours per day isn’t a minor convenience. It’s the difference between exercising or not, cooking a real meal or ordering delivery, spending time with family or showing up already exhausted. Over a year, that’s hundreds of hours. I’ve never met anyone who went back to commuting and said they were happier.
Autonomy breeds better engineers. Remote work forces people to be more self-directed. You can’t tap someone on the shoulder to ask a question, so you learn to read the docs, check the logs, and form a hypothesis before escalating. Teams I’ve managed remotely tend to develop stronger individual problem-solving habits over time. Not everyone thrives in that environment, but the ones who do become significantly better engineers.
The real dangers
Loneliness isn’t a joke. I’m not going to sugarcoat this. Working from home alone, day after day, can be genuinely isolating. The casual human interactions that happen in an office – grabbing coffee, complaining about the build system, eating lunch together – those disappear. You don’t notice it at first because you’re enjoying the quiet. Then six months in you realize you haven’t had a real conversation with a colleague that wasn’t about a Jira ticket. This hits people harder than they expect.
Work never ends unless you end it. When your office is your living room, there’s no physical act of “leaving work.” The laptop is right there. The PR review can happen after dinner. The Slack message at 10pm gets a reply because you saw the notification. I’ve caught myself multiple times checking deployment dashboards at midnight not because anything was on fire, but because the boundary between “on” and “off” had completely dissolved. This is the fastest path to burnout I’ve seen in remote teams.
Trust erodes silently. In an office, you see people working. You see them stuck on a problem, you see them helping a colleague, you see them at their desk deep in thought. Remotely, you see none of that. What you see is Slack status, commit history, and meeting attendance. Managers who don’t trust their teams start tracking mouse movements and requiring cameras on. Engineers who feel watched start performing visibility instead of doing actual work. This dynamic is toxic and it happens gradually.
Junior engineers suffer the most. This one took me a while to fully appreciate. Senior engineers have the context, the network, and the confidence to thrive remotely. Junior engineers need to absorb how a team thinks, how decisions get made, how to ask for help without feeling stupid. In an office, a lot of that happens through osmosis. Remotely, you have to build explicit systems to replace what used to happen naturally, and most teams don’t bother.
What actually works
Have a shutdown ritual. Not “set boundaries” – that’s useless advice. I mean a specific, repeatable action that signals “work is done.” For me, it’s closing the laptop lid, putting it in a drawer, and going for a walk. It sounds silly, but your brain needs a physical transition when there’s no commute to provide one. Find yours and do it every day.
Write everything down. This is non-negotiable for remote teams. Decisions made in a call that aren’t documented didn’t happen. Use written proposals for anything important. Record the outcome of every meeting. Make your team’s memory searchable. I’ve written about async communication before and I stand by it – writing-first culture is the single most important habit for distributed teams.
Create space for non-work interaction. Not forced fun, not mandatory virtual happy hours. Just space. A Slack channel for random conversation. Occasional calls with no agenda. Optional video coffee chats. The key word is optional. The moment you mandate socializing, it stops being social and starts being another meeting.
Over-invest in onboarding. When a new engineer joins a remote team, their first two weeks determine whether they will thrive or quietly disengage. Pair them with someone. Give them a small, completable task on day one. Have their manager check in daily, not weekly. Write an onboarding guide that actually reflects how the team works, not the aspirational version.
Default to async, escalate to sync. Start with a written message or document. If the thread is going in circles, jump on a call. After the call, write down what was decided. This flow protects focus time while still allowing real-time collaboration when it’s actually needed.
In short
Remote work isn’t inherently better or worse than office work. It’s a different set of tradeoffs. The focus and autonomy are real. The isolation and boundary problems are also real. What separates teams that make it work from teams that suffer through it is intentionality – about communication, about culture, about the human side of staring at a screen alone for eight hours a day.
I’m still a strong believer in remote-first teams. But I’m a much more honest one than I was five years ago.