Leading a Remote AI Team: Lessons from 4 Years and 14 Engineers
What I learned managing a fully-remote AI engineering team across 5 time zones. Hiring, async culture, on-call rotations, technical reviews, and the soft skills that matter more than the framework wars.
The Setup
At Hureka I've led a fully-remote AI engineering team spanning India, Canada, the US, and Tanzania. Different time zones, different cultures, different work styles. Here's what 4 years and 14 hires have taught me.
Hire for Curiosity, Not Frameworks
Frameworks change every 18 months. Curiosity doesn't. In interviews I now ask: "Tell me about the last time you debugged something for more than 6 hours. What kept you going?"
If the answer is "I gave up and asked someone," that's fine — but a good engineer eventually pulls a thread until it unravels.
Async-First, Sync-When-Needed
The default is async. Sync meetings have to earn their slot.
| Async (default) | Sync (when needed) |
|---|---|
| Design docs | Hard architectural disagreements |
| Code review | New-hire onboarding |
| Daily updates | Crisis response |
| Status reports | Career conversations |
A 1-hour meeting with 6 people is 6 person-hours. A well-written 5-minute design doc that takes 30 minutes to write saves all of that.
Document Decisions, Not Just Code
Every meaningful architectural decision becomes an ADR (Architecture Decision Record):
# ADR-042: Use Qdrant for vector storageStatus Accepted (2026-02-15)
Context We need to store and search 50M+ embeddings across multi-tenant workloads...
Decision We use Qdrant self-hosted with scalar quantization.
Consequences + 4× memory efficiency vs raw vectors + Sub-30ms p95 latency at our scale - Additional service to operate - Team needs to learn Qdrant-specific tuning ```
Six months later, when someone asks "Why are we using Qdrant?", the answer is one click away.
On-Call That Doesn't Burn People Out
- Max 1 week on-call per engineer per 6 weeks
- Follow-the-sun: engineer on-call is always in working hours
- Every page after on-call generates a postmortem and a follow-up to prevent recurrence
- "Quiet weeks" (no pages) are celebrated, not feared
Code Review as Teaching
- Praise something specific
- Ask before suggesting ("What were you thinking with X?" not "X is wrong because Y")
- Reject only at the architectural level — let style debates die
- Approve quickly when small things are good
The Hardest Lesson
The technical work is the easy part. The hard part is noticing when an engineer is struggling, frustrated, or quietly looking elsewhere. Remote work hides those signals.
Weekly 1:1s — protected, never canceled — are the single most important meeting I have. Half are about engineering. Half are about life.
Boring Infrastructure Wins
- Update dependencies
- Improve CI
- Refactor that ugly module
- Write the test you keep meaning to
Teams that do this stay healthy. Teams that don't drown in tech debt within 2 years.