Tech Leader in India: Lessons From 14 Years of Building Teams
Quick answer: Tech leadership in an Indian startup is not a bigger version of being a good developer. It means building psychological safety into your team on purpose, in a culture that defaults to hierarchy; staying useful to a distributed team instead of a co-located one; and knowing exactly when to put the keyboard down. The leaders who last treat all of this as core engineering work, not a side quest for HR. I am still learning this myself.
I have spent 14 years inside Indian engineering teams, most of it in Kerala rather than Bangalore or Gurugram. I started as a PHP developer in 2012. I was not confident about my interview in Acodez. Rithesh (founder of Acodez) interviewed me. Also attending that interview were Jamsheer (Tech head of Acowebs, director of Acodez), Arabind (CEO of hexeam software solutions), and Ijas(Snr WP Developer in Virtina). I sat there thinking these people are too good. I had zero idea about web development.
Somehow Jamsheer and I got the opportunity. Jamsheer became my first guru. He taught me how to inspect in a browser. It sounds small, but for a fresher with zero web development experience 14 years ago, that moment changed everything.
Years later, I moved through senior developer, team lead, technical project manager, and program manager at Acodez. I now manage a WooCommerce and Shopify product line at Acowebs and co-found visibility.so. Somewhere in that path the job stopped being “write good code” and became “build the conditions where other people can.”
This is what I have learned about what that actually takes, in this market, right now. I am still learning it.
The Job Changes Faster Than the Title Does
Most tech leader advice assumes a static role. In an Indian startup, the job mutates under you every 12-18 months, usually tied to funding stage.
At seed stage, you are the builder-in-chief. Nobody cares about your roadmap process. They care whether the product exists by Friday.
At Series A, you become the architect. You are hiring your first 5-10 engineers, and every technical decision you make now is a decision the next 50 people will inherit.
At Series B and beyond, you become a manager of managers. Your best individual contribution stops being code and starts being the org chart, the hiring bar, and the two or three decisions per quarter that actually matter.
The mistake I see most often is a leader who is excellent at stage one and refuses to grow into stage two – or a leader who skips straight to manager behavior before the team is big enough to need it.
Five Realities of Leading Engineering Teams in India Right Now
1. Hierarchy Is Inherited. Psychological Safety Is Not.
Most engineers on Indian teams grew up in schools and companies where you do not correct someone senior to you in a meeting. That instinct does not disappear because you called yourself a flat organization in the onboarding deck.
If you want juniors to say “I think this design has a bug” out loud, you have to build that explicitly. It will not happen by default, and it will not happen fast.
I learned this watching managers like Roopesh, Douglas DSilva, Suresh, Nalin, and Sajeev. They shaped how I think about leadership – not by telling me, but by showing me how to create space for people to speak up.
2. Your Team Is Distributed by Default
Even in-office Indian startups today are functionally distributed. One hub in Bangalore, a few engineers in Kerala or Pune, a founder who travels. Leading a distributed team is not a pandemic-era skill you can retire. It is the baseline.
Written decisions, async-first reviews, and documentation that survives a bad Zoom connection are not nice-to-haves. They are how anything ships at all.
3. Retention Is a Leadership Skill, Not an HR Problem
India’s engineering talent market moves faster than almost anywhere else. A strong engineer gets three inbound messages a week.
If you treat attrition as something recruiting handles, you will keep losing people the week after they get promoted. The thing that actually retains senior engineers – visible ownership, a real growth path, and work that is not busywork – is a leadership decision, not a compensation band.
4. Letting Go of the Keyboard Is a Deliberate Choice
I still write code. Not because I have to, but because staying close enough to the codebase to ask a sharp question in review is part of how I keep the team’s trust. The skill is not “stop coding.” It is knowing which 10% of hands-on work keeps you credible and cutting the other 90% ruthlessly.
5. You Are Building for Scale You Do Not Have Yet
Indian startups are frequently building for a 10x larger team and customer base than the one they have today. The funding and hiring cycles move fast once they move at all. That means the tech debt conversation is not “should we ever pay this down.” It is “which shortcuts are cheap to reverse later, and which ones we will regret in fourteen months.”
What Indian Tech Leaders Get Wrong
Confusing seniority with authority
Being the most technically capable person in the room does not automatically make you the right person to decide the roadmap, the hiring bar, or who gets promoted. I have seen this mistake more times than I can count, and I have made it myself.
Copy-pasting a Silicon Valley playbook wholesale
Flat hierarchies, no-meetings culture, and radical candor all sound great in a blog post written for a Bay Area team with ten years of psychological safety already baked in. Import the principle, not the exact mechanic. Adapt it to a team that is still building trust in hierarchy-shaped ways.
Treating tier-2 city hiring as a cost hack
Hiring in Kochi, Indore, or Coimbatore is not just cheaper than Bangalore. It is often better retention, because you are not competing with fifteen other startups for the same 500 engineers. Treat it as a talent strategy, not a budget line.
Avoiding the pressure conversation
Leaders under-communicate about hard weeks because they think showing pressure looks like weakness. It does not. Hiding it does.
What I Learned From the People Around Me
I did not learn leadership from books or courses. I learned it from the people I worked with.
From Jamsheer, I learned what quiet competence looks like. He keeps a low profile, but he is incredibly talented and sharp. When he points something out, it is always precise and worth listening to. He taught me how to inspect in a browser 14 years ago, and that moment set the standard for how I think about teaching others – patient, precise, and never making the other person feel small for not knowing.
From managers like Roopesh, Douglas DSilva, Suresh, Nalin, and Sajeev, I learned how to run teams, think about business, and lead with patience.
From colleagues like Krishnankutty, Rajeesh, Monisha, Sanesh, Nikhil, Rishitha, and Ashique and many more, I learned different ways of seeing problems and solving them.
From teammates who joined after me – Farhan, Ilyasy, Nitheesh, Vishnu, Tulasinath, Kiran etc – I learned how younger engineers view problems differently. They taught me that experience is not always the answer. Sometimes fresh perspective solves what experience overcomplicates.
From Rithesh, I learned how to lead without making people feel wrong. If someone said something off in a meeting, he would never say “that is incorrect.” He would say “you might be right, but why don’t you think about it this way?” You never felt bad. But you walked out of the room thinking differently. That is a skill I am still trying to master.
From John, I learned the opposite side of the same coin. He is straight to the point, never beats around the bush, and takes hard decisions when they need to be taken. No butter, no cushion. Just clarity.
Together, they are a better combination than either one alone. Rithesh makes people feel safe enough to stay. John makes sure the hard things get said. I try to keep both voices in my head when I make decisions today.
And from both of them, I learned what it looks like to build a company that creates space for people to grow from nervous freshers into co-founders.
I am currently taking the 1752 GTM course. Topics like ICP, buyer persona, funnels, metrics, objection handling, PLG, retention, and fundraising. Fifteen years into my career and I am still a student. That is the point. The day you stop learning from everyone around you – seniors, peers, juniors, courses – is the day you stop leading.
A Working Framework for Growing Into the Role
If you are an engineer in India wondering whether you are ready to lead, this is roughly the checklist I use when I am deciding whether someone is ready for the next step:
- Can they explain a technical tradeoff to a non-technical stakeholder in under two minutes?
- Have they given feedback that changed someone’s behavior, not just their code?
- Do people bring them bad news early, or do they find out late?
- Can they name the one thing they would cut if the team lost half its headcount tomorrow?
- Do they write things down without being asked?
If most of these are yes, the title is a formality. If most are no, more IC seniority will not fix it. Only practice with the actual leadership reps will.
Frequently Asked Questions
What does it take to become a tech leader in an Indian startup?
Technical credibility gets you considered. It does not get the job done. What takes you there is the ability to set direction under ambiguity, retain talent in a hot market, and build psychological safety in a culture that does not hand it to you by default.
Do you need to keep coding as a tech leader in India?
Not full-time. But staying close enough to review code and ask a sharp question keeps your credibility with the team intact. Cut the 90% of hands-on work that does not build trust. Keep the 10% that does.
How is tech leadership in India different from the US or Europe?
The core skills are the same. What is different is the starting conditions: inherited hierarchy instead of assumed flatness, a hotter and faster-moving talent market, and teams that are distributed across metros and tier-2 cities by default rather than by exception.
How long does it take to become a tech lead in an Indian startup?
There is no fixed timeline. The pattern I have seen is roughly 5-7 years as a strong individual contributor, then 3-5 years learning technical program management, then a jump into a leadership title once you are already doing most of the job informally.
Should tech leaders in India be based in a major metro?
Increasingly, it does not matter where you sit. It matters whether your team is set up for async, written-first communication. I have led teams from Kerala for years without it being a disadvantage.
Found this useful? Share it with someone wondering whether they are ready to lead. Follow @sanjayshankarr for more on engineering leadership and building in India.