I first wrote about remote teams in 2019. At the time, remote work was still a perk — something progressive companies offered, while most engineering organizations defaulted to open-plan offices and daily standups around a physical board. Then COVID happened, and suddenly the entire industry was running the largest uncontrolled experiment in distributed work history.
What surprised me wasn’t that remote work worked. I’d been doing it for years and knew it could. What surprised me was how many organizations learned the wrong lessons from it. They either declared remote work a failure and mandated return-to-office, or they kept the Zoom-heavy, always-on model that had burned everyone out during the pandemic and called it “remote culture.”
Neither is right. After working as a CTO in a fully-remote company and later managing distributed engineering teams across Germany and Canada at AutoScout24 and Trader Inc., I’ve landed on a set of principles that actually hold up.
The Real Problem Isn’t Productivity
Most debates about remote work obsess over the wrong variable: productivity. Managers worry people are slacking off. Employees worry they’re being watched. Both sides produce studies that confirm whatever they already believed.
Here’s what I’ve learned from running distributed platform engineering teams: individual productivity is rarely the problem. Most remote engineers are, if anything, more productive in focused work than their office counterparts. The absence of shoulder-taps, impromptu “quick questions,” and open-plan noise gives them deep work time that offices struggle to provide.
The actual failure modes of remote teams are different and harder to measure:
- Information asymmetry. Some people know things others don’t, and nobody notices because there’s no coffee machine where the gap would surface naturally.
- Decision latency. Decisions that would take five minutes in a hallway conversation take days of async back-and-forth because the right people aren’t in the same thread.
- Relationship decay. People who’ve never shared a meal together will default to the most uncharitable interpretation of a Slack message.
- Invisible struggles. A team member who’s stuck, overwhelmed, or disengaged is much harder to spot when you can’t see their face or energy level in the room.
These are the problems worth solving. And none of them are solved by installing surveillance software or mandating cameras-on during meetings.
Async-First Is the Foundation
The single most impactful shift a remote team can make is going async-first. Not async-only — that’s a different extreme with its own problems. Async-first means the default mode of communication is written and asynchronous, with synchronous meetings reserved for situations that genuinely need them.
Why does this matter so much? Because most remote teams make a critical mistake: they replicate the office experience over video calls. The result is a schedule packed with meetings, with “real work” squeezed into the gaps. Engineers end up in six hours of Zoom calls and then writing code between 7 and 10 PM. That’s not remote work — it’s office work with a shorted commute to the kitchen.
Async-first requires a few things to actually function:
Write things down. This sounds obvious but almost nobody does it well. Decisions need to be documented where people can find them — not buried in Slack threads that scroll into oblivion within hours. At AutoScout24, we use RFCs and ADRs (Architecture Decision Records) for anything that matters. The discipline of writing a decision down forces clarity that verbal discussions often skip. It also creates an artifact that new team members can find six months later, instead of having to reconstruct context from people’s memories.
Make status visible without asking. The old “what did you do yesterday?” standup question is a poor man’s visibility system. Better approaches: project boards that reflect actual state, automated deployment notifications, PR dashboards. If a manager needs to ask an engineer what they’re working on, that’s a systems failure, not a people failure.
Default to the permanent channel. Slack DMs are where information goes to die. Team decisions made in DMs are invisible to everyone who wasn’t in the conversation. Push discussions to public channels, even when it feels slightly awkward. The team member who joins next month will thank you.
Respect time zones ruthlessly. At AutoScout24, our teams span Germany and Canada — a six-hour time difference. That’s manageable, but only if you design for it. Meetings have to fit the overlap window. Everything else has to work asynchronously. This constraint, paradoxically, makes communication better because it forces you to write clearly enough that someone reading your message hours later can act on it without a follow-up call.
Trust Through Systems, Not Speeches
My 2019 article talked about “trust by default.” It’s a nice sentiment, but it’s incomplete. Trust isn’t a switch you flip. It’s an emergent property of well-designed systems.
What do I mean by that? Consider two scenarios:
Scenario A: A manager tells their team “I trust you” but has no visibility into what’s happening. When something goes wrong, they panic. Suddenly there are daily check-ins, status reports, and uncomfortable questions. The team feels surveilled. Trust evaporates.
Scenario B: The team uses a transparent project board. Code is reviewed in public PRs. Deployments are automated and visible. Release metrics are shared. The manager doesn’t need to ask what’s happening because the system makes it visible. They can genuinely trust because they’re not operating blind.
Trust-by-default without transparency is just willful ignorance dressed up as leadership philosophy. Real trust comes from systems that make the right information visible to the right people at the right time — so nobody needs to ask, nobody needs to report, and nobody needs to worry.
This is especially important during the first months with a new team member. Instead of vague expectations and a “figure it out” onboarding, build an onboarding path that makes expectations explicit: here’s how we work, here’s where decisions live, here’s what good looks like, here’s how to get help. The faster someone reaches autonomy, the faster trust develops naturally — not because you decided to “trust by default,” but because they’ve demonstrated competence in a system that makes competence visible.
The In-Person Question
My 2019 take on team building boiled down to: meet your colleagues in person and have a beer. It’s still true, but it’s too simple.
Post-COVID, the question isn’t whether to meet in person but how to make it count. Flying a distributed team to the same city for a week is expensive. If they spend that week in the same meetings they could’ve done on Zoom, you’ve wasted the budget.
In-person time should be optimized for what remote work is bad at:
- Relationship building. Unstructured time matters more than agenda items. Dinners, walks, side conversations — this is where people stop being avatars and start being humans. One real meal together is worth a hundred Slack exchanges for building trust.
- Creative problem-solving. Whiteboard sessions, design sprints, and messy collaborative work where people interrupt each other productively — these genuinely benefit from physical presence.
- Conflict resolution. Tensions that fester in async communication often dissolve in person. Tone, body language, and shared laughter do heavy lifting that text can’t.
- Onboarding. New team members benefit enormously from meeting the team in person early. It creates a foundation of personal connection that makes all subsequent remote interaction smoother.
What doesn’t need in-person time: status updates, sprint planning, retrospectives, code reviews, most decision-making. If your offsite agenda is full of these, you’re not using it well.
At AutoScout24, we bring teams together periodically, and the format has evolved through trial and error. The most successful offsites have minimal formal agenda and maximum shared experience. The work that actually needs to happen in person is usually relationship work, not project work.
AI Changes the Equation
Here’s what my 2019 article couldn’t have anticipated: AI coding assistants have fundamentally changed the dynamics of remote engineering work.
When a developer can pair-program with an AI, the cost of being stuck drops dramatically. Questions that used to require interrupting a colleague — ”How does this service handle authentication?” or ”What’s the pattern for error handling here?” — can often be answered by an AI that has context on the codebase. This is a genuine game-changer for distributed teams, where “just asking someone” carries a much higher latency cost than in an office.
But AI introduces new challenges too. When individual developers can move faster, coordination becomes more important, not less. Two engineers working in parallel with AI assistance can diverge rapidly if they’re not aligned on architecture and approach. The speed that AI enables makes shared vision and clear architectural direction more important than ever.
AI also shifts what remote team communication should focus on. Less time explaining how to do things, more time aligning on what and why. The tactical coding questions go to AI. The strategic conversations — what should we build, for whom, and why this approach over that one — still need human discussion. Remote teams that recognize this shift can redesign their communication patterns around it.
What Still Doesn’t Work
Honesty demands acknowledging what remote setups still struggle with, even when done well:
Mentoring junior engineers is harder. The osmotic learning that happens when a junior developer sits near senior engineers — overhearing design discussions, watching how they debug, absorbing judgment and taste — doesn’t transfer well to remote. You can compensate with structured pairing sessions, recorded design reviews, and deliberate teaching moments, but it requires conscious effort that offices provide for free.
Spontaneous collaboration takes a hit. The best ideas sometimes come from accidental collisions — two people from different teams chatting at the coffee machine and realizing they’re solving the same problem. Remote work has no equivalent. You can create “virtual serendipity” through cross-team channels, random coffee chats, and internal tech talks, but it’s a pale imitation.
Reading the room is impossible. In a meeting room, you can see someone’s body language shift when they disagree but don’t want to speak up. On a Zoom call with cameras off — which is most of them, despite policies — you get silence. This makes it harder to surface disagreement, which means decisions get made without genuine buy-in.
Social isolation is real. Some people genuinely need the social structure of an office. Not everyone thrives working alone from their apartment. And while the “just go to a coworking space” advice helps some, it doesn’t recreate the tribal belonging of a team that shares physical space. Leaders need to watch for signs of isolation and not dismiss them as a remote work skill issue.
None of these are dealbreakers. But pretending they don’t exist — which the “remote work is perfect” crowd tends to do — leads to teams that look functional on paper while people quietly burn out or disengage.
Making It Actually Work
After years of iterating on distributed team leadership, here’s what I’d tell someone building a remote engineering team today:
Design for async first, then add synchronous rituals where they genuinely help. Not the other way around. Most teams over-index on meetings and under-invest in documentation, which is exactly backward for remote work.
Build transparency into your tools and processes, not into your management habits. If you need to ask someone what they’re doing, you have a systems problem. Fix the system, don’t add more check-ins.
Invest in in-person time, but make it about relationships, not status updates. Two offsites per year with the right format beats monthly all-hands that nobody wants to attend.
Take the mentoring gap seriously. It won’t fix itself. Junior engineers in remote teams need structured support, not just access to a Slack channel.
And stop debating whether remote work “works.” It does. The interesting question — the one worth your leadership energy — is how to make it work well. That’s a design problem, not a policy decision. And like all design problems, it requires iteration, honesty about what’s failing, and the willingness to keep adjusting.
The organizations that thrive with distributed teams aren’t the ones that found a magic formula. They’re the ones that treat remote work as a craft — something to be studied, practiced, and refined — rather than a perk to be granted or revoked based on the latest headline.