Engineering Leadership in Remote-First Indian Startups

What Nine Years in Distributed Teams Taught Me

I have led engineering teams ranging from 4 to 35 people, always distributed, always in the pressure of a startup. The lessons that actually stuck are not from books on management — they are from the failures.

Hire for Ownership, Not Skill Alone

The most common hiring mistake I made early was optimizing for technical skill above everything else. A brilliant engineer who needs to be told what to do next is a net negative on a small team. The question I now weight most heavily is not "can you solve this problem?" but "what did you do when a problem you were not assigned to own was about to cause an incident?"

Ownership is not about working extra hours — it is about the absence of learned helplessness. Engineers who own outcomes find their own blockers, escalate early, and close the loop without reminders. No amount of technical skill compensates for its absence on a distributed team.

Async-First Is Not Remote-First

Remote-first means you allow people to work remotely. Async-first means you design the system of work so the default mode of communication does not require real-time presence. These are different things, and confusing them is why most remote teams are exhausted.

Async-first requires investment: well-written RFCs and decision documents, video walkthroughs for complex PRs, explicit decision logs. The payoff is that engineers in Bangalore, Amsterdam, and Buenos Aires can all do their best work in their own time zones — without 11pm video calls.

Velocity Is a Lagging Indicator

The leading indicators I watch: incident rate and MTTR (code quality), review queue depth (collaboration health), and product metric impact per engineering week (alignment). When all three are healthy, velocity follows. When velocity drops, I look at these three first — not at process or tooling.

Why You Should Write More

The highest-leverage activity I have found as an engineering leader is writing. Clear, well-reasoned documents multiply your thinking across the team. A well-written RFC prevents three architecture arguments and two mis-implemented features. The teams I have seen compound fastest have the highest ratio of clear written thought to meetings.