The Manager's Dilemma: Why Your Best Engineer Struggles to Lead Async Teams

You promoted your best developer to team lead six months ago. They were an A-player - shipped features faster than anyone, code quality was pristine, and the team respected them. Natural choice.

Then something broke.

They’re spending three hours a day in meetings trying to stay on top of what people are doing. They’re frustrated because they can’t tell who’s actually working and who’s just Slacking. Their one-on-ones are awkward and formal now, not the casual check-ins they were used to. The developers on their team (especially the Canadian ones) seem distant - not disengaged, but somehow less connected.

By month six, your best IC is burned out from managing. Your team’s productivity is down. And you’re wondering if promoting them was a mistake.

It wasn’t. The mistake was promoting them into a management style that doesn’t work in async environments - and then expecting them to figure it out alone.

Why Traditional Management Breaks in Async Cultures

Here’s what’s actually happening:

Your new manager was trained - through five years as an IC - to operate in a synchronous, visibility-based culture. They know how to:

Show up, get things done, and prove it through presence
Have quick face-to-face conversations to unblock problems
Mentor by pairing and watching over someone’s shoulder
Manage through informal check-ins and observation
Feel confident when they can see their team working

Those are legitimate manager skills. They work fine in an office. They work fine in a co-located remote team where everyone’s roughly on the same schedule.

But in an async-first distributed team, they become a trap.

An async developer doesn’t need you in a meeting. They need clarity - written, documented, unambiguous. They don’t need you checking in synchronously; they need you trusting them to manage their work and coming back with status you can actually use. They don’t learn from watching you code; they learn from thorough written feedback on their pull requests. And they don’t feel managed; they feel supported when you ship context to them while they sleep, so they wake up to answers.

When a manager trained in synchronous culture tries to lead an async team, here’s what happens:

They over-communicate through meetings. They schedule 1:1s, team syncs, check-ins, and status meetings to try to recreate the “management visibility” they’re used to. But in an async context, meetings are a failure mode. Every meeting is asking the developer to stop what they’re doing, join a call, and spend time on synchronous talk instead of async work. The message they send is: “I don’t trust you to tell me what’s happening in writing.”

They struggle with developer autonomy. A developer working async on a different timezone is, by definition, making decisions without your input for 8-12 hours at a time. A synchronous manager finds this anxiety-inducing. So they ask for approval on things that don’t need it. “Can you do X before you ship?” “Run this by me first.” The developer, who was hired to work independently, feels micromanaged.

They mistake silence for disengagement. In a async culture, a developer who’s in deep focus doesn’t Slack updates. They’re heads-down. They’ll post their status at 9 AM. But a synchronous manager, who’s used to seeing activity as a proxy for effort, interprets this as “they’re not working hard.”

They default to synchronous feedback. A 1:1 to discuss performance feedback is synchronous. A Slack message giving someone a quick compliment is synchronous. A meeting to align on goals is synchronous. All of these break the async rhythm. The developer is constantly being yanked out of focus for real-time conversation. It feels like management, but it’s actually management overhead.

Developers in this spot rarely leave because the work is bad. They leave because they’re worn out from context-switching and tired of being micromanaged. Retention breaks down when management doesn’t match how the team actually works.

The Management Patterns That Actually Work Async

Here’s what separates managers who thrive in async cultures from those who don’t:

One-on-ones become asynchronous check-ins.

Instead of a weekly 30-minute sync, you do a weekly async 1:1. The developer writes: what I shipped this week, what I’m working on next week, what I’m blocked on, how I’m feeling. You read it and respond in writing - not immediately, but within 24 hours. You ask follow-up questions. You share context they need. The conversation is deeper because everyone has time to think.

This feels wrong to synchronous managers, and sometimes they’re right. A written check-in won’t catch the person who’s quietly struggling but never writes it down. Keep a live conversation every few weeks, and whenever the written updates start getting shorter.

Feedback is written, not spoken.

The developer ships a PR. Your senior engineer does a thorough async code review - detailed, thoughtful, with specific reasoning. The developer reads it, thinks overnight, comes back with questions. The feedback lands in writing, where it can be referred back to, not delivered in a 1:1 where you both forget the specifics by next week.

Managers who struggle here try to give all feedback in a meeting. It feels more personal, and it is - but the developer can’t refer back to it. Hard feedback is the exception: say it live, then follow up in writing.

Goals are clarified in writing, not in meetings.

You don’t have a “goal-setting meeting.” You write a clear document: here’s what I think we’re trying to optimize for next quarter, here’s what success looks like, here’s what I need from you. You share it. The developer reads it, pushes back async, clarifies. You iterate in a shared doc. By the time you’ve reached consensus, the goal is crystal clear - not because you sat in a room together, but because you wrote it down and made it legible.

Trust signals shift from presence to shipping.

A synchronous manager feels confident when they see their team active, responding on Slack, in meetings, engaged in real time. An async manager feels confident when work ships, reviews happen within SLA, goals are being met, and the developer’s own output says they’re thriving.

This requires you to actually measure what matters. Shipped work. Code quality. Developer growth. Not presence, not activity, not Slack responsiveness. It’s more demanding than synchronous management, because you can’t lean on the appearance of busyness.

Why This Matters for Your Nearshore Hire

Here’s the connection most VPs miss:

When you hire a Canadian developer, you’re not just hiring talent. You’re committing to a management philosophy. And if your new manager isn’t equipped for async leadership, the hire will fail.

The developer will be talented. They’ll pass every technical screen. But they’ll be managed by someone who:

Schedules meetings at awkward times and calls it “timezone inclusion”
Doesn’t trust their async updates and asks for constant sync check-ins
Gives feedback in real-time conversations they can’t refer back to
Micromanages because silence makes them anxious

That developer may well leave within a year, and you’ll blame the nearshore model when the management was the problem.

DecodeTalent’s 95% retention rate exists because we’re placing developers into companies where the management culture is already async-first or willing to build it. The developers stay not because Canadian talent is magically more loyal, but because they’re managed in a way that respects how they work.

If you hire a developer and then subject them to synchronous management, you’ve just created an expensive, preventable retention problem.

The Management Audit

Before you promote your next IC into a management role, and especially before you hire a nearshore team, run this audit:

Question 1: How many synchronous meetings per week does your team attend, and how many of them could have been a written update? If you can’t name which ones, your management is probably too synchronous for async developers.

Question 2: When a developer is heads-down in focus work and not Slacking, what’s your instinct? Do you trust they’re working, or do you feel anxious? If you feel anxious, async management will be hard for you.

Question 3: How do you give feedback? In meetings, or in writing? If it’s mostly meetings, your new manager will struggle giving written feedback.

Question 4: Do you have clear, written goals for your team, or do developers understand goals through conversation and culture osmosis? If it’s osmosis, your new manager won’t be able to lead async developers who need explicit clarity.

Question 5: When someone’s underperforming, how do you notice? Through real-time signals (they’re quiet on Slack, not in meetings) or through measurable output (their work quality dropped)? If it’s real-time signals, you’re managing presence, not performance.

If your answers skew synchronous, your next manager hire - especially one managing nearshore developers - is going to struggle.

Getting Your Manager Ready

If you’ve already promoted someone and they’re struggling, here’s where to start:

This week: Sit down with them and explicitly name what’s different. Being a great IC and being a great async manager are different skills. This isn’t a performance problem - it’s a skill gap, and it’s fixable.

Week one: Redesign their 1:1 structure. Move to weekly async check-ins in a shared doc. Give it a month. Watch what changes.

Week two: Audit their meeting load. Cut every sync meeting that doesn’t require live conversation. Ask of each one, “does this actually need to be live?” You’ll likely cut more than you expect.

Month one: Build a written feedback culture. Every code review should be thorough and written. Every performance conversation should happen in writing first, then discussed if needed. Show your manager examples from async-first companies (GitLab, Zapier, Basecamp publish their standards).

Month two: Give them a proxy for measuring success that doesn’t depend on presence. Track shipped work, code quality, goal progress, and developer feedback. That’s your management dashboard, not Slack activity.

Why This Is a Hidden Competitive Advantage

Here’s what most companies don’t realize:

Managers who do well in async-first cultures can’t hide behind meetings and presence. They have to measure actual output, give clear feedback, set explicit goals, and trust their team. That’s harder, and usually more effective.

It has costs, too. Written-first management is slower for ambiguous problems, for new hires who haven’t built context yet, and for anything emotional. Some teams will want more live time than this article suggests, and that’s fine.

If you’re planning a nearshore hire, start with the audit above and pick the one answer that skews most synchronous. If you’d like to talk it through, book a discovery call.