Our Board Wants Us to 'Just Hire Remote Engineers from Lower-Cost Markets'—Is It That Simple?

General
1

I need to bring a question to the engineering leaders here because our board is pushing a solution to the talent shortage that sounds simple on paper but I’m skeptical about in practice.

The Board’s Solution

“Just hire remote engineers from lower-cost markets.”

The pitch they’re making:

  • Hire senior engineers in Eastern Europe, Latin America, or Asia
  • Pay 40-60% of US market rate
  • Solve talent shortage AND reduce costs
  • “Lots of companies are doing this successfully”

They’ve shown me spreadsheets. The cost savings look incredible. A senior engineer in Poland or Argentina for $80K instead of $180K in the US. The math is compelling.

My Skepticism

As a product leader, I’m worried about:

Time zone challenges: If engineering is in Argentina and product/design is in New York, when do we collaborate? How do we do rapid iteration?

Communication overhead: Cultural differences, language barriers (even with English proficiency), loss of hallway conversations and quick sync-ups

Team cohesion: Will distributed teams across continents build the same culture and collaboration as co-located or even distributed-within-US teams?

Legal/compliance complexity: International payroll, contractor agreements, IP protection, tax implications—this isn’t my expertise but it seems complicated

The Question I’m Bringing to Engineering Leaders

Is this actually solving the problem or creating new ones?

I hear conflicting stories:

  • Some companies thriving with fully distributed international teams
  • Other companies tried it and brought everyone back to regional hubs
  • Some use international contractors for specific projects, not core team

What I want to understand:

  1. What actually works? What’s the minimum viable approach to international hiring?
  2. What are the failure modes? Where does this fall apart?
  3. What would you do differently? If you’ve tried this, what did you learn?

The Variables I’m Trying to Understand

  • Time zone overlap: Is 4 hours enough? Do you need full overlap?
  • Cultural alignment: How do you build culture across continents?
  • Synchronous vs. asynchronous: What work can be async? What needs real-time collaboration?
  • Legal/payroll: How complicated is this really? Employer of Record services?

The Specific Scenario

We’re a Series B fintech product, 45 engineers currently (all US-based in 3 locations). Looking to add 15 engineers over next 6 months.

Board is suggesting: Hire 10 in Latin America (Argentina, Colombia, Brazil), 5 in US.

My questions:

  • Is 10 international / 5 US too aggressive for first time doing this?
  • Should we start with 2-3 international to learn before scaling?
  • What roles work internationally vs. need to be local?

I’d genuinely value the engineering leader perspective here because this decision affects product delivery, team culture, and company trajectory.

What’s your experience with international hiring? What worked? What failed?

2

David, I’m going to share our journey with this because we went fully remote in 2023 and now have 40% of our engineering team international. But the path wasn’t what your board is describing.

What We Actually Did (And Why)

We didn’t go international primarily for cost savings. We did it for access to talent that didn’t exist in our local market.

Key decision: We hired in time zones with meaningful overlap—4+ hours minimum. Not “anywhere in the world for cheapest cost.”

Our international team:

  • Latin America: Argentina, Brazil, Colombia (4-6 hour overlap with US Eastern)
  • Europe: Poland, Portugal (5+ hours overlap with US Eastern before lunch)
  • Not Asia: Considered but time zone gap was too severe for collaborative engineering work

The Critical Prerequisite: Async-First Culture

We built async-first practices before hiring internationally:

  • Documentation-first development: Every decision, design, tradeoff documented in writing
  • Recorded meetings: All standups, planning, reviews recorded and available async
  • Core hours: Everyone online 10am-2pm Eastern, flexible outside that
  • Written communication defaults: Slack/Notion over spontaneous meetings

Reality check: This took 6 months to build. We practiced async-first with our US team before adding international engineers.

The Actual Cost Savings (Less Than Your Board Thinks)

Salary saved: Yes, senior engineers in Argentina cost 40-50% less than US equivalent

Additional costs:

  • Premium collaboration tools (Slack, Zoom, Notion, Miro): +$15K/year
  • Annual company offsites to build relationships: +$80K/year
  • Legal/payroll (Employer of Record services): +$5K per international employee/year
  • Travel budget for critical in-person work: +$30K/year

Net savings: Still meaningful but not the 50% your spreadsheet shows. More like 25-30% after all costs.

What Actually Works

Success pattern: Backend platform work, data engineering, infrastructure

  • These can be largely async
  • Clear interfaces and documentation
  • Less need for real-time collaboration

Challenges: Real-time incident response, customer-facing features requiring tight product collaboration

  • Harder to coordinate across time zones
  • Benefits from synchronous communication

The Answer to Your Question

Is 10 international / 5 US too aggressive? Yes, in my opinion.

Better approach:

  • Start with 2-3 international engineers in similar time zone (Latin America for you)
  • Learn for 6 months: What works? What’s harder than expected?
  • Build async practices with that small team
  • Then scale if it’s working

Critical question for you: Does your product team have capacity to work async? Because if engineering is international but product/design requires real-time collaboration, you’ll create friction.

3

Strong advocate for international hiring here, but Michelle is right that it needs to be done thoughtfully.

My Experience: Exceptional Engineers Who Couldn’t Relocate

We’ve hired incredible engineers from Nigeria, Brazil, Poland, and Mexico. Not because they were cheaper—because they were talented people who couldn’t or wouldn’t relocate to the US.

Example: One of our best platform engineers is in Lagos, Nigeria. Brilliant systems thinker, couldn’t get US visa. We would have lost that talent if we required US-based.

The Framework That Works for Us

Time zone overlap is non-negotiable for collaborative roles:

  • 4+ hours overlap minimum for engineers working on shared systems
  • 6+ hours overlap for roles requiring tight product/design collaboration
  • No overlap required for truly independent contractor work

We built a “core hours” model:

  • Everyone online 10am-2pm Eastern (our headquarters)
  • Async outside those hours
  • Critical meetings recorded
  • Written summaries for all decisions

The Diversity Benefit (Often Overlooked)

International teams bring different perspectives that improve product thinking:

  • Our Nigerian engineer flagged mobile data cost issues we’d never considered (huge in emerging markets)
  • Brazilian engineer pushed for better internationalization from day one
  • Polish engineer brought security practices from European regulatory environment

This isn’t just cost savings—it’s better product development through diverse perspectives.

The Challenge: Onboarding for Remote/Async

We had to completely redesign onboarding for international remote engineers:

Old onboarding: Pair with senior engineer for 2 weeks, shadow meetings, ask questions
New onboarding: Self-service documentation, recorded onboarding sessions, structured async check-ins

Investment: Took 3 months to build proper async onboarding. But now new hires (domestic or international) ramp faster.

The Compensation Philosophy Question

David, this is where it gets ethically complex: Do you pay market rate for location or standard global rate?

Location-based: Engineer in Argentina gets $80K, engineer in San Francisco gets $180K for same role
Global-standard: Every engineer gets $180K regardless of location

We chose a hybrid: Base salary adjusted for location, but equity grants are equal.

Rationale: Cost of living varies dramatically, but contribution to company value doesn’t.

Controversial: Some people think this is unfair. But pure location-based feels exploitative (“we pay less because we can”), and pure global-standard is financially unsustainable for startups.

My Answer to Your Question

“Is it that simple?” No, but it’s worth doing.

Start small: 2-3 hires in Latin America (similar time zone to you)
Build async practices first: Don’t hire internationally if you’re still sync-dependent
Focus on talent access, not just cost: Hire great people who happen to be international, not cheap labor

Michelle’s right: if your product team needs real-time eng collaboration, international hiring will create friction. Does your team work async effectively? That’s the prerequisite.

4

Financial services perspective—we tried this, had mixed results, learned some hard lessons.

What Worked: Data Engineering Across 3 Countries

Our data platform team is distributed across US, Colombia, and Poland. Works beautifully.

Why it works:

  • Data pipelines are largely async work
  • Clear interfaces and data contracts
  • Less need for real-time collaboration
  • Well-documented systems and processes

We have daily standup at 11am Eastern (recorded), everyone contributes async updates, escalate issues in Slack.

Result: High-performing team, good retention, significant cost savings.

What Failed: Real-Time Trading Platform Team

We tried to build a real-time trading system with engineers distributed across 12-hour time zones.

Complete failure.

The work required:

  • Instant response to production incidents (market hours are market hours)
  • Tight coordination between services (latency measured in milliseconds)
  • Regulatory compliance requiring real-time oversight

We brought the entire team back to two US locations. The async model simply didn’t work for this use case.

The Framework I Developed

Async-compatible work = International hiring works:

  • Backend platform engineering
  • Data engineering and analytics
  • Internal tools and automation
  • Developer experience/tooling

Sync-dependent work = Keep local:

  • Real-time systems requiring instant coordination
  • Incident response and on-call work during business hours
  • Highly collaborative product development
  • Customer-facing features with tight iteration cycles

The Regulatory/Compliance Reality (Often Overlooked)

David, you’re in fintech—this matters for you:

Legal constraints we hit:

  • Some financial data cannot be accessed outside US due to regulations
  • Compliance reporting requires US-based oversight in certain cases
  • Security clearances for sensitive systems limit international hiring

We ended up with a tiered access model:

  • International engineers: General platform work, no access to sensitive customer data
  • US engineers: Customer-facing systems, compliance-sensitive work

This creates complexity but was legally necessary.

The Hidden Cost (Michelle Touched on This)

After legal fees, Employer of Record services, contractor management, increased travel for team building, collaboration tool upgrades…

Real cost savings: 15-20%, not the 50% your board’s spreadsheet shows.

Still meaningful! But set realistic expectations.

My Answer to Your Specific Question

10 international / 5 US for first time? Way too aggressive.

Better path:

  1. Start with 2 engineers in one country (I’d suggest Colombia or Argentina for time zone)
  2. Choose async-compatible roles (backend platform, data, internal tools)
  3. Learn for 6 months: what’s hard? What’s easy? What surprised you?
  4. Build async infrastructure and practices
  5. Scale if working well

Critical question: Have you assessed which parts of your fintech product can be built async vs. require sync collaboration?

Map your product requirements to work styles before hiring internationally.

5

Design systems perspective—my team is partially distributed and I have strong opinions based on what worked and what was painful.

What Works: Design Implementation Can Be Async

We have engineers in 3 time zones (US East, US West, Argentina) working on design system implementation.

This works because:

  • Component implementation is relatively independent
  • Clear specs in Figma with detailed documentation
  • Async code review works fine
  • Weekly sync is enough for alignment

Tool investment was critical: Figma for design specs, Storybook for component documentation, Loom for async video explanations, Notion for written docs.

This wasn’t optional—we spent heavily on tools to enable async work.

What Doesn’t Work: Collaborative Design Ideation

We tried having design ideation sessions with engineers distributed across 8-hour time zone gap.

Painful.

Real-time whiteboarding, brainstorming, rapid iteration—these need synchronous collaboration. Async design exploration is slow and loses creative energy.

Our solution: Keep design ideation and early product exploration synchronous (requires time zone overlap). Implementation can be distributed.

The Cultural Risk Everyone’s Underplaying

International distributed teams can work, but it takes intentional cultural investment.

What we learned the hard way:

Without regular in-person interaction, distributed teams fragment:

  • US team develops internal jokes and references international team doesn’t understand
  • Different countries develop different working norms
  • People feel isolated and disconnected from company culture

What we now do:

  • Quarterly all-hands offsites (expensive but essential)
  • Monthly virtual social events (not about work)
  • Explicit inclusion practices (record meetings, summarize in writing, rotate meeting times so no one timezone always gets inconvenient slots)

This takes work. Don’t assume remote will “just work”—it requires active culture building.

The Async Readiness Question

David, you asked if your board’s plan is realistic. Here’s my question back:

Does your engineering team culture currently support async-first working?

Quick test:

  • Can engineers get context on a project from documentation alone, without asking someone?
  • Are meetings recorded and summarized in writing?
  • Can someone who missed a meeting catch up fully from async artifacts?
  • Is decision-making transparent and documented?

If you answered “no” to any of these, you’re not ready for international distributed teams yet.

Build async practices with your local team first. Then hiring internationally becomes much easier.

My Suggestion

Before your board commits to international hiring, run a 60-day experiment:

Treat your current co-located team as if they were distributed:

  • Require all meetings to be recorded
  • Document all decisions in writing
  • Enforce async communication defaults
  • See how it feels and where it breaks

If that’s painful with your local team in the same time zone, it’ll be worse with international teams across 5+ hour gaps.

Start small, learn, iterate. Don’t let the board’s spreadsheet optimism override operational reality.