Surlink
Back to Blog
Best Practices 6 min readFebruary 25, 2026

Building Async Teams: How to Lead Remote LATAM Engineers

Remote work requires different leadership. Here's how to manage distributed teams across timezones while maintaining velocity and culture.

Agustin Prada

You hired a great engineer from Colombia. Now what?

The mistake many companies make: they treat remote like in-office, but with Zoom calls.

Remote work—especially across timezones—requires fundamentally different leadership. Communication breaks down faster. Assumptions are more dangerous. Progress is easier to lose.

But done right, distributed teams are faster and more focused than collocated ones.

Async work means: critical information shouldn't require a real-time meeting.

<strong>Example of sync dependency (bad):</strong> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Manager: &quot;Let&#39;s jump on a call to discuss the API design&quot;</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Engineer: Waits 4 hours for timezone overlap</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Actual discussion: 15 minutes</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Total lost time: 4+ hours</li></ul>

<strong>Example of async (good):</strong> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Manager: Posts design doc in Slack (with context, alternatives, open questions)</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Engineer: Reviews during their first coffee</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Engineer: Responds with concerns and suggestions</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Manager: Reads response, decides, updates doc</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Total elapsed time: 12 hours</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Total thinking time per person: 30 minutes</li></ul>

Async is slower for decisions, but faster overall because people think deeply instead of winging it.

  • Slack messages instead of Zoom calls whenever possible
  • Slack threads instead of DMs
  • Documents (Google Docs, notion) instead of whiteboard sessions
  • GitHub issues instead of sidebar conversations

<strong>When sync is necessary:</strong> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Brainstorming something truly new (design exploration)</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Unblocked decisions needed within 2 hours</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Conflict resolution or sensitive feedback</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Team building and connection</li></ul>

When you reach out to your remote engineer, assume they've forgotten everything you discussed last week.

<strong>Bad:</strong> "Can you look at this? It's blocking deployment." <strong>Good:</strong> "We need to fix the database migration for the new user table. It's blocking us from deploying Saturday. Here's the PR, here's the context on why we need it Saturday, here's what I've tried, here's where I got stuck."

Context takes 2 minutes to write. It saves 30 minutes of clarifying questions.

Don't make decisions in Slack DMs or (worse) private emails.

Instead: <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Use public Slack channels</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Write decisions to a shared doc with reasoning</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Link the decision to the work (on the GitHub PR, the ticket, the design doc)</li></ul>

Your future self will thank you. Your team will understand why things are the way they are. New hires can review history instead of asking the same questions.

30 minutes, same time every week. This is sacred time for: <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">How are they doing (personally and professionally)?</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Are they blocked on anything?</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Growth and development conversation</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Feedback (good and bad)</li></ul>

Don't cancel 1:1s for meetings. Cancel meetings for 1:1s.

Every Friday, have each engineer write: <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">What I shipped this week</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">What I&#39;m working on next week</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">What&#39;s blocking me</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">What support I need</li></ul>

3 paragraphs max. Should take 10 minutes. Prevents surprises and keeps leadership informed.

If you have timezone overlap, a 15-minute standup can work. But: <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Keep it tight (what changed since yesterday)</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Make it optional for remote engineers (they can catch up async)</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Record it (those in other timezones can watch)</li></ul>

Better: skip daily standups and do async updates + 1:1s.

All hands meetings should be: <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Monthly or quarterly (valuable for alignment, not status)</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">All-hands (not just engineers)</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Recorded for people who can&#39;t attend live</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">45 minutes max</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Mix of company updates + social connection</li></ul>

The hardest part of remote work isn't productivity. It's culture.

  • <strong>Virtual lunch days</strong> (Slack bot pairs random people for 30-min coffee chats)
  • <strong>Async channel for wins</strong> (celebrate shipped features, personal milestones)
  • <strong>Team channel for personality</strong> (photos, memes, non-work stuff)
  • <strong>Annual in-person gathering</strong> (if budget allows, it's worth it)

When someone ships a big feature, deploy, or solve a hard problem: <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Mention it in all-hands or team channel</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Thank them specifically</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Let other engineers see the quality of work</li></ul>

Recognition matters more remotely because it's not automatic.

Remote teams need more intentional relationship building: <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">New hire dinner stipend (take your local team out together)</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Stipend for coworking spaces (people want occasional in-person)</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Equipment budget for home setup (it shows you care)</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Flexible hours (respect their timezone, don&#39;t demand sync for everything)</li></ul>

  • You can't see how hard someone is working
  • You can't overhear problems
  • Slipping productivity isn't obvious until it's too late
  • Output is visible (shipped code, closed issues, shipped features)
  • You can measure real work instead of "looking busy"
  • You can scale to larger teams without losing sight

<strong>The rule:</strong> Remote management is output-focused, not input-focused.

  • Don't track hours or presence
  • Do track shipped work and impact
  • Don't require sync meetings unless necessary
  • Do require clear documentation and communication
  • Don't measure by "how many meetings did you attend"
  • Do measure by "what value did you deliver"

Watch for: <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">&lt;strong&gt;Silence on Slack&lt;/strong&gt; (engineer is stuck, not asking for help)</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">&lt;strong&gt;Missed status updates&lt;/strong&gt; (disengagement usually precedes quitting)</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">&lt;strong&gt;Declining participation in meetings&lt;/strong&gt; (check in 1:1)</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">&lt;strong&gt;Taking on too much solo&lt;/strong&gt; (they&#39;re struggling, not confident)</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">&lt;strong&gt;Slow code reviews&lt;/strong&gt; (workload building up)</li></ul>

<strong>Mistake 1:</strong> Assuming remote = async always No. Remote engineers still need scheduled overlap time, 1:1s, and team connection.

<strong>Mistake 2:</strong> Over-communicating Sending 47 Slack messages per day doesn't mean you're managing well. Clear, thoughtful communication beats frequent updates.

<strong>Mistake 3:</strong> Timezone arbitrage without respect Don't hire someone in a convenient timezone for *your* flexibility while making *them* work odd hours. Respect their local time.

<strong>Mistake 4:</strong> No feedback loops Don't assume everything is fine because they ship code. Check in about satisfaction, growth, and culture fit.

<strong>Mistake 5:</strong> Treating remote as temporary Some managers act like remote workers are "lesser than" in-office employees. They're not. Same standards, different context.

Remote LATAM engineers need: <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Clear expectations and goals</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Regular feedback and recognition</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">A sense of belonging to something bigger</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Trust (you hired well, let them do their job)</li></ul> <ul class="my-4 space-y-1"><li class="ml-5 list-disc text-gray-600 leading-relaxed">Support when they&#39;re blocked</li></ul>

Get this right, and distributed teams outpace collocated ones.

If you're hiring LATAM talent for the first time, the management challenge is real but solvable.

<a href="https://calendly.com/surlinkgmail/30min" class="text-surlink-accent underline underline-offset-2 hover:text-surlink-blue" target="_blank" rel="noopener noreferrer">Book a call</a> with us and we'll walk you through what it takes to make remote teams work, from hiring through scaling.