Over the years, I’ve worked on a wide variety of projects with different teams in all sorts of places—from Europe to Australasia and North America. In that time, I’ve seen remote setups both fall apart and completely exceed expectations. The real difference-maker was never just the tools or who was on the team—it always came down to how people built trust, how clearly they communicated, and how much they supported one another.
The shift to remote work wasn't just a pandemic trend—it fundamentally changed how we build software together. And here's the thing: most of us are still figuring it out.
Remote Work: Embracing the New Reality
After all this time, I think we need to agree: remote and hybrid work is the new norm, and there's no going back.
I understand it's difficult to adapt with old-school approaches. But just like every other evolution in our industry, we need to find new ways to work effectively and put together practices that help teams achieve more—without losing connection or the feeling that we're still one cohesive team working together.
Remote work isn't a compromise. When done right, it's an advantage that unlocks global talent, improves work-life balance, and often leads to better outcomes than traditional office setups.
The key? Intentional systems, clear communication, and genuine trust.
1. Building Trust: The Foundation of Everything
Trust is the core—the most important thing in any team. When team members trust each other, together you can achieve remarkable things. Remote setups make this a bit harder to build, but we need to acknowledge that challenge and work together as a team to establish this foundation of trust.
Here's what I've seen work well in the teams I've been part of that successfully handled remote collaboration.
Structured Standups with Human Connection
On some teams, standups were boring and lifeless. People would do other work, leave their cameras off, and hardly listen.
But the best teams handled standups in a much better way:
- Keep standups short and focused: done → next → stuck → help needed
- Ask about feelings, not just tasks—"How are you doing?" matters as much as "What are you working on?"
- Leave 10-15 minutes after standup for the team to communicate freely, tell stories, and connect
Important: Make sure product owners or project managers aren't dominating this social time. The team should rotate who leads these conversations and ensure both introverts and extroverts have space to participate.
Post-Retro Team Games
One of the best practices I've seen came from my time with the Watercare team. After each retro, we'd book time for a game that helped the team know each other better and laugh together, not at each other.
Some that worked well:
- Favorite food or brand rankings (moving items from "best" to "trash")
- "Two truths and a lie" about tech preferences
- Quick trivia about team members
These moments build genuine connections that make collaboration easier when challenges arise. The key is making it optional and genuinely fun—not forced team building that everyone dreads.
Consistency Builds Credibility
I've learned that trust isn't built with pizza parties and team offsites. It's built through showing up consistently in code reviews, following through on commitments, and being transparent when things go wrong.
- Follow through on promises—always
- Be transparent about decisions and technical challenges
- Show up reliably, especially when teammates need help
2. Mastering Asynchronous Communication
Early in my remote work experience, I watched teams struggle because everything needed a meeting. "Quick sync" became the default response to any question. The result? Engineers were in back-to-back calls all day, and actual coding happened between 6pm and midnight. That was unsustainable.
Teams need to agree on what the standard communication streams are and when each should be used.
Communication Channels
- Slack/Teams → Quick updates, questions, and daily collaboration
- Email → Formal communication, external stakeholders, documentation
- Docs/Jira → Long-term knowledge, requirements, decisions
When to Switch Channels
Here's a practical guide I've found works:
Quick question on Teams/Slack:
- After 3-5 messages, if it's taking longer → move to a call
I can't tell you how many times I've watched engineers go back and forth 20 times on Slack when a 5-minute call would have solved it. If you're typing your third explanation, just hop on a call.
Email threads:
- If an email thread becomes long and complicated → schedule a meeting to resolve it face-to-face
Long knowledge docs in Jira/Confluence:
- Make sure all team members know these exist and where to find them
- Reference them regularly in conversations
The biggest async mistake I see? Engineers writing docs that nobody knows exist. If you're not actively pointing people to your documentation, you might as well not have written it.
3. Clear Communication Protocols
After the team agrees on the main communication streams, we need to establish how to use them the right way. When you have a question or need an update, everyone should know the expected response time.
Example Response Time Setup
#urgent→ respond in 15 mins#project→ respond in 2 hours#general→ respond in 4 hours#watercooler→ reply whenever
Escalation Rules
Make it clear when and how to escalate:
- Tag someone if you need their attention
- Use @channel sparingly (real emergencies only)
- If blocked for more than 2 hours, escalate to team lead
The goal: Everyone knows where they stand, what's expected, and there are no surprises.
4. Technical Leadership in Remote Teams
I once joined a remote team where code reviews took 5 days minimum. PRs would sit there while engineers pinged on Slack, sent emails, and eventually just merged without approval. The problem wasn't laziness—it was lack of clarity on what "good enough" meant.
Structure around quality and knowledge sharing is critical when your team is distributed.
Code Reviews: Where Things Get Ugly Without Standards
Code reviews can become a pain point if they're not clear and clean. I've seen teams try complex code review standards in 10-page documents that nobody read.
Here's what actually works:
-
Establish a severity system—what's critical vs. what's a suggestion
-
Create a code review template that covers all the checklist items your team needs to maintain code quality:
- Functionality and business logic
- Tests and coverage
- Security vulnerabilities
- Performance considerations
- Code readability and maintainability
- Documentation
-
Keep reviews constructive—focus on learning, not criticism
-
Review promptly—don't leave PRs hanging for days
The key is making the distinction clear: "This will break production" vs. "I would have done this differently." Most code review drama comes from treating preferences as requirements.
Knowledge Sharing Sessions
This is a great way to maintain team culture and ensure continuous growth.
The best teams I've been on schedule regular knowledge-sharing sessions (bi-weekly or monthly) where team members can self-improve and share their knowledge. Everyone prepares questions and has healthy discussions. Rotate presenters so everyone gets experience teaching, and record sessions for those who can't attend live.
Topics that work well:
- New libraries or tools someone discovered
- Architecture decisions and trade-offs
- Debugging war stories (we all have them!)
- "Today I Learned" quick hits
The best sessions I've seen are when junior engineers teach something. It forces them to deeply understand the topic, and senior engineers often learn surprising things from fresh perspectives.
5. Handling Time Zones Without Losing Your Mind
Time zones are tough, but manageable with the right habits.
Practical Tips
- Find overlap windows for meetings—keep them short and valuable
- Use async handoffs with excellent documentation
- Advocate for rotating meeting times so no one is always stuck with midnight calls
- Record important meetings for team members who can't attend
- Use world clock tools—always show meeting times in multiple zones
Pro tip: I always add world clocks for my team's locations to my desktop and Slack. It helps me be mindful before scheduling pairing sessions or technical discussions that might be at 10pm for someone else.
I've been on teams where meeting times were convenient for some but brutal for others. Someone in Germany joining at 10pm every day burns out fast. The best teams rotate the pain—it's only fair.
6. Building Remote Team Culture
Culture doesn't "just happen" remotely—teams need to design for it intentionally.
Ideas That Actually Work
-
Virtual coffee chats—random 1:1s just to talk, not about work
-
Post-standup social time (as mentioned earlier)
-
Post-retro games that build connection
-
Fun Slack channels—but make sure they're common interests for the whole team:
#pets(universal!)#music#gaming#random-thoughts
-
Celebrate wins publicly → Recognition fuels motivation. When someone does great work, shout it out in team channels.
Remember: Make space for different personality types. Not everyone wants to be in the spotlight, but everyone wants to feel valued.
I've been on teams that tried forced fun with virtual happy hours. People hated it. The introverts felt obligated to show up and be "on," while extroverts found it artificial. What worked better? Optional hobby channels and letting relationships form naturally.
7. What Good Performance Looks Like in Remote Teams
Forget tracking hours online. Outcomes matter more than activity.
I've seen managers obsess over green dots in Slack or activity in Jira. That's not management—that's surveillance. If someone needs to track when you're online, the trust is already broken.
What Actually Matters
Delivery:
- Completing sprint commitments
- Quality of work
- Meeting technical deadlines
Collaboration:
- Code reviews given and received
- Helping teammates when they're stuck
- Documentation contributions
- Sharing knowledge
Growth:
- Learning new skills
- Taking on technical challenges
- Proposing improvements
- Mentoring junior engineers
Communication:
- Keeping team informed of progress and blockers
- Contributing to technical discussions
- Being responsive in agreed channels
- Writing clear documentation
The engineers I've most enjoyed working with aren't the ones online 24/7. They're the ones who deliver quality work, help their teammates, and communicate effectively.
What I've Learned the Hard Way
Looking back over 20+ years of working on distributed teams, here are the lessons that stick:
Trust is built through consistency, not grand gestures. Being reliable in code reviews and pairing sessions matters more than any team offsite.
Over-communicate rather than under-communicate—especially in remote settings. What feels like overkill to you is probably just enough for your team.
Write everything down. Your future self (and your teammates) will thank you. I can't count how many times documentation I wrote 6 months ago saved hours of re-explaining.
Focus on outcomes, not hours. Some of the best engineers I've worked with do their best work at 11pm in their pajamas. Judge by results, not activity.
Relationships matter—invest in them first, technical collaboration follows. I used to think relationship building was "nice to have." I was wrong. It's everything.
Embrace async—not everything needs real-time discussion. Some technical problems need space to think, not immediate responses.
Remote teams need clarity above all—clear technical requirements, clear expectations, clear communication. Ambiguity kills remote teams faster than anything else.
Final Thoughts
Working on and mentoring remote teams requires empathy, well-designed systems, the right tools, and genuine investment in people.
But here's what I've learned: When done well, remote teams don't just match traditional in-office performance—they exceed it.
Why? Because you're working with people based on talent and fit, not geography. Because team members have the flexibility to do their best work when they're at their best. Because written communication forces clarity that verbal discussions often lack.
The future of work is distributed. The tech leads and engineers who master remote collaboration—who build trust across time zones, advocate for better systems, and genuinely support their teammates—will thrive in this new reality.
What's your experience with remote teams? I'd love to hear what's worked for you. Connect with me on LinkedIn or drop me a message.